Patent ID: 12222961

In one or more implementations, not all of the depicted components in each figure may be required, and one or more implementations may include additional components not shown in a figure. Variations in the arrangement and type of the components may be made without departing from the scope of the subject disclosure. Additional components, different components, or fewer components may be utilized within the scope of the subject disclosure.

DETAILED DESCRIPTION

The detailed description set forth below is intended as a description of various implementations and is not intended to represent the only implementations in which the subject technology may be practiced. As those skilled in the art would realize, the described implementations may be modified in various different ways, all without departing from the scope of the present disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive.

The platform of the system100may automatically create and dynamically update (e.g., maintain) capitalization tables of assets underlying tokens exchanged on the platform, thereby addressing a long-standing pain point in businesses having investors for whom such capitalization tables must be manually created and revised whenever ownership changes occur. The automatic creation and live syncing maintenance of capitalization tables may facilitate their being continually up to date, complete, verified, and audit-ready (e.g., dynamically updated). For example, the platform of the system100may provide owners with a list of new investors in a tokenized asset based on the updated capitalization table, reflecting every buyer of the investors' tokens representing an interest in the underlying asset. The platform may also provide value to the transfer side via improved efficiency and the reduction of manual pain points in their business. The ease and simplicity with which the systems and methods of the platform described herein may be applied in practice may provide compelling inducements for industries traditionally slow to adopt new technology, e.g., commercial real estate, to adopt the technology disclosed herein for facilitating transaction processing for the benefit of buyers and sellers of digital assets representing fractional ownership in underlying assets, via the platform of the system100, sponsors of investments in assets and/or owners of assets (e.g., real estate) may provide access to investments in such assets which may have previously been unavailable, for example, due to securities regulations and/or rules defining sophisticated and accredited investors. Retail investors and buyers of assets have traditionally been locked out of participating in commercial real estate investments because they lack the minimum investment threshold and/or do not have sufficient qualifications as traditional investors to acquire an interest in an asset from a Seller of the interest in the asset. The platform of the system100may establish a secondary exchange via which the asset tokens are exchanged in secondary trades, following any holding periods following the primary issuance of securities underlying the asset tokens as may be required by securities regulations (e.g., Rule144), so the restrictions of the securities regulations pertaining to qualifications of the investors may not apply to the contemplated exchange of asset tokens. For example, the platform of the system100may unlock real estate investment opportunities for retail buyers, not only facilitating retail buyers to capture return on investment, but also to take advantage of potential tax savings, for example, via write-offs of depreciation of the underlying assets on tax returns. The disclosed technology platform that can create digital securities out of what are known as “real assets” and can function as a secondary market platform or Financial Exchange for these types of assets as well as for other types of assets such as, but not limited to, investments in franchises, investments in business that generate dividends or returns based on performance of the business or underlying asset, investments in ventures that capture or mine natural resource such as, but not limited to uranium, timber, and other commodities, private credit, private debt, intangible assets, tradeable assets, and any other types of appropriate assets.

FIG.1is a block diagram illustrating an exemplary technological system100including a transaction platform having semi-redundant ledgers, such as primary ledger102and secondary ledger104. An owner112, a seller114, and a buyer116may each include computing and communication systems (e.g, an owner device, a seller device, and a buyer device, respectively) corresponding to and/or representing users interfacing with the system100. The owner112may be an owner of an asset listed on the transaction platform and/or a sponsor of investments in an asset listed on the transaction platform, and may also be referred to as an asset owner or a property owner. The seller114may represent one who is selling or listing an asset as available for sale or exchange, e.g., available to be transferred to another user in exchange for something else (e.g., tokens, currency, etc.). The seller114may also be referred to as a seller when participating in a buy-sell transaction, for example. The buyer116may represent one who is seeking to purchase, buy, or acquire at least a partial interest in an asset which is listed (e.g., as available for sale or exchange) on the transaction platform. The buyer116may also be referred to as a buyer when participating in a buy-sell transaction, for example. The system100may perform verification of identification and related information for each of the users of the system100(e.g., including owner112, seller114, and/or buyer116) via an online identity verification process, for example, a know your customer (KYC) verification process for an individual user, a know your business (KYB) verification process for any business entity, such as, but not limited to, limited liability company (LLC), C corporation, S corporation, and other appropriate business entities, and/or an anti-money laundering (AML) verification process. Each user of the system100may communicatively couple an electronic and/or computer-networked funding source and/or recipients of funds (e.g., financial institution account, bank account, credit union account, investment account, cryptocurrency account, digital wallet, and/or other provider or recipient of digital representations of currency and/or digital assets associated with a transaction processed by the transaction platform) to the system100. Digital assets may include, but is not limited to, cryptocurrencies, crypto tokens, crypto coins, security token, asset tokens, non-fungible tokens (NFTs), fungible tokens, and/or other appropriate forms of digital assets. The electronic and/or computer-networked funding source and/or recipients of funds may include a computing system of one or more third-party accounts of users of the system100. Sending and/or distributing fees and/or funds, receiving and/or collecting fees and/or funds, and exchanging assets for fees and/or funds as described herein may merely be illustrative examples of the technological systems and methods described herein which may be applied in addressing challenges in a variety of other contexts and applications, also. For example, the technological systems and methods described herein may provide novel systems and methods for transmitting and/or receiving transmissions of various types of digital content (e.g., digital bits and/or bytes storable in a computer-readable memory of the system100) over a computing communication system associated with the system100. In various non-limiting examples, including those described herein, the digital content transmitted and/or received by components of the systems and methods described herein may include digital representations of currency, cryptocurrency, NFTs, and/or digital assets such as written works, artwork, photographs, audio/video programs, music, digital blueprints, computer-aided design (CAD) files representing physical articles of manufacture, architectural designs, plats of survey, deeds to real property, stock and/or membership interests in business entities, executed contracts, ownership and/or membership interests in timeshare properties, co-op properties, travel/vacation clubs, recreational clubs, social clubs, etc. Additional examples of content could be valuation estimates, third party appraisals, proof of purchases, copies of insurance policies, profit and loss data, calendars and schedules, and performance data.

The transaction platform may include the primary ledger102, a transfer agent106, backend servers132, and a website134. While the primary ledger102and the transfer agent106are depicted as separate, it should be understood that, in certain aspects, the primary ledger102and the transfer agent106are included within the same service. The users may interact with the website134via a web browser app executing on the owner112, the seller114, and the buyer116, all of which can be, but is not limited to, a desktop computer, laptop computer, tablet computer, personal digital assistant (PDA), cell phone, mobile phone, smart phone, and/or other computing devices including mobile devices. The transaction platform may be communicatively coupled with a transaction ATS broker/dealer module130, a pricing oracle 136, and a secondary ledger104. While, in some aspects, the primary ledger102is described as being centralized and the secondary ledger104as being decentralized, it should be understood that the primary ledger102could be decentralized. The primary ledger102and/or the secondary ledger104may be implemented with blockchain technology. The primary ledger102and secondary ledger104may be private or public. The primary ledger102and the secondary ledger104may include multiple copies of ledgers maintained on different computing nodes of computing networks implementing and/or supporting one or more public blockchain protocols, for example, but not limited to, Ethereum, Bitcoin, Binance Smart Chain (BSC), Cardano, Polkadot, Solana, Chainlink, Cosmos, TRON, HIVE, Polygon (Matic Network), and more.

In certain aspects, the primary ledger102can store all user personally identifiable information (PII) utilized by the system100, as well as a capitalization table (also referred to as a cap table) that maintains the status of platform assets and transactions, including the capitalization of each asset (e.g., real property) listed on the platform (e.g., listed as available for transactions on the platform). The primary ledger102may be implemented as a Structured Query Language (SQL) database, for example. In certain aspects, the primary ledger102can be maintained by the transfer agent106. The function of the transfer agent106may be unregulated. The transfer agent106may record transactions in the primary ledger102. The transfer agent106may synchronize the primary ledger102and the secondary ledger104. The transfer agent106may act as a gatekeeper and share information regarding transactions on the primary ledger102and/or the secondary ledger104only with authorized users and/or the transaction ATS broker/dealer module130.

The transaction ATS broker/dealer module130may include computing and communication systems corresponding to and/or representing a registered broker, registered dealer, registered broker/dealer licensed by the US Securities and Exchange Commission, the Financial Industry Regulatory Agency (FINRA), other domestic/international regulatory or governmental agencies, and/or similar roles in various exemplary applications and/or jurisdictions in which the system100is utilized. The transaction ATS broker/dealer module130may interface with the system100to provide associated broker/dealer functionality on the transaction platform of the system100. Functionality provided by the transaction ATS broker/dealer module130may be separate from functionality provided by other modules of the transaction platform, for example, due to regulatory requirements including those promulgated by the Financial Industry Regulatory Authority (FINRA). The transaction ATS broker/dealer module130may include an Alternative Trading System (ATS) and implementations (e.g., software, firmware, programmable logic arrays, electronic circuitry, etc.) of FINRA-compliant processes and methods for facilitating the transactions processed by the transaction platform as approved and licensed by FINRA. Functionality provided by the transaction ATS broker/dealer module130may be implemented in a virtual private cloud separate from other modules of the transaction platform. Firewalls may be established for the transaction ATS broker/dealer module130to be separate from and/or on a separate web services instance than other modules of the transaction platform. The transaction ATS broker/dealer module130may provide functionality to introduce buyers116and sellers114to each other, to generate smart contracts, to settle transactions facilitated by the transaction platform, distribute fees associated with the transactions facilitated by the transaction platform to appropriate participants in the system100, and/or to act as a gatekeeper of transactions facilitated by the transaction platform. Smart contracts are digital contracts that automatically execute, control or document events and actions according to the terms of a contract or an agreement. Fees generated from activities on the transaction platform during an acquisition/transfer transaction (e.g., buy-sell transaction, acquisition transaction, merger transaction, etc.) may be collected and/or distributed by the transaction ATS broker/dealer module130, for example, according to rules, agreements, and/or smart contracts associated with the transaction facilitated by the transaction platform. Fees generated from activities and/or participants of the system100outside the transaction ATS broker/dealer module130(e.g., from other participants of the transaction platform and/or any third-party system that is not included in the transaction platform of the system100) may be processed and collected by the transaction platform.

The transaction ATS broker/dealer module130may request payment of fees (e.g., fees associated with a transaction facilitated by the transaction platform of the system100) via third-party custody account(s) of the buyer116. The transaction ATS broker/dealer module130may deduct funds sufficient to cover the fees from proceeds of the transaction to pay seller fees (e.g., fees payable to the seller114) as stipulated by and/or agreed to by the seller114in a smart contract associated with the transaction as part of a process of listing a token as available for an exchange transaction facilitated by the transaction platform. A computing system of the third-party custody account(s) may send funds to cover the fees to the transaction ATS broker/dealer module130at which time the transaction ATS broker/dealer module130may keep the funds covering the fees. The transaction ATS broker/dealer module130may disburse funds covering a licensing fee for the transaction platform to one or more entities due those fees. The transaction ATS broker/dealer module130may disburse funds covering a partnership fee to the transfer agent106. The transaction ATS broker/dealer module130may generate and/or distribute a final settlement statement to the buyer116and seller114. In the event of any errors, omissions, glitches, or problems associated with the transaction processed by the transaction platform, the transaction ATS broker/dealer module130may notify a designated third party of the event for appropriate remediation. The transaction ATS broker/dealer module130may include one or more maintenance and support modules via which remediation, updates, upgrades, and/or support may be provided via a third-party computing system communicatively coupled with the transaction ATS broker/dealer module130.

The pricing oracle 136 may include a third-party service that connects smart contracts in the transaction platform of the system100with third-party entities and third-party systems outside of the system100. The pricing oracle 136 may provide a user of the system100with an estimate of the current value of an asset. The pricing oracle 136 may facilitate calculations and computations based on the estimate as directed by the user. The user may modify inputs to the pricing oracle 136 to utilize the pricing oracle 136 for determining the user's own market pricing estimates. For example, the buyer116may modify inputs to the pricing oracle 136 to utilize the pricing oracle 136 for estimating a future value of their investment in an asset and determining an amount of funds the buyer116may agree to exchange for the asset on a given day. The seller114may transmit information indicating agreement with pricing data provided by the pricing oracle 136, or the seller114may transmit information that overrides the pricing data provided by the pricing oracle 136. For example, in the context of commercial real estate assets, the pricing oracle 136 may include a digital broker opinion of value (BOV).

In an example, an owner112(e.g., real estate property owner) may authenticate with the system100according to KYB KYC AML118protocols and methodologies. The owner112may link a bank account140and a currency custody module142to the system100. The currency custody module142may serve as a custodian for the owner112's currency on the system100. The currency custody module142may be configured to hold fiat currency, for example, US dollars ($) or other forms of fiat currency. A platform digital wallet custody module144may serve as a custodian for the owner112's digital assets on the system100.

In the example, a seller114may authenticate with the system100according to KYB KYC AML120protocols and methodologies. In some examples, the owner112and the seller114may be the same individual or entity playing the different roles in a transaction, while in other examples, the owner112and the seller114may be different individuals or entities, for example, if the seller114is a broker or agent engaged by the owner112to list and/or transfer the property on the transaction platform of the system100on their behalf. The seller114may link a bank account148and a currency custody module150to system100. The currency custody module150may serve as a custodian for the seller114's fiat currency on the system100. A digital wallet custody module157may serve as a custodian for the seller114's digital assets on the system100. These digital assets may include cryptocurrency, e.g., USDC tokens and any other crypto currencies. The digital wallet custody module157may authenticate with the system100according to wallet KYC159protocols and methodologies. The digital wallet custody module157may also include functionality and/or an interface to convert or exchange the digital currency held thereby into fiat currency for the benefit of the seller114. Conversions or exchanges of the cryptocurrency held by the digital wallet custody module157to fiat currency may be documented by a transaction entry in the primary ledger102and the secondary ledger104. A platform digital wallet custody module152may serve as a custodian for the seller114's digital assets on the system100, including the digital assets which the seller114transfers on behalf of a separate owner (e.g., via a broker or agency relationship) and the digital assets which the seller114transfers on its own behalf as also owner112of the digital assets.

An asset tokenization module108may generate one or more digital assets representing an asset and/or a value of an asset, for example, a real estate property owned by the owner112, and store the generated digital assets in an asset wallet custody module146. The asset wallet custody module146may transmit data to the primary ledger102and the secondary ledger104for recording the generation of the digital assets on the secondary ledger104. The asset wallet custody module146may transmit the digital assets to the owner112's platform digital wallet custody module144and provide data to the transfer agent106to record in the primary ledger102regarding the creation and/or transfer of the digital assets generated by the asset tokenization module108. The asset wallet custody module146may transmit an invitation to the seller114to claim the digital assets generated by the asset tokenization module108. When the seller114claims or retrieves its associated portion of the digital assets generated by the asset tokenization module108that is stored in the asset wallet custody module146, for example, if the seller114is going to trade its associated portion of the digital assets generated by the asset tokenization module108on the system100, then the asset wallet custody module146may transmit the digital assets to the seller114's platform digital wallet custody module152and transmit information regarding the transfer to the transfer agent106for recording on the primary ledger102. In certain other aspects, instead of transmitting an invitation to the seller114, the asset wallet custody module146can transmit the digital assets generated by the asset tokenization module108directly to the seller114's asset wallet custody module146.

In an example, a buyer116may authenticate with the system100according to KYB KYC AML122protocols and methodologies. The buyer116may link a bank account154and a currency custody module156to the system100. The currency custody module156may serve as a custodian for the buyer116's fiat currency on the system100. A digital wallet custody module158may serve as a custodian for the buyer116's digital assets on the system100. These digital assets may include cryptocurrency, e.g., USDC tokens and any other crypto currencies. The digital wallet custody module158may authenticate with the system100according to wallet KYC160protocols and methodologies. The digital wallet custody module158may also include functionality and/or an interface to convert or exchange the digital currency held thereby into fiat currency for the benefit of the buyer116. Conversions or exchanges of the cryptocurrency held by the digital wallet custody module158to fiat currency may be documented by a transaction entry in the secondary ledger104. A platform digital wallet custody module162may serve as a custodian for the buyer116's digital assets on the system100, for example, shares in tokenized assets generated by the asset tokenization module108.

In an example, the buyer116may see that the seller114has listed its associated portion the digital assets generated by the asset tokenization module108that is stored in the asset wallet custody module146represented by one or more digital assets on the website134and engages in a transaction processed by the system100to exchange currency via the currency custody module156and/or digital assets via the digital wallet custody module158for digital assets generated by the asset tokenization module108representing the asset in which the buyer116is interested. The seller114may receive currency and/or digital assets from the buyer116's currency custody module156and/or digital wallet custody module158, while the buyer116may receive digital assets, representing the asset from the seller114's platform digital wallet custody module152, into the buyer116's platform digital wallet custody module162. Data regarding the transfer may be transmitted to the transfer agent106for recording on the primary ledger102as well as on the secondary ledger104.

FIG.2illustrates an exemplary process200for tokenization of an asset, according to some embodiments of the disclosed technology. There are two types of participants in the process200. One is an owner, (e.g., an asset holder), such as the owner112, who may also be referred to as a sponsor or general partner (GP). The other is an investor, also referred to as a limited partner (LP). The investor may be a current investor in the asset or an investor who wants to invest in the asset. The investor may also be referred to as the buyer, such as the buyer116.

Initially (e.g., at or prior to “START”), the participants (e.g., users) may be onboarded with the system100as discussed with reference toFIG.1, and the process200that the participants undergo to become onboarded with the system100is described in detail below. For example, the owner (e.g., may be GP) may undergo a KYB process and a KYC account for the owner112may be created with the system100(operation202). The owner112may approve sale of the asset using the system100(operation204) to generate a smart contract memorializing agreement to sell and list. After the owner112agrees to tokenize an asset (operation206), the system100may tokenize the asset as security tokens (operation208), for example, or as other digital assets including, but is not limited to, nonfungible tokens (NFTs), fungible tokens, hybrid tokens, cryptocurrencies, crypto tokens, crypto coins, security token, and asset tokens, having metadata including identification information of the buyer of the NFTs. The security tokens may include, for example, ERC1400tokens. The security tokens may be fungible tokens or non-fungible tokens, which are unique and differentiated from other tokens representing a share of value in the asset, and may store associated meta data. In various examples, other digital asset types may be used. The security tokens created may include tokens designated as being owned by the GP and tokens owned by each of the investors or LPs who also hold an interest in the asset.

In the example ofFIG.2, an asset having a net value of $1,000,000 may be tokenized as 1,000 tokens, each token having a value of $1,000. In this example, the net value of the asset may be taken into account any debt by which the asset is burdened. In other words, an asset having a market value of $2,000,000, and a mortgage securing a debt of $1,000,000 recorded as a lien against the asset, may have a net value of $1,000,000. An asset having a market value of $1,000,000, and no debt against the asset, may have a net value of $1,000,000.

These tokens may be sent by the transfer agent106to a platform digital wallet, such as the platform digital wallet custody module152, created for the asset (operation210), and the capitalization table for the asset may be updated by the transfer agent106to reflect moving the tokens (operation224). An identification number (ID) identifying the unique tokens may be included in the capitalization table along with the token's owner or investor's identification information. The platform digital wallet may be held by the system100or a third party.

The system100may invite the GP to claim the tokens (operation212). When the GP claims the tokens, they may be moved from the platform wallet to the GP's digital wallet (operation214), and the capitalization table may be updated to reflect the move (operation224). The tokens claimed by the GP are only the GP's tokens, not investors' (LP's) tokens. The GP may then invite the investors (LPs) to claim their tokens (operation216). Once the LPs claim their tokens, the LPs may be free to conduct transactions on the system100using the tokens, for example, transferring their tokens or exchanging their tokens for other items of value, for example, other tokens representing interests in other assets. If an LP who wishes to claim their tokens is not registered or onboarded onto the system100, the LP may undergo a KYC process to create an investor account with the platform on the system100(operation218) and create the LP's digital wallet (operation220). The LPs may then claim their tokens, which may then be moved from the platform asset digital wallet (which may have been holding the tokens since they were created in operation208) to the LP wallets (operation222), and the capitalization table may be updated to reflect the moves (operation224). For example, the capitalization table may associate the token identifiers (IDs) with the names of the LPs.

When the capitalization table is updated (operation224), the capitalization table may be updated in the primary ledger on the blockchain by the system100. The system100may also update the secondary ledger to match the primary ledger. PII about the GP or LPs may be withheld from and not stored in the secondary ledger. For example, instead of an LP name, the secondary ledger may associate token IDs with a hash value that is unique to the LP. In this manner, the blockchain transaction may be linked to the LP, while the LP may remain anonymous. The primary and secondary ledgers102,104may be correlated using a database within the platform of the system100.

FIG.3illustrates an exemplary process300for user (e.g., the owner112, the seller114, or the buyer116) onboarding and account creation, according to some embodiments of the disclosed technology. For a new user, e.g., the owner112, the seller114, or the buyer116, the platform of the system100may first perform a light account creation with the user's name, email address, and password (operation302). The platform may then verify the user's email address (operation304), for example, by emailing a verification link to the user's email address, which the user may click or follow to verify the user's email address with the platform.

After successful email verification, the platform of the system100may perform a level 1 account creation for the user (operation306). The level 1 account may provide limited access to the exchange, for example, authorizing the user to browse tokenized assets, but not to acquire or exchange the tokens created to represent the tokenized assets.

A user may gain level 2 access by successfully completing the KYB/KYC/AML process (operation308). The platform may create a level 2 access account for the user to provide the user with full exchange access (operation310), which may include all access of the level 1 access plus full access to the exchange, for example, authorizing the user to acquire and/or exchange tokens created to represent tokenized assets. Upon successful completion of the KYB/KYC/AML process, the platform of the system100may also create multiple digital wallets or financial holdings accounts for the user, for example: a digital security wallet to hold digital assets (operation312), a fiat account to hold fiat currency (operation314), and a digital currency wallet to hold cryptocurrency tokens (operation318). The user's digital currency wallet may receive and/or transmit cryptocurrency tokens from/to digital currency wallets and/or accounts off of the platform of the system100. The user may fund the user's fiat account, for example, via an ACH transfer or ACH exchange with a bank (operation316). The user may also transfer fiat currency from the user's fiat account on the platform of the system100to a bank external to the system100via an ACH transfer (operation316).

With reference to operation318, the level 2 account may facilitate the user (e.g., the buyer116) to acquire and exchange tokens on the platform of the system100. When the user (e.g., the buyer116) acquires an asset token from a seller114, funds may be transferred out of the user's (e.g., buyer's) fiat account (e.g., the currency custody module156) and/or the digital wallet custody module158to the seller's fiat account (e.g., the currency custody module150) and/or the digital wallet custody module157, respectively, and the asset token may be moved from the owner's or seller's digital wallet for security tokens (e.g., platform digital wallet custody module144and platform digital wallet custody module152, respectively) to the user's digital token wallet (e.g., platform digital wallet custody module162). When the user (e.g., the seller114) transfers an asset token to a buyer116, funds may be transferred into the user's fiat account (e.g., the seller114's currency custody module150) from the buyer's fiat account (e.g., the currency custody module156), and the asset token may be moved out of the user's token wallet (e.g., the seller114's platform digital wallet custody module152) and into the buyer's token wallet (e.g., the platform digital wallet custody module162). In certain aspects, the user's account(s) on the platform of the system100may earn dividends, and the earned dividends may be moved into the user's fiat account when in the form of fiat currency or into the user's digital currency wallet when in the form of a cryptocurrency. Note that on the platform of the system100, asset tokens may be purchased by and/or sold for any or a variety different forms of fiat currency and/or cryptocurrency, or combinations thereof. Likewise, in such aspects, the dividends may be earned and paid to a user's account in a variety different forms of fiat currency and/or cryptocurrency, or combinations thereof.

Some users may purchase asset tokens using cryptocurrency, as described in detail below. Such a user may first successfully complete a wallet know-your-transaction (KYT) process, such as a security process, and address screen (operation320) to ensure the authenticity and security of the user's existing cryptocurrency. The platform of the system100may then connect the digital currency wallet to an external cryptocurrency digital wallet for the user (operation322) based on determining that the authenticity and security are proper. The user may then transfer cryptocurrency from an off-platform digital wallet to the user's on-platform cryptocurrency digital wallet. In certain aspects, the security process is continually monitoring the digital currency wallet to determine proper authenticity and security.

When the user acquires an asset token on the platform of the system100using cryptocurrency, cryptocurrency may be transferred from the user's crypto wallet to the platform crypto wallet and the asset token may be moved to the user's token wallet. When the user transfers an asset token on the platform of the system100using cryptocurrency, cryptocurrency may be transferred into the user's crypto wallet from the platform crypto wallet and the asset token may be moved out of the user token wallet. In either case, the platform may settle the transaction with the counterparty, either in cryptocurrency or fiat currency.

FIG.4illustrates an exemplary process400for acquiring and transferring asset tokens on the transaction platform of the system100, according to some embodiments of the disclosed technology. A first investor (illustrated at block402), referred to herein as the “seller,” such as the seller114, holds an asset token in the seller's asset wallet (e.g., the platform digital wallet custody module152), as depicted at block432. The seller114requests (404) the asset token be listed for sale on the exchange, as illustrated at block408. In response, the platform informs the broker/dealer (at block416), such as the transaction ATS broker/dealer module130, which generates a corresponding seller smart contract, and sends that seller smart contract to the seller for acceptance (shown at406).

A second investor (depicted at block414), referred to herein as the “buyer,” such as the buyer116, agrees (at410) to acquire the asset token. In response, the platform informs the broker/dealer (at block416), which generates a corresponding buyer smart contract, and sends (at412) that buyer smart contract to the buyer (depicted at block414) for acceptance.

The broker/dealer (at block416) may perform a verification of funds available in the buyer's accounts, for example, to ensure that the buyer has a sufficiently high balance to complete the transaction. If not, the platform of the system100may send the buyer a request to add additional currency (e.g., fiat currency, cryptocurrency, tokens, and/or other digital representations of value offered to complete the transaction) to their platform account(s) being used to provide items of sufficient value in exchange for the acquisition. The platform of the system100may send a release request (at418) to the buyer's fiat account (block422), such as the currency custody module156, to transfer the required amount of fiat currency from the buyer's fiat account (block422) to the seller's fiat account (block423), such as the currency custody module150via currency transfers (424). The purchase price amount may be transferred from the buyer's fiat account to the seller's fiat account, minus a service fee (at420) associated with the acquisition. For example, if there was a purchase of $1000 and a fee of $50, there would be a transfer of $950 from the buyer's fiat account to the seller's fiat account, and a transfer of $50 from the buyer's fiat account to the broker dealer (at block416). A service fee may be transferred from the buyer's fiat account to the broker/dealer. On receipt of the required amount into the seller's fiat account (at block423), the platform may inform the broker/dealer.

Process steps may be taken to protect the token from being transferred to another other than the buyer during the process of the buyer acquiring the token, being delisted from the platform, or otherwise being tampered or interfered with during the process of the buyer acquiring the token. For example, at approximately the same time as the release request (at418) sent by the platform to the buyer's fiat account (at block422), a second release request (at434) may be sent to the seller's asset token wallet (at block432) to hold the asset token for the buyer. This process may protect the buyer's currency by ensuring the buyer receives the asset token in exchange for the currency transferred to the seller of the asset token, by preventing the seller from interrupting the transfer of the asset token once the seller has accepted the terms to transfer the asset token. On receipt of the agreed-upon amount of currency (e.g., fiat currency, cryptocurrency, etc.) into the seller's corresponding account, the platform of the system100may transmit a confirmation of receipt to the seller's asset token wallet. In response to receiving the confirmation of receipt of the currency, the seller's asset token wallet (at block432) may transfer (at436) the asset token to the buyer's asset token wallet (at block438), such as the platform digital wallet custody module162. Upon receipt of the asset token, the buyer's asset token wallet (at block438) may transmit (at440) confirmation of receipt of the asset token to the broker/dealer (at block416), thereby completing the transaction. The platform of the system100may update the capitalization table in the primary ledger, such as the primary ledger102(shown inFIG.1), to reflect the transaction, and update the secondary ledger, such as the secondary ledger104(shown inFIG.1), accordingly.

Although the acquire/transfer process has been described herein largely in terms of the exchange of fiat currency, either or both of the buyer and seller may use other digital representations of value (e.g., cryptocurrency or other digital tokens) instead of, or in addition to, fiat currency. The platform of the system100may perform any conversions (at454) between fiat currency, cryptocurrency, and/or other digital tokens as appropriate to facilitate and complete the transactions (444,446) on the transaction platform of the system100.

FIG.5illustrates an exemplary seller login and transaction flow500using the exemplary transaction platform of the system100. A seller114may register with and log into the system100and be authenticated as an authorized user of the system100according to KYB KYC AML120protocols and methodologies. The seller114may link a bank account148and a currency custody module150to system100. The currency custody module150may serve as a custodian for the seller114's fiat currency on the system100. A platform digital wallet custody module152may serve as a custodian for the seller114's digital assets on the system100. The seller114may receive, from the asset wallet custody module146, an invitation505to claim digital assets generated by the asset tokenization module108to represent investors' shares in an asset tokenized by the asset tokenization module108. An example of such an asset may include real property, e.g., commercial real estate. When the seller114claims the digital assets generated by the asset tokenization module108, for example, if the seller114is going to trade the digital crypto tokens generated by the asset tokenization module108on the system100, the asset wallet custody module146may transmit the digital assets to the seller114's platform digital wallet custody module152and transmit information regarding the transfer to the transfer agent106for recording on the primary ledger102as well as on the secondary ledger104without recording any PII thereon.

The seller114may then list510the asset and/or asset tokens on the transaction platform of the system100as being available for sale, purchase, exchange, investing in, transferring, or any other appropriate listing action. The seller114may list510the asset and/or asset tokens via the website134, for example, using the website134as an interface to the transaction platform of the system100to make the listing. The website134may include a list of assets and/or asset tokens that are available on the transaction platform, and the act of listing510the asset and/or asset tokens may include the listed asset and/or asset tokens in the website134's list of assets and/or asset tokens that are available on the transaction platform.

Responsive to the listing510of the asset and/or asset tokens via the website134, a sell order515may be generated by the website134, the backend servers132(which may host or control at least some aspects of the website134), and/or a combination of the website134and the backend servers132in conjunction with one another. The sell order may be an order to request creation of a smart contract (SC)525to facilitate a sale, purchase, exchange, investment in, transferring of, or similar type of disposition of the asset and/or asset tokens. In response to receiving the sell order515, the backend servers132may generate and transmit a sell SC request520to the transaction ATS broker/dealer module130to request the creation of the SC525between the transaction ATS broker/dealer module130and the seller114. The transaction ATS broker/dealer module130may establish the SC525with the seller114for the contemplated transaction involving the asset and/or asset tokens transferred to the platform digital wallet custody module152. The transaction ATS broker/dealer module130may record the smart contract (operation530) and update and/or validate the capitalization (cap) table (operation535) via the transfer agent106, for example, based on the SC525and/or the asset tokens transferred to the platform digital wallet custody module152by the asset wallet custody module146. The transfer agent106may include and/or utilize user PII of the seller114and/or the owner112in the update and/or validation of the cap table. The transfer agent106may maintain an up-to-date copy of the cap table and related user PII. The transfer agent106may update the cap table and/or related user PII based on input provided via the website134and routed to the transfer agent106via the backend servers132and/or transaction ATS broker/dealer module130. The transfer agent106records the smart contract525as well as entries pertaining to the contemplated and performed transactions involving the asset and/or asset tokens in both the primary ledger102and the secondary ledger104.

FIG.6illustrates an exemplary buyer login and transaction flow600using the exemplary transaction platform of the system100. A buyer116may register with and log into the system100and be authenticated as an authorized user of the system100according to KYB KYC AML122protocols and methodologies. The buyer116may link a bank account154and a currency custody module156to system100. The currency custody module156may serve as a custodian for the buyer116's fiat currency on the system100. A digital wallet custody module158may serve as a custodian for the buyer116's digital assets on the system100. These digital assets may include cryptocurrency, e.g., USDC tokens and/or other appropriate digital assets. The digital wallet custody module158may authenticate with the system100according to wallet KYC160protocols and methodologies. The digital wallet custody module158may also include functionality and/or an interface to convert or exchange the digital currency held thereby into fiat currency for the benefit of the buyer116, if desired. Conversions or exchanges of the cryptocurrency held by the digital wallet custody module158to fiat currency may be documented by a transaction entry in the both the primary ledger102and the secondary ledger104. A platform digital wallet custody module162may serve as a custodian for the buyer's asset tokens to be acquired on the system100by the buyer116.

The buyer116may view the listed asset and/or asset tokens on the transaction platform of the system100as being available for sale, purchase, exchange, investing in, transferring, or the like via the website134. Responsive to viewing the listing of the asset and/or asset tokens via the website134, the buyer116may make an offer to buy605the listed asset and/or asset tokens via the website134. Responsive to the buyer116's offer to buy605the listed asset and/or asset tokens, a buy order610may be generated by the website134, the backend servers132(which may host or control at least some aspects of the website134), and/or a combination of the website134and the backend servers132in conjunction with one another. The buy order610may be an order to request creation of a create a smart contract (SC)615to facilitate a sale, purchase, exchange, investment in, transferring of, or similar type of disposition of the asset and/or asset tokens. In response to receiving the buy order610, the backend servers132may generate and transmit a buy SC request620to the transaction ATS broker/dealer module130to request the creation of the SC615between the transaction ATS broker/dealer module130and the buyer116. The transaction ATS broker/dealer module130may establish the SC615with the buyer116for the contemplated transaction involving the asset and/or asset tokens transferred to the platform digital wallet custody module152.

The transaction ATS broker/dealer module130may perform on the SC615by transmitting message(s) instructing the digital wallet custody module158and the currency custody module156to release the buyer116's funds and/or tokens to be exchanged for the seller114's asset tokens while also transmitting message(s) instructing the platform digital wallet custody module152to release the seller114's asset tokens to be exchanged for the buyer116's funds and/or tokens (operation625). Responsive to receiving the message from the transaction ATS broker/dealer module130, the seller114's platform digital wallet custody module152may transmit the asset token(s) to the buyer116's platform digital wallet custody module162and/or currency custody module156may transmit trade proceeds630being exchanged for the asset token(s) to the seller114's currency custody module150per the terms of the smart contract615. The trade proceeds630may include cryptocurrency, cryptocurrency converted to fiat currency, and/or fiat currency. In certain aspects, the digital wallet custody module158may include or interface with a module configured to convert cryptocurrency (e.g., USDC) which may be held by the digital wallet custody module158into fiat currency acceptable by the seller114's currency custody module150. The digital wallet custody module158can, alternatively or additionally, transmit trade proceeds being exchanged for the asset token(s) that are held in crypto to the seller114's digital wallet custody module157. The secondary ledger104may create and store a blockchain entry corresponding to the transfer of the trade proceeds from the buyer116's currency custody module156and/or digital wallet custody module158to the seller114's currency custody module150and/or digital wallet custody module157, respectively. In certain aspects, the seller114may also have, included within or coupled with the system100, the digital wallet custody module157to receive and hold digital assets such as cryptocurrency in addition to or in place of fiat currency in exchange for asset tokens. In such aspects, the buyer116's digital wallet custody module158may not convert cryptocurrency funds into fiat currency when transmitting the trade proceeds630to the seller114's digital wallet custody module157. In certain aspects, the seller114's digital wallet custody module157can similarly include or interface with a module configured to convert cryptocurrency (e.g., USDC) which may be held by the digital wallet custody module157into fiat currency acceptable by the buyer116's currency custody module156. Responsive to receiving the message from the transaction ATS broker/dealer module130, the seller114's platform digital wallet custody module152may transmit the asset token(s)635to the buyer116's platform digital wallet custody module162per the terms of the smart contract615. The secondary ledger104may create and store a blockchain entry corresponding to the transfer of the asset token(s)635.

The transaction ATS broker/dealer module130may record the smart contract and transaction (operation640) and update and/or validate the capitalization (cap) table (operation645) via the transfer agent106, for example, based on the SC615, the trade proceeds transferred to the seller114's currency custody module150and/or digital wallet custody module (not shown), and/or the asset tokens635transferred to the buyer116's platform digital wallet custody module162by the seller114's platform digital wallet custody module152. The transfer agent106may include and/or utilize user PII of the buyer116, the seller114, and/or the owner112in the update and/or validation of the cap table. The transfer agent106may maintain an up-to-date copy of the cap table and related user PII. The transfer agent106may update the cap table and/or related user PII based on input provided via the website134and routed to the transfer agent106via the backend servers132and/or transaction ATS broker/dealer module130. The transfer agent106may also record entries pertaining to the contemplated and performed transactions involving the asset and/or asset tokens in the primary ledger102and/or secondary ledger104.

FIG.7illustrates an exemplary fee flow700using the exemplary transaction platform of the system100. As the trade proceeds are being transferred on the transaction platform of the system100as illustrated inFIGS.5-6, the transaction ATS broker/dealer module130transmits requests to buyer116's currency custody module156and/or digital wallet custody module158as well as to the seller114's currency custody module150and/or digital wallet custody module157to collect the transaction fees715for distribution. The transactions fees715can include, but is not limited to, licensing fees710distributed to the transaction ATS broker/dealer module130, partnership fees distributed to the transfer agent106, and other appropriate fees. The transaction ATS broker/dealer module130may then receive the transaction fees715associated with the transaction completed on the transaction platform of the system100from the buyer116's currency custody module156and/or digital wallet custody module158as well as to the seller114's currency custody module150and/or digital wallet custody module157. The transaction fees715may be payable and funded via fiat currency and/or cryptocurrency, for example, as described above. In some examples, the transaction fees715may be payable and funded by other digital assets, for example, NFTs. Moreover, transaction ATS broker/dealer module130transmits settlement statements705to the seller114and/or the buyer116. The transfer of the transaction fees715may be recorded on both the primary ledger102and the secondary ledger104. While the example illustrated inFIG.7shows that the transaction fees715are payable by and transferred to the transaction ATS broker/dealer130, this is merely an example, and in other examples, the transaction fees715may be payable by and transferred to the transaction ATS broker/dealer module130by any combination of the owner112, the seller114, the buyer116, and/or third parties outside the system100, and/or their associated currency custody modules, digital custody modules, platform wallet custody modules, asset wallet custody modules, and/or the like.

The transaction ATS broker/dealer module130may distribute the license fees710associated with the transaction completed on the transaction platform of the system100to those owed the license fees710, such as the transaction ATS broker/dealer module130. Examples of license fees may include royalties, service fees, intellectual property license fees, and software license fees for software, systems, and methods used by the system100to complete the transactions. The license fees710may be funded from the transaction fees715received by the transaction ATS broker/dealer module130.

The disclosed technologies provide numerous advantages over conventional systems. For example, the platform of the system100may provide owners and sellers with the ability to exit a commercial real estate investment (as an asset) much earlier than the typical hold period for such asset types. In most commercial real estate investments, investors may hold the asset for five to seven (5 to 7) years for various reasons associated with processes and procedures for transferring ownership of the asset as a whole. At the end of the hold period (which may be mandated by statute, regulation, or other law, for example, SEC Rule144), the owner of an investment property (e.g., commercial real estate) may typically either transfer the property or refinance the property. Refinancing the property may provide a liquidity event to the investor. A technological system and method for fractionalizing and tokenizing such assets as described herein may provide owners of assets that would otherwise be subject to extended hold periods the ability to participate in liquidity opportunities and/or offer liquidity opportunities to their investors on a shorter timeline than with conventional legal processes, which may by and large be manually executed with extended delays. The technologies disclosed herein facilitate sellers in trading asset tokens and monetizing their investments in underlying assets, thereby unlocking an ability to re-invest capital and supporting the cycle of investment. For example, liquidity provided by the disclosed technology of the platform of the system100, even after just one year, may help create at least five to seven (5-7) times the liquidity in the entire ecosphere compared to traditional approaches. As an example, compared to traditional approaches in which a share of a real estate investment property is held for five (5) years, the technology disclosed herein may facilitate the asset tokens being traded five (5), ten (10), one hundred (100), or more times, for example, within the same five years.

FIG.8depicts a block diagram of an example computer system800in which embodiments described herein may be implemented. The computer system800may include a bus802or other electronic communication mechanism for communicating information, and one or more hardware processors804coupled with the bus802for processing information. The hardware processor(s)804may include, for example, one or more general purpose microprocessors and/or application specific integrated circuits (ASICs) configured to perform the processes and methods described herein and related processes and methods.

The computer system800also may include a main memory806, for example, a random access memory (RAM), cache, and/or other dynamic storage devices, coupled to the bus802for storing information and instructions to be executed by the processor(s)804. The main memory806also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor(s)804. Such instructions, when stored in storage media accessible to the processor(s)804, may render computer system800into a special-purpose machine that is customized to perform the operations specified in the instructions.

The computer system800may further include a read only memory (ROM)808and/or other static storage device coupled to the bus802for storing static information and instructions for the processor(s)804. A storage device810, for example, a magnetic disk, optical disk, and/or USB thumb drive (Flash drive), etc., may be provided and coupled to the bus802for storing information and instructions.

The computer system800may be coupled via the bus802to a display812, for example, a liquid crystal display (LCD), light emitting diode (LED) display, touch screen, and/or other electronic display for displaying information to a computer user. One or more input device(s)814, including alphanumeric and/or other keys, may be coupled to the bus802for communicating information and command selections to the processor(s)804. Another type of user input device may include cursor control816, for example, a mouse, a trackball, a touchpad, and/or a set of cursor direction keys for communicating direction information and command selections to the processor(s)804and for controlling cursor movement on the display812. In some examples, direction information and command selections as may be provided by cursor control may also or alternatively be implemented via receiving touches on a touch screen without the use of a separate cursor control device.

The computing system800may include a user interface module to implement a graphical user interface (GUI) that may be stored in a mass storage device as executable software codes that are executed by the computing device(s). This and other modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

In general, the words “component,” “engine,” “system,” “database,” “data store,” and the like, as used herein, may refer to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, C, or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software components may be callable from other components or from themselves, and/or may be invoked in response to detected events or interrupts. Software components configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disc, or any other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression, and/or decryption prior to execution). Such software code may be stored, partially or fully, on a memory device of the executing computing device, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware components may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors.

The computer system800may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system800to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system800in response to processor(s)804executing one or more sequences of one or more instructions contained in main memory806. Such instructions may be read into main memory806from another storage medium, such as storage device810. Execution of the sequences of instructions contained in main memory806may cause the processor(s)804to perform the process steps and/or operations described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

The term “non-transitory media,” and similar terms, as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such non-transitory media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device810. Volatile media includes dynamic memory, such as main memory806. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.

Non-transitory media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between non-transitory media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus802. Transmission media may also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

The computer system800may also include one or more communication network interface(s)818coupled to the bus802. The network interface(s)818may provide two-way data communication coupling to one or more network links that are connected to one or more local networks. For example, the network interface(s)818may include an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the network interface(s)818may include a local area network (LAN) card to provide a data communication connection to a compatible LAN (and/or a wide area network (WAN) component to communicate with a WAN). Wireless links may also be implemented. In any such implementation, the network interface(s)818send and receive electrical, electromagnetic, and/or optical signals that carry digital data streams representing various types of information.

A network link typically provides data communication through one or more networks to other data devices. For example, a network link may provide a connection through a local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn may provide data communication services through the worldwide packet data communication network now commonly referred to as the “Internet.” Local network and Internet both use electrical, electromagnetic, and/or optical signals that carry digital data streams. The signals through the various networks and the signals on network link and through network interface(s)818, which may carry the digital data to and from the computer system800, are example forms of transmission media.

The computer system800may send messages and receive data, including program code, through the network(s), network link and network interface(s)818. In the Internet example, a server might transmit a requested code for an application program through the Internet, the ISP, the local network, and the network interface(s)818.

The received code may be executed by the processor(s)804as it is received, and/or stored in the storage810, or other non-volatile storage for later execution.

FIGS.9A-Care block diagrams illustrating an exemplary process of syncing a traditional (e.g., web2) primary ledger (e.g., database) with a secondary blockchain (e.g., web3) ledger (e.g., blockchain), according to example embodiments of the disclosed technology. The syncing module910will detect and correct any deltas between the two ledgers. This syncing module910is radically different from what exists today because it has devised a way to bridge data across web2 and web3.

It is understood that web2 databases can be altered from their original state, either intentionally or inadvertently (for example, via human error or fraud). It is also understood that the blockchain is an immutable record of data and transactions. The convergence of the two via this syncing module910is needed before old web2 technology systems can transition into the new world of web3 technology. This syncing module910will be applicable throughout the sunset of web2 into the sunrise of web3.

The original use case for the syncing module910is, for example, within a regulated financial Exchange.

As part of the trading flow in the Exchange, a primary database ledger, such as the primary ledger102, keeps a record of ownership in the real estate assets that are listed and trading on the Exchange. The ultimate ownership record consists of an original Capitalization Table; the database e.g., the primary ledger102) stores the original and then updates it when changes occur. Within the Exchange ecosystem, ownership in real estate assets is represented by digital assets including, but not limited to, nonfungible tokens (NFTs), fungible tokens, hybrid tokens, cryptocurrencies, crypto tokens, crypto coins, security token, and asset tokens, having metadata including identification information of the buyer of the NFTs, that trade on the Exchange. When the tokens transact between buyers (such as buyer116) and sellers (such as seller114), these transactions are captured on the primary ledger (and are reflected as changes to the original Capitalization Table), such as the primary ledger102.

All of the activity on the primary ledger102is then written to the blockchain as a secondary ledger, such as the secondary ledger104. There is a slight time delay between the primary entry on the primary ledger102and the secondary entry on the secondary ledger104to ensure the primary entry is complete and correct. This means that the same original Capitalization Table, as well as subsequent transactions and changes in ownership, are recorded on the blockchain (e.g., the secondary leger104) after they are recorded to the primary ledger102. The syncing module910ensures that the two ledgers (such as the primary ledger102and the secondary ledger104) always match. When they do not match, that means that a mutation has occurred on the primary ledger102. The syncing module910flags an investigation into why the primary ledger102has changed. In the case of fraud or human error, the primary ledger102can be corrected. In the event the original primary entry was incorrect and the updated entry fixes a problem, the blockchain (such as the secondary ledger104) will be updated to reflect the correct entry (and the two ledgers, the primary ledger102and the secondary ledger104, will again be in sync).

The broader use case beyond the financial Exchange is with any kind of industry or company where a business is currently saving data into any structured web2 database (an example would be SQL or NoSQL). As the majority of businesses today write to a database for some reason, this syncing module910will ultimately be ubiquitous.

The standard practice for a basic database is to write many times, and read many times. A key issue with this model is that a company or entity's database is not visible to the public, and cannot be audited (except via express invitation). This necessarily reduces transparency in whatever system is in question (law enforcement, public financial markets, etc.) because the public has no access to original information- and cannot independently verify any activity or changes to that information (either before or after any public disclosure). However, implementation with the blockchain (e.g., the secondary ledger104) provides a solution. The secondary ledger104is immutable (write once, read many). It is also public and can be viewed by anyone. Using this novel syncing module910, a company or entity can still maintain their own database (e.g., the primary ledger102), and can also have some transparency and accountability within public society, systems, and markets.

Increasing transparency does not mean reducing privacy. The syncing module is configured to hide the identifiers that make a person or entity “who” they are (e.g., hide identifiers associated with a person or entity). What is shown on the blockchain (e.g., the secondary ledger104), to the public, is the transaction data itself. This syncing module allows the public arena to audit a private database system (e.g., the primary ledger102) without necessarily knowing who the private information belongs to (beyond knowing that the transaction or entry occurred, and therefore it belongs to someone). In fact, the disclosed technology makes it less likely to have privacy data leaks out of institutional databases (via manual error or criminal activity), and thus will preserve privacy. The syncing module910creates a bridge to help transition into a world of increased transparency, improved fraud and consumer protection, increased data accuracy, and improved privacy.

This technology should be instantly helpful to all companies that have some component of needing public trust. For example, when a publicly-traded company hires an accounting firm to do an audit for their 10K-details are not public and there is often no way to corroborate that the audit is correct besides accepting the auditor's work. With implementation of the syncing module, information in the databases (e.g., the primary ledger102)—as well as even initial work by auditors—would be on the blockchain (e.g., the secondary ledger104) for anyone to see and verify. In the initial use case of a financial Exchange, the public will be able to see transaction records clearly on the blockchain (e.g., the secondary ledger104). Although private entity details will be hidden on the secondary ledger104, inherently the Exchange will be fully auditable by the public. This is a key way for any Enterprise to prove integrity to the world in a way that has never been done before. As such, the syncing module910provides an improvement over existing computing functionality by allowing computing performance of a function not previously performed before.

The disclosed technology will also have a positive impact on the efficiency and profitability of any entities that require some sort of audit in their business. Users will range from private entities, to public companies, to non-profit organizations, to different arms of the government (ranging from law enforcement agencies to legislatures), and beyond. Auditing of information will no longer take months, it will take seconds. This will reduce labor costs, and direct efforts towards more productive areas of the business/agency/user than the auditing function. Discrepancies will be quickly logged and remedied, meaning that costly errors will be resolved much more quickly as well.

The syncing module910first interacts with a primary database (“DB”), such as the primary ledger102, of an entity. The DB is private, for example, such as the primary ledger in the initial use case of the Exchange. Entries are written to the DB according to the business practice of the entity.

The syncing module910will next record the private DB entries on a public blockchain (e.g., the secondary ledger104), after removing or anonymizing any PII or otherwise required or nonpublic data. Note that there is an option to remove the PII (or not). If PII is stripped, the entry will be turned into a hashID via the syncing module910, in some aspects. The hashID is stored somewhere (off chain such as IPFS, or another database). The PII may be replaced by a hash in the blockchain (e.g., the secondary ledger104).

After this anonymization (by choice) process, the entry is recorded in the blockchain (e.g., the secondary ledger104). Recording an entry in the blockchain (e.g., the secondary ledger104) will lag its entry into the private DB (e.g., the primary ledger102), for example by 24 hours or any other appropriate time interval. The lag is intentional, to give time to correct errors in the original DB (e.g., the primary ledger102) before recording those entries as final on the blockchain (e.g., the secondary ledger104).

There are several options for the user regarding the length of the lag. The user could select a lag that is arbitrary, meaning that the organization or individual can choose any length of time they want. It is noted that the longer the time frame becomes (between the original entry and the writing to the blockchain (e.g., the secondary leger104)), the more risk is introduced that original data integrity has not been preserved. It is also noted that if the lag is too short after the initial ledger entry, this introduces risk that 1) the blockchain (e.g., the secondary ledger104) will have to be updated, or 2) that multiple data entries would have to be input into the primary ledger102and the secondary ledger104(to correct initial benign issues in the primary ledger102that are the result of human error and are corrected soon thereafter). The user could select a lag that is a stated non-arbitrary time frame based on business practices. Some transactions take longer to settle than others, or some datasets take a defined time period to complete from start to finish, and therefore a longer time frame might make sense to sync the databases (e.g., the primary ledger102and the secondary ledger104). Finally, the user could select a randomizer that writes the database at different times to help prevent the predictability of the process. Once written to the blockchain (e.g., the secondary ledger104), the entry is immutable.

Subsequent modifications to the DB entry must be reflected in the blockchain (e.g., the secondary ledger104). Any intentional changes to a DB entry (after it is initially recorded on the blockchain (e.g., the secondary ledger104)) can be made by recording an additional, corrected entry in the blockchain (e.g., the secondary ledger104). The key point here is that any changes will be transparent to the world.

After the entry is recorded in both the DB (e.g., the primary ledger102) and the blockchain (e.g., the secondary ledger104), the syncing module910will come in and perform an audit at random. The randomization of the timing of the audit means that an entity looking to manipulate the syncing technology cannot predict when and “where” (on the blockchain (e.g., the secondary ledger104)) it will perform its checks (this is a deterrent).

The syncing module910manages the randomization process by an algorithm built for this purpose. The syncing module910randomly selects dates and times from a calendar list. The selection process entrants are from1) the beginning of time of the entity (the first entry is the earliest the audit can “look back” to), through 2) up until the last (most recent) entry. The date entrants are identified by numbers (e.g. Dec. 1, 2021 is “25”). Every single date and time in between that range is within the randomizer. The randomizer selects a group of numbers (like a lottery). The chosen numbers correlate to the date and time for which the syncing is checked. For example, if the randomizer pulls 25, Dec. 1, 2021 is checked. The audit process of the syncing module910will then look to see what transactions were recorded on the date and time that the randomizer selected. If there were no transactions on that date, then the randomizer would not perform an audit (this would be highly unlikely, but that would be the outcome). If there are transaction(s) on the date selected, the syncing module910will look up all transactions on that day, and selects a number (from one transaction to infinite transactions) in order to determine how many transactions it will audit on that date and time. For example, if “4” is chosen, the randomizer then goes in and selects at random any 4 transactions on Dec. 1, 2021 and performs the audit.

The audit will use a time lag to confirm the integrity of the primary DB (e.g., the primary ledger102). The syncing module910will look back in time at a random date on the primary ledger102, and compare the data for that date (and back) to the blockchain (e.g., the secondary ledger104). The syncing module910confirms that nothing has been changed by comparing the data for that date (or the data for a block of dates) to the blockchain (e.g., the secondary ledger104). In the initial use case of the Exchange, the audit might confirm that the income statement and balance sheet remain consistent on a given day, or that randomly-selected transactions (for example, 100 different transactions within a given date range) remain consistent

An example of how this audit works: On July 1, the blockchain (e.g., the secondary ledger104) can go to a random date (e.g. June 29th) and look at the data on the primary ledger (e.g., the primary ledger102) for that date (or a bulk of dates, e.g. June 25-June 29). Assuming a standard 24-hour lag in the syncing process of the syncing module910, the entry to the secondary ledger104would have been written on the 30th. The syncing module910will compare the block of data from June 25-June 29th on both the primary ledger102and the secondary ledger104, and confirms it still matches. The audit can be performed at multiple different times. Ranges are selectively entered and could be from every second to once a day or longer, depending on the use case (this is user defined).

If syncing module910determines that there is a mismatch between the primary ledger102and the secondary ledger104, the auditor will alert the user. There are several ways this can happen: (1) alert within the system-system alerts, (2) outside the system-emails or SMS, or (3) due to the public nature of the secondary ledger104on the blockchain, the public is also performing a constant audit simultaneously. Public users can alert the user. Whatever the user does to remedy the mismatch will be written to the blockchain (e.g., the secondary ledger104) and that too will be publicly seen.

The outcome of the audits are public. If there have not been any changes and the primary ledger102and the secondary ledger104match during the audit, the audit is recorded on the blockchain (e.g., the secondary ledger104) as passing. This increases the transparency score of the entity (either explicitly via user KPIs, or implicitly via public perception). If changes are detected via the syncing module910, after the system is alerted and corrections are made to the primary ledger102, this change is also published on the blockchain (e.g., the secondary ledger104). This incentives timely response and accurate correction by the user.

The syncing module910is configured to use transaction IDs to indicate whether the new entry on the blockchain (e.g., the secondary ledger104) is an original entry, or is a correction that refers to a prior block on the chain. Any update will have a transaction ID, which reflects either an initial transaction or a correction based on an audit. The entry will flag that this is a unique and new transaction, or it will reflect the date and time the original entry was made to the blockchain (e.g., secondary ledger104). Any correction will show that this is not an initial transaction, but a corrected action based on the audit (the entry will point to the original transaction ID on the blockchain (e.g., the secondary ledger104) and the primary ledger102—they will always be linked). A user can query on the blockchain (e.g., the secondary ledger104) using the transaction ID to see how many (if any) updates were made (beyond the original entry). There could be multiple corrections made to the blockchain (e.g., the secondary ledger104) over time, of which the transaction ID and the date of every blockchain entry will be listed. In theory there could be one to infinity audit entries that will always be linked to one another.

FIGS.9A,9B, and9Ccollectively illustrate an exemplary syncing flow using the exemplary transaction platform of the systems ofFIGS.1and5-7. With particular reference toFIG.9A, Step One shows a sample sync, via the syncing module910, between the primary ledger102(with illustrative “days” representing data written over a daily period), and then shows a time delay to sync to the secondary ledger104(blockchain).

Referring toFIG.9B, Step Two shows a sample audit process of the syncing module910where the syncing module910takes a sample data set912on the blockchain (e.g., the secondary ledger104), and “looks back” to compare the data between the primary ledger102and the secondary ledger106. If the syncing module910does not find any changes, the audit is recorded on the secondary ledger106as PASSING. If the syncing module910does detect changes, on the other hand, the syncing module910can facilitate transmission of alerts via text (SMS), email, and other appropriate alerts, and the changes are also publicly available for viewing on the secondary ledger104.

Referring toFIG.9C, Step Three shows a sample data structure914for the entries in the primary ledger102and the secondary ledger104. The pointers are the names of the data in the structure. In certain aspects, the primary pointers in the syncing module910are, for example, transaction date, transaction time, the date the entry was written to the ledger, the time the entry was written to the ledger, and user ID (pointing between the primary ledger102and the secondary ledger104). All the fields need to match for the check to be complete.

The syncing module910is able to combine a check of the transaction date and time (down to the millisecond) and join that with the transaction ID (as it is a unique identifier). Those two in tandem are the primary ways to look up and point between the dual ledgers (e.g., the primary ledger102and the secondary ledger104), and joining these points together is the primary way the syncing module910checks to determine whether there has not been any manipulation in the primary ledger102.

Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The various features and processes described above may be used independently of one another, or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate, or may be performed in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The performance of certain of the operations or processes may be distributed among computer systems or computers processors, not only residing within a single machine, but deployed across a number of machines.

As used herein, a circuit might be implemented utilizing any form of hardware, or a combination of hardware and software. For example, one or more processors, controllers, ASICs, PLAS, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a circuit. In implementation, the various circuits described herein might be implemented as discrete circuits or the functions and features described can be shared in part or in total among one or more circuits. Even though various features or elements of functionality may be individually described or claimed as separate circuits, these features and functionality can be shared among one or more common circuits, and such description shall not require or imply that separate circuits are required to implement such features or functionality. Where a circuit is implemented in whole or in part using software, such software can be implemented to operate with a computing or processing system capable of carrying out the functionality described with respect thereto, such as the computer system800.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, the description of resources, operations, or structures in the singular shall not be read to exclude the plural. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps.

Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. Adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known,” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.

The foregoing description of the present disclosure has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Many modifications and variations will be apparent to the practitioner skilled in the art. The modifications and variations include any relevant combination of the disclosed features. The embodiments were chosen and described in order to best explain the principles of the disclosure and its practical application, thereby enabling others skilled in the art to understand the disclosure for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the disclosure be defined by the following claims and their equivalence.

In one aspect, a method may include an operation, an instruction, and/or a function and vice versa. In one aspect, a clause or a claim may be amended to include some or all of the words (e.g., instructions, operations, functions, or components) recited in other one or more clauses, one or more words, one or more sentences, one or more phrases, one or more paragraphs, and/or one or more claims.

To illustrate the interchangeability of hardware and software, items such as the various illustrative blocks, modules, components, methods, operations, instructions, and algorithms have been described generally in terms of their functionality. Whether such functionality is implemented as hardware, software or a combination of hardware and software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application.

The functions, acts or tasks illustrated in the Figures or described may be executed in a digital and/or analog domain and in response to one or more sets of logic or instructions stored in or on non-transitory computer readable medium or media or memory. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, microcode and the like, operating alone or in combination. The memory may comprise a single device or multiple devices that may be disposed on one or more dedicated memory devices or disposed on a processor or other similar device. When functions, steps, etc. are said to be “responsive to” or occur “in response to” another function or step, etc., the functions or steps necessarily occur as a result of another function or step, etc. It is not sufficient that a function or act merely follow or occur subsequent to another. The term “substantially” or “about” encompasses a range that is largely (anywhere a range within or a discrete number within a range of ninety-five percent and one-hundred and five percent), but not necessarily wholly, that which is specified. It encompasses all but an insignificant amount.

As used herein, the phrase “at least one of” preceding a series of items, with the terms “and” or “or” to separate any of the items, modifies the list as a whole, rather than each member of the list (e.g., each item). The phrase “at least one of” does not require selection of at least one item; rather, the phrase allows a meaning that includes at least one of any one of the items, and/or at least one of any combination of the items, and/or at least one of each of the items. By way of example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” each refer to only A, only B, or only C; any combination of A, B, and C; and/or at least one of each of A, B, and C.

The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Phrases such as an aspect, the aspect, another aspect, some aspects, one or more aspects, an implementation, the implementation, another implementation, some implementations, one or more implementations, an embodiment, the embodiment, another embodiment, some embodiments, one or more embodiments, a configuration, the configuration, another configuration, some configurations, one or more configurations, the subject technology, the disclosure, the present disclosure, other variations thereof and alike are for convenience and do not imply that a disclosure relating to such phrase(s) is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. A disclosure relating to such phrase(s) may apply to all configurations, or one or more configurations. A disclosure relating to such phrase(s) may provide one or more examples. A phrase such as an aspect or some aspects may refer to one or more aspects and vice versa, and this applies similarly to other foregoing phrases.

A reference to an element in the singular is not intended to mean “one and only one” unless specifically stated, but rather “one or more.” The term “some” refers to one or more. Underlined and/or italicized headings and subheadings are used for convenience only, do not limit the subject technology, and are not referred to in connection with the interpretation of the description of the subject technology. Relational terms such as first and second and the like may be used to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. All structural and functional equivalents to the elements of the various configurations described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and intended to be encompassed by the subject technology. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the above description. No claim element is to be construed under the provisions of 35 U.S.C. § 112 (f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”

While this specification contains many specifics, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of particular implementations of the subject matter. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

The subject matter of this specification has been described in terms of particular aspects, but other aspects can be implemented and are within the scope of the following claims. For example, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. The actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the aspects described above should not be understood as requiring such separation in all aspects, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

The title, background, brief description of the drawings, abstract, and drawings are hereby incorporated into the disclosure and are provided as illustrative examples of the disclosure, not as restrictive descriptions. It is submitted with the understanding that they will not be used to limit the scope or meaning of the claims. In addition, in the detailed description, it can be seen that the description provides illustrative examples and the various features are grouped together in various implementations for the purpose of streamlining the disclosure. The method of disclosure is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as the claims reflect, inventive subject matter lies in less than all features of a single disclosed configuration or operation. The claims are hereby incorporated into the detailed description, with each claim standing on its own as a separately claimed subject matter.

The claims are not intended to be limited to the aspects described herein, but are to be accorded the full scope consistent with the language claims and to encompass all legal equivalents. Notwithstanding, none of the claims are intended to embrace subject matter that fails to satisfy the requirements of the applicable patent law, nor should they be interpreted in such a way.