Electronic Payment Systems
The electronic payment system stabilizes transaction values by using a basket of securities as a unified currency, addressing currency fluctuations and inefficiencies in traditional systems, enabling secure and efficient transactions.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-02-29
- Publication Date
- 2026-03-10
AI Technical Summary
Traditional payment systems are vulnerable to currency fluctuations due to lack of intrinsic backing, leading to unstable pricing and inefficiencies in transactions using fiat currencies and cryptocurrencies, and there is a need for a system that stabilizes transaction values and allows for seamless use of different currencies and securities.
A computer-implemented electronic payment system that facilitates transactions using a single underlying asset, such as fiat currency, cryptocurrency, or commodities, allowing parties to select securities from a basket of accepted securities for transactions, independent of currency fluctuations, and utilizing a 'securities switchboard' for secure and efficient transfers.
The system provides stable transaction values by using a basket of securities as a unified currency, enabling efficient and secure transactions across different currencies and commodities, reducing volatility and computational intensity.
Smart Images

Figure 2026508398000001_ABST
Abstract
Description
[Technical Field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 449,717, filed March 3, 2023, which is incorporated by reference in its entirety for all purposes.
[0002] This application is directed generally to electronic payment systems, and more particularly to systems and methods for making securities payments based on underlying assets. [Background technology]
[0003] The world's most common payment transaction system may be one in which a local buyer pays a local seller in an accepted local legal tender currency issued by the local country (e.g., U.S. dollars). The buyer may transfer an agreed-upon amount of the local legal tender to the seller. If the buyer and seller are in different countries, since there is no existing agreed-upon common currency, one party may convert their currency into the currency of the other party.
[0004] In our modern payment system paradigm, currency is not "backed" or directly supported by assets. Instead, the value of currency is derived from the faith and confidence placed in the governments and central banks that issue the currency. As a result, payment systems that rely on these paradigms are more susceptible to fluctuations influenced by a variety of factors, such as economic conditions, policies, and global market dynamics. This inherent lack of intrinsic backing can leave traditional payment systems vulnerable to volatility.
[0005] As the use of various cryptocurrencies increases, more and more transactions are being conducted using these cryptocurrencies. Because most cryptocurrencies are not backed by fiat currency or a commodity, cryptocurrencies tend to fluctuate significantly in value. In addition to the wide bid / offer price spread in cryptocurrency transactions, these cryptocurrencies have become undesirable for transactions in the absence of a reliable system for assessing value. It would be desirable to have a payment system that allows cryptocurrencies and other currencies to be used in a manner that makes their value more stable and less unusual. Current computer-based payment systems are not configured to handle transactions using cryptocurrencies or fiat currency that are not subject to such fluctuations. Summary of the Invention
[0006] Thus, there is a need for buyers and sellers worldwide to calculate the value of goods or services using a single, agreed-upon underlying asset (e.g., fiat currency, cryptocurrency, commodity), thereby eliminating the need for currency conversion. Using a single, global underlying asset would simplify global transactions. There is also a need for a system that allows buyers to transfer marketable, publicly traded securities that are part of a basket of accepted securities as payment, instead of transferring physical commodities, which can be cumbersome. The embodiments described herein present a system for conducting transactions that seeks to meet these needs.
[0007] The use of traditional fiat currencies in transactions often poses problems such as unstable pricing. One of the primary reasons for this instability is the constant fluctuation in the value of fiat currencies due to factors such as inflation, economic conditions, and government policies. These fluctuations can lead to unpredictable price changes for goods and services, making it challenging for both consumers and businesses to plan and budget effectively. Therefore, using traditional currencies may not be ideal for various transactions. Furthermore, conducting transactions using cryptocurrencies has also proven inefficient. First, the lack of central control can make the value / price of cryptocurrencies volatile. Second, using cryptocurrencies can require cryptomining, which can be computationally intensive and time-consuming.
[0008] Described herein are methods and systems for creating novel computer-implemented electronic payment systems capable of facilitating transactions in a currency-independent manner. Using the methods and systems discussed herein, a processor may enable a user to conduct a transaction in any underlying currency. For example, the processor discussed herein determines a secondary value that is separate from the value of the underlying currency of the transaction. Using this secondary value, the processor may facilitate the transaction in a manner that protects the transaction from currency fluctuations and / or devaluation (e.g., the value of the product or service exchanged in the transaction remains the same regardless of whether the currency fluctuates or is devalued).
[0009] Because transactions conducted using the methods and systems discussed herein are currency agnostic, different parties involved in a transaction can conduct the transaction using different currencies / fiat currencies. For example, two parties can conduct a transaction in which one party is liquidating certain stocks in its portfolio and the second party receives cryptocurrency. In some embodiments, the processor may allow different parties involved in a transaction to select the underlying currency to be used in the transaction. For example, the platform may provide a "securities switchboard" for the buyer to select one or more assets (e.g., digital assets such as securities) to be used in the transaction. The platform may display a separate "securities switchboard" for the seller, so that the seller can select the underlying currency to be used (e.g., in which the seller will be paid).
[0010] In a non-limiting example, as depicted in FIGS. 1-11 , a processor discussed herein can access each party's electronic wallet and identify its assets (e.g., securities, stocks, or cryptocurrencies). Each party can then use one or more features depicted within a graphical user interface to select the currency to be used in the transaction while viewing a currency-independent price (e.g., Goldstix) associated with the transaction. Using the methods and systems discussed herein, the processor can facilitate the transaction using the selected currency. For example, a buyer can be charged a specific amount of the buyer's selected securities. Additionally, a seller can receive the value of a product / service expressed in the seller's selected currency.
[0011] Using the methods and systems discussed herein, a novel payment infrastructure can be realized in which transactions can be conducted regardless of the underlying currency. The discussed payment system can increase the supply of money in the payment system by making a basket of securities fungible with one underlying asset.
[0012] Currently, the world does not have enough Bitcoin or enough gold to base a payment system on just one of the single assets. The payment system discussed herein should make other assets easily fungible with Bitcoin or gold, thereby expanding the supply of Bitcoin or gold so that there is a large enough pool of "money supply" for these assets to effectively function as a global / unified currency.
[0013] The payment systems discussed herein may also provide pricing granularity; thus, the currency received or sent can be chosen by one or both parties involved in a transaction. The payment system may provide a "securities switchboard" where someone wanting a particular security within a basket of accepted securities can obtain that particular security.
[0014] The systems and methods described herein provide a payment system that allows for an alternative to existing payment systems for products and services that rely solely on government-backed currencies (e.g., U.S. dollars) or cryptocurrencies (e.g., Bitcoin, Ethereum, etc.). Securities may be priced based on an underlying asset, as opposed to using fiat currency itself. For example, the cost of all goods or services purchased by a buyer would first be priced in the underlying asset. The buyer would then have the option to transfer to the seller any combination of securities from a predetermined basket of accepted securities as payment for the goods or services. These securities would also be priced in the underlying asset. The seller would then have to accept any securities being transferred, as long as they are of the correct value (priced in the underlying asset) and are included in the basket of accepted securities.
[0015] As an example of a basket of accepted securities, this grouping or pool can include stocks from around the world. For example, the basket of accepted securities may include any stock that is part of the Standard and Poor's 500 ("S&P 500") index of stocks for use as payment for goods or services. In some configurations, the basket of accepted securities may include a list of the world's top 100 market capitalization stocks based on underlying assets.
[0016] In one example, the underlying asset may be any defined grade and amount of a particular commodity transferred to a defined location. The underlying asset may be, for example, one ounce of pure gold, one ounce of pure silver, one bushel of red winter wheat, one bushel of corn, one barrel of Brent crude oil, one gallon of emulsion, or one board foot of lumber. The underlying asset itself may also be used as payment for goods or services—similar to how a buyer can purchase them using cash. Nevertheless, securities (such as ETFs) based on the underlying asset (such as ETF securities based on gold, ticker symbol: GLD) can be used to pay for goods and services in current payment systems. The commodity on which the security would be based would be the underlying asset in the payment system. Note that even though this example discusses the use of a commodity, other examples may include using non-commodity or intangible assets, such as fiat currency or perhaps cryptocurrency.
[0017] According to one or more embodiments, gold may be used as the underlying asset upon which securities will be priced. Gold is used to create a gold standard system. However, instead of transferring physical gold, publicly traded securities priced based on a defined amount of gold would be transferred. An embodiment may resemble a modified gold standard payment system that uses the fact that securities are easier to transfer electronically than gold. Also, there is not enough gold in the world to support the size of the global economy. A payment system must have a pool of "currency" or "money supply" large enough to support the global economy.
[0018] A global currency based on gold but including a large enough basket of accepted securities could be standardized in the global economy worldwide and more easily transferable between parties, with a large enough basket of accepted securities to create a "money supply" large enough to fit the size of the global economy. The gold standard alone does not have enough physical gold available in the world today to fit the size of the global economy. By combining the concept of a gold standard with a publicly traded securities market, the world could have a gold-based monetary system within a regulatory framework in which publicly traded securities are used as payment in buy / sell transactions. The systems and methods herein would use current settlement systems in place for securities worldwide, along with current regulatory frameworks such as those of the U.S. Securities and Exchange Commission, the U.S. Commodity Futures Trading Commission, and other relevant entities in other jurisdictions around the world.
[0019] In one embodiment, a method includes receiving, by one or more processors from the electronic terminal, a selection of a first user account; receiving, by the one or more processors, a request from the electronic terminal to transfer an amount from the first user account to a second user account; in response to authorizing the request based on at least one data record in the first user account, updating in real time by the one or more processors a database to represent a transfer of at least a portion of the amount from the first user account to the second user account; and in response to transferring the amount, updating a database containing the amount, an identification of the first user account, an identification of the second user account, and a selection of digital assets in the first user account. automatically generating, by one or more processors, an input data packet, wherein the digital asset is pre-selected in the first user account, the digital asset is selected from a group of digital assets, and the amount is limited to transactions using the digital asset from the group of digital assets; and routing, by the one or more processors, the data packet to a digital entity based on the digital asset, wherein the data packet instructs the digital entity to execute a transfer instruction on a digital asset exchange platform of the digital asset from the first user account to a second user account for an amount, the amount being based on the digital asset amount relative to an underlying asset amount.
[0020] In one embodiment, the method may include receiving, by one or more processors from a point-of-sale terminal, a selection of a buyer account. The method may include displaying, by the one or more processors, a set of digital assets associated with the buyer account in a user interface, the user interface including an owned amount for each digital asset and an interim value for each digital asset based on a current legal value relative to a tangible asset value. The method may include receiving, by the one or more processors, a transaction request from the point-of-sale terminal to transfer funds from the buyer account to a seller account, the transaction request including a transfer amount displayed in the user interface and a selection of a digital asset within the set of digital assets. The method may include, in response to authorizing the transaction request based on a sufficient amount of the interim value in the buyer account, transferring at least a portion of the interim value from the buyer account to the seller account in real time by the one or more processors. The method may include automatically generating, by one or more processors, instructions for a clearing house to execute a transfer instruction for the digital asset at the ending fiat value (or any other underlying asset) from the buyer account to the seller account in response to transferring the intermediate value. The method may include transmitting, by the one or more processors, the instructions to the clearing house.
[0021] In another embodiment, the system may include one or more processors configured to execute instructions stored on a non-transitory computer-readable medium. The one or more processors may be configured to receive a selection of a buyer account from a point-of-sale terminal. The one or more processors may be configured to display a set of digital assets associated with the buyer account in a user interface, the user interface including an owned amount for each digital asset and an intermediate value for each digital asset based on a current underlying asset value relative to a tangible asset value. The one or more processors may be configured to receive a transaction request from the point-of-sale terminal to transfer funds from the buyer account to a seller account, the transaction request including a transfer amount displayed on the user interface and a selection of a digital asset within the set of digital assets. In response to authorizing the transaction request based on a sufficient amount of the intermediate value in the buyer account, the one or more processors may be configured to transfer at least a portion of the intermediate value from the buyer account to the seller account in real time. In response to transferring the intermediate value, the one or more processors may be configured to automatically generate instructions for the payment facility to execute a transfer command for the first digital asset from the buyer account to the seller account at the ending fiat value (or any other underlying asset value). The one or more processors may be configured to transmit the instructions to the payment facility.
[0022] The techniques of this disclosure generally relate to underlying asset and securities payment systems and methods of use. Various embodiments disclosed herein relate to systems and methods for unifying securities transfers (e.g., transferring stocks between different electronic accounts) and payment of transaction amounts based on underlying assets, thereby enabling more stable trading.
[0023] In another embodiment, a method includes receiving, by one or more processors of a payment system from a point of sale terminal, a selection of a buyer account representing a fiat or cryptocurrency alternative for use in the transaction; receiving, by the one or more processors from the point of sale terminal, a transaction request to transfer an amount from the buyer account to a seller account; in response to authorizing the transaction request based at least on an amount existing in the buyer account, updating in real time by the one or more processors a database of the payment system to represent a transfer of at least a portion of the amount from the buyer account to the seller account; and in response to transferring the amount, updating a database of the payment system based on the amount, an identification of the buyer account, an identification of the seller account, and a transaction request from the point of sale terminal to transfer an amount. automatically generating, by one or more processors, a data packet containing the identification and a selection of digital assets in the buyer account, wherein the digital assets are pre-selected in the buyer account, the digital assets are selected from a group of digital assets, and an amount is limited to transactions using digital assets from the group of digital assets; and routing, by the one or more processors, the data packet to a settlement facility based on the digital assets, wherein the data packet instructs the settlement facility to execute a transfer instruction on a digital asset exchange platform of the digital assets from the buyer account to the seller account at the end of the exchange, the amount being based on the digital asset amount relative to the underlying asset amount.
[0024] In another embodiment, the system receives from the point of sale terminal a selection of a buyer account representing a fiat or cryptocurrency substitute for use in the transaction; receives from the point of sale terminal a transaction request to transfer an amount from the buyer account to the seller account; in response to authorizing the transaction request based at least on an amount existing in the buyer account, updates a payment system database in real time to represent a transfer of at least a portion of the amount from the buyer account to the seller account; and in response to transferring the amount, transmits a data packet to one or more processors containing the amount, an identification of the buyer account, an identification of the seller account, and a selection of digital assets in the buyer account. and routing a data packet to a settlement facility based on the digital assets, the data packet instructing the settlement facility to execute a transfer instruction on a digital asset exchange platform of the digital assets from the buyer account to the seller account at the end of the exchange for the amount, the amount being based on the digital asset amount relative to the underlying asset amount.
[0025] Non-limiting embodiments of the present disclosure are described by way of example with reference to the accompanying figures, which are schematic and are not intended to be drawn to scale, and unless indicated as representing background art, the figures represent aspects of the present disclosure. [Brief explanation of the drawings]
[0026] [Figure 1A] FIG. 1 is a diagram of an example computer system for processing securities payments based on underlying assets, according to one embodiment. [Figure 1B] FIG. 1 is a block diagram illustrating an example of a computing system, according to one embodiment. [Figure 2] 1 is a flow diagram of a process performed to make securities payments based on underlying assets, according to one embodiment. [Figure 3A] FIG. 1 is a block diagram of updating buyer and seller accounts when payments are made using an underlying asset and securities payment system, according to one embodiment. [Figure 3B] FIG. 1 is a block diagram of updating buyer and seller accounts when payments are made using an underlying asset and securities payment system, according to one embodiment. [Figure 3C] FIG. 1 is a block diagram of updating buyer and seller accounts when payments are made using an underlying asset and securities payment system, according to one embodiment. [Figure 4A] FIG. 1 is a diagram of a user interface for configuring the underlying asset and securities payment system, according to one embodiment. [Figure 4B] FIG. 1 is a diagram of a user interface for configuring the underlying asset and securities payment system, according to one embodiment. [Figure 4C] FIG. 1 is a diagram of a user interface for configuring the underlying asset and securities payment system, according to one embodiment. [Figure 5A] FIG. 1 is a diagram of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 5B] FIG. 1 is a diagram of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 5C] FIG. 1 is a diagram of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 6A] FIG. 10 is a diagram of another example of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 6B]FIG. 10 is a diagram of another example of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 6C] FIG. 10 is a diagram of another example of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 7A] FIG. 1 is a diagram of a user interface for a seller to request a change to a security in an underlying asset and securities payment system, according to one embodiment. [Figure 7B] FIG. 1 is a diagram of a user interface for a seller to request a change to a security in an underlying asset and securities payment system, according to one embodiment. [Figure 7C] FIG. 1 is a diagram of a user interface for a seller to request a change to a security in an underlying asset and securities payment system, according to one embodiment. [Figure 8A] FIG. 1 is a diagram of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 8B] FIG. 1 is a diagram of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 8C] FIG. 1 is a diagram of a user interface for making payments using the underlying asset and securities payment system, according to one embodiment. [Figure 9A] FIG. 1 is a diagram of a user interface for a seller to select the securities that the seller wants to receive from a buyer for payment in an underlying asset and securities payment system, according to one embodiment. [Figure 9B] FIG. 1 is a diagram of a user interface for a seller to select the securities that the seller wants to receive from a buyer for payment in an underlying asset and securities payment system, according to one embodiment. [Figure 9C]FIG. 1 is a diagram of a user interface for a seller to select the securities that the seller wants to receive from a buyer for payment in an underlying asset and securities payment system, according to one embodiment. [Figure 10A] FIG. 1 is a diagram of a user interface for a seller to select the securities that the seller wants the buyer to send for payment and to select the securities that the seller wants to receive from the buyer for payment in a basic asset and securities payment system, according to one embodiment. [Figure 10B] FIG. 1 is a diagram of a user interface for a seller to select the securities that the seller wants the buyer to send for payment and to select the securities that the seller wants to receive from the buyer for payment in a basic asset and securities payment system, according to one embodiment. [Figure 10C] FIG. 1 is a diagram of a user interface for a seller to select the securities that the seller wants the buyer to send for payment and to select the securities that the seller wants to receive from the buyer for payment in a basic asset and securities payment system, according to one embodiment. [Figure 11A] FIG. 1 is a diagram of a user interface for switching between underlying assets and securities in a securities payment system, according to one embodiment. [Figure 11B] FIG. 1 is a diagram of a user interface for switching between underlying assets and securities in a securities payment system, according to one embodiment. [Figure 11C] FIG. 1 is a diagram of a user interface for switching between underlying assets and securities in a securities payment system, according to one embodiment. [Figure 12] 1 is a flow diagram of a process performed to make securities payments based on underlying assets, according to one embodiment. [Figure 13] FIG. 1 is a block diagram of updating buyer and seller accounts when payments are made using an underlying asset and securities payment system, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0027] Reference will now be made to the illustrative embodiments depicted in the drawings, and specific language will be used herein to describe same. It will nevertheless be understood that no limitation of the claims or the scope of the present disclosure is thereby intended. Alterations and further modifications of the features of the inventions illustrated herein, and additional applications of the principles of the subject matter illustrated herein, will occur to those skilled in the relevant art and in possession of this disclosure, and should be considered within the scope of the subject matter disclosed herein. Other embodiments may be used, and / or other changes may be made, without departing from the spirit or scope of the disclosure. The illustrative embodiments described in the detailed description are not intended to be limitations on the subject matter presented.
[0028] The term "underlying asset" may be used to indicate currency (such as fiat or cryptocurrency), securities, or a defined grade and amount of a particular commodity that is transferred to a defined location. In the example embodiment herein, the underlying asset is a commodity, but it is intended that the underlying asset is not limited to commodities, and is not limited to only tangible assets. The use of a commodity as an underlying asset may be modeled after "specs" in global futures markets. For example, the Chicago Mercantile Exchange® trades gold futures and lists gold futures "specs" online. Every commodity futures exchange in the world has commodity "specs" listed on its exchange. In some embodiments, to be considered an underlying asset, a commodity has a specific amount of a specific quality that is transferred to a specific location. This underlying asset can be the "yardstick" by which all securities are valued.
[0029] In one example configuration, the system may use an amount (e.g., 1 / 1000 ounce) of an underlying asset (e.g., gold) to calculate a currency-independent value (Goldstix). The underlying asset has a "spec" as listed on the Chicago Mercantile Exchange®, but for gold, for example, it may be 1 / 1000 ounce (or other amount) of gold, rather than 100 ounces of gold as listed on the Chicago Mercantile Exchange® gold contract. For calculation purposes, the price of gold may be assumed to be, for example, $1,800 per ounce. The currency-independent value may be named, for example, 1 "Goldstix," and, as shown in the examples herein, may use the nomenclature 1.00 Goldstix (which may be spoken of as "1 Goldstix and 0 cents") when writing single or multiple amounts of this currency. It should be understood that the term "Goldstix" as used herein is in no way intended to be limiting. This term is for illustrative purposes only, and therefore the base asset may ultimately be assigned any other standardized unit designation.
[0030] The term "basket of accepted securities" may be used to refer to a grouping, pool, or selection of acceptable or predetermined securities (or digital assets) from which a buyer can choose to transfer funds to a seller in payment for goods or services. As shown in FIG. 1 , a base asset 160 may be used with a basket of accepted securities 180 that includes various marketable securities (or digital assets) 170. While the illustration in FIG. 1 shows eight securities 170, it is contemplated that any number of securities may be included in the basket of accepted securities. The basket of accepted securities 180 includes securities 170 that are fungible for the base asset 160. The securities 170 may also be referred to herein as "digital assets."
[0031] In some embodiments, the system may present only selected digital assets from a basket of securities, where the digital assets may depend on the type and amount of assets owned by the buyer. For example, a seller may review a list of digital assets owned by the buyer and select one or more of the accepted securities accordingly. In this manner, the system may dynamically modify the listing of digital assets from the basket of accepted securities based on those actually owned by the buyer and thus be customized for the buyer and / or the particular transaction to display only selected digital assets from these accepted securities. In some embodiments, to improve security, one or more of the digital assets owned by the buyer may be obfuscated. In one configuration, a buyer may determine that a particular digital asset or set of digital assets is visible and available to the seller (from the basket of securities), and the seller may only select from these visible digital assets; the remaining digital assets (whether owned by the buyer or not) may be obfuscated (e.g., obscured, blacked out, or hidden from view). In another configuration, the system may present only the digital assets that the seller is interested in utilizing, so that the remaining digital assets may still be available but may be obfuscated (e.g., obscured, blacked out, or hidden from view) to simplify the user interface for the seller.
[0032] The basket's acceptable securities 180 can be any basket of marketable securities that are publicly traded and cleared electronically. Illustrated with underlying assets 160 as the hub, there are one or more spokes of marketable securities 170 that may be interchangeable with underlying assets 160. Marketable securities 170 should generally be electronically traded and electronically cleared securities, such as publicly traded securities traded on major exchanges around the world.
[0033] The term "price granularity" may be used to refer to the number of "significant digits" from which a price is extracted when determining a price. For example, in the current pricing format for the United States dollar, prices are extracted to the "hundredth" digit, or in other words, to the "two decimal places." The smallest increment in the current United States dollar payment system is one penny. This is the coarsest price in the United States dollar payment system. According to some embodiments, the price granularity can be chosen at any level. According to some embodiments, the price granularity may be rounded to the nearest two decimal places (the same as the current level of granularity for the United States dollar).
[0034] The term "payment interval granularity" may be used to refer to how frequently payments between buyers and sellers are exchanged. For payments to be settled, a clearing firm may set a specific time for marking all of the securities in a basket of accepted securities with the current market closing price. Once each basket of accepted securities is priced, the clearing firm may analyze all of the payment amounts submitted to the clearing firm from all buyer and seller accounts over the payment interval period. At the end of each payment interval, a transfer of securities from the buyer account to the seller account may be processed. This granularity of the payment interval may be any unit of time. According to some embodiments, the granularity of the payment interval may be at the end of each trading day. This means that there may typically be five payment intervals per week in a week without holidays, with one closing price per weekday at, for example, 4:00 PM Eastern Time (the time when stock trading currently ends each weekday).
[0035] The terms "buyer account" and "seller account" may be used to refer to a buyer's or seller's brokerage account, similar to a stock brokerage account at a brokerage firm such as, for example, Charles Schwab Corporation®, TD Ameritrade®, Fidelity Investments™, JPMorgan Chase®, Merrill Lynch®, Wells Fargo®, or the like. This may also be a futures brokerage account at RJ O'Brien & Associates™, Interactive Brokers Bank™, ABN AMRO™, Deutsche Bank AG™, Credit Suisse Securities™, Bank of America®, Nomura Securities™, Scotiabank®, UBS™, Morgan Stanley®, or others.
[0036] The terms "clearing office," "clearing company," or "clearing facility" may be used to refer to an entity where all trades are confirmed, matched, and settled daily (or more frequently). Settlement is the process of reconciling options, futures, or securities transactions or the direct transfer of funds from one financial institution to another. The process verifies the availability of the appropriate securities or funds in the buyer's account, records the transfer, and, in the case of securities, ensures the transfer of the securities or funds to the seller in the seller's account. As an example, CME Group™ has a division within its company called CME Clearing™ that performs settlement operations for trades on its exchange. Intercontinental Exchange™ also has settlement operations for its products. Stock exchanges such as the New York Stock Exchange (NYSE®) and NASDAQ® have clearing offices. Many banks also have clearing offices. The National Securities Clearing Corporation (NSCC®), a subsidiary of the Depository Trust & Clearing Corporation (DTCC®), is one of the primary clearing offices in the U.S. According to some embodiments, the clearing office may be NSCC®.
[0037] Embodiments herein generally describe an underlying asset and securities payment system and method of use. In some configurations, the system may include one or more processors configured to execute instructions stored on a non-transitory computer-readable medium. The one or more processors can receive a selection of a buyer account from a point-of-sale terminal. The one or more processors can display a set of digital assets associated with the buyer account in a user interface, the user interface including an owned amount for each digital asset and an intermediate value for each digital asset based on the current underlying asset value relative to the tangible asset value. The one or more processors can receive a transaction request from the point-of-sale terminal to transfer funds from the buyer account to a seller account, the transaction request including a transfer amount displayed on the user interface and a selection of a first digital asset in the set of digital assets. In response to authorizing the transaction request based on a sufficient amount of the intermediate value in the buyer account, the one or more processors can transfer at least a portion of the intermediate value from the buyer account to the seller account in real time. In response to transferring the intermediate value, the one or more processors may automatically generate instructions for the clearing facility to execute a transfer command for the first digital asset from the buyer account to the seller account at the ending fiat value (or other underlying asset value). The one or more processors may transmit the instructions to the clearing facility.
[0038] 1A illustrates an example of a computer system (e.g., underlying asset and securities payment system 100) for processing securities payments based on underlying assets 160, according to one embodiment. System 100 represents electronic communications between different computing infrastructures involved in processing securities payments based on underlying assets. System 100 includes a buyer device 110b, a seller device (e.g., a seller's point-of-sale (POS) system / terminal or other computing device), a first intermediary server 120 (also referred to as first intermediary computing system 120), at least one second intermediary server 130 (also referred to as second intermediary computing system 130), at least one payment computing server 140 (also referred to as payment computing system 140), and a network 150.
[0039] In some embodiments, the buyer device 110b may be a computing device such as a cell phone, laptop computer, smart watch, tablet, desktop computer, or other smart device. The buyer device 110b may be a payment device such as a credit card, computing device, or mobile device configured to provide payment information to the seller device 110s (e.g., a point of sale terminal).
[0040] In some embodiments, the seller device 110s may be a seller's computing device such as a point-of-sale terminal, a payment terminal, a cell phone, a laptop, a smartwatch, a tablet, a computer, a workstation, or other device. The seller device 110s may be configured to communicate with the buyer device 110b directly or over the network 150.
[0041] The buyer device 110b may communicate over network 150 with a first intermediary system 120 of a first brokerage firm (or facility) with which the buyer has an account (e.g., a brokerage account). The first intermediary system 120 may maintain the buyer's brokerage account at the first brokerage firm. The buyer device 110b may also communicate, directly or over network 150, with a second intermediary system 130 of a second brokerage firm (or facility) with which the seller has an account (e.g., a brokerage account). The second intermediary system 130 may maintain the seller's brokerage account at the second brokerage firm.
[0042] The seller device 110s may be one of a point of sale system / terminal, a payment terminal, a cell phone, a laptop, a smartwatch, a tablet, a computer, or other smart device. The seller device 110s may communicate with the first intermediary system 120 and the second intermediary system 130 directly or via a network 150. The settlement system 190 belongs to a settlement company / facility and is configured to use the closing price per security to determine the exact number of shares to transfer from the buyer's account to the seller's account, thus satisfying the buyer's payment obligation to the seller.
[0043] Each component, including buyer device 110b, seller device 110s, first intermediary server 120, second intermediary server 130, and payment computing server 140, may have a configuration similar to that of computing system 105 shown in FIG. 1B. In some embodiments, first intermediary server 120 may be a server of a first stock brokerage facility / company, and second intermediary server 130 may be a server of a second stock brokerage facility / company different from the first stock brokerage facility / company.
[0044] Using the methods and systems herein, a buyer can make a purchase of a product or service from a seller. In some configurations, the transaction may occur online, whereby the buyer can initiate the purchase on a computer connected to the Internet, and the seller may have a server configured to process commands from the website. In another configuration, the buyer can visit the seller at a brick-and-mortar location and conduct the transaction at a point-of-sale terminal at the seller's location (e.g., a store). In FIG. 1A , when the buyer conducts a transaction with the seller, the buyer's user computing device 110b may communicate with the seller's server 110s. When the buyer conducts a transaction with the seller at a brick-and-mortar location, the buyer can interact with the point-of-sale terminal 110s without the user computing device 110b. While the example embodiment may describe an online transaction in which the buyer's user computing device 110b communicates with the seller's computing device 110s, it is intended that the functionality may be applied to configurations for brick-and-mortar locations in which the buyer interacts with the seller's point-of-sale terminal.
[0045] In an online purchasing configuration, when a buyer buys a product from a seller, the buyer uses computing device 110b (e.g., a desktop or laptop computer) to conduct a transaction with the seller's computing device 110s (e.g., a server) over network 150. The buyer may have options to pay using various payment mechanisms, including credit, debit, or other accounts. One of the options for the buyer may be conducting the transaction using the methods described herein that utilize digital assets and underlying asset-based value. For example, the buyer may choose to purchase a pair of jeans using a publicly traded stock owned by the buyer. Alternatively, the buyer may utilize an electronic payment card, such as a debit card or credit card, for the transaction. Thus, the methods and systems discussed herein may provide an alternative option to traditional payment plans and may be implemented in conjunction with (e.g., as a better alternative to) traditional payment systems.
[0046] In another embodiment, a buyer can use a traditional payment card for a transaction, but at least a portion of the transaction is conducted using a transfer of digital assets. In this configuration, the buyer pays for an item from a seller using a credit card. The credit card issuer can pay the seller using a digital asset, such as one of the securities in a basket of accepted securities. The buyer can pay the credit card issuer using a traditional payment mechanism, such as writing a check from the buyer's checking account. Alternatively, the credit card issuer can pay the seller using a digital asset, and the buyer can pay the credit card issuer using assets, which may be the same asset or different assets, and all of the digital assets used may be selected from the basket of accepted securities. A transaction between a buyer and a credit card issuer or a transaction between a credit card issuer and a seller using assets may be similar to the process described herein for a transaction between a buyer and a seller.
[0047] The buyer's computing device 110b (e.g., the buyer's mobile phone or computer) can be configured to select a buyer account (e.g., the buyer's account in a first intermediary system) from the seller's computing device 110s. For example, the buyer can select a buyer account configured to use the basic asset transaction described below. The buyer's computing device 110b can receive information about the seller's account and the second intermediary system (where the seller's account is housed) from the seller's computing device 110s, so that the first intermediary system will have the necessary information needed to transfer the securities to the seller's account in the second intermediary system.
[0048] In a configuration for brick-and-mortar location purchases (in-person), a buyer can interact with a seller's point-of-sale terminal 110s. The screen of the point-of-sale terminal 110s can present a graphical user interface configured to display information to the buyer and receive selections and inputs from the buyer. For example, the buyer can use the screen of the point-of-sale terminal 110s to select a buyer account. The buyer can select a buyer account configured to use basic asset transactions, described below.
[0049] The buyer's account may be an account at a stock brokerage facility / company. The buyer device 110b may be configured to display a set of digital assets associated with the buyer's account from the brokerage computing system (e.g., a set of stocks owned by the buyer, such as stocks of Apple®, Verizon®, and Coca-Cola®) on a user interface (e.g., a user interface on the buyer's mobile phone or computer, or a screen displaying a graphical user interface at a point-of-sale terminal). An example user interface for buyer account 460 is shown in FIG. 4C, described below. The user interface may include the amount owned for each digital asset (e.g., number of shares per stock) and an intermediate value for each digital asset (e.g., an equivalent value in units of 1 / 1000 ounce of gold) based on a current underlying asset value (e.g., the value of the stock in USD) relative to a tangible asset value (e.g., the value of gold). The payment computing system 140 can calculate an intermediate value for each digital asset based on the current base asset value relative to the tangible asset value and send / transmit the calculated intermediate value to the buyer's computing device 110b and point of sale terminal 110s.
[0050] The buyer's computing device 110b may be configured to receive a transaction request from the point-of-sale terminal 110s to transfer funds (e.g., the price of a product purchased from the seller) from a buyer account to a seller account (e.g., the seller's account in a second intermediary system). The buyer and seller accounts may be accounts from the same intermediary facility, but in some embodiments, may be accounts from different intermediary facilities. The transaction request may include a transfer amount (e.g., an amount owed to the seller, such as the price of a product purchased from the seller) displayed in a user interface and a selection of a first digital asset within a set of digital assets. The first digital asset may be one or more digital assets (e.g., stocks) acceptable to the seller. For example, if the buyer and seller both own the same set of stocks (e.g., both the buyer and seller own Apple® stock and Verizon® stock), the first digital asset may be the same set of stocks (e.g., Apple® stock and Verizon® stock). In response to authorizing the transaction request based on a sufficient amount of the interim value in the buyer's account (e.g., the total value of Apple® stock owned by the buyer is equal to or greater than the transfer amount), the buyer's computing device 110b may transfer at least a portion of the interim value from the buyer's account to the seller's account in real time.
[0051] In response to transferring the intermediate value, the buyer's computing device 110b can automatically generate instructions for a clearing facility (not shown in FIG. 1A) to execute a transfer command for the first digital asset from the buyer's account to the seller's account at the closing base asset value (e.g., the closing price of Apple® stock and Verizon® stock each weekday). In some embodiments, the clearing facility can be an entity (e.g., a clearing house, a stock exchange, or a bank) where all transactions are confirmed, matched, and settled daily. The buyer's computing device 110b can transmit the instructions to the clearing facility.
[0052] The payment computing system 140 may store records associated with each user (e.g., buyer and / or seller) account. The records may include the amount of underlying assets 160 and a listing of shares for each security 170 (or digital asset) owned by the user. As transactions with the first intermediary computing system 120 and the second intermediary computing system 130 are conducted, the payment computing system 140 may update its records.
[0053] In some embodiments, the payment computing system 140 may be configured to store closing price data 144, including the closing price for each security. In some embodiments, the payment computing system may be configured to communicate with an external server or database (e.g., an external commercial database server) to retrieve the current closing prices for the named securities. Once the closing prices for the securities are retrieved, the pricing logic module 143 may calculate the value of the securities in Goldstix and determine how many shares (or partial shares) of the securities will be remitted as payment. In some embodiments, the payment computing system 140 may be configured to store listing price data 145, including the listing price for each security, which is analyzed by the trading module 142 to calculate the value of the security, for example, in Goldstix.
[0054] In some embodiments, once the trading module 142 determines how many shares of the named securities should be transferred from the buyer account to the seller account as payment for the transaction, the transfer may first be processed and settled by the settlement system 190. In some embodiments, the settlement system 190 may be configured to authenticate the availability of appropriate funds from the buyer account at the first intermediary facility 120, record the transfer, and, in the case of securities, secure the transfer of the securities or funds to the seller account at the second intermediary facility 130.
[0055] In some embodiments, payment computing system 140 may include one or more applications 141 and a trading module 142. Application 141 may include an underlying asset and securities payment application configured to present a user interface (e.g., the interfaces shown in FIGS. 4A-11C) for buyer 110b and seller 110s to send / receive an agreed-upon payment amount using securities in an underlying asset (e.g., Goldstix). Similarly, payment device 110b and seller device 110s may each include an underlying asset and securities payment application configured to present a user interface (e.g., the interfaces shown in FIGS. 4A-11C) for buyer 110b and seller 110s to send / receive an agreed-upon payment amount using securities priced in the underlying asset (e.g., Goldstix) and having a value equal to the agreed-upon payment amount priced in the underlying asset. Trading module 142 may include a pricing logic module 143 that implements the underlying asset pricing scheme as described above (see Equation 1 and Equation 2, Tables 1-3). Each of application 141, trading module 142, and pricing logic module 143 may be software modules that may be executed by a payment computing system. Pricing logic module 143 may be configured to compute and price the value of the buyer's nominated securities in Goldstix, and then determine how many shares (or partial shares) of the securities need to be transferred from the buyer's account to the seller's account based on the Goldstix value of the securities to satisfy the buyer's obligation to pay the seller an agreed-upon value of the underlying assets using securities from a basket of accepted securities as payment.
[0056] 1B is a block diagram illustrating an example of a computing system, according to one embodiment. The illustrated example computing system 105 includes memory 106, at least one network interface controller 103 having a network interface port for connecting to a network (not shown), and one or more processors 101 in communication with other components, such as input / output (“I / O”) components 109, via a communication system 104 (e.g., a bus). Generally, the processor 101 will execute instructions (or computer programs) received from memory. The illustrated processor 101 incorporates or is directly connected to a cache memory 102. In some examples, instructions are read from memory 106 into the cache memory 102 and executed by the processor 101 from the cache memory 102.
[0057] More specifically, processor 101 may be any logic circuitry that processes instructions, such as instructions fetched from memory 106 or cache 102. In many implementations, processor 101 is a microprocessor unit or a special-purpose processor. Computing device 105 can be based on any processor or set of processors capable of operating as described herein. Processor 101 may be a single-core processor or a multi-core processor. Processor 101 may also be multiple separate processors.
[0058] The memory 106 may be any device suitable for storing computer-readable data. The memory 106 may be a device with fixed storage or a device for reading removable storage media. Examples include all forms of volatile memory (e.g., RAM), non-volatile memory, media and memory devices, semiconductor memory devices (e.g., EPROM, EEPROM, SDRAM, and flash memory devices), magnetic disks, magneto-optical disks, and optical disks (e.g., CD-ROM, DVD-ROM, or Blu-ray discs). The computing system 105 may have any number of memory devices 106.
[0059] Cache memory 102 is a form of computer memory that is generally located in close proximity to processor 101 for fast read times. In some implementations, cache memory 102 is part of processor 101 or on the same chip as processor 101. In some implementations, there are multiple levels of cache 102, for example, L2 and L3 cache layers.
[0060] The network interface controller 103 manages data exchange through network interfaces (sometimes referred to as network interface ports). The network interface controller 103 handles the physical and data link layers of the OSI model for network communication. In some implementations, some of the network interface controller's tasks are handled by one or more of the processors 101. In some implementations, the network interface controller 103 is part of the processor 101. In some implementations, the computing system 105 has multiple network interfaces controlled by a single controller 103. In some implementations, the computing system 105 has multiple network interface controllers 103. In some implementations, each network interface is a connection point for a physical network link (e.g., a cat5 Ethernet link). In some implementations, the network interface controller 103 supports wireless network connections, and the interface ports are wireless (e.g., radio) receiver / transmitters (e.g., for either the IEEE 802.11 protocol, Near Field Communication "NFC", Bluetooth, ANT, or any other wireless protocol). In some implementations, the network interface controller 103 runs one or more network protocols, such as Ethernet. Generally, the computing system 105 exchanges data with other computing devices over a physical or wireless link through a network interface. A network interface can link to another device directly or through an intermediate device, such as a network device like a hub, bridge, switch, or router, that connects the computing system 105 to a data network, such as the Internet.
[0061] Computing system 105 may include one or more input or output ("I / O") devices or provide an interface for I / O devices. Input devices include, but are not limited to, keyboards, microphones, touchscreens, foot pedals, sensors, MIDI devices, and pointing devices such as mice or trackballs. Output devices include, but are not limited to, video displays, speakers, refreshable Braille terminals, lights, MIDI devices, and 2-D or 3-D printers.
[0062] Other components may include an I / O interface, an external serial device port, and any additional coprocessors. For example, the computing system 105 may include an interface (e.g., a Universal Serial Bus (USB) interface) for connecting an input device, an output device, or an additional memory device (e.g., a portable flash drive or an external media drive). In some implementations, the computing device 105 includes additional devices such as coprocessors; for example, a math coprocessor can assist the processor 101 with high-precision or complex calculations.
[0063] Component 109 may be configured to interface with external media, display 107, input device 108, or any other component in computing system 105, or a combination thereof. Display 107 may be a liquid crystal display (LCD), organic light emitting diode (OLED), flat panel display, solid state display, cathode ray tube (CRT), projector, printer, or other now known or later developed display device for outputting determined information. Display 107 may serve as an interface for a user to view the functions of processor 101, or specifically, to software stored in memory 106.
[0064] The input device 108 may be configured to allow a user to interact with any of the components of the computing system 105. The input device 108 may be a number of pads, a keyboard, a cursor control device such as a mouse, or a joystick. The input device 108 may also be any other device operable to interact with the computing system 105, such as a remote control, a touchscreen display (which may be a combination of the display 107 and the input device 108), or any device operable to act as an interface between a user and the computing system 105.
[0065] According to some embodiments, the systems and methods described herein can provide an alternative to existing payment systems for products and services that rely on government-backed currencies (e.g., fiat currencies such as the U.S. dollar) or cryptocurrencies (e.g., Bitcoin, Ethereum, etc.). Embodiments of the present disclosure provide a system in which securities are priced in an underlying asset. For example, the cost of all goods or services purchased by a buyer may first be priced in an underlying asset. The buyer may then have the option to transfer any combination of securities from a predetermined basket of accepted securities to a seller as payment for the goods or services. These securities may also be priced in the underlying asset. The seller may then accept any securities to be transferred, as long as they are of the correct value (priced in the underlying asset) and are included in the basket of accepted securities.
[0066] As an example, the basket of accepted securities may include any stock that is part of the Standard and Poor's 500 ("S&P 500") index of stocks. In this situation, any stock that is part of the S&P 500 index may be used as payment for goods or services. The basket of accepted securities may also include stocks from around the world. In some embodiments, the basket of accepted securities may include a list of the world's largest 100 market capitalization stocks based on the underlying assets.
[0067] The underlying asset may be any defined grade and amount of a particular commodity to be transferred to a defined location. The underlying asset may be, for example, one ounce of pure gold, one ounce of pure silver, one bushel of red winter wheat, one bushel of corn, one barrel of Brent crude oil, one gallon of emulsion, or one board foot of lumber. In some embodiments, the underlying asset may be a cryptocurrency (such as Bitcoin, Ethereum, etc.). In some embodiments, the underlying asset may be a particular security (such as a stock or bond).
[0068] The underlying asset itself may also be used as payment for goods or services similar to how a buyer can purchase using cash. In accordance with the principles of the present disclosure, a security (perhaps an exchange-traded fund (ETF)) based on a commodity (such as ETF securities based on gold, ticker symbol: GLD) can be used to pay for goods and services in current payment systems. The commodity on which the security can be based can be the underlying asset in the payment system.
[0069] According to some embodiments, gold may be used as the commodity upon which securities will be priced. Gold is used to create a gold standard system. In some embodiments, instead of transferring physical gold, publicly traded securities priced based on a defined amount of gold may be transferred. This is a modified gold standard payment that uses the fact that securities are easier to transfer electronically than gold. Also, while there is not enough gold in the world to support the size of the global economy, it would be preferable for a payment system to have a pool of "currency" or "money supply" large enough to support the global economy.
[0070] The methods and systems discussed herein can be used to address the scarcity or limited nature of currency or supply of assets such as gold to serve as a global currency to support the global economy. With a basket of acceptable securities fungible for the underlying asset, we have increased the amount of the global money supply to a size large enough to support the global economy. Currently, the world economy has a GDP of approximately US$100 trillion. The world economy would require a global money supply of approximately US$50-70 trillion (based on the relative size of global GDP to global currencies throughout history). The present invention solves the need for a larger money supply than is possible with the current amount of any single commodity, currency, or cryptocurrency currently available in the world.
[0071] According to some embodiments of the present disclosure, a global currency based on gold but including a large enough basket of accepted securities could be standardized in global economies around the world, easily transferable between parties, and, importantly, have a large enough basket of accepted securities to create a "money supply" large enough to fit the size of the global economy. A gold standard alone does not have enough physical gold available in the world today to fit the size of the global economy. By combining the concept of a gold standard with a publicly traded securities market, the world can have a gold-based monetary system within a regulatory framework in which publicly traded securities are used as payment in buy / sell transactions. Some embodiments of the present disclosure can use current settlement systems in place for securities around the world, along with current regulatory frameworks such as those of the U.S. Securities and Exchange Commission, the U.S. Commodity Futures Trading Commission, and other relevant entities in other jurisdictions around the world.
[0072] According to some embodiments, the basket of accepted securities may include the following 151 globally traded stocks: ● ETF securities based on the underlying asset. In part, this can be a gold-based ETF, such as the ETF SPDR Gold Shares, Ticker: "GLD." ● All 100 stocks in the USA's S&P 100 stock index. These stocks have a combined market capitalization of approximately $40 trillion. ● The 10 largest stocks in the FTSE 100 UK stock index. These 10 stocks have a combined market capitalisation of approximately $1 trillion. ● The 10 largest stocks in the DAX40 German stock market index. These 10 stocks have a combined market capitalization of approximately $1 trillion. ● The 10 largest stocks in the S&P / ASX200 Australian Stock Market Index. These 10 stocks have a combined market capitalization of approximately $1 trillion. ● The 20 largest stocks in the Nikkei 225 Japan Stock Market Index. These 20 stocks have a combined market capitalization of approximately $2 trillion.
[0073] In some embodiments, the basket of accepted securities may include stocks from other countries that make up the world's largest economies, such as China, India, Canada, Italy, Brazil, Russia, South Korea, Iran, Spain, Mexico, Saudi Arabia, the Netherlands, Switzerland, Taiwan, Poland, Turkey, Sweden, Belgium, Argentina, Norway, Israel, and Ireland. In order for stocks from these countries to be added to the basket of accepted securities, the countries would be required to meet trading regulations, disclosure, and inspection standards similar to those of other leading economies in the world.
[0074] Also, debt securities issued by governments or large corporations denominated in underlying assets may be included in the basket of accepted securities. The advantage of debt securities issued by governments, such as U.S. government debt denominated in underlying assets (e.g., Goldstix), is that these U.S. government debt securities generally would be more stable and less liquid than stocks. There are advantages to using a stable asset as currency, and thus government debt issued by the world's largest governments would be attractive securities in the basket of accepted securities. Naturally, an ETF based on the underlying asset itself would be the most stable and least liquid of any of the securities in the basket of accepted securities, since its value would not fluctuate at all. Initially, government debt would still be denominated in fiat currency, rather than denominated in underlying assets. Therefore, government debt would not initially be included in the basket of accepted securities. However, this would be possible if the government were to denomine its liabilities in underlying assets.
[0075] According to some embodiments, the buyer account is an account at brokerage facility A, and the seller account is an account at brokerage facility B (which may be the same as or different from brokerage facility A). In some embodiments, to improve efficiency, the underlying asset and securities payment system utilizes securities / brokerage accounts to trade in both the commodity futures market and the securities market, thus bridging two markets: commodity futures and securities such as stocks and bonds. In some cases, not all futures accounts can trade stocks and bonds, and not all stock and bond accounts can trade futures. Given that commodity ownership can be transformed into securities, such as SPDR Gold Shares, Ticker: "GLD," a futures account may not be necessary. Accounts that only trade stocks and bonds may suffice for the buyer and seller accounts.
[0076] According to some embodiments, the buyer may get to choose which securities from a basket of accepted securities, nominated by the buyer, should be transferred to the seller from the buyer's account to the seller's account. The amount of securities transferred (the exact number of all shares and fractions of shares) may be equal to the amount required to equal the total the buyer owes the seller, using the yardstick of the amount of the underlying assets as the magnitude of the amount owed to the seller. The buyer would likely have a fixed "designation of securities used for payment" in the buyer's account.
[0077] According to some embodiments, the buyer can nominate the securities to be used for payment. As a non-limiting example, the nominated securities may be Apple® stock, which may be one of many shares in a basket of accepted securities. In addition to Apple® stock being one of the shares in the basket of accepted securities, the buyer must also own a sufficient amount of Apple® stock to fully satisfy its payment obligation to the seller. The buyer may also have second and third options (and more) if the buyer did not have enough Apple® stock to satisfy the entire obligation owed. If the buyer did not have enough value in the securities to fully satisfy the obligation, this would be similar to a "bounced check" or "declined charge" on a credit card when there were not enough securities in the buyer's account on the payment date.
[0078] During each payment interval, the buyer and seller can communicate by electronically accessing the buyer's and seller's accounts and then send the agreed-upon payment amount due to each other, along with the buyer's account information and the buyer's designated securities to be used for payment, and the seller's account information, to the clearing house. The clearing house then uses the closing price per security to determine the exact number of shares to transfer from the buyer's account to the seller's account, thus satisfying the buyer's payment obligation to the seller. The seller can also send information to the clearing house, including the buyer's account information and the amount of the expected payment. In this way, the clearing house can "match" the payment agreed upon by both the buyer and seller.
[0079] Algorithm for converting legal prices to basic assets
[0080] In some embodiments of the operation of the Electronic Payment System ("System"), pricing of a security may be based on an underlying asset (rather than basing the price solely on fiat currency). The System may perform pricing by utilizing the price of the underlying asset in a currency and the price of the security in the same currency. The System (e.g., a trading module of the System) may then perform pricing logic using equations described below to offset the common fiat currency pricing of both the underlying asset and the security and calculate a security priced in the amount of the underlying asset rather than the amount of fiat currency. Below is an example where the underlying asset is gold and the stock is Apple® stock when both are priced in US dollars:
[0081]
number
[0082] The system can perform this calculation for securities priced in fiat currencies other than US dollars. Below is a calculation of the number of Goldstix that one share of Toyota® Motors stock should equal, using Toyota® Motors stock traded in yen on the Tokyo Stock Exchange™. Toyota® Motors' stock symbol on this exchange is 7203. The closing price on 12 / 30 / 2022 was ¥1,817 per share. One ounce of gold priced in yen on 12 / 30 / 2022 is equal to ¥239,315.2. One thousandth of an ounce of gold priced in yen would be ¥239.3152.
[0083]
number
[0084] What is important to show with this pricing mechanism is that any security, commodity, or service can have its price converted from any fiat currency and then into an underlying asset. As a result, the world can have one single currency based on an agreed-upon underlying asset. Perhaps the underlying asset will be gold, but any commodity could be used. It could also be wheat, crude oil, or silver, or any other commodity.
[0085] Also, when securities (as well as goods and services) are priced in fiat currency, a process using the above formulas would be put in place and the securities would be actively priced in the underlying assets. When securities are priced in real time, every second, these fiat prices can be converted in real time to the underlying assets by using the above calculations in conjunction with a computer to actively price the securities (as well as goods and services) using the underlying assets. The process is described in more detail below.
[0086] Securities Pricing
[0087] In some embodiments, the system may price the security in a commodity (e.g., Goldstix, which in this example is 1 / 1000 ounce of gold). In the following, the security is first priced in United States dollars (USD), and then the USD pricing is then offset from both sides of the equation, leaving only the pricing in the underlying asset (e.g., a tangible asset such as gold). ● Gold price per ounce = $1,800.00 ● 1 / 1000th of an ounce of gold = $1.80 ● In this example, 1 / 1000th of an ounce of gold is defined as 1 Goldstix.
[0088] [Table 1] The prices listed above will be used in the steps below.
[0089] Securities Switchboard Matrix
[0090] In some embodiments, the system may swap / exchange securities for other securities. An active swaps market is required in which the system disseminates the price of each security in the basket of accepted securities relative to all other securities in the basket of accepted securities. In some embodiments, the system may include a trading module configured to effect swaps of securities with other securities. For example, a seller may prefer to hold assets in securities different from the securities the seller received in payment from the buyer.
[0091] In some embodiments, the system can calculate and maintain a trading matrix or security switchboard matrix. For example, Table 2 below shows a security switchboard matrix using only five securities in a basket of accepted securities and a sixth security that is an ETF security, where one ETF share (digital asset) is equal to 1 / 1000 ounce of gold (the underlying asset), where 1 / 1000 ounce of gold is calculated here as 1 Goldstix. The system can continuously update the matrix with the system's pricing logic. The system can trade between these securities based on direct swaps of one security for another. The security switchboard matrix described in this section is a component of an efficient payment system that allows direct swaps or trades to be made between all securities in a basket of accepted securities, and potentially more securities. Below is an example matrix based on the prices shown in the example above.
[0092] [Table 2]
[0093] The first column in Table 2 shows the price of each security relative to Goldstix. The second column shows how many shares of each stock on the left side of the table someone can trade one share of Apple® stock for. For example, one share of Apple® stock can be traded for 11.1734 shares of Ford® stock, or 1.0548 shares of Tesla® stock, or 3.2974 shares of Verizon® stock, or 2.0424 shares of Coca-Cola® stock. Similarly, the adjacent column to the right shows how many shares one share of Ford® stock can acquire.
[0094] The system (or its pricing logic) can continuously display and update a transaction (securities switchboard) matrix such as that shown in Table 2. The system's pricing logic may be connected to or in communication with one or more computing devices around the world via a network and servers (described in more detail below). The system may enable transactions between parties by directly swapping shares with one another via this electronic trading platform. An aspect of the present disclosure is that the system can implement swaps of shares based on an underlying asset that is then used to price a direct swap of one security for another. Unlike existing payment systems, the system can use a securities switchboard matrix that does not rely on the use of fiat currency.
[0095] Pricing of goods and services
[0096] In some embodiments, the system may price goods and services in commodities (in this example, Goldstix = 1 / 1000 ounce of gold). In the following, goods and services are first priced in United States dollars (USD), then the USD pricing is then offset from both sides of the equation, leaving only the pricing in the underlying asset (gold or Goldstix). ● Gold price per ounce = $1,800.00 ● 1 / 1000th of an ounce of gold = $1.80 ● In this example, 1 / 1000th of an ounce of gold is defined as 1 Goldstix.
[0097] [Table 3]
[0098] When purchasing from a seller, a buyer can use a payment device such as a credit card or a computing device such as a cell phone, laptop, smartwatch, tablet, computer, or other smart device. The purchase can be made in person or online. When the buyer makes this purchase, their brokerage account information can be shared with the seller over the system network and with the intermediary facility where the seller holds their brokerage account. In this example, the buyer's account can be held at intermediary facility A, and the seller's account can be held at intermediary facility B (which can be the same as or different from facility A). During the purchase transaction, the buyer's brokerage account information can be shared with facility B, and the seller's brokerage account information can be shared with facility A. Both the buyer's intermediary (e.g., facility A) and the seller's intermediary (e.g., facility B) can receive all of the sales information and all of the account information necessary to process the payment over any communications network, such as the Internet or a private electronic connection. This transaction would be very similar to a traditional credit or debit card transaction, except that instead of exchanging fiat currency, the buyer and seller can be exchanging securities priced based on an underlying asset.
[0099] In some embodiments of the present disclosure, the granularity of the payment interval may be at the end of each trading day. For example, the end of each payment interval occurs at the end of each weekday, e.g., at 4:00 PM Eastern Time, and the processing (or settlement) of the payment would occur, e.g., at 4:00 PM Eastern Time on the same day the buyer purchased the product from the seller. During the time between payment intervals, the system may aggregate an inventory of purchase transactions from all parties (e.g., the buyer, the buyer's intermediary, the seller, and the seller's intermediary). Then, at the end of each payment interval, the system may process all of the aggregated inventory of purchase transactions. It is important to note that all purchase transactions may be processed at the closing price of all securities at the end of the payment interval. The closing value per security, for example, as priced in Goldstix, may determine how much of the buyer's designated securities used for payment will be transferred from the buyer's account to the seller's account as payment for the purchased goods or services. It is instructive to note that at the time of purchase, the buyer would not yet know how many shares of Apple® stock the buyer would have to pay the seller. The number of shares may not be known until the next close of trading. After the next close of trading, the closing price of Apple® stock (determined based on the underlying assets) can be known, and the system can perform a calculation as to how many shares of Apple® stock should be transferred from the buyer's account to the seller's account.
[0100] Once all parties (e.g., the buyer, the buyer's intermediary, the seller, and the seller's intermediary) have the purchase information, the trade can be settled through an intermediate clearing company (or clearing facility), such as, for example, the National Securities Clearing Corporation (NSCC®), a subsidiary of the Depository Trust & Clearing Corporation (DTCC®). NSCC® would receive transaction information from both the buyer's intermediary and the seller's intermediary, and / or from the underlying asset and securities payment systems. At the end of each payment interval, whenever the information from both intermediaries matches, the clearing facility (e.g., NSCC®) can process and settle the payment. This information would be transmitted all electronically, via the Internet or any type of electronic communication system, or any other type of communication system.
[0101] In some embodiments, at the time of purchase, the seller may give the buyer the option to pay in fiat currency (such as U.S. dollars) or in securities priced using an underlying asset (such as Apple® stock priced in Goldstix, which is based on gold). When the buyer chooses to pay in a currency-independent value (Goldstix), the price of the good or service quoted in U.S. dollars can be quickly converted to Goldstix using the price conversion formulas described herein to convert the fiat currency price to an underlying asset-based price. This conversion of price would be performed by a computer computation at the time of purchase. During a transition period to an underlying asset-based system, the price of the good and service may be priced in both fiat currency and underlying asset-based pricing systems. During this transition period, the computer computation process at the time of purchase plays a critical role when the good or service is quoted in fiat currency prices. When a buyer chooses to pay using the underlying asset and securities payment system and the seller is set up to accept payment via the underlying asset and securities payment system, the seller can receive the amount of securities transferred from the buyer's account to the seller's account in lieu of fiat currency. The amount of securities transferred by the buyer to the seller can be based on the amount of the underlying asset. The price or value conversion process between fiat currency and the underlying asset at the point of sale terminal can be performed automatically by a computer program executed by the system described herein and using the algorithms and formulas described above. Given that the price relationship between fiat currency and the underlying asset is constantly changing every second, this computer program may be executed (to update price data) in some cases, so that the price conversion from the fiat price to the underlying asset-based price is accurate at the time of sale.
[0102] In some embodiments, the underlying asset and securities payment system may include a payment computing system, a buyer's payment device, a seller device, a first intermediary system, a second intermediary system, and / or a settlement system, which may be connected to each other via a network. The payment device may be one of a credit card, a smartphone, a laptop, a computer, a tablet, or the like, and is configured to enable and facilitate communication between the payment device and the payment computing system 140. The payment computing system and the network may be programmed and / or configured to enable the transmission of data between the payment device and the seller device. The payment device may communicate via the network with a first intermediary system belonging to a first brokerage firm (or facility) with which the buyer has an account (e.g., a brokerage account). The first intermediary system may maintain the buyer's brokerage account at the first brokerage firm. The payment device may also communicate, directly or via a network, with a second intermediary system belonging to a second brokerage firm (or facility) with which the seller has an account (e.g., a brokerage account). The second intermediary system may maintain the seller's brokerage account at the second brokerage firm. The seller device may be one of a point of sale system / terminal, a payment terminal, a cell phone, a laptop, a smartwatch, a tablet, a computer, or other smart device. The seller device may communicate with the first intermediary system and the second intermediary system directly or over a network. The settlement system belongs to a settlement company / facility and may be configured to use the closing price per security to determine the exact number of shares to transfer from the buyer's account to the seller's account, thus satisfying the buyer's payment obligation to the seller. Each of the payment computing system, payment device, seller device, first intermediary system, second intermediary system, and settlement system may have a configuration similar to that of computing system 105 of FIG. 1B.
[0103] In some embodiments, the payment computing system may include one or more applications and trading modules. The applications may include a payment application configured to present a user interface for buyers and sellers to send / receive payments using a currency-independent value (e.g., Goldstix) based on a digital asset (e.g., a security) relative to an underlying asset (e.g., gold). Similarly, the payment device and seller device may each include a payment application configured to present a user interface for buyers and sellers to send / receive payments using securities priced based on the underlying asset. The trading module may include a pricing logic module that implements the underlying asset-based pricing scheme as described above (see Equations 1 and 2, Tables 1-3). Each of the applications, trading modules, and pricing logic modules may be software modules that can be executed by the payment computing system. The pricing logic module may be configured to perform computer calculations to price the value of the buyer's designated securities in Goldstix and then determine how many shares (or partial shares) of the securities will be transferred from the buyer's account to the seller's account based on the Goldstix value of the securities.
[0104] In some embodiments, the payment computing system may be configured to store closing price data, including the closing price per security. In some embodiments, the payment computing system may be configured to communicate with an external server or database (e.g., an external market database server) to retrieve the current closing prices of the named securities. Once the closing prices of the securities are retrieved, the pricing logic module may calculate the value of the securities in Goldstix and determine how many shares (or partial shares) of the securities will be remitted as payment. In some embodiments, the payment computing system may be configured to store listing price data, including the listing price per security, that is analyzed by the trading module to calculate the value of the securities in Goldstix, for example.
[0105] In some embodiments, once the trading module determines how many shares of the named securities should be transferred from the buyer account to the seller account as payment for the transaction, the transfer may first be processed and settled by a settlement system. In some embodiments, the settlement system may be configured to authenticate the availability of appropriate funds from the buyer account at the first brokerage firm, record the transfer, and, in the case of securities, secure the transfer of the securities or funds to the seller account at the second brokerage firm.
[0106] In some embodiments, the system may include one or more processors configured to execute instructions stored on a non-transitory computer-readable medium. The one or more processors may be configured to receive a selection of a buyer account from a point-of-sale terminal. The one or more processors may be configured to display a set of digital assets associated with the buyer account in a user interface, the user interface including an owned amount for each digital asset and an intermediate value for each digital asset based on a current legal value relative to a tangible asset value. The one or more processors may be configured to receive a transaction request from the point-of-sale terminal to transfer funds from the buyer account to the seller account, the transaction request including a transfer amount displayed on the user interface and a selection of a first digital asset in the set of digital assets. In response to authorizing the transaction request based on a sufficient amount of the intermediate value in the buyer account, the one or more processors may be configured to transfer at least a portion of the intermediate value from the buyer account to the seller account in real time. In response to transferring the intermediate value, the one or more processors may be configured to automatically generate instructions for a payment facility to execute a transfer instruction for the first digital asset from the buyer account to the seller account at the ending fiat value. The one or more processors may be configured to transmit the instructions to the payment facility.
[0107] In some embodiments, the underlying asset value may relate to a tangible item or commodity, such as the price of gold. Yet, in other embodiments, the underlying asset may be intangible and is not limited to physically tangible items. For example, the asset may correspond to a cryptocurrency.
[0108] The transaction may be conducted using a first digital asset. That is, the buyer may use the first digital asset to pay for an item associated with the buyer's purchase. The first digital asset may be held in a buyer account and a seller account. For example, the first digital asset may be one or more stocks owned by the buyer and held in the buyer account. The instruction (received via the point-of-sale terminal) may indicate the number of shares of the first digital asset to be transferred. The one or more processors may determine at least a portion of an intermediary value (Goldstix), also referred to as a currency-independent value, based on the transfer amount and the value of the digital asset relative to the value of the underlying asset. For example, the one or more processors may determine the intermediary value of the item to be purchased according to a tangible asset, such as the price of gold (or a specific designation for the price of gold).
[0109] When a transaction occurs, the one or more processors may transfer the amount of the first digital asset to the seller's account if the amount of the first digital asset corresponds to the midpoint value. For example, if a buyer is using XYZ stock to purchase a pair of jeans worth $100, the one or more processors may determine the Goldstix value of the pair of jeans (a midpoint value based on the price of gold). The one or more processors may then transfer XYZ stock (corresponding to the calculated Goldstic amount for the pair of jeans) from the buyer's account to an account held by the seller.
[0110] FIG. 2 illustrates a flow diagram of a process 200 performed to make a payment from a buyer to a seller based on an underlying asset, according to one embodiment. In some embodiments, process 200 is performed by one or more processors of a system (e.g., payment computing system 140, one or more processors 101 of user computing devices 110b, 110s). The one or more processors may be configured to execute instructions stored on a non-transitory computer-readable medium. In some embodiments, process 200 is performed by another entity. In some embodiments, process 200 includes more, fewer, or different steps than those shown in FIG. 2. Details of process 200 are described below with reference to FIGS. 3A-11C. Process 200 may be performed by a buyer to make payment for products that the buyer buys from a seller using the buyer's securities account (e.g., the buyer's account at a brokerage facility).
[0111] 3A-3C show example scenarios in which process 200 can be implemented. FIGS. 3A-3C illustrate block diagrams for updating buyer and seller accounts when payments are made using an underlying asset and securities payment system. FIG. 3A shows block diagram 300, including a user interface showing an overview of buyer account 312 (at intermediary facility A 310) and a user interface showing an overview of seller account 332 (at intermediary facility B 330) before a particular purchase 301. In this example, the securities account (e.g., intermediary account) may be accessed like a personal bank account and may be accessed when withdrawing payments. Prior to any payment transaction, the buyer can pre-designate which securities should be used for any payment. For example, in buyer account 312 at intermediary facility 310, the buyer designated that he or she would like to pay for any purchases he or she makes with Apple® stock first, Verizon® stock second, and Coca-Cola® stock third. This designation can inform the buyer's brokerage facility 310 which shares to transfer to the seller when the buyer makes any purchase. For example, in a hypothetical scenario, a buyer may purchase a product from a seller. Typically, the product may cost $9.00 USD. Yet, according to the computer calculations described herein, $9.00 USD is converted into 5.00 Goldstix, which equals $9.00 / $1.80 (1 / 1,000 ounce of gold priced at $1,800 per ounce = 5.00 Goldstix). After this purchase, the buyer is obligated to pay the seller 5.00 Goldstix.
[0112] 3B shows a block diagram 350 including a user interface depicting an overview of a buyer's account 312 (at intermediary facility A 310) and a user interface depicting an overview of a seller's account 332 (at intermediary facility B 330) during a particular purchase 301. The buyer has instructed intermediary facility 310 that the buyer wants to pay for any purchases he or she makes first in Apple® stock. The buyer owes the seller 5.00 Goldstix. 5.00 Goldstix worth of Apple® stock equals or correlates to 0.06927 shares of Apple® stock (depending on the closing price of Apple® stock on the particular day of the transaction). For example, if the closing price of Apple® stock on the transaction date, priced in Goldstix, equals 72.18 Goldstix, then the underlying asset and securities payment system (e.g., system 100 or payment computing system 140 of FIG. 1A ) can perform the calculation 5.00 Goldstix / 72.18 Goldstix=0.06927 shares to determine how many shares of Apple® stock should need to be transferred from the buyer to the seller. In some embodiments, the system can determine the granularity of the number of shares per share in the basket of accepted securities, per share, such that significant digits after the decimal point correlate with the fraction of a share that should also be related to the price granularity. In some embodiments, taking the fraction of a share of Apple® stock to five significant digits after the decimal point is a reasonable number of significant digits of Apple® stock to match the price granularity (e.g., two significant digits after the decimal point) when pricing items in Goldstix. In some embodiments, the underlying asset and securities payment system can automatically generate instructions for the payment company 320 to transfer 0.06927 shares of Apple® stock from the buyer's account to the seller's account and send the instructions to the payment company 320 to cause the payment company 320 to execute the transfer. The transaction can be completed once the buyer transfers 0.06927 shares of Apple® stock to the seller as payment for the purchased product.It is important to note that fiat currency may not be used in this transaction. In some embodiments, account information for this transaction may be exchanged between the buyer and seller and their respective intermediary facilities (e.g., 310, 330). This information may be inventoried by each intermediary in the transaction until the end of the payment interval, which may be, for example, 4:00 PM Eastern Time.
[0113] For example, at 4:00 PM Eastern Time on the date of purchase, a payment interval may end and payment processing may occur. At the end of each payment interval, the system (e.g., trading module 142 or pricing logic module 143 of FIG. 1A) may determine the closing prices of all of the securities in the basket of accepted securities. The system may use these closing prices to determine how many shares (and fractional shares) will be transferred from buyers of goods and services to sellers of such goods and services. Some of these transactions may occur within the same brokerage (e.g., when the buyer and seller use the same brokerage). As shown in FIG. 3B, many of these transactions (e.g., transfer 351 of 0.06927 shares of Apple® stock from buyer's brokerage facility 310) may be routed to a clearing house 320, such as NSCC®, so that the clearing house 320 can transfer shares between these third-party brokerage offices. Each intermediary facility may tally its inventory (e.g., names and share counts of securities) of transactions sent through the clearing house 320 and to other third-party intermediaries. All intermediary facilities may exchange information with the clearing house 320 about shares to be transferred or accepted from other third-party intermediaries via the clearing house 320 (e.g., NSCC®). When the clearing house 320 deems the stock transfer information to match between both sides of a purchase between intermediary facilities, the clearing house 320 may transfer the shares from the buyer's intermediary facility to the seller's intermediary facility (e.g., transfer 352 of 0.06927 shares of Apple® stock to the seller's intermediary facility 330). Each intermediary facility may then internally adjust its customer account to reflect the increase or decrease in shares in the customer account. Figure 3C also shows a block diagram 380, including what the respective user interfaces might look like, summarizing the buyer's and seller's accounts 312, 332 following completion of transaction 381 (e.g., with updated share counts).
[0114] 2, in step 202, one or more processors (e.g., buyer's payment device 110b) may receive a selection of a buyer account (e.g., buyer account 312 of FIG. 3A) from a point-of-sale terminal (e.g., seller device 110s). For example, during a particular transaction, the system (e.g., underlying asset and securities payment system 140) may receive (1) information about the transaction from the seller (e.g., from seller device 110s of FIG. 1A) (e.g., the transaction amount the buyer owes the seller, e.g., 7000 Goldstix, which is equivalent to $12,600), (2) seller account information (e.g., the account the seller logged into to use the system), and / or (3) buyer account information. The system may receive buyer account information through a card reader (using a physical card), communication between the seller device and the buyer device (e.g., using near field communication (NFC)), scanning a barcode or QR code containing the buyer's identification / account information, text entry of the buyer's information (e.g., entering an email, user ID, etc. into the seller device 110s of FIG. 1B), or the like.
[0115] In some embodiments, a buyer can manage their buyer account using an application running on a device (e.g., payment computing system 140, buyer device 110b, seller device 110s). FIGS. 4A-4C illustrate user interfaces 400, 430, 460 for a buyer to configure / manage their buyer account in the underlying asset and securities payment system, according to one embodiment. Each of user interfaces 400, 430, 460 may be presented on the buyer's payment device or on the seller's seller device. In some embodiments, the user interface for use by the buyer is not necessarily presented on the buyer's device; the user interface can be presented on any device that allows the buyer to log in to the system (e.g., the underlying asset and securities payment application 141 running on payment computing system 140, buyer device 110b, and / or seller device 110s). Similarly, the user interface for use by the seller is not necessarily displayed on the seller's device; the user interface can be displayed on any device that enables the seller to log in to the system (e.g., payment computing system 140, buyer device 110b, and / or underlying asset and securities payment application 141 running on seller device 110s). With reference to FIGS. 4A-4C, user interfaces 400, 430, 460 may be displayed after the buyer logs into the system with the buyer's ID before a particular transaction in which the buyer purchases a product from the seller. In other configurations, the user interface may be presented upon the performance of an action in a mobile application, swiping a payment card, or other action. With reference to FIG. 4A, when the buyer logs into the system, user interface 400 may show an indication 401 that the buyer has logged in, a message 402 instructing the buyer to select one of their accounts, and buttons 403, 404, 405 corresponding to the buyer's available accounts (e.g., accounts 1-3).4B , in response to the buyer selecting Account 1, user interface 430 may display an indication 431 that the buyer is logged in and an indication 432 that Account 1 is currently displayed. User interface 430 may prompt the buyer to select a preferred pricing structure from among available pricing structures (e.g., Goldstix 434, USD, Bitcoin) using a selection user interface (e.g., drop-down user interface 433). In some embodiments, user interface 430 may display any selection user interface other than a drop-down user interface for selection of a preferred pricing structure. In response to the buyer selecting Goldstix 434 as the preferred pricing structure and pressing submit button 435, the system may begin displaying prices (e.g., security prices, product, asset values, etc.) in Goldstix. Referring to FIG. 4C , user interface 460 can show the buyer an account summary 463 for buyer account 1, including the number of shares and total market value of each security owned by the buyer in account 1 (e.g., Apple® 464, Verizon® 465, Coca-Cola® 466), and / or the total market value 467 of the securities owned by the buyer in account 1.
[0116] 2, in step 204, one or more processors (e.g., buyer device 110b) may display a set of digital assets (e.g., a "basket of accepted securities") associated with the buyer's account in a user interface (e.g., user interface 500 of FIG. 5A). For example, the system (e.g., system 100) may receive information about securities owned by the buyer and seller in their accounts (e.g., by querying brokerage systems 120, 130) and / or determine a "basket of accepted securities" (or pool, grouping, or selection of securities) that have been accepted by the seller as payment for goods or services (e.g., products purchased by the buyer). The user interface may include the amount owned per digital asset (e.g., number of shares per stock) and an intermediate value per digital asset (e.g., value per share in Goldstix) based on the current legal value relative to the tangible asset value (e.g., gold price per ounce = $1,800.00). In some embodiments, the tangible asset value corresponds to the price of gold (e.g., value / price of 1 / 1000 ounce of gold). In response to receiving a selection from the point-of-sale terminal, the one or more processors may query a third-party server (e.g., a market database server) to receive at least one of the amount owned per digital asset, the current legal value of at least one digital asset, or the tangible asset value. An example basket of accepted securities (e.g., Apple® stock, Verizon® stock) is shown in FIG. 5A.
[0117] Referring again to FIG. 2, in step 206, one or more processors (e.g., buyer device 110b) may receive a transaction request from a point of sale terminal (e.g., seller device 110s) to transfer funds from a buyer account (e.g., account 1 in FIG. 5A) to a seller account (e.g., account 4 in FIG. 5B), the transaction request including a transfer amount displayed on a user interface (e.g., 7000 Goldstix in FIG. 5A) and a selection of a first digital asset (e.g., a basket of accepted securities; Apple® stocks and Verizon® stocks in FIG. 5A) within a set of digital assets (e.g., Apple® stocks, Verizon® stocks, Coca-Cola® stocks in FIG. 5A). In some embodiments, the first digital asset may be held in a buyer account and a seller account (e.g., Apple® stock and Verizon® stock in FIG. 5A are held in buyer account 1 and seller account 4, while Coca-Cola® stock in FIG. 5A is not held in seller account 4).
[0118] Illustrative user interfaces are shown in Figures 5A-5C. User interfaces 500, 530 may be shown after a buyer and seller log into the system and during a particular transaction in which a buyer purchases a product from a seller. User interface 560 may be shown after the next close of the transaction (e.g., 4:00 PM ET on the same day that a particular transaction occurs). Referring to FIG. 5A , upon receiving a request from a seller including a basket (or pool, grouping, or selection of securities), a transaction amount, and / or the buyer's account information (e.g., Account 1), user interface 500 may display to the buyer a message 503 instructing the buyer to select one or more securities for paying the transaction amount (e.g., 7000 Goldstix) to the seller, selection user interfaces 504, 505, 506 corresponding to securities owned by the buyer in Account 1 (e.g., Apple® stock, Verizon® stock, Coca-Cola® stock), and / or information about the securities (e.g., number of shares, market value). In some embodiments, the selection interfaces may be check boxes, although any interactive selection element on the user interface may be used for security selection. In some embodiments, user interface 500 may display all securities owned by the buyer in Account 1 and deactivate selection of securities not included in the basket.
[0119] As shown in FIG. 5A , user interface 500 may display Apple® stock, Verizon® stock, and Coca-Cola® stock, but may deactivate checkbox 506 for Coca-Cola® stock that is not included in the basket received from the seller. In some embodiments, the user interface may display only securities included in the basket (see FIGS. 6A and 7A ). In response to the buyer selecting Apple® stock by clicking checkbox 504, user interface 500 may display a selected amount of 7218 Goldstix equal to the market value of Apple® stock, a send button 508, and / or a change pricing structure button 509. In response to the buyer selecting / pressing / clicking send button 508, the system may send the transaction amount (e.g., 7000 Goldstix) from the selected amount of 7218 Goldstix to the seller. Note that remittance of the transaction amount is not confirmed until the seller accepts the transaction amount sent by the buyer (see Figure 5B), and even if the seller accepts the transaction amount, payment will not be processed until the next end of the transaction (e.g., 4:00 PM Eastern Time on the same day the transaction occurred). In response to the buyer selecting / pressing / clicking Change Pricing Structure 509, the system may display a selection user interface (e.g., a user interface similar to drop-down user interface 433) to allow the buyer to change the current pricing structure (e.g., Goldstix) to another pricing structure (e.g., USD).
[0120] 2, in step 208, in response to authorizing the transaction request based on a sufficient amount of interim value in the buyer's account (e.g., in response to the settlement company 320 verifying the availability of appropriate funds from the buyer's account at the buyer's intermediary facility), the one or more processors may transfer at least a portion of the interim value (e.g., 7,000 Goldstix of the 7,218 Goldstix in Apple® stock in FIG. 5A) from the buyer's account to the seller's account in real time (see FIG. 5C). Referring to FIG. 5B, in response to the buyer selecting / pressing / clicking the transfer button 508, the user interface 530 may display to the seller (1) an indication 531 that the seller has logged in with their seller ID, (2) an indication 532 that the seller's account 4 is shown, and (3) a message 533 about the transaction amount (e.g., 70 Goldstix), and / or detailed information 534, 535 about the basket in the buyer's account. For example, user interface 530 may indicate that 7000 Goldstix in Apple® stock have been received from the buyer (information 534) and that 0 (zero) Goldstix in Verizon® stock have been received from the buyer (information 535). The seller may confirm the current transfer of the transaction amount (e.g., 7000 Goldstix in Apple® stock) by selecting / pressing / clicking accept button 536.
[0121] In response to the seller selecting the Accept button 536, the system populates information about the current remittance of the transaction amount per intermediary facility (e.g., intermediary facility 310, 330 in Figures 3A-3C) until the next end of the trade. If the seller prefers a different selection of securities (e.g., a selection of 5000 Goldstix of Apple® stock and 2000 Goldstix of Verizon® stock rather than the current selection of 7000 Goldstix of Apple® stock), the seller can select / press / click the Modify button 537. More details about modifying the current selection are described below with reference to Figures 7A-7C.
[0122] Referring to FIG. 5C, user interface 560 may be presented to the buyer after the next close of trading (e.g., 4:00 PM Eastern Time on the same day that a particular transaction occurred). User interface 560 may show an account summary 563 for buyer Account 1, including the number of shares and total market value per security (e.g., Apple® 564, Verizon® 565, Coca-Cola® 566) owned by the buyer in Account 1, and / or the total market value 567 of securities owned by the buyer in Account 1. Compared to account summary 463 (see FIG. 4C), account summary 563 shows that the number of shares and market value of Apple® stock has decreased by 7,000 Goldstix. In some embodiments, the one or more processors may determine at least a portion of the interim value (e.g., 7000 Goldstix of Apple® stock in FIG. 5A ) based on the transfer amount (e.g., a transaction amount of $12,600) and the current legal value relative to the tangible asset value (e.g., the price of gold per ounce = $1,800.00). The one or more processors may update a user interface to indicate that at least a portion of the interim value has been deducted from the first digital asset in the buyer's account (e.g., user interface 560 in FIG. 5C is updated from user interface 460 in FIG. 4C ).
[0123] In some embodiments, a buyer may select two or more digital assets within a set of digital assets displayed in a user interface such as that shown in Figures 6A-6C, which illustrate example user interfaces 600, 630, 660 for making a payment using an underlying asset and securities payment system, according to one embodiment. Upon receiving a request from a seller including a basket (or pool, grouping, or selection of securities), a transaction amount, and / or the buyer's account information (e.g., Account 1), user interface 600 may display a message 603 instructing the buyer to select one or more securities for paying the transaction amount (e.g., 9000 Goldstix) to the seller, selection user interfaces 604, 605 corresponding to the securities included in the basket (e.g., Apple® stock, Verizon® stock), and / or information about the securities (e.g., number of shares, market value). In response to the buyer selecting Apple® stock by clicking checkbox 604, user interface 600 may display a selected amount of 7218 Goldstix equal to the market value of Apple® stock, a transfer button 608, and / or a change pricing button. In some embodiments, in response to determining that the selected amount (e.g., 7218 Goldstix) is less than the transaction amount (e.g., 9000 Goldstix), user interface 600 may deactivate transfer button 608 and / or display a message 607 that the selected amount is insufficient and that the buyer should select more securities to meet the transaction amount.
[0124] 6B, in response to the buyer selecting more securities (e.g., Verizon® stock) by selecting / pressing / clicking checkbox 605, user interface 630 may activate transfer button 608 and / or display instructions 637 for the total selected amount (e.g., 9407 Goldstix). In response to the buyer selecting / pressing / clicking (the activated) transfer button 608, the system may send the transaction amount (e.g., 9000 Goldstix) from the selected amount of 9407 Goldstix to the seller.
[0125] 6C , in response to the buyer selecting / pressing / clicking the transfer button 608, a user interface 660 may display to the seller (1) an indication 661 that the seller has logged in with a seller ID, (2) an indication 662 that the seller's account 4 is indicated, and (3) a message 663 about the transaction amount (e.g., 9,000 Goldstix), and / or detailed information 664, 665 about the basket in the buyer's account. For example, the user interface 660 may indicate that 7,218 Goldstix of Apple® stock have been received from the buyer (information 664) and that 1,782 Goldstix of Verizon® stock have been received from the buyer (information 665). The seller may confirm the current transfer of the transaction amount (e.g., 7,218 Goldstix of Apple® stock and 1,782 Goldstix of Verizon® stock) by selecting / pressing / clicking the accept button 666. In response to the seller selecting the accept button 666, the system may post information about the current transfer of the transaction amount per intermediary facility (e.g., intermediary facilities 310, 330 in Figures 3A-3C) until the next end of the transaction.
[0126] In some embodiments, the seller can modify the amount of securities in the buyer's account from the buyer's selected amount of securities as the digital assets the seller wants to receive from the buyer's account, as shown in Figures 7A-7C, which illustrate user interfaces 700, 730, 760 for the seller to request changes to underlying assets and securities in the securities payment system, according to one embodiment. User interfaces 700, 730, 760 can be shown after the buyer and seller log into the system, as well as during a particular transaction in which the buyer purchases a product from the seller. 7A , upon receiving a request from a seller including a basket (or pool, grouping, or selection of securities), a transaction amount, and / or the buyer's account information (e.g., Account 1), user interface 700 may display a message 703 instructing the buyer to select one or more securities for paying the transaction amount (e.g., 1,000 Goldstix) to the seller, selection user interfaces 704, 705 corresponding to the securities included in the basket (e.g., Apple® stock, Verizon® stock), and / or information about the securities (e.g., number of shares, market value). In response to the buyer selecting Apple® stock by clicking checkbox 704, user interface 700 may display a selected amount of 7,218 Goldstix equal to the market value of Apple® stock, a transfer button 708, and / or a change pricing structure button. In response to the buyer selecting / pressing / clicking the send button 708, the system may send the transaction amount (e.g., 1000 Goldstix) from the selected amount of 7218 Goldstix to the seller.7B , in response to the buyer selecting / pressing / clicking the Send button 708, user interface 730 may display to the seller (1) an indication 731 that the seller is logged in with seller ID, (2) an indication 732 that the seller's account 4 is indicated, (3) a message 733 about the transaction amount (e.g., 1000 Goldstix), and / or detailed information 734, 735 of the basket in the buyer's account. For example, user interface 730 may indicate that 1000 Goldstix of Apple® stock have been received from the buyer (information 734) and that 0 (zero) Goldstix of Verizon® stock have been received from the buyer (information 735). If the seller prefers a different selection of securities instead of the current selection of 1000 Goldstix of Apple® stock, the seller may select / press / click the Modify button 737.
[0127] 7C , in response to the seller selecting / pressing / clicking the Amend button 737, user interface 760 may display to the seller a message 763 instructing the seller to amend the amount of one or more securities from the buyer's account to meet the transaction amount (e.g., 1,000 Goldstix), detailed information for each security in the basket in the buyer's account, and / or input user interfaces (e.g., input boxes) 764, 765 for entering the amendment amount for the one or more securities. For example, the seller may enter 0 (zero) Goldstix for Apple® stock in input box 764 and 1,000 Goldstix for Verizon® stock in input box 765. Upon receiving the amendment amounts in input boxes 764, 765, user interface 760 may display instructions 766 for the total amendment amount and a request button 767. In response to the seller selecting / pressing / clicking the request button 767, the system may enable the seller to submit a request including the revised amount of the securities in the buyer's account (e.g., Account 1) and display a new user interface (not shown) to the buyer, similar to user interface 730 of Figure 7B, with the revised amount. If the buyer selects the accept button in the new user interface, the system may post information about the revised remittance of the transaction amount per intermediary facility (e.g., intermediary facilities 310, 330 of Figures 3A-3C) until the next end of the trade.
[0128] 7A-7C, upon receiving a second request for the seller account (e.g., when the seller sends a request including an adjustment to the security in the buyer account by selecting / pressing / clicking request button 767 in FIG. 7C), the one or more processors can transfer a second digital asset (e.g., 1000 Goldstix of Verizon® stock in FIG. 7C) having a value corresponding to the first digital asset (e.g., 1000 Goldstix of Apple® stock in FIG. 7B) in the seller account. The one or more processors can update a user interface (e.g., user interface 730 in FIG. 7B) to indicate that value (e.g., 1000 Goldstix) has been deducted from the second digital asset (e.g., Verizon® stock) and added to the first digital asset (e.g., Apple® stock) in the buyer account (e.g., buyer account).
[0129] In some embodiments, the system may display one or more recommended securities to the buyer for payment of the transaction amount, so that the buyer can choose between the securities recommended by the system or their preferred securities for payment of the transaction amount. Figures 8A-8C illustrate user interfaces 800, 830, 860 for making payments using the underlying asset and securities payment system, according to one embodiment. Referring to FIG. 8A, upon receiving a request from a seller including a basket (or pool, grouping, or selection of securities), a transaction amount, and / or the buyer's account information (e.g., Account 1), user interface 800 may display to the buyer a message 803 instructing the buyer to select one or more securities for paying the transaction amount (e.g., 2000 Goldstix) to the seller, selection user interfaces 804, 805 corresponding to securities owned by the buyer in Account 1 (e.g., Apple® stock, Verizon® stock), and / or information about the securities (e.g., number of shares, market value).
[0130] In some embodiments, selection interface 804 may be pre-selected (or pre-checked) to indicate that the system (e.g., the underlying asset and securities payment system) recommends Apple® stock for the buyer to pay the transaction amount. The buyer may select / press / click transfer button 808 as recommended by the system. Alternatively, as shown in FIG. 8B , the buyer may not follow the recommendation and instead select a different security (e.g., Verizon® stock) by checking selection user interface 805 and transfer the transaction amount (e.g., 2,000 Goldstix) by selecting / pressing / clicking transfer button 838. 8C , in response to the buyer selecting / pressing / clicking the transfer button 838, user interface 860 may display to the seller (1) an indication 861 that the seller is logged in with seller ID, (2) an indication 862 that the seller's account 4 is indicated, and (3) a message 863 about the transaction amount (e.g., 200 Goldstix), and / or detailed information 864, 865 about the basket in the buyer's account. For example, user interface 860 may indicate that 2000 Goldstix of Verizon® stock have been received from the buyer (information 865). The seller may confirm the current transfer of the transaction amount (e.g., 2000 Goldstix of Verizon® stock) by selecting / pressing / clicking the accept button 866. In response to the seller selecting the accept button 866, the system may post information about the current transfer of the transaction amount per intermediary facility (e.g., intermediary facilities 310, 330 in Figures 3A-3C) until the next end of the transaction.
[0131] In some embodiments, the system may display a basket (e.g., Apple® stock and Verizon® stock) to the seller (e.g., before displaying it to the buyer), so that the seller can review the basket and / or send a request to the buyer via the system's user interface (e.g., by pressing a submit button), the request including the basket (or pool, grouping, or selection of securities), the transaction amount, and / or the buyer's account information. Figures 9A-9C and 10A-10C show example user interfaces in which a basket of accepted securities is displayed to the seller so that the seller can select his or her preferred securities for payment of the transaction amount.
[0132] 9A-9C illustrate user interfaces 900, 930, 960 for a seller to select the securities the seller wants to receive from the buyer for payment in an underlying asset and securities payment system, according to one embodiment. In some embodiments, before sending a payment request (e.g., a request including a basket of securities, a transaction amount, and / or the buyer's account information) to the buyer, the system may display a user interface to the seller that allows the seller to select one or more securities the seller wants to receive from the buyer for payment. For example, user interface 900 may display a message 903 instructing the seller to select one or more securities the seller wants to receive from the buyer for payment of the transaction amount (e.g., 2000 Goldstix), and selection user interfaces 904, 905 corresponding to securities owned by the buyer in Account 1 (e.g., Apple® stock, Verizon® stock). The seller can submit a payment request to the buyer by checking user interface 905 to select Verizon® stock as the seller's preferred security that the seller wants to receive from the buyer for payment and selecting / pressing / clicking submit button 906. Referring to FIG. 9B, upon receiving a payment request from the seller, user interface 930 can display to the buyer a message 933 instructing the buyer to select one or more securities for paying the transaction amount (e.g., 2000 Goldstix) to the seller, selection user interfaces 934, 935 corresponding to securities owned by the buyer in account 1 (e.g., Apple® stock, Verizon® stock), and / or information about the securities (e.g., number of shares, market value).The buyer can select a security (e.g., Apple® stock) different from the seller's preferred security (e.g., Verizon® stock) by checking the selection user interface 934 and transfer the transaction amount (e.g., 2000 Goldstix) by selecting / pressing / clicking the transfer button 938.
[0133] Referring to FIG. 9C , in response to the buyer selecting / pressing / clicking the transfer button 938, the user interface 960 may display a message 963 about the transaction amount (e.g., 2,000 Goldstix) and / or detailed information 964, 965 of the basket in the buyer's account to the seller. For example, the user interface 960 may indicate (information 965) that 2,000 Goldstix of Verizon® stock (the seller's preferred security) have been received from the buyer. In some embodiments, after receiving the security (e.g., 2,000 Goldstix of Apple® stock) from the buyer, the system may swap / exchange the received Apple® stock for Verizon® stock using the transaction (security switchboard) matrix shown in Table 2. The seller may confirm the current transfer of the transaction amount (e.g., 2,000 Goldstix of Verizon® stock) by selecting / pressing / clicking the accept button 966. In response to the seller selecting the accept button 966, the system may post information about the current transfer of the transaction amount per intermediary facility (e.g., intermediary facilities 310, 330 in Figures 3A-3C) until the next end of the transaction.
[0134] 10A-10C illustrate a user interface in an underlying asset and securities payment system, according to one embodiment, for a seller to (1) select the securities that the seller wants the buyer to send for payment, and (2) select the securities that the seller wants to receive from the buyer for payment. In some embodiments, before sending a payment request to a buyer (e.g., a request that includes a basket of securities, a transaction amount, and / or the buyer's account information), the system may display a user interface to the seller that enables the seller to (1) select the securities that the seller wants the buyer to send for payment, and (2) select the securities that the seller wants to receive from the buyer for payment. 10A , user interface 1000 may display to the seller a message 1003 instructing the seller to select one or more securities that the seller wants the buyer to transfer to pay the transaction amount (e.g., 2000 Goldstix), selection user interfaces 1004, 1005 corresponding to securities owned by the buyer in Account 1 (e.g., Apple® stock, Verizon® stock), and / or information about the securities (e.g., number of shares, market value). A selection may be made by checking selection user interface 1004 to select the security (e.g., Apple® stock) as the seller's preferred security that the seller wants the buyer to transfer. In response to the seller selecting / pressing / clicking the continue button 1006, as shown in FIG. 10B, user interface 1030 may display to the seller a message 1033 instructing the seller to select one or more securities that the seller wishes to receive from the buyer for payment of the transaction amount (e.g., 2000 Goldstix), and selection user interfaces 1034, 1035 corresponding to securities owned by the buyer in Account 1 (e.g., Apple® stock, Verizon® stock).The seller can submit a payment request to the buyer by checking user interface 1035 to select Verizon® stock as the seller's preferred security that the seller wants to receive from the buyer for payment and selecting / pressing / clicking submit button 1036. Referring to FIG. 10C , upon receiving a payment request from the seller, user interface 1060 can display to the buyer a message 1063 instructing the buyer to select one or more securities for paying the transaction amount (e.g., 2000 Goldstix) to the seller, selection user interfaces 1064, 1065 corresponding to securities owned by the buyer in Account 1 (e.g., Apple® stock, Verizon® stock), and / or information about the securities (e.g., number of shares, market value). In some embodiments, selection interface 1064 can be pre-selected (or pre-checked) to indicate to the buyer that the seller has selected Apple® stock for paying the transaction amount. The buyer can select / press / click the transfer button 1066 to transfer pre-selected Apple® stock or select a different security (e.g., Verizon® stock) by checking the selection user interface 1065 for payment of the transaction amount (e.g., 2000 Goldstix).
[0135] 2, in step 210, in response to transferring the intermediate value (e.g., by selecting / pressing / clicking the “Transfer” button or the “Accept” button as shown in FIGS. 4A-10C), the one or more processors may be configured to automatically generate instructions (e.g., instructions for transfer 351 of 0.06927 shares of Apple® stock from the buyer account to the seller account in FIG. 3B) for a clearing facility (e.g., payment system 190, clearing company 320) to execute a transfer command for the first digital asset from the buyer account to the seller account at the ending fiat value (e.g., the closing price of Apple® stock and Verizon® stock at the end of each payment interval). In some embodiments, the instructions may indicate the number of shares of the first digital asset to be transferred.
[0136] 2, in step 212, one or more processors may send instructions to a settlement facility (e.g., settlement system 190, settlement company 320). In some embodiments, the one or more processors may send the instructions (to the settlement facility) in response to an indication that the market for the first digital asset has closed (e.g., at the end of each payment interval).
[0137] In some embodiments, a system (e.g., underlying asset and securities payment system 100) may include a trading module (e.g., trading module 142) configured to implement swaps of securities with other securities. For example, a seller may prefer to hold their assets in securities (e.g., Verizon® stock in FIGS. 9A and 9C) different from the securities received in payment from a buyer (e.g., Apple® stock in FIG. 9B). In some embodiments, the system may swap / exchange securities for other securities as shown in FIGS. 11A-11C.
[0138] 11A-11C illustrate user interfaces for switching between underlying assets and securities in a securities payment system, according to one embodiment. With reference to FIG. 11A, user interface 1100 may show (1) an indication 1101 that the seller is logged in with a seller ID, and (2) an indication 1102 that the seller's account 4 is shown. User interface 1100 may show an account summary 1103 for seller account 4, including the number of shares and total market value per security (e.g., Apple® 1104, Verizon® 1105, Tesla® 1106) owned by the seller in account 4, and / or the total market value 1107 of the securities owned by the seller in account 4. With reference to FIG. 11B, the system may show a user interface 1130 for a user (e.g., the seller) to switch between securities owned by the user. User interface 1130 may present a securities switchboard 1133 for seller account 4 that includes (1) a selection user interface (e.g., drop-down user interface 1134) for selecting a source security, (2) an input user interface (e.g., input box) 1136 for entering the amount of the selected source security, and (3) a selection user interface (e.g., drop-down user interface 1137) for selecting a target security (to which the source security will be switched). The seller may select Apple® stock 1135 as the source security, enter 1,000 Goldstix in input box 1136, select Verizon® stock 1135 as the target security, and select / press / click switch button 1139. In response to the seller clicking switch button 1139, the system may swap / exchange 1,000 Goldstix of Apple® stock for 1,000 Goldstix of Verizon® stock. In some embodiments, the system may implement stock switches / swap / exchanges using the trading (Securities Switchboard) matrix shown in Table 2.After performing the switch / swap / exchange, as shown in FIG. 11C , user interface 1160 may display an account summary 1163 for seller account 4, including the number of shares and total market value of each security (e.g., Apple® 1164, Verizon® 1165, Tesla® 1166) owned by the seller in account 4, and / or the total market value 1167 of the securities owned by the seller in account 4. Compared to account summary 1103 (see FIG. 11A ), account summary 1163 indicates that 1000 Goldstix of Apple® stock have been exchanged for the corresponding value of Verizon® stock. In other words, the number of shares and market value of Apple® stock have been decreased by 1000 Goldstix, and the number of shares and market value of Verizon® stock have been increased by 1000 Goldstix.
[0139] 12 illustrates a flow diagram of a process 1200 performed to make a payment from a buyer to a seller based on an underlying asset, according to one embodiment. In some embodiments, the process 1200 is performed by one or more processors of the system (e.g., the payment computing system 140, one or more processors 101 of the user computing devices 110b, 110s).
[0140] In step 1210, one or more processors of the payment system may receive from the point-of-sale terminal a selection of a buyer account representing an alternative to fiat or cryptocurrency for use in the transaction. As discussed herein, the buyer may elect to use the methods of electronic payment discussed herein as an alternative form of payment. Specifically, a buyer wishing to purchase a product at a point-of-sale terminal may use an input element of the terminal to select Goldstix in place of other forms of electronic payment.
[0141] In step 1220, one or more processors may receive a transaction request from a point-of-sale terminal to transfer an amount from a buyer's account to a seller's account. When a buyer selects Goldstix, one or more processors may receive the request from the point-of-sale terminal. The request may indicate that the buyer wants to purchase a product (or otherwise conduct a transaction). The request may also indicate that one or more processors should transfer an amount from the buyer's account to the seller's account. For example, the request may indicate that a buyer wants to transfer 10 Goldstix to a particular seller's account.
[0142] In step 1230, in response to the one or more processors authorizing the transaction request based at least on the amount existing in the buyer account, the one or more processors may update a database of the payment system in real time to represent a transfer of at least a portion of the amount from the buyer account to the seller account.
[0143] The one or more processors may first ensure and determine whether the buyer has sufficient value in the buyer's account to cover the transaction. For example, if the buyer requests to purchase a product for 10 Goldstix, the buyer's account may be reviewed to determine whether the buyer's account contains 10 Goldstix (or an amount of stock or other value equivalent to 10 Goldstix). If the transaction is authorized, the one or more processors may update an internal / external database associated with the buyer's account. The update may reflect that the buyer is transferring (or has transferred) the amount to the seller's account.
[0144] In step 1240, in response to the one or more processors transferring the amount, the one or more processors automatically generate a data packet containing the amount, an identification of the buyer account, an identification of the seller account, and a selection of digital assets in the buyer account, the digital assets being pre-selected in the buyer account, the digital assets being selected from the group of digital assets, and the amount being limited to transactions using digital assets from the group of digital assets.
[0145] The one or more processors may generate a data packet containing data associated with the transaction, such as the transaction amount, the identification of the buyer and its account, the identification of the seller and its account, and the like. The data packet may also indicate that the underlying assets are to be used by the buyer and / or to pay the seller.
[0146] As used herein, a data packet may refer to the basic unit of data used in a computer network to send and receive information. A data packet may be a small, self-contained block of data that contains both the actual information being sent and the control information necessary for the data to reach its destination. A data packet may contain a data payload that includes various information regarding the transaction. A data packet may also include a header with metadata that indicates the source of the payment and an indication of the destination of the payment (e.g., the buyer's account of the seller's account). A data packet may also include code that causes the recipient to perform one or more actions, such as those discussed with respect to step 1250.
[0147] In some embodiments, the one or more processors may encrypt the data packet, such that the contents of the data packet are accessible only to the recipient (e.g., a payment facility server) and / or the seller (e.g., the seller's server or computer). In some embodiments, the one or more processors may use an asymmetric encryption protocol, where a key (e.g., whether public or private) associated with the seller is used to encrypt the data, and the key may be required to access the data. As a result, only digital entities with access to the seller's key can access the data packet.
[0148] In step 1250, the one or more processors may route the data packet to a settlement facility based on the digital asset, where the data packet instructs the settlement facility to execute a transfer instruction on the digital asset exchange platform for the digital asset from the buyer account to the seller account at the end of the exchange, where the amount is based on the digital asset amount relative to the underlying asset amount.
[0149] The data packets may be transmitted to a payment facility server, which causes the payment facility to facilitate the transaction. Specifically, the data packets may cause the payment facility server to facilitate the transfer of a transaction amount from the buyer's account to the seller's account. For example, the payment facility server may redeem a specific amount of digital assets from the buyer's account and transmit the amount to the seller's account using a digital asset exchange platform for the underlying digital assets.
[0150] In some embodiments, the one or more processors may generate and send a notification (e.g., a push notification, text message, email message, application message) to the buyer indicating that the transaction amount has been debited from the buyer's account and sent to the seller's account (e.g., by sending a notification directly to the buyer's electronic device or by updating the user interface of the point of sale). To thwart possible cyber-attacks and provide secure transactions, information in the seller's account may be obfuscated. In some embodiments, the type of asset being credited to the seller's account (e.g., a basket of accepted securities) may be obfuscated, so the buyer (or others) cannot see what type of digital asset (and how much) has been paid to the seller.
[0151] In some embodiments, transferring the underlying asset from the buyer's account to the seller's account may face technical challenges. For example, while commodities may be easily exchanged in real time or near real time, the processors discussed herein may face various technical challenges. Specifically, the underlying asset may be difficult to identify and transfer from one account to another. In examples where the value of the underlying asset may be constantly changing, it may be desirable to reduce any delays. In other examples, performing additional transactions to complete the transfer may be computationally intensive, and therefore it may be desirable to implement the process more efficiently.
[0152] For example, a buyer may agree to transfer 1 Goldstix to a seller, where the underlying assets are a specific stock on the buyer's side and cryptocurrency on the seller's side (e.g., the seller requested to receive only a specific cryptocurrency). In this example, a processor discussed herein must first calculate the amount of stock needed to fulfill the transaction (e.g., calculate how many shares equal the amount of Goldstix indicated by the buyer), redeem the amount of stock, calculate the equivalent amount of cryptocurrency, and facilitate the transfer of the correct amount of cryptocurrency to the seller's account. Thus, a processor discussed herein must add a block instance to the blockchain associated with the cryptocurrency, access the seller's wallet, and work with miners to add the correct amount of cryptocurrency to that wallet. This process can be time-consuming and requires high processing power.
[0153] To address these technical challenges, the processors discussed herein may use a different paradigm, so that transactions can be facilitated faster and more efficiently while using fewer computing resources.
[0154] In one non-limiting example, as depicted in FIG. 13, one or more processors discussed herein can facilitate a transaction between two parties. FIG. 13 depicts a transaction similar to that depicted in FIGS. 3A-3C. For example, block diagram 1300 may include a user interface 1302b representing a buyer account summary displayed on a computing device operated by a buyer (buyer computer 1302a). Block diagram 1300 may also include a user interface 1304b representing a seller account summary displayed on a computing device operated by a seller (seller computer 1302a). In this example, as in FIGS. 3A-3C, a buyer operating buyer computer 1302a operates seller computer 1304a to purchase a product from a seller and owes the seller 5.00 Goldstix. Yet, unlike the example depicted in Figures 3A-3C, a central server 1306 (e.g., associated with a clearing facility, a first intermediary facility, a second intermediary facility, or a central computer that maintains and updates the central ledger) can directly debit the buyer's account (e.g., 0.06927 shares) and credit the same amount (or sometimes less, depending on fees) to the seller's account.
[0155] In some embodiments, debits and credits may occur in real time or near real time, simultaneously with the purchase of the underlying product. Thus, server 1306 can immediately transfer amounts to the seller's account. If transferring the underlying assets is not practical, server 1306 can transfer amounts to the seller's account from a reserve or repository (e.g., a central trust) created for this purpose. For example, server 1306 may have real-time or near-real-time access to a reserve of stocks (or any other currency or digital asset associated with the transaction). In this example, when server 1306 holds accounts for the buyer and seller, server 1306 can settle the transaction in real time or near real time without generating further instructions for additional processing. As a result, the seller's account reflects receipt of payment nearly instantly as the transaction is made. Server 1306 can then later debit the buyer's account and use the debited funds to replenish the reserve / repository.
[0156] In some embodiments, server 1306 may receive a data packet indicating that a buyer operating buyer computer 1302a is attempting to conduct a transaction with a seller operating seller computer 1304a. Server 1306 may then parse the data packet to determine whether the pending transaction is suitable for being facilitated by server 1306, as opposed to other methods discussed herein, such as using a different intermediary facility as depicted in Figures 3A-3C. Specifically, server 1306 may determine the amount of Goldstix to be used in the transaction and the preferred underlying asset to be used (e.g., 0.06927 Apple shares). Server 1306 may first determine whether the reserve (central trust) contains the amount and type of underlying asset (e.g., Apple shares in this case) needed to facilitate the transaction. The determination may require the amount to meet a certain threshold, such as the maximum amount of the transaction that can be funded by the amount in the reserve, which may be a percentage or value threshold. The server 1306 may also determine whether the seller's preferred type of asset is included in the central trust / reserve. For example, the seller may request to be paid in a particular cryptocurrency, which may need to be included in the reserve before the server 1306 can proceed. Once the server 1306 determines that the reserve / central trust has sufficient funds and the transaction meets the threshold, the server 1306 may proceed with conducting the transaction using the reserve, as discussed herein.If a transaction requires funds that do not meet a reserve threshold, for example, if the transaction requires more stocks (or currency or other assets) than are held in the reserve, server 1306 can initiate a transaction utilizing the data packet to obtain additional assets to satisfy the transaction, or for the transaction and additional assets for other future transactions, according to a projected or indicated need. For example, server 1306 can conduct transactions in a manner similar to the processes discussed in Figures 3A-3C.
[0157] In some embodiments, the server 1306 may perform transactions in batches (eg, batch various transactions for a seller and periodically deposit them into the seller's account).
[0158] Using the methods and systems discussed herein, one or more processors can provide a secure, relatively fast and secure alternative payment method. In one embodiment, the method includes receiving, by one or more processors of a payment system from a point of sale terminal, a selection of a buyer account representing an alternative to fiat or cryptocurrency for use in a transaction; receiving, by the one or more processors from the point of sale terminal, a transaction request to transfer an amount from the buyer account to a seller account; and, in response to authorizing the transaction request based at least on an amount existing in the buyer account, updating in real time by the one or more processors a database of the payment system to represent a transfer of at least a portion of the amount from the buyer account to the seller account, and receiving, by the one or more processors, the amount, an identification of the buyer account, automatically generating, by one or more processors, a data packet containing an identification of the seller account and a selection of digital assets in the buyer account, wherein the digital assets are selected from a group of digital assets and the amount is limited to transactions using digital assets from the group of digital assets; and routing, by the one or more processors, the data packet to a settlement facility based on the digital assets, wherein the data packet instructs the settlement facility to execute a transfer instruction on a digital asset exchange platform for the digital assets from the buyer account to the seller account at the end of the exchange, wherein the amount is based on the digital asset amount relative to the underlying asset amount.
[0159] The method may include transmitting, by one or more processors, instructions in response to an indication that a market for the digital asset has closed.
[0160] The value of the digital asset may correspond to the value of at least one of the following: the price of gold, a fiat currency, or a cryptocurrency.
[0161] The instructions may indicate the number of shares of the digital asset to be transferred.
[0162] The method may further include querying, by the one or more processors, a third-party server to receive at least one of an amount of the digital assets associated with the buyer account or a current legal value of the digital assets.
[0163] Digital assets may be held in buyer and seller accounts.
[0164] The method may include encrypting, by one or more processors, the data packet such that the encrypted data packet is only accessible to the digital entity.
[0165] The method may include debiting at least a portion of the amount from the buyer's account by one or more processors.
[0166] The method may include updating, by the one or more processors, a user interface of the point of sale to indicate that the amount has been debited from the buyer's account.
[0167] The method may include updating, by the one or more processors, a user interface associated with the seller account to indicate that at least a portion of the amount has been credited to the seller account.
[0168] In another example, a system includes one or more processors configured to execute instructions stored on a non-transitory computer-readable medium, the system comprising: receiving from a point-of-sale terminal a selection of a buyer account representing a fiat or cryptocurrency alternative for use in a transaction; receiving from the point-of-sale terminal a transaction request to transfer an amount from the buyer account to a seller account; and, in response to authorizing the transaction request based at least on an amount existing in the buyer account, updating a payment system database in real time to represent a transfer of at least a portion of the amount from the buyer account to the seller account; and, in response to authorizing the transaction request based at least on an amount existing in the buyer account, updating a payment system database in real time to represent a transfer of at least a portion of the amount from the buyer account to the seller account. and automatically generating, by one or more processors, a data packet containing a selection of digital assets in a buyer account, where the digital assets are selected from a group of digital assets and the amount is limited to transactions using digital assets from the group of digital assets; and routing the data packet to a settlement facility based on the digital assets, where the data packet instructs the settlement facility to execute a transfer instruction on a digital asset exchange platform of the digital assets from the buyer account to the seller account at the end of the exchange, where the amount is based on the digital asset amount relative to the underlying asset amount.
[0169] The one or more processors may be further configured to send instructions in response to an indication that the market for the digital asset has closed.
[0170] The value of the digital asset may correspond to the value of at least one of the following: the price of gold, a fiat currency, or a cryptocurrency.
[0171] The instructions may indicate the number of shares of the digital asset to be transferred.
[0172] The one or more processors may be further configured to query a third-party server to receive at least one of an amount of digital assets associated with the buyer account or a current legal value of the digital assets.
[0173] Digital assets may be held in buyer and seller accounts.
[0174] The one or more processors may be further configured to encrypt the data packet such that the encrypted data packet is only accessible to the digital entity.
[0175] The one or more processors may be further configured to debit the buyer account by at least a portion of the amount.
[0176] The one or more processors may be further configured to update a user interface of the point of sale to indicate that the amount has been debited from the buyer's account.
[0177] The one or more processors may be further configured to update a user interface associated with the seller account to indicate that at least a portion of the amount has been credited to the seller account.
[0178] The various illustrative logic blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functions in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure or the claims.
[0179] Computer software-implemented embodiments may be implemented in software, firmware, middleware, microcode, hardware description language, or any combination thereof. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
[0180] The actual software code or specialized control hardware used to implement these systems and methods is not a claimed feature or a limitation of this disclosure. Accordingly, the operation and behavior of the systems and methods have been described without regard to the specific software code, understanding that software and control hardware may be designed to implement the systems and methods based on the description herein.
[0181] When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable media include both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. Non-transitory processor-readable storage media may be any available medium that can be accessed by a computer. By way of example and not limitation, such non-transitory processor-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while discs reproduce data optically with a laser. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.
[0182] The previous description of the disclosed embodiments is provided to enable those skilled in the art to make or use the embodiments described herein and variations thereof. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other embodiments without departing from the spirit or scope of the subject matter disclosed herein. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the appended claims and the principles and novel features disclosed herein.
[0183] While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various disclosed aspects and embodiments are for purposes of illustration and are not intended to be limiting, the true scope and spirit being indicated by the appended claims.
Claims
1. receiving, by one or more processors, a selection of a first user account from an electronic terminal; receiving, by the one or more processors, a request from the electronic terminal to transfer an amount from the first user account to a second user account; updating, in real time by the one or more processors, a database to represent a transfer of at least a portion of the amount from the first user account to the second user account in response to authorizing the request based at least on verification of at least one data record in the first user account; automatically generating, by the one or more processors, a data packet containing the amount, an identification of the first user account, an identification of the second user account, and a selection of digital assets in the first user account, in response to transferring the amount; the digital asset is pre-selected in the first user account; the digital asset is selected from a group of digital assets, and the amount is limited to transactions using digital assets from the group of digital assets; routing the data packet by the one or more processors to a digital entity based on the digital asset, wherein the data packet instructs the digital entity to execute a transfer instruction on a digital asset exchange platform of the digital asset from the first user account to the second user account for the amount, the amount being based on the digital asset amount relative to an underlying asset amount; A method comprising:
2. receiving, by one or more processors of the payment system from the point of sale terminal, a selection of a buyer account representing a fiat or cryptocurrency alternative for use in the transaction; receiving, by the one or more processors, a transaction request from the point of sale terminal to transfer an amount from the buyer account to a seller account; updating, in real time by the one or more processors, a database of the payment system to represent a transfer of at least a portion of the amount from the buyer account to the seller account in response to authorizing the transaction request based at least on the amount existing in the buyer account; automatically generating, by the one or more processors, a data packet containing the amount, an identification of the buyer account, an identification of the seller account, and a selection of digital assets in the buyer account; the digital asset is selected from a group of digital assets, and the amount is limited to transactions using digital assets from the group of digital assets; routing the data packet by the one or more processors to a settlement facility based on the digital asset, wherein the data packet instructs the settlement facility to execute a transfer instruction on a digital asset exchange platform for the digital asset from the buyer account to the seller account at the end of the exchange, the amount being based on the digital asset amount relative to an underlying asset amount; A method comprising:
3. transmitting, by the one or more processors, the instructions in response to an indication that the market for the digital asset is closed. The method of claim 2 further comprising:
4. 3. The method of claim 2, wherein the value of the digital asset corresponds to the value of at least one of the following: the price of gold, a fiat currency, or a cryptocurrency.
5. 3. The method of claim 2, wherein the instructions indicate a number of shares of the digital asset to be transferred.
6. querying by the one or more processors to a third party server to receive at least one of an amount of the digital assets associated with the buyer account or a current legal value of the digital assets; The method of claim 2 further comprising:
7. The method of claim 2 , wherein the digital assets are held in the buyer account and the seller account.
8. encrypting, by the one or more processors, the data packets such that the encrypted data packets are accessible only to the digital entity. The method of claim 2 further comprising:
9. debiting, by the one or more processors, at least a portion of the amount from the buyer account. The method of claim 2 further comprising:
10. updating, by said one or more processors, a user interface of said point of sale to indicate that said amount has been debited from said buyer's account. The method of claim 2 further comprising:
11. updating, by the one or more processors, a user interface associated with the seller account to indicate that at least a portion of the amount has been credited to the seller account. The method of claim 2 further comprising:
12. One or more processors configured to execute instructions stored on a non-transitory computer-readable medium, receiving from the point of sale terminal a selection of a buyer account representing a fiat currency or cryptocurrency alternative for use in the transaction; receiving a transaction request from the point of sale terminal to transfer an amount from the buyer account to the seller account; In response to authorizing the transaction request based at least on the amount existing in the buyer account, updating a database of the payment system in real time to represent a transfer of at least a portion of the amount from the buyer account to the seller account; automatically generating, by the one or more processors, a data packet containing the amount, an identification of the buyer account, an identification of the seller account, and a selection of digital assets in the buyer account, wherein the digital assets are selected from a group of digital assets and the amount is limited to transactions using digital assets from the group of digital assets; routing the data packet to a settlement facility based on the digital asset, wherein the data packet instructs the settlement facility to execute a transfer instruction on a digital asset exchange platform for the digital asset from the buyer's account to the seller's account at the end of the exchange, the amount being based on the digital asset amount relative to an underlying asset amount; one or more processors configured to perform A system comprising:
13. 13. The system of claim 12, wherein the one or more processors are further configured to send the instructions in response to an indication that a market for the digital asset is closed.
14. 13. The system of claim 12, wherein the value of the digital asset corresponds to the value of at least one of the price of gold, a fiat currency, or a cryptocurrency.
15. 13. The system of claim 12, wherein the instructions indicate a number of shares of the digital asset to be transferred.
16. the one or more processors: querying a third-party server to receive at least one of the amount of the digital assets associated with the buyer account or the current legal value of the digital assets; The system of claim 12 , further configured to:
17. 13. The system of claim 12, wherein the digital assets are held in the buyer account and the seller account.
18. the one or more processors: encrypting the data packet such that the encrypted data packet is accessible only to the digital entity; The system of claim 12 , further configured to:
19. the one or more processors: debiting said buyer's account by at least a portion of said amount; The system of claim 12 , further configured to:
20. the one or more processors: updating a user interface of the point of sale to indicate that the amount has been debited from the buyer's account.
20. The system of claim 19, further configured to:
21. the one or more processors: updating a user interface associated with the seller account to indicate that at least a portion of the amount has been credited to the seller account. The system of claim 12 , further configured to: