WO2023141241A1 - Structures de données référentielles pour la mise à jour automatique d'attributs d'actifs en temps réel sur la base de données transmises en continu - Google Patents

Structures de données référentielles pour la mise à jour automatique d'attributs d'actifs en temps réel sur la base de données transmises en continu Download PDF

Info

Publication number
WO2023141241A1
WO2023141241A1 PCT/US2023/011193 US2023011193W WO2023141241A1 WO 2023141241 A1 WO2023141241 A1 WO 2023141241A1 US 2023011193 W US2023011193 W US 2023011193W WO 2023141241 A1 WO2023141241 A1 WO 2023141241A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
exchange
data
processor
assets
Prior art date
Application number
PCT/US2023/011193
Other languages
English (en)
Inventor
Michael B. ROHLFS
Original Assignee
Dearborn Financial, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/580,272 external-priority patent/US11403655B1/en
Application filed by Dearborn Financial, Inc. filed Critical Dearborn Financial, Inc.
Publication of WO2023141241A1 publication Critical patent/WO2023141241A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G06Q2220/10—Usage protection of distributed data files
    • G06Q2220/14—Requiring a supplemental attachment or input, e.g. a dongle, to open

Definitions

  • the present disclosure relates to referential data structures for automatically updating asset attributes in real time based on streaming data cross-reference to related applications.
  • a server connected to a network comprises a processor and memory storing instructions which when executed by the processor configure the processor to generate a database.
  • the database comprises a first data structure configured to store attributes of fungible assets. The attributes determine market values of the fungible assets.
  • the database comprises a second data structure having fields referential ⁇ related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure.
  • the instructions configure the processor to receive a stream of data regarding one or more of the attributes of the fungible assets from the network, and to modify one or more of the fields of the second data structure based on the stream of data received from the network.
  • the instructions configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure.
  • the instructions configure the processor to maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.
  • the first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure, and the updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time.
  • the attributes of the fungible assets include an asset type, valuation data, and geographic data of the fungible assets.
  • the stream of data is based on trading activity associated with the one or more of the fungible assets over the network.
  • the instructions further configure the processor to maintain a plurality of baskets of the fungible assets in the database, and modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time.
  • the instructions further configure the processor to receive via the network buy and sell orders from counterparties for trading one or more of the fungible assets in the baskets and to match the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining the relative value equivalence of the fungible assets in the baskets.
  • the instructions further configure the processor to generate a weighted average benchmark based on a plurality of asset forms of one or more of the fungible assets and to match the orders using the weighted average benchmark.
  • the instructions further configure the processor to provide liquidity and physical delivery of the traded fungible assets to the counterparties via the network upon matching the orders while maintaining the relative value equivalence of the fungible assets in the baskets.
  • the instructions further configure the processor to align the orders to comply with Sharia law.
  • the instructions further configure the processor to generate a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network.
  • the instructions further configure the processor to securitize and tokenize the digitized medium of exchange for trading the fungible assets over the network.
  • the server further comprises a dongle that cryptographically authenticates access to the server via the network and that secures data transfers between the server and the network.
  • the server further comprises a dongle that provides transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between the server and the network.
  • a method comprises generating a database on a server.
  • the database comprises a first data structure configured to store attributes of fungible assets.
  • the attributes determine market values of the fungible assets.
  • the database comprises a second data structure having fields referential ⁇ related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure.
  • the method comprises receiving a stream of data regarding one or more of the attributes of the fungible assets at the server from a network, and modifying one or more of the fields of the second data structure based on the stream of data received from the network.
  • the method comprises allowing at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure.
  • the method comprises maintaining a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.
  • the method further comprises automatically updating the first data structure in real time as the stream of data modifies the one or more of the fields of the second data structure, and automatically updating, based on the updating of the first data structure, the attributes and valuations of the fungible assets in real time.
  • the attributes of the fungible assets include an asset type, valuation data, and geographic data of the fungible assets.
  • the method further comprises receiving the stream of data in response to trading activity associated with the one or more of the fungible assets over the network.
  • the method further comprises maintaining a plurality of baskets of the fungible assets in the database, and automatically updating, based on the modifying of the one or more of the fields of the second data structure, the attributes and valuations of the fungible assets across the baskets in real time.
  • the method further comprises receiving, at the server via the network, buy and sell orders from counterparties for trading one or more of the fungible assets in the baskets, and matching, at the server, the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining the relative value equivalence of the fungible assets in the baskets.
  • the method further comprises generating a weighted average benchmark based on a plurality of asset forms of one or more of the fungible assets, and matching the orders using the weighted average benchmark.
  • the method further comprises providing liquidity and physical delivery of the traded fungible assets to the counterparties via the network upon matching the orders while maintaining the relative value equivalence of the fungible assets in the baskets.
  • the method further comprises aligning the orders to comply with Sharia law.
  • the method further comprises generating, at the server, a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network.
  • the method further comprises securitizing and tokenizing, at the server, the digitized medium of exchange for trading the fungible assets over the network.
  • the method further comprises cryptographically authenticating access to the server via the network and securing data transfers between the server and the network by using a dongle coupled to the server.
  • the method further comprises providing transformational data protection via encryption and adding authentication and fault tolerant information to data transfers between the server and the network by using a dongle coupled to the server.
  • a server connected to a network comprises a processor and memory storing instructions which when executed by the processor configure the processor to generate a database comprising a first data structure and a second data structure.
  • the first data structure is configured to store attributes of fungible assets.
  • the attributes determine market values of the fungible assets and include an asset type, valuation data, and geographic data of the fungible assets.
  • the second data structure has fields referential ⁇ related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure.
  • the instructions configure the processor to receive a stream of data regarding one or more of the attributes of the fungible assets from the network and modify one or more of the fields of the second data structure based on the stream of data received from the network.
  • the first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure.
  • the updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time.
  • the instructions configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure.
  • the instructions configure the processor to maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.
  • the instructions configure the processor to maintain a plurality of baskets of the fungible assets in the database. Modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time.
  • the instructions configure the processor to at least one of securely validate, verify, record, trace, and track transactions for cryptocurrency specimens based on the stream of data, the cryptocurrency specimens having net cumulative values derived from digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets.
  • the instructions further configure the processor to convert one or more digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets into one or more cryptocurrency specimens.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens without using proof-of work mining based processes.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by encoding the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange; verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation; and providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by implementing one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by interfacing, using the one or more application programming interfaces, with one or more graphical user interfaces configured to: provide bids, offers, and executed prices attendant to each underlying net cumulative value component to the users; and allow the users to post counter prices of net cumulative value components via iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.
  • the instructions further configure the processor to account for and reconcile periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network.
  • the instructions further configure the processor to encode the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset- backed mediums of exchange that have migrated through formulation, securitization, issuance, and initial valuation processes as of a specified date of origin.
  • the instructions further configure the processor to verify, using the encoding, that unitary ownership interests associated with the digitized asset- backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation.
  • the instructions further configure the processor to generate cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.
  • the instructions further configure the processor to implement one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.
  • the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to users.
  • the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to allow the users to post counter prices of net cumulative value components per iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.
  • the stream of data is based on trading activity associated with the one or more of the fungible assets over the network.
  • the instructions further configure the processor to receive via the network buy and sell orders from counterparties for trading one or more of the fungible assets in the baskets and to match the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining the relative value equivalence of the fungible assets in the baskets.
  • the instructions further configure the processor to generate a weighted average benchmark based on a plurality of asset forms of one or more of the fungible assets and to match the orders using the weighted average benchmark.
  • the instructions further configure the processor to provide liquidity and physical delivery of the traded fungible assets to the counterparties via the network upon matching the orders while maintaining the relative value equivalence of the fungible assets in the baskets.
  • the server further comprises a dongle that cryptographically authenticates access to the server via the network and that secures data transfers between the server and the network.
  • the server further comprises a dongle that provides transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between the server and the network.
  • the instructions further configure the processor to align the orders to comply with Sharia law.
  • the instructions further configure the processor to generate a digitized medium of exchange that is based on a set of baskets comprising the fungible assets and that is usable for trading the fungible assets over the network.
  • the instructions further configure the processor to securitize and tokenize the digitized medium of exchange for trading the fungible assets over the network.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens using processes selected from a group consisting of proof of work, proof of stake, delegated proof of stake, proof of capacity, proof of elapsed time, proof of identity, proof of authority, and proof of activity.
  • a server connected to a network comprises a processor and memory storing instructions which when executed by the processor configure the processor to generate a database comprising a first data structure and a second data structure.
  • the first data structure is configured to store attributes of fungible assets.
  • the second data structure has fields referentially related to the attributes stored in the first data structure such that a change in any one of the fields induces a change in real time in a corresponding one of the attributes in the first data structure.
  • the instructions configure the processor to receive a stream of data regarding one or more of the attributes of the fungible assets from the network and modify one or more of the fields of the second data structure based on the stream of data received from the network.
  • the first data structure is automatically updated in real time as the stream of data modifies the one or more of the fields of the second data structure.
  • the updating of the first data structure automatically updates the attributes and valuations of the fungible assets in real time.
  • the instructions configure the processor to maintain a plurality of baskets of the fungible assets in the database. Modifying the one or more of the fields of the second data structure automatically updates the attributes and valuations of the fungible assets across the baskets in real time.
  • the instructions configure the processor to at least one of securely validate, verify, record, trace, and track transactions for cryptocurrency specimens based on the stream of data, the cryptocurrency specimens having net cumulative values derived from digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets.
  • the instructions further configure the processor to allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets associated with the first data structure based on the modified one or more fields of the second data structure; and maintain a relative value equivalence of the fungible assets based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets associated with the first data structure.
  • the attributes include an asset type, valuation data, and geographic data of the fungible assets.
  • the instructions further configure the processor to convert one or more digitized asset-backed mediums of exchange comprising one or more of the plurality of baskets into one or more cryptocurrency specimens.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens without using proof-of work mining based processes.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by encoding the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange; verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation; and providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by implementing one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens by interfacing, using the one or more application programming interfaces, with one or more graphical user interfaces configured to: provide bids, offers, and executed prices attendant to each underlying net cumulative value component to the users; and allow the users to post counter prices of net cumulative value components via iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.
  • the instructions further configure the processor to account for and reconcile periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network.
  • the instructions further configure the processor to encode the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset- backed mediums of exchange that have migrated through formulation, securitization, issuance, and initial valuation processes as of a specified date of origin.
  • the instructions further configure the processor to verify, using the encoding, that unitary ownership interests associated with the digitized asset- backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation.
  • the instructions further configure the processor to generate cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.
  • the instructions further configure the processor to implement one or more application programming interfaces that allow users dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.
  • the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to users.
  • the instructions further configure the processor to interface, using the one or more application programming interfaces, with one or more graphical user interfaces configured to allow the users to post counter prices of net cumulative value components per iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific time and date stamp.
  • the instructions further configure the processor to securely validate, verify, record, trace, and track the transactions for the cryptocurrency specimens using processes selected from a group consisting of proof of work, proof of stake, delegated proof of stake, proof of capacity, proof of elapsed time, proof of identity, proof of authority, and proof of activity.
  • FIGS. 1 A and 1 B show an example of Asset-Backed Exchange Traded Baskets (ABETB’s) for an ABETB-centric order matching system according to the present disclosure
  • FIG. 2 shows an example of a database comprising first and second data structures for the ABETB-centric order matching system according to the present disclosure
  • FIG. 3 shows a simplified example of a distributed computing system that can implement the ABETB-centric order matching system of the present disclosure
  • FIG. 4 shows a simplified example of a client device of FIG. 3
  • FIG. 5 shows a simplified example of a server of FIG. 3
  • FIG. 6 shows a flowchart of a method performed by the ABETB-centric order matching system for automatically updating attributes of fungible assets according to the present disclosure
  • FIG. 7 shows a flowchart of a method performed by the ABETB-centric order matching system for maintaining a relative value equivalence of the fungible assets according to the present disclosure
  • FIG. 8 shows a flowchart of a method performed by the ABETB-centric order matching system for maintaining a relative value equivalence of the fungible assets according to the present disclosure
  • FIG. 9 shows a flowchart of a method performed by the ABETB-centric order matching system for automatically updating attributes of fungible assets across a set of baskets comprising the fungible assets according to the present disclosure
  • FIG. 10 shows a flowchart of a method performed by the ABETB-centric order matching system for matching buy and sell orders according to the present disclosure
  • FIG. 11 shows a flowchart of a method performed by the ABETB-centric order matching system for generating a weighted average benchmark for matching buy and sell orders based on practically opposite rather than absolute opposite trading interests of counterparties according to the present disclosure
  • FIG. 12 shows a flowchart of a method performed by the ABETB-centric order matching system for ensuring that buy and sell orders comply with Sharia law according to the present disclosure
  • FIG. 13 shows a flowchart of a method performed by the ABETB-centric order matching system for generating, securitizing, to organizing a digitized medium of exchange for trading fungible assets according to the present disclosure
  • FIG. 14 shows a flowchart of a method performed by the ABETB-centric order matching system for providing secure transactions between devices used for trading fungible assets across a network according to the present disclosure
  • FIG. 15 shows multiple dimensions impacting data structures developed around BCS-based hybrid paradigm according to the present disclosure
  • FIG. 16 shows operations of the ABETB-centric order matching system performed by an exchange (i.e., by a server at the exchange; e.g., the server of FIGS. 3-5) in an ABETB-centric order matching system 500 according to the present disclosure;
  • FIG. 17 shows a method for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens according to the present disclosure
  • FIG. 18 shows a method for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens using a three-layer encoding system according to the present disclosure
  • FIG. 19 shows a system for securely trading tokens over subnetworks and validating, verifying, recording, tracing, and tracking transactions for tokens over the subnetworks according to the present disclosure
  • FIG. 20 shows a method for securely trading tokens over subnetworks and validating, verifying, recording, tracing, and tracking transactions for tokens over the subnetworks using the system of FIG. 19 according to the present disclosure.
  • GLEBS Global e-Bourse Suites, is an organization of affiliated exchanges whose computerized trading platforms are uniquely integrated according to the teachings of U.S. Patent No. 10,510,115, which is incorporated herein by reference in its entirety.
  • ABETB Asset-Backed Exchange Traded Baskets, are investment products with meaningful prospects in their own right, are structured inter alia to serve as major drivers of tradable asset liquidity throughout multiple markets targeted by Global e- Bourse Suites (“GLEBS”).
  • GLEBS Global e- Bourse Suites
  • BCS Benchmark Complex Solutions (as disclosed in U.S. patents 9,002,741 , 9,460,470, and 10,269,070; and in U.S. patent application publication 20190095995) result in matching practically opposite orders for fungible-yet varying tradable assets that would otherwise be victims of illiquidity inherent to absolute opposite matching.
  • ABMoE Asset-Backed Medium of Exchange comprising sets of ABETB.
  • FPDDI Forward Point Delivery Differential Index
  • GDI Complementary Differential Index
  • CPL Customized Permissioned Ledger
  • WAB Weighted Average Benchmark
  • CUspCF Commodity User posts bid data for specific commodity form
  • All-in A function of price discovery mechanisms whereby each fungible-yet- varying asset qualifying as a member of an ABETB is valued on the basis of its operative WAB contact price ⁇ the net price effects of its requisite number of long or short CDI and FPDDI contracts specified by the exchange as called for under the circumstances.
  • the net sum of the updated all-in prices attributable to the various qualifying members then equals the updated market value of the operative WAB, after giving effect to the respective Exchange-specified weighting attributes attendant to each of its contents.
  • the present disclosure relates to an ABETB- centric order matching system that uses synergy created by a computer implemented hybrid paradigm leveraging multi-market price discoveries to optimize all-in BCS-based price liquidity achieved over a plurality of trading platforms integrated via an ECN that connects an organization of affiliated Exchanges, their customers, and COI.
  • ABETB holders can gain connectivity and liquidity when the exchanges uniformly employ systems, methods, and instruments that work together to contemporaneously maintain macro level NAV equilibrium as cross-listed trading contracts attendant to qualifying fungible-yet-varying assets underpinning an Exchange- specified basket, formulated to emulate a WAB Set, are exposed to continuous micro level price fluctuations throughout each trading day.
  • GUI graphical user interface
  • Pro-forma all-in market value indications are by-products of computer implemented algorithmic formulas applied to each of the hybrid paradigm’s compendium of physical, financialized, and digitized assets when they are being bought, sold, financed, hedged, cycled (e.g., physically exchanged between ABETB’s and Exchange managed/controlled inventories), securitized, and tokenized over affiliated Exchange trading platforms.
  • Risks go up when supplies of useful standalone assets confined to absolute opposite order matching increase relative to demand, especially from speculators that thrive on liquidity. Risks are particularly extended to fungible-yet-varying credit instruments and commodities held in conventional exchange-traded products, like ETF’s, which employ multi-basket structures (i.e., creation, redemption and holding baskets). To mitigate such ETF risks, “insider” transactions with Authorized Parties are permitted to increase liquidity and narrow differences between the product’s publicly traded price and its NAV. Also, Fund Managers focus more on end-of-day NAV machinations, rather than providing more efficient price discovery and market valuation processes throughout each trading day.
  • ABETB’s, ABMoE’s and DABMoE’s are offered as novel and commercially more efficient and proactive means to deal with excess illiquidity.
  • ABETB-centric order matching system is designed to transform connectivity between physical asset markets and the financial sector, comprising an exchange- specified plurality of fungible assets possessing varying quantitative, qualitative, logistics, and settlement timing properties, each gaining transparency and liquidity via hybrid paradigm formed by Benchmark Complex Solutions (“BCS”) that satisfy practically, rather than absolute, opposite counterparties’ trading interests to facilitate continuous market price discoveries sufficient to consistently maintain relative value equivalency among all qualifying assets underpinning the ABETB and maintained in exchange-segregated, -managed, and -controlled inventories.
  • BCS Benchmark Complex Solutions
  • ETD exchange traded derivatives
  • ABETB a novel financial product backed by exchange-specified tradable assets formulated in baskets that can be transparently maintained and regularly replenished by proprietary asset-cycling systems employing practically opposite matching and relative value equivalency processes predicated on BCS.
  • ETF Exchange- Traded Funds
  • ABETB can be described as possessing the following characteristics.
  • ABETB are single asset baskets designed to emulate WAB sets linked to exchange-specified varying assets, with many billions of dollars of commodities and credit instruments particularly suited for inclusion since GLEBS affiliated ETD platforms would benefit considerably by added transparency and liquidity ensuing from such arrangements.
  • each asset in an ABETB is valued at the operative WAB set market price ⁇ adjustments linked to market prices for cash-settled Complementary and Forward Point Delivery Differential Indexes (CDI’s and FPDDI’s), the requisite number of contracts of which are determined by proprietary algorithms formulated to factor the impact of qualitative, logistics, and settlement timing variability applying under the circumstances, as well as any positive or negative asset carrying costs not otherwise provided for directly as part of CDI and FPDDI contracts.
  • CDI Complementary and Forward Point Delivery Differential Indexes
  • ABETB’s are sets of single asset baskets, structured for more diversified offerings, e.g., Asset-Backed Medium of Exchange (“ABMoE”) developed for the Global e-Counter barter and countertrade platform described in U.S. patent 9,460,470. Complementing core physical asset baskets with varying levels of US dollar and/or foreign currency baskets, ABETB’s produce meaningful stores of value aimed inter alia at consistently outperforming the annual rate of inflation. Digitized (i.e., securitized and tokenized) ABMoE, called DABMoE, can also be formulated to offer secondary cryptocurrency markets diversely substantive alternatives to Bitcoin and the plethora of Altcoins in the field.
  • ABMoE Asset-Backed Medium of Exchange
  • ABETB’s are structured to enable each of a single asset basket’s contents to be periodically replenished and continuously valued by a proprietary asset-cycling system based on practical (rather than absolute) equivalency and links to market prices of the operative WAB set and differential indexes discovered throughout each trading day via ECN and CPL, achieved by integrating GLEBS’ computerized trading platforms as elucidated throughout the patents referenced above.
  • the BCS-based counterparty matching comprises the following operations performed by one or more exchange affiliates.
  • the BSC-based counterparty matching includes one or more exchange affiliates formulating a weighted average benchmark (“WAB”) set linked to an exchange-specified plurality of qualifying asset forms, rather than arbitrarily denoting one single asset form as the benchmark for all forms of that asset.
  • WAB weighted average benchmark
  • the BSC-based counterparty matching includes one or more exchange affiliates identifying and factoring the impact of quantitative, qualitative, logistics, and settlement timing properties unique to each of the qualifying asset forms comprising a neutral WAB formulated by the exchange for the entire set.
  • the BSC-based counterparty matching further includes one or more exchange affiliates providing uniform allowances for cases where traders physically own or are seeking to own varying-yet-fungible asset forms, each qualifying as an interchangeable component of an exchange-specified set, offer or bid their specific asset form pursuant to standardized spot or forward Exchange for Physical (EFP) contracts calling for settlement by physical delivery or receipt of their respective underlying assets, with each contract's specifications linked to an operative WAB formulated by the exchange to cover an entire set of qualified asset forms.
  • EFP forward Exchange for Physical
  • the BSC-based counterparty matching further includes one or more exchange affiliates ensuring that each component in a Weighted Average Benchmark (WAB) possesses quantitative characteristics, as well as varying qualitative, logistics, and settlement timing properties that customarily add to or detract from each respective asset's market value, the net aggregate effects of which are uniformly balanced exchange-wide by methods integral to the following: establishing benchmark-specific WAB sets, each formulated for incorporation into a family of standardized exchange- traded derivatives (“ETD”) contracts, the ETD contracts typically including spots, forwards, futures, options and spreads, specifications of which differ only by timing and type of settlement taking place; requiring EFP spot and forward traders to acquire a specific number of long or short Complementary Differential Index (CDI) contracts, for cash tendered or received as the case may be, linked to varying qualitative and logistics attributes of underlying assets respectively delivered or received, and to ensure co-delivery of such contracts as of an operative EFP physical delivery date; and requiring EFP spot and forward traders to acquire a
  • the BSC-based counterparty matching further includes one or more exchange affiliates uniformly employing the forgoing methods to formulate, acquire, maintain, and hedge future price volatility risks of ABETB and ABMoE on a practically equivalent basis, achieved by instilling parameters for cycled interchange of varying-yet-fungible assets qualified within exchange-specified baskets underpinning the forgoing, the parameters serving to account for qualitative, logistics, supply chain, life cycle and any other positive or negative cost of carry factors unique to the assets held and, when necessary, securitized by exchange(s), all taking place prior to deliveries scheduled to meet future commitments to counterparties, plus assets held in reserve by exchange(s) to ensure their ongoing role as order liquidity provider(s), with such parameters incorporated as part of proprietary float processes employed within the confines of an affiliated exchange organization-wide inventory management and control system.
  • Global d-Bourse is designed to cooperate with GLEBS-affiliated platforms, plus others when necessary, to undertake the following functions: formulating WAB Sets specified for ABETB; enhancing aggregate GLEBS-wide liquidity by cross-listing ABETB products over multiple platforms inside and outside GLEBS and effectuating back-to-back order executions accordingly; exercising constructive management and control over assets acquired and stored prior to satisfying physical delivery commitments to ETD and other platforms inside and outside the GLEBS group, including those assets employed to underpin ABETB; exercising constructive management and control over assets cycled in and out of ABETB in a manner that consistently maintains market value equivalence as practically, rather than absolute, opposite assets are interchanged, which involves continuously maintaining a transactional database containing all GLEBS affiliates’ ETD contract market prices attendant to EFP spots and forwards, futures, options, and swaps,
  • the BCS-based algorithms uniformly factor the integrated effects of each trader’s specified asset form posted in its bid/offer vis-a-vis the latest offers/bids posted for their operative spot or forward contract.
  • the algorithm output identifies the requisite quantities of Complementary Differential Index and Forward Point Delivery Differential Index (CDI and FPDDI) contracts to be bought or sold by each counterparty pursuant to an exchange-wide pursuit of aggregate zero-sum equivalence achieved within the confines of practically opposite matching.
  • GUI Graphical User Interfaces
  • GUI display algorithm-generated output to provide each buyer and seller with computed data that continuously indicates net cumulative all-in market prices and values attributable to each asset on an equivalent-for-equivalent basis.
  • the counterparty matching processes include identifying trading party types (denoted for each respective party at dongle-enabled sign-in).
  • the trading party types include Commodity Producers (Sellers), Commodity Users (Buyers), Exchange Market Makers (Covering Buy and Sell Sides), Commodity Trading Firms (Covering Buy and Sell Sides), and Global d-Bourse (Covering Buy and Sell Sides).
  • the processes followed to fill buy-side orders include the following.
  • Commodity User posts bid data for specific commodity form (the “CUspCF”) that qualifies within a specified plurality of forms comprising an operative exchange-formulated WAB Set, with the bid data indicating desired quantity, incoterms and price, as well as exchange confirmation that the Commodity User is logistically and financially qualified to take delivery of the denoted commodity pursuant to the terms of its bid.
  • the exchange compares Commodity User’s bid data with offer data posted by Sellers - in this case, primarily Commodity Producers, Exchange Market Makers, and Commodity Trading Firms - aimed at identifying whether an absolute matching offer exists to offset against Commodity User’s bid.
  • the exchange inquires with Global d- Bourse to see if it is willing and able to sell CUspCF inventory in its possession to the Commodity User, which is a decision Global d-Bourse makes after determining the extent to which required quantity of CUspCF is physically available and uncommitted pursuant to Global d-Bourse inventory management and control guidelines; and after determining the extent to which different yet practically equivalent form(s) of the commodity (i.e., also qualifying in the attendant WAB Set’s plurality) can be acquired to suitably replace the CUspCF at values acceptable to Global d-Bourse.
  • the exchange informs Commodity User whether matching offer(s) for the CUspCF are posted, albeit at higher selling price(s), by one or more of the aforementioned Sellers; or different yet practically equivalent form(s) of the desired commodity (i.e., qualified as another component in the WAB Set’s specified plurality) are available in the quantity sought and at a comparably similar unit price equivalent to that originally sought by the Commodity User with respect to CUspCF.
  • the processes followed to fill sell-side orders include the following.
  • CPspCF specific commodity form
  • the exchange compares Commodity Producer’s offer data with bid data posted by Buyers - in this case, primarily Commodity Users, Exchange Market Makers, and Commodity Trading Firms - aimed at identifying whether bid(s) can be absolutely matched with Commodity Producer’s offer.
  • the exchange inquires with Global d- Bourse to see if it is willing and able to buy CPspCF from the Commodity Producer for inclusion as part of the tradable asset inventories under its constructive control, which is a decision Global d-Bourse makes pursuant to its inventory management and control guidelines. If the process still fails to result in an absolute match, the exchange informs Commodity Producer whether matching bid(s) for the CPspCF have been posted, albeit at lower price(s), by one or more of the aforementioned Buyers.
  • the BCS-based matching can also be used for credit instruments.
  • QE Quantitative Easing
  • GLEBS aims to advance diversity of art in this field via affiliated computerized trading platforms employing BCS within an ECN customized to facilitate the use of permissioned ledgers.
  • BCS Computerized trading platforms
  • ETD contracts esp. physically-settled spots and forwards linked to pluralities of fungible credit instruments qualified in WAB sets to underpin ABETB, factoring attributes such as bond classifications and varying qualitative attributes.
  • bond classifications include corporate industrials, transports, utilities, and financial services, plus various types of preferred stocks, leveraged loans, municipals and even Shariabased Sukuks.
  • varying qualitative attributes include coupon rate of interest, credit quality rating, and remaining time to maturity/convertibility/callability, each incorporated into standardized WAB integrated with Complementary Differential and Forward Point Delivery Differential Indexes (CDI and FPDDI).
  • the order matching processes include identifying Trading Party Types (denoted by each respective party per dongle-enabled sign-in).
  • the Trading Party Types include Buyers of physically-settled spot and forward ETD contracts linked to individual securities that qualify as components of an exchange-formulated WAB Set (i.e., a basket of credit instruments, also referred to as an Exchange-Traded Bond Basket or “ETBB”).
  • the Trading Party Types include Buyers of physically-settled spot and forward ETD contracts linked to ETBB, qualifying as one or more components within a plurality of tradable asset baskets underpinning an ABMoE.
  • the Trading Party Types further include Sellers of either of the forgoing, Exchange Market Makers (covering both buy and sell Sides), and Global d-Bourse (covering both buy and sell sides).
  • the processes followed to fill buy side orders include the following.
  • the exchange compares Buyer’s bid data with offer data posted by Sellers, including Exchange Market Makers, aimed at identifying whether an absolute matching offer exists.
  • the exchange inquires with Global d- Bourse to see if there is willingness and ability to sell inventory in its constructive possession to the Buyer, which is a decision Global d-Bourse makes after determining whether required quantity of the asset desired by Buyer is physically available and uncommitted pursuant to Global d-Bourse inventory management and control guidelines; or after determining whether practically equivalent alternative credit securities (i.e., also qualifying within attendant WAB Set’s plurality) can be acquired, at satisfactory terms, to suitably replace assets removed from Global d-Bourse inventory for sale to Buyer.
  • the exchange informs Buyer whether matching offer(s) for the desired asset is posted, albeit at higher selling price(s), by one or more of the aforementioned Sellers; or whether practically equivalent alternative form(s) of the desired asset (i.e., qualified within the WAB Set’s specified plurality) are available in the quantity and at a satisfactorily equivalent unit price to what was originally indicated by the Buyer.
  • the processes followed to fill sell side orders include the following.
  • Seller posts offer data for a specific credit Instrument security that’s a qualified component of an operative exchange-formulated WAB Set, with the data including desired quantity and price.
  • the exchange compares Seller’s offer data with bid data posted by Buyers, including Exchange Market Makers, aimed at identifying whether absolutely matching bid(s) exist.
  • the exchange inquires with Global d- Bourse to see if it is willi ng/able to buy the securities from the Seller for inclusion as part of the tradable asset inventories under its constructive control, a decision Global d- Bourse makes pursuant to its inventory management and control guidelines. If the process still fails to result in absolute match, the exchange informs Seller whether any matching bid(s) for the credit instrument securities have been posted, albeit at lower price(s), by one or more of the aforementioned Buyers.
  • ABETB’s are novel financial products backed by exchange- specified tradable assets formulated into baskets whose contents can be continuously replenished and valued by proprietary asset-cycling systems and methods employing practically, rather than absolute, opposite matching processes predicated on BCS. Designed to compete with ETF’s and other fractionalized interest investment products emerging in secondary markets today, ABETB’s are structured as single asset baskets as well as sets of single asset baskets.
  • the single asset baskets are designed to emulate Weighted Average Benchmark (“WAB”) Sets linked to exchange-specified plurality of qualifying asset forms.
  • WAB Weighted Average Benchmark
  • Each single asset basket in an ABETB is backed by fungible-yet varying assets; and many billions of dollars of commodities and credit instruments particularly targeted for trading over GLEBS affiliated Exchange-Traded Derivatives (“ETD”) platforms should benefit considerably by the added liquidity ensuing from such arrangements.
  • Assets are cycled in and out via practically opposite matches, executed at prevailing market prices ⁇ cash adjustments tied to BCS-based Complementary Differential Indexes (CDI’s) uniquely valuing the intrinsic impacts of qualitative, logistics, and settlement timing variability.
  • CDI Complementary Differential Indexes
  • ABETB’s are also structured as sets of single asset baskets, structured for more diversified offerings, such as ABMoE fractionalized interest instruments developed for the Global e-Counter (barter and countertrade) platform per U.S. patent 9,460,470. Complementing with US Dollar and foreign currency baskets, these build meaningful stores of value aimed inter alia at outperforming annual rates of inflation. Digitized (i.e., securitized and tokenized) ABMoE (called “DABMoE”) are also designed to provide global cryptocurrency (“CC”) markets with diversely substantive alternatives to Bitcoin and the plethora of Altcoins in the field.
  • ABMoE fractionalized interest instruments developed for the Global e-Counter (barter and countertrade) platform per U.S. patent 9,460,470.
  • Digitized (i.e., securitized and tokenized) ABMoE (called “DABMoE”) are also designed to provide global cryptocurrency (“CC”) markets with diversely substantive alternatives to Bitcoin and the plethora of Altcoins
  • U.S. Patent Application Publication No. 20190095995 is directed to a BCS-based hybrid paradigm formed to further increase transparency, liquidity, and volume by creating synergy to uniformly provide standardized-yet customizable trading, hedging, digitization, repo-based finance, and asset management and control systems, methods and instruments, GLEBS-wide, upon integration of its affiliates’ IT Resources (esp. ECN and CPL) and reporting processes; and by cycling fungible-yet-varying assets in and out of ABETB alongside securitization and tokenization processes essential to DABMoE and CC offerings.
  • IT Resources esp. ECN and CPL
  • BCS Benchmark Complex Solutions
  • ETD Exchange Traded Derivatives
  • Traders physically owning or seeking to own differing-yet-interchangeable asset forms can offer/bid their respective asset form via standardized set of EFP contracts linked with an operative WAB formulated by the exchange to cover the entire set of qualified asset forms.
  • BCS novel order-matching process - based on satisfying counterparties’ practically, rather than absolute, opposite, interests - is designed to satisfy all parties’ demands for more flexibility, transparency, liquidity and cost effectiveness.
  • Spot and EFP-forward contracts specify physical delivery and receipt, respectively, of underlying assets.
  • Each component in a WAB has specific geographic and other quantitative characteristics, as well as varying qualitative properties that customarily add to or detract from that asset’s market value, the net effects of which can be balanced exchange-wide by proprietary algorithms integral to the standardized ETD contracts designed for (i) benchmark specific (WAB) sets, (ii) complementary differential indexes and (iii) forward point delivery differential indexes.
  • the forgoing ETD contracts [(i) - (iii)] have been custom-formulated for transparent trading in the open market; each/all structured to be co-settled as of the operative spot or EFP-forward contract’s physical delivery date. Offering strictly financially-settled versions of those ETD contracts (each on a standalone basis) likewise offer considerable appeal to speculators and other financial investors.
  • Each exchange-formulated WAB Set is based on distinct geographic, quantitative, qualitative, and logistics attributes that can be incorporated into a family of standardized ETD contracts, the specifications of which differ only by the timing and type of settlement taking place.
  • Financially settled contracts linked to WAB Sets - available to all exchange customers - trade similarly to today’s arbitrarily-denoted single asset form benchmark contracts (e.g., Brent or WTI crude oil) typically executed over conventional regulated futures exchanges.
  • Spot and EFP-forward contracts linked to WAB Sets can be traded by qualifying (i.e., dongle-authenticated) customers meeting the exchange’s applicable financial, logistics, and other requirements attendant to delivering/receiving their traded contracts’ underlying assets.
  • CD Index contracts determined by algorithms attendant to the varying qualitative attributes of respective underlying assets being delivered or received. Spot and EFP traders must co-deliver the CD Index contracts as of their contract’s operative physical delivery date. The CD Index contracts, available for trading by all exchange customers, are listed with expiration dates.
  • EFP-forward customers must buy/sell a requisite number of financially settled Forward Point Delivery Differential (“FPDD”) Index contracts computed by algorithms attendant to negotiated timing of respective underlying assets being delivered/received.
  • EFP-forward traders must co-deliver FPDD Index contracts as of their contract’s operative physical delivery date.
  • FPDD Index contracts available for trading by all exchange customers, are listed with expiration dates.
  • Certain qualifying customers can convert their net open long or short cash- settled WAB Set contracts for EFP-forward contracts subject to (i) exchange verifying that sufficient physical assets are available as of those contracts’ operative physical delivery dates; and (ii) the customer buying/selling requisite (algorithm determined) number of CD Index and FPDD Index contracts called for under the circumstances.
  • each one of GLEBS’ standardized-yet-customizable ETD contract families is uniquely formed to enhance transparency, liquidity, and flexibility in a manner that will attract not only a wide range of commercials but also financial investors and speculators.
  • the present disclosure provides novel financial products in the form of Asset-Backed Exchange-Traded Baskets (ABETB’s) and Asset-Backed Mediums of Exchange (ABMoE) comprised of sets of ABETB. Additionally, as shown in FIG.
  • Global d-Bourse serves as a liquidity provider engaged in BCS-based matching of practically opposite assets underlying physically-settled WAB set ETD contracts; serves as an automated market data provider of continuously updated standalone and BCS-based "all-in” bids, offers, and executed orders for WAB, CDI, and FPDDI contracts, as well as for ABETB, ABMoE, and DABMoE, thereby facilitating efficient price discovery; and serves as a provider of BCS-based algorithms applied to the forgoing, the net cumulative effects of which transform WAB set contracts to "all-in" market price indications for respective assets qualifying as underlying members of (i) ABETB and (ii) inventories managed and controlled to meet Exchange affiliates-wide commitments for physically settled spot, forward, and ABETB asset-cycling transactions.
  • the hybrid paradigm comprises digitizing (i.e., securitizing + tokenizing) and managing varying-yet- fungible and cyclable physical asset-backed units, baskets (distinct alternatives to ETF’s backed by futures contracts - e.g., “USO” criticized for exacerbating recent oil market dislocation), and mediums of exchange (DABMoE) that can be financed by repurchase agreements or other debt instruments in special purpose vehicles.
  • the hybrid paradigm further comprises managing the physical assets’ price volatility risks via GLEBS’ diverse ETD hedging solutions.
  • DABMoE can transform a nascent field that’s been dominated to date by native cryptocurrency payment systems (i.e., Bitcoin) and thousands of so-called utility tokens (the latter, called “altcoins”, using funds raised from initial coin offerings or “ICG’s”) since those competitors tend to lack backing of substantive assets other than fiat currencies, and their IT and social networking platforms.
  • native cryptocurrency payment systems i.e., Bitcoin
  • utility tokens the latter, called “altcoins”, using funds raised from initial coin offerings or “ICG’s”
  • Bitcoin and altcoins disregard many trillions of dollars of tangible assets, held globally, in storage facilities or investment venues. Many underutilized fungible assets are ripe for formulation into diversified weighted average DABMoE baskets that can be securitized into units of ownership made eligible for use and trading by wholesale customers over a variety of Global e-Bourse Suites platforms, as well as retail customers of external cryptocurrency exchanges (and related wallet and payment processing apps).
  • GLEBS GLEBS
  • GLEBS art in this field does not emulate existing decentralized crypto-currency solutions. Rather, it provides CPL solutions specifically attuned to ECN’s that employs GLEBS’ synergistic ETD systems, methods, and instruments. The following is a synopsis of the CPL solutions: (1 ) Privacy of transactional data shared with COI is critically important; (2) Data is securely and accurately produced and stored using cryptography; (3) Access involves authentication using keys and cryptographic signatures; and (4) Once stored, all the data is part of an immutable database governed by rules of the ECN.
  • Micro-segmentation is an option that can help customize and secure permissioned ledger systems employed over Global e-Bourse Suites’ ECN.
  • pSeg has become widely recognized as an efficient means of delivering operational agility for network virtualization that is foundational to modern software-defined data center networks. It is increasingly employed in cloud solutions provided by Amazon, Microsoft, VMware, IBM, etc.
  • Agnostic solutions e.g., Unisys Stealth
  • pSeg can keep different parts of Global e-Bourse Suites platforms logically separate via hardware and/or software (defined in above patents as “dongles”) encrypted to maximize security of all authenticated network devices while also controlling (i) access to the ECN, (ii) what data is made available to each server over the ECN, (iii) where data is stored, and (iv) who manages various storage needs within the ECN’s defined communities of interest (“COI”).
  • Dongles defined in above patents as “dongles”
  • pSeg also enables buy and sell orders to be cryptographically authenticated, posted and ultimately matched, executed, and confirmed as trades to be cleared, settled, and reported over ECN in compliance with policies and rules established by the exchange; all accomplishable contemporaneously without use of intermediaries in the chain of communications.
  • Globally compliant cryptography systems - a list which is growing - can be used to effectuate and protect each CPL.
  • pSeg implementation involves loading software to ECN devices, with a management console typically coupled with bits of code that run on IP devices in the ECN. Together, they allow the exchange to layer on controls that decide who gets to do what, and easily enforce those rules at the network packet level.
  • pSeg is identity driven, straight from Active Directory or LDAP systems already in place. It can simply/quickly take control of new or existing enterprises - which will help legacy systems be efficiently transitioned - without the need to deal with challenges like firewall rules, outdated applications, remote users, cloud-based services and 3 rd party attack vectors.
  • FIGS. 1 A-2 show unique data structures of the ABETB-centric order matching system according to the present disclosure.
  • the ABETB-centric order matching system can be implemented on a server (e.g., server 130 shown in FIGS. 3-5 and described below).
  • the data structures improve the functioning of the server implementing a database generally and improve the functioning of the database specifically.
  • the functioning of the server and the database is improved by using a unique referential relationship between the data structures in ways that did not exist in prior art systems and that are faster and more efficient than the prior art systems.
  • the referential relationship between the data structures significantly reduces storage capacity and processing time associated with the database, particularly when the number of tradeable assets is relatively very large.
  • the referential relationship simplifies the operation of the database due to automatic updating of attributes of assets stored in a first data structure in real time as a stream of trading data modifies fields of a second data structure that are referential ⁇ related to the first data structure. Normally many individual calculations and aggregation of results of those calculations would be necessary, which is obviated by the referential relationship between the two data structures, and which allows for real time updating of attributes and valuations of the assets.
  • FIGS. 1 A and 1 B show an example of Asset-Backed Exchange Traded Baskets (ABETB’s) according to the present disclosure.
  • a plurality of ABETB’s comprise a plurality of fungible assets.
  • a first ABETB shown as ABETB-1 10-1
  • ABETB-2 may comprise fungible assets Asset-1 20-1 , Asset-2 20-2, ..., and Asset-N 20-N (collectively assets 20), where N is a positive integer.
  • a second ABETB, shown as ABETB-2 10-2 may comprise fungible assets Asset-1 20-1 , Asset-2 20-2, ..., and Asset-N 20-N (collectively assets 20), where N is a positive integer.
  • An Nth ABETB shown as ABETB-N 10-N, may comprise fungible assets Asset-1 20-1 , Asset-2 20-2, ..., and Asset-N 20-N (collectively assets 20), where N is an arbitrary integer greater than or equal to 1.
  • the ABETB’s ABETB-1 10-1 , ABETB-2 10-2, ..., ABETB-N 10-N, where N is an arbitrary integer greater than or equal to 1 may be collectively called ABETB’s 10. While each ABETB 10 is shown as including the same assets 20, each ABETB 10 can include different assets. Further, each ABETB 10 can include different quantities of each of the assets.
  • FIG. 1 B shows one of the ABETB’s 10 (e.g., the ABETB-N 10-N) in further detail.
  • Each of the ABETB’s 10 may have similar composition.
  • the ABETB 10 includes the assets 20.
  • Each asset 20 has a plurality of attributes, which are shown as Attribute-1 30-1 , Attribute-2 30-2, ..., and Attribute-n 30-n (collectively attributes 30), where n is an arbitrary integer greater than or equal to 1 . While each asset 20 is shown as including the same attributes 30, each asset 20 can include different attributes. Further, each asset 20 can include different number of attributes.
  • each ABETB 10 is a data structure comprising fields associated with assets 20 and subfields associated with attributes 30 of the assets 20.
  • FIG. 2 shows a database 40 comprising first and second data structures 50, 60 according to the present disclosure.
  • the database 40 may be implemented as one of the databases 188 shown in FIGS. 3-5.
  • the first data structure 50 stores the attributes 30 of the assets 20 of the ABETB’s 10.
  • the second data structure 60 comprises a plurality fields 62-1 , 62-2, ..., and 62-N (collectively fields 62), where N is an arbitrary integer greater than or equal to 1 .
  • the fields 62 in the second data structure 60 are referentially related to the attributes 30 of the assets 20 of the ABETB’s 10 stored in the first data structure 50.
  • a data stream comprising trading data associated with the assets 20 is received in the database 40 (e.g., via a distributed communications system 110 shown in FIGS. 3-5), one or more of the fields 62 in the second data structure 60 are modified by the trading data in real time.
  • a change in one or more of the fields 62 in the second data structure 60 automatically and contemporaneously updates one or more attributes 30 of one or more of the assets 20 in the one or more ABETB’s 10 due to the referential relationship between the fields 62 in the second data structure 60 and the attributes 30 of the assets 20 of the ABETB’s 10 stored in the first data structure 50.
  • the referential relationship between the second and first data structures 60, 50 significantly reduces storage capacity and processing time, particularly when the number of underlying assets 20 in the ABETB’s 10 are numerous.
  • the referential relationship simplifies the operation of the database 40 due to the automatic updating of the first data structure 50 in real time as the stream of data modifies the second data structure 60. Normally many individual calculations and aggregation of results of those calculations would be necessary, which is obviated by the referential relationship between the two data structures 50, 60, and which allows for real time updating of the attributes 30 and valuations of the assets 20.
  • a server e.g., server 130 shown and described below with reference to FIGS. 3-5
  • a network e.g., distributed communications system 110 shown and described below with reference to FIGS. 3-5
  • a database e.g., one of the databases 188 shown and described below with reference to FIGS.
  • the database 188 may comprise the first data structure 50 configured to store attributes 30 of fungible assets 20, where the attributes 30 determine market values of the fungible assets 20.
  • the database 188 comprises the second data structure 60 having fields 62 referentially related to the attributes 30 stored in the first data structure 50 such that a change in any one of the fields 62 induces a change in real time in a corresponding one of the attributes 30 in the first data structure 50.
  • the server 130 can receive a stream of data regarding one or more of the attributes 30 of the fungible assets 20 from the network 110.
  • the server 130 can modify one or more of the fields 62 of the second data structure 60 based on the stream of data received from the network 110.
  • the server 130 can allow at least one of cycling, liquidating, and replenishing of one or more of the fungible assets 20 associated with the first data structure 50 based on the modified one or more fields 62 of the second data structure 60.
  • the server 130 can maintain a relative value equivalence of the fungible assets 20 based on the at least one of cycling, liquidating, and replenishing of the one or more of the fungible assets 20 associated with the first data structure 50.
  • the server 130 maintains a plurality of baskets of the fungible assets 20 in the form of data structures in a database (e.g., database 188 shown in FIGS. 3-5).
  • a database e.g., database 188 shown in FIGS. 3-5.
  • each ABETB is a data structure stored in the database
  • each ABMoE generated by the server 130 based on the ABETB’s is also a data structure stored in the database. It follows that the DABMoE’s generated by the server 130 based on the ABMoE’s are also data structures.
  • All of these data structures - the ABETB’s, the ABMoE’s, and the DABMoE’s - are referentially related to the second data structure 60 and are therefore automatically updated based on modifications to the fields 62 of the second data structure 60 made by the trading data received by the server 130 in real time.
  • FIG. 3 shows a simplified example of a distributed computing system 100 that can be used by the ABETB-centric order matching system according to the present disclosure.
  • the system 100 includes a distributed communications system 110, one or more client devices 120-1 , 120-2, ..., and 120-M (collectively, client devices 120), and one or more servers 130-1 , 130-2, ..., and 130-N (collectively, servers 130). M and N are integers greater than or equal to one.
  • the distributed communications system 110 may include a local area network (LAN), a wide area network (WAN) such as the Internet, or other type of network.
  • the client devices 120 and the servers 130 may be located at different geographical locations and communicate with each other via the distributed communications system 110.
  • the client devices 120 and the servers 130 may connect to the distributed communications system 110 using wireless and/or wired connections.
  • the client devices 120 may include smartphones, personal digital assistants (PDAs), tablets, laptop computers, personal computers (PCs), etc.
  • the clients of the ABETB-centric order matching system may use the client devices 120 to interact with the ABETB-centric order matching system via the distributed communications system 110.
  • the client devices 120 may implement the devices used for trading by traders at various financial institutions (e.g., see FIG. 16).
  • the client devices 120 e.g., clients’ mobile phones and/or laptops, the POS system 70, and the recycling machines 14
  • suitable applications shown as client applications 166 in FIG. 4 to perform respective functions (e.g., trading) by interacting with the ABETB-centric order matching system implemented on one or more servers 130 via the distributed communications system 110.
  • One or more of the servers 130 may implement the ABETB-centric order matching system.
  • the servers 130 may provide multiple services to the client devices 120.
  • the servers 130 may execute software applications developed by one or more vendors (shown as applications 186 in FIG. 5).
  • the servers 130 may host multiple databases (shown as 188 in FIG. 5) that are relied on by the software applications and the ABETB-centric order matching system in providing services to users of the client devices 120 (e.g., clients’ mobile phones and/or laptops).
  • the servers 130 implementing ABETB-centric order matching system may be implemented in a cloud.
  • the software applications executed by the servers 130 to implement the ABETB-centric order matching system may be distributed as software- as-a-service (SaaS).
  • FIG. 4 shows a simplified example of the client device 120-1.
  • the client device 120-1 may be any one of the clients’ mobile phones and/or laptops.
  • the client device 120-1 may typically include a central processing unit (CPU) or processor 150, one or more input devices 152 (e.g., a keypad, touchpad, mouse, touchscreen, scanner, etc.), one or more output devices 153 (e.g., a dispenser to dispense cash, coupons, receipts, etc. when the client device 120-1 is the recycling machine 14), a display subsystem 154 including a display 156, a network interface 158, memory 160, and bulk storage 162.
  • CPU central processing unit
  • input devices 152 e.g., a keypad, touchpad, mouse, touchscreen, scanner, etc.
  • output devices 153 e.g., a dispenser to dispense cash, coupons, receipts, etc. when the client device 120-1 is the recycling machine 14
  • a display subsystem 154 including a display 156, a network interface
  • the network interface 158 connects the client device 120-1 to the distributed computing system 100 via the distributed communications system 110.
  • the network interface 158 may include a wired interface (e.g., an Ethernet interface) and/or a wireless interface (e.g., a Wi-Fi, Bluetooth, near field communication (NFC), or other wireless interface).
  • the network interface 158 connects the client device 120-1 to the distributed communications system 110 via a dongle 159, which is described below in detail.
  • the memory 160 may include volatile or nonvolatile memory, cache, or other type of memory.
  • the bulk storage 162 may include flash memory, a magnetic hard disk drive (HDD), and other bulk storage devices.
  • the processor 150 of the client device 120-1 executes an operating system (OS) 164 and one or more client applications 166.
  • the client applications 166 include an application that accesses the servers 130 via the distributed communications system 110.
  • the client applications 166 may include mobile apps that the client devices 120 can use to interact with the ABETB-centric order matching system.
  • FIG. 5 shows a simplified example of the server 130-1.
  • the server 130-1 may implement the ABETB-centric order matching system.
  • the server 130-1 typically includes one or more CPUs or processors 170, a network interface 178, memory 180, and bulk storage 182.
  • the server 130-1 may be a general-purpose server and include one or more input devices 172 (e.g., a keypad, touchpad, mouse, and so on) and a display subsystem 174 including a display 176.
  • the network interface 178 connects the server 130-1 to the distributed communications system 110.
  • the network interface 178 may include a wired interface (e.g., an Ethernet interface) and/or a wireless interface (e.g., a Wi-Fi, Bluetooth, near field communication (NFC), or other wireless interface).
  • the network interface 178 connects the server 130-1 to the distributed communications system 110 via a dongle 179, which is described below in detail.
  • the memory 180 may include volatile or nonvolatile memory, cache, or other type of memory.
  • the bulk storage 182 may include flash memory, one or more magnetic hard disk drives (HDDs), or other bulk storage devices.
  • the processor 170 of the server 130-1 executes an operating system (OS) 184 and one or more server applications 186, which may be housed in a virtual machine hypervisor or containerized architecture, which include the reward system 16.
  • the bulk storage 182 may store one or more databases 188 that store data structures used by the server applications 186 to perform respective functions.
  • the server applications 186 may perform the functions of the ABETB-centric order matching system.
  • the server applications 186 may include the methods shown and described below with reference to FIGS. 6-14.
  • the databases 188 comprise the database 40 comprising the first and second data structures 50, 60 shown and described above with reference to FIGS. 1A, 1 B, and 2.
  • the one or more servers 130, the one or more server applications 186, the one or more databases 188 comprising the data structures 50, 60 collectively implement the ABETB-centric order matching system.
  • FIGS. 6-14 show various methods performed by the ABETB-centric order matching system implemented on the server 130.
  • the methods describe the operations and functions of the ABETB-centric order matching system implemented on the server 130 using the server applications 186, which includes these methods, and using the databases 188, which include the database 40.
  • the term control referenced in the methods below refers to the processor 170 of the server 130 shown and described above with reference to FIGS. 3-5, which executes the server applications 186 using the databases 188 and implements the ABETB-centric order matching system.
  • FIG. 6 shows a method 200 for automatically updating attributes of fungible assets according to the present disclosure.
  • control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure.
  • the two data structures include a first data structure and a second data structure.
  • the first data structure stores the attributes of the fungible assets.
  • the second data structure includes fields that are referential ⁇ related to the attributes of the fungible assets stored in the first data structure. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1 A-2.
  • control receives a stream of data regarding trades of one or more of the fungible assets over the network.
  • control modifies one or more fields of the second data structure based on the stream of data received over the network.
  • control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.
  • FIG. 7 shows a method 220 for maintaining a relative value equivalence of the fungible assets according to the present disclosure.
  • control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure.
  • the two data structures include a first data structure and a second data structure.
  • the first data structure stores the attributes of the fungible assets.
  • the second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1 A-2.
  • control receives a stream of data regarding trades of one or more of the fungible assets over the network.
  • control modifies one or more fields of the second data structure based on the stream of data received over the network.
  • control automatically changes/updates one or more of the attributes of the one or more fungible assets in the first data structure.
  • the modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.
  • control maintains a relative value equivalence of the fungible assets regardless of the trades.
  • FIG. 8 shows a method 250 for maintaining a relative value equivalence of the fungible assets according to the present disclosure.
  • control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure.
  • the two data structures include a first data structure and a second data structure.
  • the first data structure stores the attributes of the fungible assets.
  • the second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1 A-2.
  • control receives a stream of data regarding trades of one or more of the fungible assets over the network.
  • control modifies one or more fields of the second data structure based on the stream of data received over the network.
  • control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure.
  • the modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.
  • control allows at least one of cycling, liquidating, and replenishing of one or more of the fungible assets.
  • control maintains a relative value equivalence of the fungible assets regardless of the cycling, liquidating, and replenishing of one or more of the fungible assets.
  • FIG. 9 shows a method 300 for automatically updating attributes of fungible assets across a set of baskets (e.g., ABETB’s) comprising the fungible assets according to the present disclosure.
  • control maintains a set of baskets of fungible assets in a database.
  • control generates in the database two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure.
  • the two data structures include a first data structure and a second data structure.
  • the first data structure stores the attributes of the fungible assets.
  • the second data structure includes fields that are referentially related to the attributes of the fungible assets stored in the first data structure. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1 A-2.
  • control receives a stream of data regarding trades of one or more of the fungible assets over the network.
  • control modifies one or more fields of the second data structure based on the stream of data received over the network.
  • control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure and across the set of baskets. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure and across the set of baskets.
  • FIG. 10 shows a method 320 for matching buy and sell orders according to the present disclosure.
  • control maintains a set of baskets (e.g., ABETB’s) of fungible assets in a database. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1A- 2.
  • control automatically updates one or more attributes of the one or more fungible assets across the baskets by using referential data structures in the database based on a stream of data received regarding trades of one or more of the fungible assets over the network.
  • control receives buy and sell orders over the network from counterparties for trading one or more of fungible assets in the baskets.
  • control matches the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining a relative value equivalence the fungible assets in the baskets.
  • FIG. 11 shows a method 350 for generating a weighted average benchmark for matching buy and sell orders based on practically opposite rather than absolute opposite trading interests of counterparties according to the present disclosure.
  • control maintains a set of baskets (e.g., ABETB’s) of fungible assets in a database. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1A-2.
  • control generates a weighted average benchmark based on characteristics of a plurality of asset forms of one or more of the fungible assets.
  • control receives buy and sell orders over the network from counterparties for trading one or more of fungible assets in the baskets.
  • control matches the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining a relative value equivalence the fungible assets in the baskets.
  • FIG. 12 shows a method 370 for ensuring that buy and sell orders comply with Sharia law according to the present disclosure.
  • control maintains a set of baskets (e.g., ABETB’s) of fungible assets in a database. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1A-2.
  • control receives buy and sell orders over the network from counterparties for trading one or more of fungible assets in the baskets.
  • control determines whether the buy and sell orders comply with the requirements of Sharia law. Control proceeds to 380 if the buy and sell orders comply with the requirements of Sharia law.
  • control aligns the buy and sell orders with the requirements of Sharia law as described in detail in U.S. Patent No. 10,269,070, which is incorporated herein by reference in its entirety.
  • control matches the orders based on practically opposite rather than absolute opposite trading interests of the counterparties while maintaining a relative value equivalence the fungible assets in the baskets.
  • FIG. 13 shows a method 400 for generating, securitizing, and tokenizing a medium of exchange for trading fungible assets according to the present disclosure.
  • control maintains a set of baskets (e.g., ABETB’s) of fungible assets in a database. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1A-2.
  • control generates a medium of exchange (e.g., ABMoE) based on the set of baskets of the fungible assets in the database and generates a digitized medium of exchange (e.g., DABMoE) therefrom.
  • control securitizes and tokenize the digitized medium of exchange for trading the fungible assets.
  • FIG. 14 shows a method 420 for providing secure transactions between devices used for trading fungible assets across a network (e.g., element 110 shown in FIGS. 3-5) according to the present disclosure.
  • Each device e.g., a server 130 or client device 120 shown in FIGS. 3-5
  • Each device e.g., a server 130 or client device 120 shown in FIGS. 3-5
  • Each device e.g., a server 130 or client device 120 shown in FIGS. 3-5
  • control secures data transfers between the device and the network via a dongle connected to the device.
  • control authenticates access to the server via the dongle connected to the server.
  • control provides transformational data protection via encryption that adds authentication and fault-tolerant information to data transfers between the server and the network.
  • FIG. 15 shows the multiple dimensions impacting data structures developed around BCS-based hybrid paradigm according to the present disclosure, which include the following: Physical assets (e.g., spots and forwards over conventional, Shariabased and countertrade platforms); Financialized assets (e.g., futures and options over conventional exchange-traded derivatives platforms); Digitized assets (e.g., repos for asset financing; ABMoE for barter, and countertrade and other wholesale exchangebased settlements; and DABMoE for cryptocurrencies and other retail exchange-traded products); Order matching and execution directly over one exchange platform or via back-to-back order executions entailing multiple markets and platforms; and so on.
  • Physical assets e.g., spots and forwards over conventional, Shariabased and countertrade platforms
  • Financialized assets e.g., futures and options over conventional exchange-traded derivatives platforms
  • Digitized assets e.g., repos for asset financing; ABMoE for barter, and countertrade and other wholesale exchangebased settlements; and DABMoE for cryptocurrencies
  • FIG. 16 shows the operations performed by an exchange 502 (i.e., by a server at the exchange 502; e.g., the server 130 shown in FIGS. 3-5) in an ABETB-centric order matching system 500 according to the present disclosure.
  • the system 500 comprises the exchange 502 that allows trading of various assets according to the ABETB-centric order matching system 500 of the present disclosure.
  • the assets include tradeable assets from authorized COI 504, tradeable assets from affiliated global e-Souks 506, tradeable assets from affiliated global e-counter 508, tradeable assets from affiliated global e-bourses 510, and tradeable assets from affiliated global e-credit 512.
  • the exchange 502 segregates, manages, and controls asset inventories 514. Additional assets handled by the exchange include currencies including the U.S. dollar and other national currencies 516.
  • the exchange 502 generates ABETB (commodities) 518 and ABETB (credit instruments) 520 as described above.
  • the ABETB (commodities) 518 includes commodity-based ETF’s 522 tradeable in secondary markets.
  • the ABETB (credit instruments) 520 includes credit-based ETF’s 524 tradeable in secondary markets.
  • the exchange 502 generates ABMoE 526 based on ABETB (commodities) 518 and ABETB (credit instruments) 520 as described above.
  • the exchange 502 generates DABMoE 528 and WAB DABMoE 530 as described above.
  • the Exchange 502 formulates ABETB’s 518, 520 for product offerings in their own right or as components of ABMoE 526, whereby baskets emulate BCS-based WAB Sets, each underpinned by a specified plurality of fungible assets having varying quantitative, qualitative, logistics and settlement timing properties.
  • the exchange 502 acts cooperatively in an organization of Exchange affiliates 506-512, their customers and respective COI 504, with fully automated multi-faceted order matching systems employed by integrated computerized trading platforms to optimize organization-wide liquidity by cross-listing products and effectuating back-to-back order executions, as needed, to match practically opposite orders for qualifying assets in ABETB and related Managed and Controlled Inventories 514, all predicated on BCS.
  • the exchange 502 exercises constructive management and control over assets acquired and stored as inventories that can be used in the future to satisfy physical delivery commitments to ETD and other platforms affiliated with the exchange 502, including those assets qualified to underpin ABETB.
  • the exchange 502 exercises constructive management and control over those qualified assets cycled in and out of ABETB and related inventories, in a manner that consistently maintains market value equivalence as practically, rather than absolute, opposite assets are interchanged based on BCS.
  • the exchange 502 continuously maintains a transactional database encompassing all Exchange and affiliates’ ETD contract market prices linked to cash- settled and physically-settled WAB’s and Differential Indexes attendant to EFP spots and forwards, as well as futures, options and swaps.
  • the exchange 502 employs algorithms to determine which Complementary and Forward Point Delivery Differential Indexes should be used to determine the extent to which cash adjustments must be paid or received as part of physically-settled spot, forward, and asset cycling transactions.
  • the exchange 502 otherwise acts as a liquidity provider engaged in BCS- based order matching processes.
  • ABS Asset-backed Exchange-traded basket
  • BCS Benchmark Complex Solutions
  • ABETB’s are comprised of Exchange-specified baskets, emulating Weighted Average Benchmark (“WAB”) Sets linked to Exchange-traded derivatives (“ETD”), in each case underpinned by a plurality of fungible assets having varying quantitative, qualitative, logistics and settlement timing properties whose respective impacts on relative asset value are transparently discoverable via BCS-based Differential Index ETD contracts, the requisite quantities of which are determined by computer implemented algorithms formulated to uniformly maintain equilibrium within the context of macro-level ABETB-wide price movements emulating the operative WAB’s microlevel price movements;
  • WAB Weighted Average Benchmark
  • ETD Exchange-traded derivatives
  • the BCS-based counterparty matching comprises one or more Exchange affiliates configuring weighted average benchmark (“WAB”) sets, with each set linked to an Exchange-specified plurality of qualifying asset forms, rather than arbitrarily denoting one single asset form as the benchmark for all forms of that asset.
  • WAB weighted average benchmark
  • the BCS-based counterparty matching comprises one or more Exchange affiliates identifying and factoring impact of quantitative, qualitative, logistics and settlement timing properties unique to each of the qualifying asset forms serving as a basis of a neutral WAB formulated by the Exchange for an entirety of the set.
  • the BCS-based counterparty matching comprises one or more Exchange affiliates providing a uniform method of allowances for incidences where traders own or are seeking to own varying yet interchangeable physical asset forms, each qualified as a component of an Exchange-specified set, and to offer or bid their specific asset form pursuant to standardized spot or forward EFP contracts requiring settlement by physical delivery or receipt of their respective underlying assets, with each contract’s specifications linked to an operative WAB formulated by the Exchange to cover an entire set of qualified asset forms.
  • the BCS-based counterparty matching comprises one or more Exchange affiliates ensuring that each component in a WAB provides quantitative characteristics, plus varying qualitative, logistics and settlement timing properties customarily adding to or detracting from such asset’s market value, net aggregate effects of which are balanced Exchange-wide by methods comprised of the following.
  • the ECN is controlled by an Exchange.
  • the ECN comprises a host server controlled by the Exchange.
  • the host server is located at a first location.
  • the ECN comprises a plurality of front-end virtual servers communicating with the host server; located at a plurality of locations, respectively; assigned to communities of interest ("COI") authorized by the host server; and authenticated by the host server to cryptographically validate, process, transmit, and receive pre-approved digital information passed along the ECN without using intermediaries.
  • COI communities of interest
  • the ECN comprises a plurality of dongles operating in conjunction with the respective front-end virtual servers and performing the functions comprising the following: controlling access by the front-end virtual servers to the ECN and controlling availability and storage of digital data on the front-end virtual servers; enabling the front-end virtual servers to cryptographically authenticate, post and confirm buy and sell orders for trades ultimately matched, executed, cleared, settled and reported by the host server contemporaneously over the ECN in compliance with policies and rules established by the host server, and without using intermediaries; and facilitating transformational data protection via encryption that adds authentication and fault tolerant information to the digital data.
  • the host server comprises a processor and memory storing machine executable instructions which when executed by the processor perform the following functions: collecting data for a plurality of tradable assets, the data including parameters accounting for qualitative, logistical, supply chain, life cycle settlement timing factors unique to the tradable assets; selecting assets from the tradable assets based on the parameters; generating, based on the selection, sets of tradable assets underlying ABETB’s; generating weights based on a rate denoting estimated global commercial value of a selected tradable asset relative to aggregate estimated global commercial value of all tradable assets underlying the ABETB; generating, using the weights, weighted averages for the ABETB’s; generating specifications for tradable asset baskets based on aggregate weighted averages of the selected tradable assets in a weighted average ABETB; communicating specifications for ABETB to customers and their COI; collecting, generating and communicating, as noted above, for ABMoE comprising sets of ABETB;
  • the host server comprises a back-to-back execution module that reserves a portion of gross segregated tradable asset inventories on hand for each type of asset, the portion optimizing: efficiency of the host server in matching practically, rather than absolutely, the bilateral trading interests of its Exchange affiliates’ counterparties to physically settle their outstanding derivatives orders over a projected future time frame; and ability of the host server to substitute different varying-yet-fungible and cyclable tradable asset forms while managing individual traded assets, ABETB and ABMoE.
  • the tradable assets comprise at least one of the following types: any commodity produced for global consumption and having varying quality, logistics and settlement timing properties or attributes that impact a market place value of the asset; any credit or other financial instrument having varying quality, logistics and settlement timing properties or attributes that impact a market place value of the instrument; any national currency; and any other tradable asset that is subject to the terms of barter or countertrade transaction executed over an Exchange affiliate’s barter and countertrade platform.
  • the host server updates the collected data periodically; updates the Exchange’s specification for tradable assets, ABETB and ABMoE based on the collected and updated data; communicates specifications for tradable assets, ABETB and ABMoE to Exchange customers and their COI; works in cooperation with back-to-back execution module to acquire tradable assets from Exchange members including but not limited to asset producers, trading companies, financial institutions and investors, with such acquisitions transacted over the host server via cash payments, issuance of one or more Exchange memberships, issuance of ABETB and/or ABMoE ownership interests; and works in cooperation with back-to-back execution module to acquire, segregate, manage and control inventories of qualifying tradable assets for purposes of replenishing ABETB’s while satisfying the diverse needs of all Exchange and affiliates counterparties’ spot and forward physically-settled trading interests.
  • the ECN is in communication with at least one of a wide area network and the Internet.
  • the ECN further comprises a server in communication with a computing device used by the COI via the at least one of the wide area network and the Internet.
  • the ABETB’s are single asset baskets designed to emulate WAB Sets linked to Exchange-specified fungible-yet- varying assets, wherein each asset in an ABETB is uniformly valued “all in” at the operative WAB Set market price ⁇ adjustments linked to market prices transparently discovered in connection with cash-settled Complementary and Forward Point Delivery Differential Indexes applicable under the circumstances.
  • the ABETB’s are sets of single asset baskets comprising more diversified offerings, such as the ABMoE developed for barter and countertrade platform disclosed in U.S. Patent No. 9,460,470, and upon being securitized and tokenized, Digitized ABMoE formulated to inter alia provide secondary cryptocurrency markets with substantive alternatives to Bitcoin and altcoins in the field.
  • the ABETB’s are structured to allow each of a single asset basket’s contents to be cycled in and out in exchange for other basket qualifiers as part of a system that practically, rather than absolutely, offsets their respective equivalent values by adjusting the prevailing market price of an operative WAB Set higher or lower to uniformly reflect the impact of applicable Differential Indexes’ market prices, each and all of the aforementioned prices discovered continuously each trading day over transparent computerized trading platforms serving an organization of affiliated Exchanges via integrated ECN and CPL, as elucidated in U.S. Patents No. 9,002,741 , 9,460,470, 10,269,070, and 10,515,115.
  • a back-to-back execution module amalgamates all Exchange affiliates’ customer bids and offers for ultimate execution at the host server pursuant to a cross-liquidity process factoring order flow of each Exchange trading platform and triggers, when necessary, back-to-back executions satisfying the needs of an ABETB that is being formulated for trading or replenished, whereby: the Exchange becomes a counterparty to the ABETB’s required bid or offer; and the host server then posts an offsetting offer or bid of the Exchange, which upon processing by the back-to-back execution module becomes a committed component of the ABETB or Exchange managed and controlled inventories segregated for the sake of providing future liquidity satisfying the needs of all products cross-listed within the organization of affiliated Exchanges.
  • the host server employs inventory management and control systems supporting gross and net segregated tradable assets qualified for present and future inclusion in an ABETB, with such systems employing at least private and public warehouse receipts and shipping certificates that can be reconciled with all tradable assets underpinning the ABETB’s present and future composition.
  • the authorized COI includes at least one of: wholesale commercial and speculator customers of the Exchange; introducing brokers; non-clearing commercial merchants; clearing members of the Exchange or its Exchange affiliates; non-clearing members of the Exchange or its Exchange affiliates; one or more tradable asset inventory control and logistics service providers authorized by the host server; one or more tradable asset securitization and/or tokenization service providers authorized by the host server; one or more clearinghouses either affiliated with the Exchange or independently contracted; one or more trade reporting service firms; and one or more independent regulatory bodies charged with oversight responsibility in connection with the conduct of the Exchange’s trading markets.
  • the ABETB-centric order matching system comprises counterparty matching processes for affiliated computerized trading platforms dealing with commodities, each qualified as a member of an Exchange-formulated basket of varying-yet-fungible commodity forms comprising an ABETB that can be offered as an alternative to certain conventional ETF’s and other financial products.
  • the trading party types are denoted by each respective party at its dongle-enabled sign-in, including the following: Commodity Producers (Sellers) as wholesale customers of the Exchange; Commodity Users (Buyers) as wholesale customers of the Exchange; Exchange Market Makers (covering Buy and Sell sides), including those that are clearing and non-clearing members of the Exchange; Commodity Trading Firms (covering Buy and Sell sides), including those that are clearing and non-clearing members of the Exchange; and Global d-Bourse (covering Buy and Sell sides), on behalf of the Exchange, cooperatively engaging with affiliated Exchanges to perform the following functions:
  • WAB Sets specified for each ABETB and ABMoE formulate WAB Sets specified for each ABETB and ABMoE; enhance Exchange affiliate-wide liquidity by cross-listing ABETB products over multiple platforms to effectuate back-to-back order executions; exercise constructive management and control over assets acquired and stored prior to their use to satisfy physical delivery commitments to ETD and other trading platforms in the affiliated Exchange organization, including assets underpinning ABETB; exercise constructive management and control over assets cycled in and out of ABETB in a manner that contemporaneously maintains “all-in” market value equivalence for each qualifying asset while practically, rather than absolutely, opposite assets are interchanged; maintaining a transactional data base encompassing “all-in” bids and offers attendant to cash-settled and physically-settled ETD contract market prices, Exchange affiliatewide, including EFP spots and forwards, futures, options and swaps linked to an operative WAB, and factoring the impact of BCS-based algorithms directing the extent to which Complementary and Forward Point Delivery Differential Indexes
  • the ABETB-centric order matching system comprises matching processes to fill commodity buy-side orders (iterative until a match is executed).
  • Commodity User posts “all-in” bid data for specific commodity form (the “CUspCF”) that qualifies within a plurality of forms comprising an operative Exchange-formulated WAB Set underpinning an ABETB, with said bid data indicating desired quantity, incoterms and price, as well as Exchange confirmation that Commodity User is logistically and financially qualified to take delivery of the denoted commodity pursuant to the terms of its bid.
  • CUspCF specific commodity form
  • Exchange informs Commodity User whether: matching “all-in” offer(s) for the CUspCF are posted, albeit at higher selling price(s), by one or more of the aforementioned Sellers; or different yet practically equivalent form(s) of the desired commodity, also qualified as a component in the WAB Set’s specified plurality, are available in the quantity sought and at an “all-in” prevailing market price equivalent to that originally sought by the Commodity User with respect to CUspCF.
  • the ABETB-centric order matching system comprises matching processes to fill sell-side orders (iterative until a match is executed).
  • Commodity Producer posts “all- in” offer data for a specific commodity form (the “CPspCF”) that qualifies within a plurality of forms comprising an operative Exchange-formulated WAB Set, with said data indicating desired quantity, incoterms and price, as well as Exchange confirmation that the Commodity Producer is operationally, logistically and financially qualified to make delivery of the denoted commodity pursuant to the terms of its offer.
  • CPspCF specific commodity form
  • the ABETB-centric order matching system comprises counterparty matching processes integral to affiliated Exchanges’ computerized trading platforms employing BCS within an ECN customized to facilitate use of permissioned ledgers, all linked to pluralities of fungible credit instruments qualifying to underpin an ABETB that emulates an Exchange-formulated WAB Set, factoring such quantitative attributes as bond classifications, such as corporate industrials, transports, utilities and financial services, and various types of preferred stocks, leveraged loans, municipals and even Sharia- based Sukuks, and varying qualitative attributes, such as coupon rate of interest, credit quality rating, remaining time to maturity, convertibility and callability, each incorporated into an operative WAB integrated with Complementary Differential and Forward Point Delivery Differential Indexes.
  • the trading party types denoted for each respective party at its dongle-enabled sign-in include: Buyers of physically-settled spot and forward ETD contracts linked to individual credit instruments that qualify as components of an Exchange-formulated WAB Set; Buyers of physically-settled spot and forward ETD contracts linked to an ABETB, qualifying as a component within a plurality underpinning an ABMoE; Sellers of either of the forgoing; Exchange market makers covering both buy and sell sides; and Global d-Bourse covering both buy and sell sides.
  • the ABETB-centric order matching system comprises processes to fill buy side orders (iterative until a match is executed).
  • Buyer posts “all-in” bid data for a specific credit instrument qualifying as a component of ABETB emulating an Exchange- formulated WAB Set, with said bid data including desired quantitative and qualitative properties and price.
  • Exchange compares Buyer’s “all-in” bid data with “all-in” offer data posted by Sellers for the same credit instrument, including offers by Exchange Market Makers, aimed at identifying whether an absolute matching offer exists.
  • Exchange informs Buyer whether: matching offer(s) for the desired asset is posted, albeit at higher “all-in” selling price(s), by one or more of the aforementioned Sellers; or practically equivalent form(s) of the desired asset, qualifying within the WAB Set’s specified plurality, are available in the quantity and at a prevailing “all-in” market price equivalent to what was originally sought by the Buyer.
  • the ABETB-centric order matching system comprises processes to fill sell side orders (iterative until a match is executed).
  • Exchange compares Seller’s “all-in” offer data with “all- in” bid data posted by Buyers, including Exchange Market Makers, aimed at identifying whether absolutely matching bid(s) exist.
  • an order for derivatives contracts based on differences between actual properties of the tradable asset to be physically delivered under the terms of an operative derivatives contract and the aggregate qualities indicated by an operative tradable asset benchmark is processed by a computer implemented algorithm employed to compute the requisite number of long or short Complementary Differential Index-based contracts valuing attendant tradable asset quality or logistics variability, with said contracts being executable for co-delivery on the operative derivatives contract's settlement date.
  • the processor 170 uses the computer implemented algorithm to compute the requisite number of co-deliverable long or short Complementary Differential Index-based contracts, in accordance with operations employing program logic summarized below.
  • the algorithm identifies the extent of a traders open long position, which is the commitment to take physical delivery of Exchange-qualified tradable asset, or the trader's short position, which is the commitment to physically deliver the Exchange-qualified tradable asset, in the operative derivatives contract, each said operative derivatives contract being denominated in a standard unit of volume.
  • the algorithm multiplies the trader's identified open long or short derivatives contract position by a factor, related to the standard unit of volume, which is a predetermined number, times the difference between the tradable asset’s quality or logistics level specified in the operative tradable asset benchmark and the actual level contained in the tradable asset to be physically received or delivered; upon solving that equation the algorithm determines the extent to which the trader must buy or sell Complementary Differential Index contracts based on the factors described as follows:
  • the algorithm multiplies the trader's identified open long or short derivatives contract by a factor, related to the standard unit of volume, which is a predetermined number, time the difference between the quality or logistics level specified in the operative tradable asset benchmark and the actual level contained in the tradable asset to be physically received or delivered; once that equation is solved, the algorithm determines the extent to which the trader must buy or sell Complementary Differential Index contracts based on the factors described as follows.
  • the ABETB-centric order matching system is configured to process orders for Forward Point Delivery Differential Index derivatives contracts based on differences between the actual, desired date for the tradable asset to be delivered under the terms of an operative derivatives contract and the date indicated by an operative tradable asset benchmark, wherein the orders are processed by a processor using an algorithm employed to compute the requisite number of long or short Forward Point Delivery Differential Index-based contracts valuing the tradable asset's forward point delivery variability, with said contracts being structured for co-delivery as of the operative derivatives contract's settlement date.
  • the processor 170 uses the algorithm to compute the requisite number of co-deliverable long or short complementary Forward Point Delivery Differential Index derivatives contracts, in accordance with operations employing program logic summarized below.
  • the processor 170 uses the algorithm, identifies the extent of a trader's open long position, which is a commitment to take physical delivery of exchange-qualified tradable asset, or short position, which is a commitment to physically deliver exchange-qualified tradable asset, in the operative derivatives, and wherein the operative derivatives contract is also known as the underlying EFP contract, and wherein each said operative derivatives contract is denominated in the standard unit of volume.
  • the processor uses the algorithm, multiplies the trader's identified open long or short underlying EFP contract position by the number of trading days forward differing between the delivery date specified in the operative tradable asset benchmark and the actual, desired date specified by the trader for the tradable asset to be physically received or delivered under the underlying EFP contract; upon solving that said equation, the algorithm determines the extent to which traders must buy or sell Forward Point Delivery Differential Index contracts based on the factors described as follows: [0266] Long traders experiencing a contango condition in their underlying EFP contract's market, that is where forward prices exceed spot prices, must buy complementary Forward Point Delivery Differential Index contracts; conversely, long traders experiencing a backwardation condition in their underlying EFP contract's market, that is where spot prices exceed forward prices, must sell Forward Point Delivery Differential Index contracts. Short traders experiencing a contango condition in their underlying EFP contract's market must sell Forward Point Delivery Differential Index contracts. Conversely, short traders experiencing a backwardation condition in their
  • the Exchange continuously provides prevailing “all-in” market values attributable to each tradable asset underpinning an ABETB and imputes cumulative ABETB market values, as well as cumulative ABMoE market values, by computing the sum of those underpinnings, including effects of net cash paid or received to acquire all Differential Index contracts, applicable thereto, processes which negate (or circumvent) the need to employ a conventional multi-basket ETF structure encompassing creation, redemption and holding baskets, respectively, each specifying different assets, and Authorized Parties (“AP’s”) that provide liquidity whenever there is an imbalance of buy and sell orders for ETF shares selling at a premium or discount to the ETF’s net asset value computed at the end of each trading day by the ETF’s Fund Manager.
  • AP Authorized Parties
  • the ABETB-centric order matching system described above with reference to FIGS. 1A-16 can implement multiple layered encoding systems and methods to securely validate, verify, record, trace and track transactions for cryptocurrency (“CC”) specimens.
  • CC cryptocurrency
  • the CC specimens are generated by the server 130 by converting one or more digitized asset-backed mediums of exchange (“DABMoE’s”) comprising one or more Asset-Backed Exchange-Traded Baskets (“ABETB’s) into one or more cryptocurrency specimens.
  • DBMoE digitized asset-backed mediums of exchange
  • ABSETB Asset-Backed Exchange-Traded Baskets
  • Each CC specimen may be structured for transformative fair market price-discovery processes employed to uniquely compile Cumulative Net Asset Values (“CNAV’s) attendant to an operative plurality of underlying components, including but not limited to the following:
  • DBMoE Digitized Asset-Backed Mediums of Exchange
  • ABSETB Asset-Backed Exchange-Traded Baskets
  • the multiple encoding systems and methods implemented on the server 130 and the client devices 120 employ several layers (described below) of crypto-modules, keying processes, and related algorithms to validate CC specimen transactions, instead of the costly and wasteful proof-of-work (“POW”) CC mining-based processes used by legacy cryptocurrencies.
  • a first layer developed by the Originator is encoded onto DABMoE units placed into secondary CC markets, denoting that the Originator:
  • a third layer is generated when a dongle-authenticated ECCEO shares its access to the Exchange Network’s operative CNAV price discovery systems and methods described above with reference to FIGS. 1A-16 with qualifying CC usercustomers via interactive graphic user interfaces implemented on the client devices 120 configured to: report the latest bids, offers, and executed prices attendant to each underlying CNAV component; and enable each user-customer to post counter prices of CNAV components per iterative processes culminating in the ultimate execution of CC transactions assigned a specific date and stamp, user ID (e.g., dongle ID, ID of the client device 120, etc.), execution price, etc. This information is added to the transaction history that is used to encode the transaction.
  • user ID e.g., dongle ID, ID of the client device 120, etc.
  • This encoding allows the server 130 to verify that DABMoE unitary ownership interests are validly linked to the CC specimens placed in and removed from external circulation, which guards against future threats of manipulated or falsified transactions that may be perpetrated in the field.
  • the encoding allows the server 130 to securely validate, verify, record, trace and track transactions for cryptocurrency specimens without using the POW mining-based processes used by legacy cryptocurrencies.
  • the ECCEO’s non-POW cryptocurrency consensus mechanism implemented on the server 130 validates executed transactions attendant to all CC specimens encoded with the three layers of encryption described above.
  • the periodically reported information includes but is not limited to: quantities issued by the Originator to each ECCEO and in total, less any redemptions, thus arriving at net quantities outstanding; quantities transferred among ECCEO’s in connection with their user-customers’ transactions (e.g., buying, selling, spending, transfers, etc.); quantities held by ECCEO’s on behalf of their user-customers; quantities held privately by user-customers; and based on the forgoing, and respective CC specifications established by the Originator, extended unitary quantities and market values of operative DABMoE’s and their underlying ABETB’s.
  • each CC specimen is unique due to the specific but varied composition of the underlying assets in one or more ABETBs that back each CC specimen.
  • the legacy cryptocurrency is simply subdivided into subunits of the legacy cryptocurrency, where the subunits again represent the same legacy cryptocurrency, just when a dollar is subdivided into quarters, and the quarters are further subdivide into dimes and cents, the subunits still represent the dollar.
  • each subunit CC specimen resulting from the subdivision of the prior CC specimen can be different depending on how the prior CC specimen is subdivided. That is, the composition of each subunit of the CC specimen depends on the composition of the underlying assets that compose each subunit of the CC specimen upon the division of the CC specimen. Therefore, not only one CC specimen can differ from another CC specimen, but each subunit of a CC specimen can be unlike another subunit of the same CC specimen. Accordingly, unlike the legacy cryptocurrencies, valuations of which fluctuate unpredictably based on pure speculation, the valuations of the CC specimens vary based on variations of the underlying assets that back the CC specimens, which are not purely speculative.
  • the CC specimens are asset-backed, the CC specimens are not merely derivatives of the assets that back them. Rather, the digitized asset-backed mediums of exchange comprising ABETB’s are converted into various cryptocurrency specimens, and multiple layers of encoding are applied thereto, which allows secure validation, verification, recording, tracing, and tracking of transactions related to the cryptocurrency specimens.
  • the server 130 which implements the ABETB-centric order matching system as described above with reference to FIGS. 1A-5, further securely validates, verifies, records, traces, and tracks transactions for the cryptocurrency specimens using a three-layer coding system implemented by performing the methods described below.
  • the server 130 performs these methods in addition to (i.e., in conjunction) with the methods described above with reference to FIGS. 6-14.
  • FIGS. 17 and 18 show various methods performed by the ABETB-centric order matching system implemented on the server 130 for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens according to the present disclosure.
  • FIG. 17 shows a method 1000 for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens according to the present disclosure.
  • control generates a database comprising two data structures that allow automatically updating the attributes of the fungible assets according to the present disclosure.
  • the two data structures include a first data structure and a second data structure.
  • the first data structure stores the attributes of the fungible assets.
  • the second data structure includes fields that are referential ⁇ related to the attributes of the fungible assets stored in the first data structure. For example, see the database 40 and the first and second data structures 50, 60 shown and described above with reference to FIGS. 1 A-2.
  • control receives a stream of data regarding trades of one or more of the fungible assets over the network.
  • control modifies one or more fields of the second data structure based on the stream of data received over the network.
  • control automatically changes one or more of the attributes of the one or more fungible assets in the first data structure. The modification of one or more fields of the second data structure based on the received stream of data induces automatic changes to one or more attributes of the one or more fungible assets in the first data structure.
  • control allows at least one of cycling, liquidating, and replenishing of one or more of the fungible assets.
  • control maintains a relative value equivalence of the fungible assets regardless of the cycling, liquidating, and replenishing of one or more of the fungible assets.
  • control maintains a set of baskets of fungible assets in the database.
  • control generates a medium of exchange (e.g., ABMoE) based on the set of baskets of the fungible assets in the database and generates a digitized medium of exchange (e.g., DABMoE) therefrom.
  • ABMoE medium of exchange
  • control converts the digitized asset-backed mediums of exchange into various cryptocurrency specimens.
  • control securely validates, verifies, records, traces, and tracks transactions for the cryptocurrency specimens using a three-layer encoding system, which is described below in detail with reference to FIG. 18.
  • Control securely validates, verifies, records, traces, and tracks transactions for the cryptocurrency specimens without using proof-of work mining based processes.
  • FIG. 18 shows a method 1050 for securely validating, verifying, recording, tracing, and tracking transactions for cryptocurrency specimens using the three-layer encoding system according to the present disclosure.
  • control securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the first layer of encoding, which comprises encoding the digitized asset-backed mediums of exchange with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange.
  • control verifies, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the cryptocurrency specimens placed in and removed from external circulation.
  • control provides cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the transactions for access using the dongle-based authentication system.
  • the dongle-based authentication system is employed by both the server 130 and the client devices 120 to provide end-to-end encryption between the server 130 and the client devices 120, in addition to authenticating access by the client devices 120 to the server 130.
  • the dongles provide transformational data protection via encryption that adds authentication and fault tolerant information to data transfers between the server 130 and the network 110.
  • control securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the second layer of encoding, which comprises implementing one or more application programming interfaces (e.g., on the server 130) that allow the users (e.g., the client devices 120) dongle-based access to view and evaluate continuously updated and compiled price discovery data related to the net cumulative values of the cryptocurrency specimens.
  • application programming interfaces e.g., on the server 130
  • control securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the third layer of encoding, which comprises: interfacing, using the one or more application programming interfaces (e.g., implemented on the server 130), with one or more graphical user interfaces (e.g., implemented on client devices 120) configured to provide bids, offers, and executed prices attendant to each underlying net cumulative value component to the users.
  • application programming interfaces e.g., implemented on the server 130
  • graphical user interfaces e.g., implemented on client devices 120
  • control interfaces using the one or more application programming interfaces (e.g., implemented on the server 130), with one or more graphical user interfaces (e.g., implemented on client devices 120) configured to allow the users to post counter prices of net cumulative value components via iterative processes culminating in execution of the transactions of the cryptocurrency specimens with a specific date and time stamp, user ID (e.g., dongle ID, ID of the client device 120, etc.), execution price, etc.
  • the CC specimen transaction is ready for application of the ECCEO’s other legacy cryptographic consensus mechanisms, examples of which are summarized below.
  • control accounts for and reconciles periodically reported information for each unitary ownership-based cryptocurrency specimen in circulation over the network.
  • the server 130 securely validates, verifies, records, traces, and tracks the transactions for the cryptocurrency specimens by using the three-layer encoding system described above instead of using the conventional proof-of-work mining based processes.
  • the server 130 can securely validate, verify, record, trace, and track the CC specimen transactions using other legacy cryptographic consensus mechanisms, which include proof of work (POW) and other alternatives to proof of work (POW).
  • legacy cryptographic consensus mechanisms include the following.
  • Proof of stake This method uses a randomized process to figure out which miner get a chance to produce the next block.
  • Blockchain users can lock up their tokens for a certain time for becoming a validator. After becoming a validator, a user can produce blocks.
  • Validators can also be selected based on the design of blockchain. Generally, a user who owns the biggest stake or owns coins for the longest period of time has better odds of creating a new block.
  • the validators usually get rewarded for their work with all or part of transaction fees of all the transactions carried out in the block they created. Alternatively, the validators may receive a specific amount of coins due to inflation.
  • the proof of stake method offers incentives to validators for maintaining the blockchain network. This method is more energy efficient compared to other blockchain consensus mechanisms like proof of work.
  • Delegated proof of stake In this process, users can stake their coins and vote for a particular number of delegates to create a new block. The weight of a user’s vote is based on the user’s stake. The delegate that receives the highest number of votes gets a chance to produce new blocks. The delegates get rewarded with transaction fees or a specific amount of coins similar to other blockchain consensus mechanisms such as proof of stake. This mechanism is one of the fastest blockchain consensus mechanisms and can handle a higher number of transactions than the proof of work mechanism.
  • Proof of identity This method compares a private key of a user with an authorized identity.
  • Proof of Identity is cryptographic evidence for a user’s private key that is cryptographically attached to a specific transaction. Any identified user from a blockchain network can create a block of data that can be presented to anyone in the network. This method ensures integrity and authenticity of created data.
  • Proof of authority This mechanism is a modified version of proof of take where identities of validators in the network are at stake.
  • identity is the correspondence between a validators’ personal identification and the validator’s official documentation used to verify the validator’s identity.
  • the validators stake their reputation on the network.
  • nodes that become validators are the only ones allowed to produce new blocks.
  • the validators whose identities are at stake are incentivized to secure and preserve the blockchain network. The number of validators is generally relatively small.
  • Proof of activity This mechanism is a combination of proof of work and proof of stake. In this method, miners try to find the solution to a puzzle and claim their reward. However, the blocks created in this mechanism are simple templates with mining reward address and header information. The header information is used to select a random group of validators for signing a block. The validators with larger stakes can have greater odds of being selected to sign a new block. After the selected validators sign a new block, the signed block becomes a part of the network. If a block remains unsigned by some validators, the block is discarded and a new block is utilized. The network fees generated in the process are distributed between a winning miner and the validators.
  • the ABETB-centric order matching system described above with reference to FIGS. 1A-18 and the system and method described below with reference to FIGS. 19 and 20 can implement systems and methods to generate and transmit market data streams derived from the trading of Exchange-formulated tokens backed by cash-settled Exchange Traded Derivatives (ETD) contracts linked to Weighted Average Benchmarks, Complementary Differential Indexes, and Forward Point Delivery Differential Indexes, which on a standalone basis enhance Benchmark Complex Solutions-based price discovery processes (“BCSBPDP”) developed for fungible physical assets underpinning the CC Specimens described above.
  • ETD Exchange Traded Derivatives
  • the tokens can be bought and sold over subnetworks directed by Exchange-affiliated Futures Commission Merchant (FCM) Clearing Firms where distributed ledger technologies and consensus mechanisms, as well as multiple encryption and encoding schemes cooperatively developed by the Exchange and its FCM’s are used to more securely and efficiently validate, verify, record, trace, and track transactions whose market prices and related data are contemporaneously streamed into the ECN-accessible BCSBPDP, thereby increasing liquidity within the Exchange organization beyond that generated by the physical settlement based multi-platforms and -markets forming its Hybrid Paradigm.
  • the tokens may also be bought and sold over subnetworks directed by foreign exchanges or boards of trade employing similar systems and methods.
  • the systems and methods described with reference to FIGS. 1A-20 address challenges posed by high-frequency and algorithmic trading protocols.
  • DLT distributed ledger technology
  • Exchange organizations and traders tend to experience major challenges attempting to confirm and reconcile continually adjusted (due to the myriad of bids and offers being posted and cancelled iteratively) order execution data with compliant post-trade data needed for timely clearance, settlement, and reporting of all ETD contracts bought, sold, and held as open interest under high-frequency and algorithm-based trading protocols.
  • Such challenges are exacerbated by relative disparities in communications systems and links, likely caused by Exchange organizations deciding to maximize order and transactional liquidity for the sake of revenue growth while being reluctant or unable to get slower and less efficient back- office processes up to speed.
  • the systems and methods described with reference to FIGS. 1A-20 overcome these challenges by employing Exchange-authorized order matching systems, subnetworks, and DLT systems directed by FCM Clearing Firms.
  • the systems and methods use distributed consensus mechanism(s) to validate executed customer orders, information about which can then be routed to update all impacted files and ledgers belonging to authorized COI members. Included in the COI is the Exchange’s owned or contracted Data Reporting Service, which upon receipt of requisite validated trade information, packages trade information into reports routed to the ECN-Accessible price discovery system described above as well as to other subscribers of the ECN.
  • Tokens present standalone trading opportunities appealing to speculators and other financial interests, especially those exploiting use of high-frequency and other algorithm-based trading protocols, the tokens are capable of generating large trading volumes adding substantial liquidity to ECN-accessible price discovery processes previously defined by this Inventor.
  • the system and method described below produce that result.
  • FCM Clearing Firms are entities that are registered with applicable regulatory bodies (e.g., the National Futures Association and the Commodity Futures Trading Commission) and comply with their various rules, guidelines, and oversight regarding minimum regulatory capital, risk management, customer funds segregation, operational capacity and expertise, etc.
  • FCMs are authorized to perform the following operations (a non-exhaustive list is provided): solicit or accept orders to buy or sell futures contracts or options on futures in the open market; act as market makers that take positions opposite to customer orders for the purpose of providing market liquidity; accept money or other assets from customers to support their orders; affiliate with one or more Exchange organizations, which requires them to hold substantial deposits with the Clearinghouses (“CHs”) of which they are members; properly segregate each customer’s funds from their own, as well as those of other parties; make margin calls and collect margin funds or return them to customers per CH requirements since customers generally do not have direct relationships with CHs; in fact, the CH looks to its member FCM Clearing Firms for financial performance as guarantors and “as if principals”; and ensure asset deliveries are made by the time futures contracts expire.
  • CHs Clearinghouses
  • both the Exchange and its affiliated or contracted CH may benefit by relying on the use of one or more subnetworks serving as logical extensions of the ECN described above with reference to FIGS. 1A-18 to at least: allocate additional address space among each FCM Clearing Firm and its respective COI members; increase routing efficiency of orders executed, validated, and reported; and accommodate post-trade DLT-systems designed to provide efficient controls over inter alia operational, administrative, accounting, and reporting functions.
  • multiple encryption and encoding systems are employed to: identify the Exchange as the party responsible for (a) specifying and circulating the ETD Contracts underpinning Tokens formulated for trading over subnetworks organized around FCM Clearing Firms; and (b) ensuring that interoperable distributed ledger technology (“DLT”) systems and methods are implemented and practiced; grant all dongle-authenticated Token traders ECN- Access (as described above with reference to FIGS.
  • DLT distributed ledger technology
  • FIGS. 19 and 20 The system works in conjunction with the systems and methods described above with reference to FIGS. 1A-18.
  • the system and method is implemented partially in the server 130 and partially in servers 1104 described below.
  • the servers 1104 may be structurally similar to the servers 130.
  • Client devices 1106 and 1108 described below may be structurally similar to the client devices 120.
  • the functionalities of the servers 1104 and the client devices 1106 and 1108 are described below in detail.
  • FIG. 19 shows a system 1100 for trading the tokens according to the present disclosure.
  • the system 1100 comprises the system 100 shown in FIG. 3 and further comprises a plurality of subnetworks 1102-1 , ..., and 1102-N (collectively the subnetworks 1102), where N is a positive integer.
  • the subnetworks 1102 are part of the ECN represented by the system 100 shown in FIG. 3. In general, the subnetworks 1102 are similar to the distributed communications system 110 shown in FIG. 3.
  • Each of the subnetworks 1102 is controlled separately from the ECN. Specifically, each of the subnetworks 1102 is controlled by a respective FCM clearing firm. Each FCM clearing firm may work with traders and customers that trade the tokens using the respective subnetwork 1102.
  • each FCM clearing firm may use client devices to communicate with the servers of the FCM clearing firm via the subnetworks controlled by the FCM clearing firm. While each subnetwork 1102 is shown as comprising one server for simplicity of illustration, each subnetwork 1102 may comprise multiple servers connected to the subnetwork 1102.
  • a first FCM clearing firm may control a first subnetwork 1102-1.
  • the first subnetwork 1102-1 may comprise a server 1104-1 and client devices 1106-1 , ..., and 1106-M (collectively the client devices 1106), where M is a positive integer.
  • An N th FCM clearing firm may control an N th subnetwork 1102-N.
  • the N th subnetwork 1102-N may comprise a server 1104-N and client devices 1108-1 , ..., and 1108-P (collectively the client devices 1108), where P is a positive integer.
  • the server (or servers) 130 of the ECN may be called the Exchange server 130 or ECN server 130, and the servers 1104 of the subnetworks 102 may be called the subnetwork servers 1104. The operations of the servers 1104 and 130 and the client devices 1106 and 1108 are now described below with reference to FIG. 20.
  • the system 100 comprises the ECN server 130 and further comprises one or more of the subnetworks 1102.
  • the ECN server 130 is configured to generate tokens based on one or more of the fungible assets for trading over one or more subnetworks 1102 that are controlled separately from the ECN server 130. While the ECN server 130 is controlled by the ECN, the subnetworks 1102 and the subnetwork servers 1104 are controlled by the FCM clearing firms.
  • the ECN server 130 receives trading data associated with the trading of the tokens from the one or more subnetworks 1102 in the stream of data received by the ECN server 130 to update the attributes and valuations of the fungible assets underpinning the cryptocurrency specimens.
  • the one or more subnetworks 1102 comprises the respective subnetwork servers 1104 configured to securely validate, verify, record, trace, and track the trades of the tokens by: encoding the tokens with a history of attributes and activities unique to the one or more of the plurality of baskets underpinning the digitized asset-backed mediums of exchange; verifying, using the encoding, that unitary ownership interests associated with the digitized asset-backed mediums of exchange are validly linked to the tokens placed in and removed from external circulation; and providing cryptographic keys for a dongle-based authentication system to create immutable and traceable data and records of the trades for access using the dongle-based authentication system.
  • the subnetwork servers 1104 are configured to process buy and sell orders from counterparties for trading the tokens and to match, clear, and settle the orders based on absolute opposite trading interests of the counterparties and to provide liquidity to the counterparties for the settled orders.
  • the subnetwork servers 1104 are configured to securely validate, verify, record, trace, and track the trades of the tokens by implementing one or more application programming interfaces that allow traders dongle-based access to the ECN server 130 to view and evaluate continuously updated price discovery data compiled at the ECN server 130.
  • FIG. 20 shows a method 1150 performed by the subnetwork servers 1104 and the ECN server 130 for securely validating, verifying, recording, tracing, and tracking transactions for the tokens and providing liquidity and price discovery for the transactions according to the present disclosure.
  • the method 1150 describes the operations and functions of the system 1100 implemented on the subnetwork servers 1104 and the ECN server 130, which include the server applications 186 and the databases 188.
  • the server applications 186 of the subnetwork servers 1104 implement the method 1150 using the databases 188 of the subnetwork servers 1104.
  • a portion of the method 1150 is implemented on the ABETB-centric order matching system implemented on the ECN server 130 using the server applications 186 and the databases 188 of the ECN server 130.
  • control referenced in the method 1150 below refers to the processors 170 of the servers 1104 and 130 shown and described above with reference to FIGS. 3-5, which execute the server applications 186 using the databases 188 of the servers 1104 and 130.
  • the subnetwork servers 1104 implement the three-layer encoding and encryption system, which is implanted by the ECN server 130 as described above with reference to FIGS. 6-14.
  • the ECN server 130 generates tokens based on one or more fungible assets for trading over the separately controlled subnetworks 1102.
  • the subnetwork servers 1104 provide dongle-based access to the ECN server 130 for price discovery and allow users (e.g., traders) to place orders from trading the tokens.
  • the subnetwork servers 1104 validate, verify, record, trace, and track the traded tokens using the encryption and encoding schemes and consensus mechanisms described above.
  • the subnetwork servers 1104 provide token trading counterparties with liquidity, order matching, clearing, and settlement.
  • the subnetwork servers 1104 provide the validated trading data for the tokens to the ECN server 130 via the separately controlled subnetworks 1102.
  • the ECN server 130 uses the validated trading data received from the subnetwork servers 1104, the ECN server 130 updates the attributes and valuations of the fungible assets underpinning the CC specimens.
  • the subnetwork servers 1104 provide APIs to allow token traders’ client devices 1106 and 1108 dongle-based access to the ECN server 130 to view and evaluate continuously updated price discovery data compiled at the ECN server 130.
  • the system 1100 and the method 1150 can be used to trade Exchange-specified Tokens underpinned by (a) cash-settled ETD contracts linked to WAB’s, Complementary Differential Indexes and Forward Point Delivery Differential Indexes, unique combinations of which are configured to value a WAB Set’s qualifying fungible assets whose market prices are associated with data structure referencing described above with reference to FIGS. 1A-18; and (b) systems, methods, and instructional specifications developed by the Exchange in cooperation with its FCM Clearing Firms, as described above with reference to FIGS.
  • the system 1100 and the method 1150 utilize the three layers of cryptomodules, keying processes, and encoding described above with reference to FIGS. 1A-18 as follows.
  • Layer 1 when the ECN server 130 formulates the Tokens for trading over conventional ETD markets implemented by the subnetworks 1102, the ECN server 130 assign a cryptographic vintage ID for each Token upon its origination.
  • the ECN server 130 in cooperation with its Clearing FCM’s controlling the subnetworks 1102 (e.g., the subnetwork servers 1104), grants qualifying dongle-authenticated customers (e.g., the client devices 1106 and 1108) access to the ECN server 130 to view and assess operative the Tokens’ price discovery information in the manner described above with reference to FIGS. 1A-18.
  • the Clearing FCM customers e.g., the subnetwork servers 1104 and the client devices 1106 and 1108
  • access the ECN server 130 access the Token price discovery information compiled on the ECN server 130, and undertake order executions via the use of a GUI implemented on the subnetwork servers 1104 and the client devices 1106 and 1108.
  • the system 1100 and the method 1150 utilize permissioned DLT and distributed consensus protocols implemented on the subnetworks 1102 and the subnetwork servers 1104 as follows.
  • the FCM Clearing Firms e.g., the subnetworks 1102 and the subnetwork servers 1104 therein
  • the ECN server 130 uses the distributed consensus protocols to validate the customers’ executed orders (e.g., via the client devices 1106 and 1108), at which point they can be registered onto reports transmitted by contracted or affiliated data service providers that are members of the Exchange’s COI.
  • the reported validated market data (e.g., last bids, offers, trades, open interest and related prices and quantities) is transmitted inter alia from the subnetworks 1102 and the subnetwork servers 1104 to the ECN server 130 and becomes part of the continuously provided data streams as described above with reference to FIGS. 1A-18, which dongle-authenticated COI with ECN-access - including CC exchanges and their retail user-customers - can review and assess as part of their operative price discovery processes.
  • the state of the art in the DLT field is advanced by synergy generated when the ECN server 130 complements permissionless (for underlying ETD contracts’ executed and validated orders) with permissioned (for purposes of establishing and maintaining the ledgers of its FCM Clearing Firms and their COI) systems to facilitate enhanced security for attendant Tokens.
  • the system 1100 and the method 1150 implemented on the servers 1104 and 130 perform all of the functions and operations described above, which overcome the challenges described above by employing Exchange-authorized order matching systems, the subnetworks 1102, and DLT systems directed by FCM Clearing Firms.
  • the system 1100 and the method 1150 use distributed consensus mechanism(s) to validate executed customer orders, information about which can then be routed to update all impacted files and ledgers belonging to authorized COI members. Included in the COI is the Exchange’s owned or contracted Data Reporting Service, which upon receipt of requisite validated trade information, packages trade information into reports routed to the ECN-Accessible price discovery system implemented on the ECN server 130 described above as well as to other subscribers of the ECN.
  • the system 1100 and the method 1150 implemented on the subnetwork servers 1104 and 130 focus on trading and hedging Exchange-formulated Tokens underpinned by certain cash-settled ETD contracts: conventional-style futures linked to specified WAB’s, Complementary Differential Indexes and Forward Point Delivery Differential Indexes integral to implementing BCS. Since such Tokens present standalone trading opportunities appealing to speculators and other financial interests, especially those exploiting use of high-frequency and other algorithm-based trading protocols, the tokens are capable of generating large trading volumes adding substantial liquidity to ECN-accessible price discovery processes previously defined by this Inventor. The 1100 and the method 1150 described above produce that result and provide the advancements to the state of the art described above.
  • the system 1100 and the method 1150 implemented on the subnetwork servers 1104 generate and transmit market data streams derived from the trading of Exchange-formulated tokens backed by cash-settled ETD contracts linked to Weighted Average Benchmarks, Complementary Differential Indexes, and Forward Point Delivery Differential Indexes, which on a standalone basis enhance the Benchmark Complex Solutions-based price discovery processes (“BCSBPDP”) developed for fungible physical assets underpinning the CC Specimens described above.
  • BCSBPDP Benchmark Complex Solutions-based price discovery processes
  • the tokens can be bought and sold over the subnetworks 1102 directed by the Exchange-affiliated FCM Clearing Firms where distributed ledger technologies and consensus mechanisms, as well as multiple encryption and encoding schemes cooperatively developed by the Exchange and its FCM’s are used to more securely and efficiently validate, verify, record, trace, and track transactions whose market prices and related data are contemporaneously streamed into the ECN-accessible BCSBPDP, thereby increasing liquidity within the Exchange organization beyond that generated by the physical settlement based multi-platforms and -markets forming its Hybrid Paradigm.
  • the phrase at least one of A, B, and C should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR, and should not be construed to mean “at least one of A, at least one of B, and at least one of C.”
  • the direction of an arrow generally demonstrates the flow of information (such as data or instructions) that is of interest to the illustration.
  • information such as data or instructions
  • the arrow may point from element A to element B. This unidirectional arrow does not imply that no other information is transmitted from element B to element A.
  • element B may send requests for, or receipt acknowledgements of, the information to element A.
  • module or the term “controller” may be replaced with the term “circuit.”
  • the term “module” may refer to, be part of, or include: an Application Specific Integrated Circuit (ASIC); a digital, analog, or mixed analog/digital discrete circuit; a digital, analog, or mixed analog/digital integrated circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code; a memory circuit (shared, dedicated, or group) that stores code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip.
  • ASIC Application Specific Integrated Circuit
  • FPGA field programmable gate array
  • the module may include one or more interface circuits.
  • the interface circuits may include wired or wireless interfaces that are connected to a local area network (LAN), the Internet, a wide area network (WAN), or combinations thereof.
  • LAN local area network
  • WAN wide area network
  • the functionality of any given module of the present disclosure may be distributed among multiple modules that are connected via interface circuits. For example, multiple modules may allow load balancing.
  • a server (also known as remote, or cloud) module may accomplish some functionality on behalf of a client module.
  • code may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, data structures, and/or objects.
  • shared processor circuit encompasses a single processor circuit that executes some or all code from multiple modules.
  • group processor circuit encompasses a processor circuit that, in combination with additional processor circuits, executes some or all code from one or more modules. References to multiple processor circuits encompass multiple processor circuits on discrete dies, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above.
  • shared memory circuit encompasses a single memory circuit that stores some or all code from multiple modules.
  • group memory circuit encompasses a memory circuit that, in combination with additional memories, stores some or all code from one or more modules.
  • the term memory circuit is a subset of the term computer-readable medium.
  • the term computer-readable medium does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); the term computer-readable medium may therefore be considered tangible and non-transitory.
  • Non-limiting examples of a non-transitory, tangible computer-readable medium are nonvolatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).
  • nonvolatile memory circuits such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit
  • volatile memory circuits such as a static random access memory circuit or a dynamic random access memory circuit
  • magnetic storage media such as an analog or digital magnetic tape or a hard disk drive
  • optical storage media such as a CD, a DVD, or a Blu-ray Disc
  • the apparatuses and methods described in this application may be partially or fully implemented by a special purpose computer created by configuring a general- purpose computer to execute one or more particular functions embodied in computer programs.
  • the functional blocks, flowchart components, and other elements described above serve as software specifications, which can be translated into the computer programs by the routine work of a skilled technician or programmer.
  • the computer programs include processor-executable instructions that are stored on at least one non-transitory, tangible computer-readable medium.
  • the computer programs may also include or rely on stored data.
  • the computer programs may encompass a basic input/output system (BIOS) that interacts with hardware of the special purpose computer, device drivers that interact with particular devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, etc.
  • BIOS basic input/output system
  • the computer programs may include: (i) descriptive text to be parsed, such as HTML (hypertext markup language), XML (extensible markup language), or JSON (JavaScript Object Notation) (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc.
  • source code may be written using syntax from languages including C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK, and Python®.
  • languages including C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMU

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un serveur connecté à un réseau générant une base de données comprenant une première structure de données configurée pour stocker des attributs d'actifs fongibles, où les attributs déterminent les valeurs de marché des actifs fongibles, et une seconde structure de données ayant des champs liés de manière référentielle aux attributs stockés dans la première structure de données de sorte qu'un changement dans l'un quelconque des champs induit un changement en temps réel dans un attribut correspondant dans la première structure de données. Le serveur reçoit un flux de données concernant les attributs des actifs gérables provenant du réseau, modifie les champs de la seconde structure de données, et permet le cyclage, la liquidation et le réapprovisionnement d'un ou de plusieurs des actifs gérables tout en maintenant une équivalence de valeur relative des actifs gérables. Le serveur validé de manière sécurisée, vérifie, enregistre, trace et suit des transactions pour des spécimens de cryptomonnaie. Le serveur génère des jetons sur la base des actifs gérables pour un échange sur des sous-réseaux et fournit une découverte de prix.
PCT/US2023/011193 2022-01-20 2023-01-20 Structures de données référentielles pour la mise à jour automatique d'attributs d'actifs en temps réel sur la base de données transmises en continu WO2023141241A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/580,272 2022-01-20
US17/580,272 US11403655B1 (en) 2020-10-13 2022-01-20 Referential data structures for automatically updating asset attributes in real time based on streaming data

Publications (1)

Publication Number Publication Date
WO2023141241A1 true WO2023141241A1 (fr) 2023-07-27

Family

ID=87349117

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/011193 WO2023141241A1 (fr) 2022-01-20 2023-01-20 Structures de données référentielles pour la mise à jour automatique d'attributs d'actifs en temps réel sur la base de données transmises en continu

Country Status (1)

Country Link
WO (1) WO2023141241A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8046286B2 (en) * 2005-02-16 2011-10-25 SRI, Inc., Prisma & Company, Inc. Systems and methods for implementing the structuring, pricing, quotation, and trading of SPOT synthetics (SPOTS), SPREAD instruments (SPRINTS), SPRINTS based on SPOTS, ratio derivatives (RADS), RADS based on SPOTS, and options based on these instruments
US20130036039A1 (en) * 2011-08-01 2013-02-07 Rohlfs Michael B System for market hedging and related method
US20150278915A1 (en) * 2014-03-26 2015-10-01 Auction.Com, Llc Recommendation system for non-fungible assets
KR20210050525A (ko) * 2018-08-10 2021-05-07 티제로그룹, 인코포레이티드 분할 가능한 증권형 토큰
US11107160B2 (en) * 2020-10-13 2021-08-31 Dearborn Financial, Inc. Referential data structures for automatically updating asset attributes in real time based on streaming data
US11403655B1 (en) * 2020-10-13 2022-08-02 Dearborn Financial, Inc. Referential data structures for automatically updating asset attributes in real time based on streaming data

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8046286B2 (en) * 2005-02-16 2011-10-25 SRI, Inc., Prisma & Company, Inc. Systems and methods for implementing the structuring, pricing, quotation, and trading of SPOT synthetics (SPOTS), SPREAD instruments (SPRINTS), SPRINTS based on SPOTS, ratio derivatives (RADS), RADS based on SPOTS, and options based on these instruments
US20130036039A1 (en) * 2011-08-01 2013-02-07 Rohlfs Michael B System for market hedging and related method
US20150278915A1 (en) * 2014-03-26 2015-10-01 Auction.Com, Llc Recommendation system for non-fungible assets
KR20210050525A (ko) * 2018-08-10 2021-05-07 티제로그룹, 인코포레이티드 분할 가능한 증권형 토큰
US11107160B2 (en) * 2020-10-13 2021-08-31 Dearborn Financial, Inc. Referential data structures for automatically updating asset attributes in real time based on streaming data
US11403655B1 (en) * 2020-10-13 2022-08-02 Dearborn Financial, Inc. Referential data structures for automatically updating asset attributes in real time based on streaming data

Similar Documents

Publication Publication Date Title
US11908011B2 (en) Global liquidity and settlement system
US10740844B2 (en) System and method of managing trustless asset portfolios
US11893637B2 (en) Systems and methods for cryptographic trading
US20230076526A1 (en) Multi-tier tokenization platform system
Lo et al. Bitcoin as money?
JP2022547130A (ja) ブロックチェーンベースの記録プロセスを提供するシステムおよび方法
US20190095995A1 (en) Systems and methods for operating exchange controlled network handling digitized asset backed mediums of exchange
US11107160B2 (en) Referential data structures for automatically updating asset attributes in real time based on streaming data
US11263629B2 (en) Referential data structures for automatically updating asset attributes in real time based on streaming data
Dos Santos et al. A new era of blockchain-powered decentralized finance (DeFi)-a review
Popescu Transitions and concepts within decentralized finance (Defi) Space
US20220188781A1 (en) Systems and methods for efficient electronic token ecosystems
US20210042823A1 (en) Single-action digital asset collateral-multiplier loan equivalent to a series of recursive digital asset collateral loans
US20220222657A1 (en) Method and system for managing life cycle of a tokenized real asset in a blockchain-based ecosystem
Adrian et al. A multi-currency exchange and contracting platform
Schuh et al. Bitshares 2.0: Financial smart contract platform
US11403655B1 (en) Referential data structures for automatically updating asset attributes in real time based on streaming data
WO2023141241A1 (fr) Structures de données référentielles pour la mise à jour automatique d'attributs d'actifs en temps réel sur la base de données transmises en continu
WO2023003618A1 (fr) Structures de données référentielles pour la mise à jour automatique d'attributs d'actifs en temps réel sur la base de données transmises en continu
US20230075931A1 (en) Transpositive Network For Converting Variable-Volume Fixed-Value Units To Fixed-Volume Variable-Value Units And Vice Versa
Aggarwal DeFi and Investing in Entrepreneurial Ventures
US20140279678A1 (en) Automated Cash Leveraging Facility to Provide Available Cash from Sweep Investments for Margin Financing
Mancini-Griffoli et al. A Multi-Currency Exchange and Contracting Platform
WO2023225237A1 (fr) Systèmes et procédés pour fournir une plateforme de volatilité décentralisée pour un échange d'options de cryptomonnaie
KR20210061106A (ko) 디폴트 저항성이 구비된 블록 체인을 이용한 가상화폐 유동성 대여 방법 및 그 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23743745

Country of ref document: EP

Kind code of ref document: A1