Apparatus, system, or method for facilitating value transfer between parties with low or no trust

Abstract

An apparatus, system and method are provided that facilitate the transfer of value between parties with low or no trust. [Solution] Client A, Client B, and a facilitator, connected via a computer network 140, each include a computer processor. The transfer mechanism includes the Bitcoin protocol, and each client and facilitator includes a persistent data store for storing a key pair and a first transaction. Client A monitors the state of the transfer mechanism, the facilitator, a data source, Client B, etc., or some other input, automatically interacts with various participants based on state changes, and upon observing that it has acquired new ownership of 150 Bitcoins, initiates an offer to trade exposure to one financial instrument or security (e.g., US dollars) in exchange for exposure to another financial instrument or security (e.g., US dollars) via the facilitator.

Description

[Technical Field]

[0001] Related fields include telecommunications, digital communications and computer technology.

[0002] Priority claim This application claims priority to U.S. Provisional Application No. 61 / 990,795, filed May 9, 2014, the disclosures of all applications mentioned in this paragraph being incorporated herein by reference as if fully set forth herein.

[0003] Copyright Statement The entire contents of this document, including any illustrations, are subject to copyright protection under the laws of the United States and other countries, and the owner has no objection to the reproduction or disclosure of this document as it appears in official government records. All other rights remain with the author. [Background technology]

[0004] Market efficiency tends to increase, and therefore transaction costs tend to decrease in proportion to the degree of mutual trust between the parties. However, as market size increases, interest rates tend to exceed market rates, and therefore trust tends to decrease. Efficient and productive participation in larger markets (Non-Patent Document 1) requires mitigating this trust problem, but this comes at a cost. Although these costs are often reduced through economies of scale, there are still significant expenses today to buffer against risks from counterparties, intermediaries, post-delivery payment failures, guarantor failures, escrows, etc.

[0005] Since the mid-1990s, there has been an explosion of commercial activity, with transactions being agreed between parties who previously did not know each other, sometimes across national borders, using the Internet as the primary communication medium. Establishing and maintaining trust between parties plays a crucial role, and various solutions have been attempted using traditional and inefficient methods.

[0006] These privately held markets include those trading financial instruments (stocks, bonds, options, futures, swaps, uncovered balances, etc.). The advent of financial engineering has enabled individuals and firms to leverage computation in financial trading, automating the entry and exit of trades through programmed conditions and algorithms. However, despite the explosive growth in the use of technology in this area, such technologies remain overwhelmingly embedded within traditional centralized markets. Nearly all impose relatively high costs for trading. Some large exchanges promote the idea that "high value" (i.e., high-value) customers are given priority over less sophisticated or unskilled investors. Some question the fairness of such practices.

[0007] Furthermore, the costs of enforcing contracts in international trade can be prohibitive, and success can be very difficult to predict. Furthermore, a seller may want to receive one currency while a buyer wants to send another. The value of currencies denominated in other currencies can be volatile. Traditionally, parties to distance trades have often mitigated risk by involving a third party. One such mechanism is the letter of credit (L / C). A letter of credit works when the seller does not necessarily trust the buyer with a large order, but does trust the bank to which the buyer has established a credit line. The buyer and bank agree to release funds from the credit line once the seller meets certain conditions (often contingent on sending evidence of shipment to the bank by a specific date and time). The bank issues a promise (L / C) to the seller, and the seller and buyer agree to the remaining terms. However, payment is often made later than agreed upon, and exchange rates may fluctuate between the agreed date and payment. Only the largest institutions have the resources to adequately handle such exchange rate volatility. Furthermore, the amounts charged by banks for letters of credit and exchanges are substantial. Conversely, intermediaries must be highly trustworthy to effectively act as self-interested document examiners who can independently verify the authenticity of the documents before releasing funds, potentially leaving the seller with a high risk of error, forgery, or fraud. Letters of credit are therefore less suitable for trade where relative currency values ​​may fluctuate widely, or for consumer transactions.

[0008] Decentralized digital currencies (also known as cryptocurrencies) are relatively new creatures, promising the creation of tightly controlled assets, the ability to transfer control or ownership of assets when strictly defined criteria are met, with little or no third-party intervention, and at significantly lower transfer costs than previous mechanisms. Bitcoin and its derivatives (Ethereum, Litecoin, etc.) are one such technology that has recently seen a rapid rise in popularity (and recognition).

[0009] To illustrate this by way of non-limiting example, these particular decentralized digital currencies generally function by maintaining a partial or complete history of a "ledger" (sometimes called a "blockchain") of all transactions "verified" by network participants. With some exceptions beyond the scope of this invention, transactions function roughly as follows (see Non-Patent Document 2): A transaction consists of at least one input and one output, where the input consists of an input "script" consisting of regular, well-defined executable operations. The output consists of a second output script that also contains such operations. A new (child) transaction is created by predictably combining the output script from an existing (parent) transaction with the input script. A new transaction is considered valid and produces the expected result if a majority of network participants agree that the combination is acceptable given the predetermined rules. A transaction output is considered "spent" when it is associated with a valid child transaction by a majority of network participants, and "unspent" when it is not associated with a valid child transaction by a majority of network participants. The concept of "ownership" or "rights" to a transaction output is defined by which entity controls said output, or more specifically, who can create new transactions or "spend" the output in a way that is recognized as valid by the majority of network participants.

[0010] More specifically, an entity wishing to submit a new transaction to the ledger transmits (or "broadcasts") a transaction record containing details of the desired transaction to several network participants (called "peers") who are familiar with the transaction record. Each of these peers attempts to verify the transaction record, and if successful, transmits the transaction record to more of their peers, and so on. Eventually, the transaction record containing the transaction reaches the participants configured to execute it.

[0011] A transaction occurs when one entity generates a child transaction that is accepted as valid by a majority, and whose inputs are associated with unspent outputs from a parent transaction. In most cases, this is a simple transfer of control to a second entity, and the output script of the new transaction is a small series of operations such that creating the corresponding input script is computationally easy for a single entity that owns a particular asymmetric grid key pair and computationally impractical for all others. In other words, it is addressed to an entity with access to a particular private key. Existing software abstracts these addresses and simple transactions away from programmers and the general public, who are not protocol experts.

[0012] However, the script that defines the conditions under which a transaction is accepted as valid is considered a set of available operations. Because the typical way to describe these operations is usually in binary or programming code (NPL 3), the average person cannot comprehend or create arbitrary transactions. For example, as of April 21, 2014, the Bitcoin Contracts Wild page consisted of several simple theoretical instructions (NPL 4). Each instruction is unrelated to its role in the transaction, making it difficult for the average person to even understand these instructions. The basic steps and combinations of similar transactions that would allow for confident execution are missing. Despite its great potential, this kind of unabstracted complexity prevents the Bitcoin protocol and its derivatives from becoming as widely adopted as previous "easy" payment methods.

[0013] Decentralized Digital Currencies or "Cryptocurrencies"

[0014] The design and functionality of the Bitcoin protocol and its derivatives can be described as follows (Non-Patent Document 5). Although this section refers to Bitcoin by name, this description is generally valid for nearly all decentralized digital currencies currently known in the art.

[0015] Blockchain: A "blockchain" is a public ledger that records Bitcoin transactions. The new solution achieves block maintenance without the intervention of a central authority. The chain is carried out by a communication network via communication nodes running Bitcoin software. Transactions of the form "Payer X sends Bitcoin to Recipient Z" are broadcast to this network using readily available software applications. Network nodes can verify transactions, add them to their copy of the ledger, and broadcast these ledger additions to other nodes. To independently verify ownership of any Bitcoin amount, each network node stores its own copy of the blockchain. Approximately six times per hour, a new group of accepted transactions (a block) is created and published to all nodes immediately after being added to the blockchain. This allows the Bitcoin software to determine when a particular Bitcoin has been spent, which is necessary to prevent double-spending in an environment without a central authority. While traditional ledgers record the transfer of actual invoices or promissory notes that exist separately from them, the blockchain is the only place where Bitcoin can be said to exist in the form of unspent transaction outputs.

[0016] Units: Bitcoin's unit of account is Bitcoin (). Smaller multiples of Bitcoin used as alternative units are millibitcoin (mBTC), microbitcoin (μBT), and satoshi. A "satoshi," named after Bitcoin's creator, is the smallest multiple of Bitcoin and represents 0.00000001, or one hundred millionth of a Bitcoin. A millibitcoin is 0.001, or one thousandth of a Bitcoin, and a microbitcoin is 0.000001, or one millionth of a Bitcoin. A microbitcoin is also known as a "bit."

[0017] Ownership: See Figure 24. Bitcoin ownership refers to a user's ability to spend Bitcoins by associating them with a specific address. This requires the payer to digitally sign the transaction using a personal key. Without knowledge of the private key, the transaction cannot be signed and the Bitcoin cannot be spent. The network verifies the signature using the public key. If the private key is lost, the Bitcoin network does not recognize any other proof of ownership; therefore, the coins become unspent and are effectively lost. In 2013, one user claimed to have lost 7,500 Bitcoins (valued at $7.5 million) when he threw away the hard drive that stored his private key.

[0018] Transaction: A transaction typically requires one or more inputs. (A "coinbase" is a special transaction used to create Bitcoin and has an input of 0; see "mining" and "supply" below.) For a transaction to be valid, all inputs must be "unspent" outputs from previous transactions, and all inputs must be digitally signed. Multiple inputs imply the use of multiple coins in a cash transaction. A transaction can also have multiple outputs, allowing multiple payments to be combined in one transaction. Transaction outputs can be specified as any multiple of "satoshis." As with cash transactions, the total inputs (coins for payment) can be greater than or equal to the total payment amount. In such cases, the additional output provides change to the payer. Satoshi inputs not included in the transaction output constitute transaction fees.

[0019] Every transaction record has a "lock time" attached to it, which prevents the transaction from being accepted as valid and makes it available for redemption or exchange until an agreed-upon time in the future. In Bitcoin and similar protocols, this can be specified as a block index or a timestamp. The transaction record will not be accepted into the blockchain until the lock time is reached. Other, more flexible mechanisms have also been proposed (Non-Patent Document 6).

[0020] Mining: "Mining" is a record-keeping service. Miners keep the blockchain constant, complete, and immutable by repeatedly validating the blockchain and collecting newly announced transactions into new groups of transactions called "blocks." New blocks contain information that "connects" them to the previous block (hence the name). That information is a cryptographic hash of the previous block using the SHA-256 hashing algorithm.

[0021] Each new block must contain what's called a "proof of work." This proof includes a number called the "difficulty target" and a technical term for a "nonce," a number used only once. Miners must find a "nonce" that generates a new block's hash that's smaller than the difficulty target. When a new block is created and distributed to the network, network nodes can easily verify the proof. However, finding the proof is a substantial undertaking, since there's only one way to find the "nonce" needed for secure cryptographic hashing: by trying different integers one by one, then two by three, and so on, until the required output is achieved. The fact that the new block's hash is smaller than the difficulty target proves that this laborious work has actually been done, hence the term "proof of work."

[0022] Block chaining and the proof-of-work system make it extremely difficult to change the blockchain because an attacker must modify all subsequent blocks for a block to be accepted. Because new blocks are constantly being mined, the number of subsequent blocks (also known as confirmations of a given block) increases over time, making it increasingly difficult to change a block.

[0023] Supply: Miners who successfully find new blocks are rewarded with newly minted bitcoins and transaction fees. As of November 28, 2012, the reward was 25 newly minted bitcoins for each block added to the blockchain. A special transaction called a "coinbase" is included in processed payments to receive the reward. Every bitcoin in circulation can be traced back to that coinbase transaction. The Bitcoin protocol specifies that the reward for adding a block is halved approximately every four years. Eventually, at an arbitrary limit of 21 million bitcoins in circulation around 2140, the reward itself will be abolished and record-keeping will be rewarded solely through transaction fees. [Prior art documents] [Non-patent literature]

[0024] [Non-Patent Document 1] Electronic commerce, Rose, David C. The Moral Foundations of Economic Behavior, New York Oxford UP, 2011 Printing, "online" escrow and dispute resolution using third parties with expensive fees, various reputation systems, third-party guarantors, etc. [Non-patent document 2] This is an overly simplified description of the Bitcoin protocol. For more information, see Bitcoin Wiki.<https: / / en.bitcoin.it / > For more information about the Ethereum protocol, see the Ethereum Wiki.<https: / / github.com / etliereum / wiki / wiki> See Ledger Record (i.e., valid "blocks" - see detailed explanation below). [Non-patent document 3] See "How to Create a Bitcoin Multi-Signature 2-of-3 Transaction" StackExchange March 23, 2014 Web April 2014. https: / / bitcoin.stackexchangexom / questions / 37i2 / how-can-i-create-a-multi-signature-2-of-3-transaction [Non-patent document 4] Hahn, Mike "Bitcoin Contracts" Bitcoin Community April 9, 2014 Web April 2014 <https: / / bitcoin.stackexchangexom / questions / 37i2 / how-can-i-create-a-m ulti-signature-2-of-3-transaction> . [Non-patent document 5] <https: / / en.wikipedia.org / wiki / Bitcoin> and<https: / / en.bitcoin.it / wiki / Contracts> Quote from [Non-patent document 6] See, for example, "BIP-65: Revisiting i LockTime," Qntra.net, November 13, 2014. Web, May 4, 2015.<http: / / qntra.net / 2014 / 11 / bip-65-revisiti11g-niocktime / > . Summary of the Invention

[0025] The present invention relates to systems and methods for negotiating and enforcing agreements subject to third-party input at any distance without special technical knowledge of the underlying transfer mechanism, allowing third parties to intervene at will, substitute terms, amend, improve, etc. Such transfers can be performed reliably without the previously required expensive third-party intermediaries and without the previously required counterparty risk.

[0026] In this application, we consider two forms of value transfer: discretionary swaps and letters of credit. Discretionary swaps and letters of credit are useful for illustration because they are two very different entities, but have strikingly similar representations and enforceability due to the invention. It will be apparent to those skilled in the art that the invention can be applied to many other forms of value transfer.

[0027] In one example, suppose A believes that Bitcoin will appreciate significantly in value over the next few weeks when valued in New Zealand dollars. B believes the opposite, that Bitcoin will fall in value over the next few weeks when valued in New Zealand dollars. Neither party knows the other, but they want to make a small bet that aligns with their beliefs. One embodiment of the present invention allows the two parties to find each other, negotiate to determine specific terms, and then enforce this agreement without traditionally expensive methods.

[0028] In another example, A is a merchant who wants to accept payment for her services in Bitcoin, but would prefer to be paid in US dollars rather than Bitcoin, which is volatile. She doesn't care if Bitcoin fluctuates in value against the US dollar. She can periodically (once a day or with each transaction) sell her US dollar-valued Bitcoin exposure in proportion to the Bitcoin she receives from her customers. In other words, she converts her Bitcoin exposure into US dollars. B wants Bitcoin, but has a lot of US dollars and would like more Bitcoin exposure valued in US dollars. In one embodiment of the present invention, B can find A and exchange or swap their exposure with A, allowing A to receive payment for goods and services in Bitcoin, knowing that if Bitcoin's value declines against the US dollar, B will compensate her, provided that B receives the increase in Bitcoin's value against the US dollar. In another embodiment, these swaps are found automatically whenever A is detected as having received additional Bitcoin.

[0029] Combinations are possible. For example, Person A accepts Australian Dollars (AUD) but prefers USD and wants to hedge against the volatility of the AUD against the USD. In one embodiment of the present invention, Person A could exchange USD exposure for Bitcoin with Person B, and then exchange Bitcoin exposure for AUD with Person C over a similar period, thus compounding the AUD hedge in USD. B and C do not have to be different entities (they could even be the same person), and Person A does not have to execute two different transactions. Furthermore, various embodiments of the present invention allow parties to execute this type of transaction without maintaining foreign currency deposits or buying and exchanging currencies.

[0030] In yet another example, A may want to purchase goods from B, two parties unknown to each other, and B wants assurance of the availability of funds from A, but A does not want to release those funds to B (or the transferor) until B shows proof of shipment (and meets other predetermined conditions).

[0031] In one embodiment involving a swap, a first device and a second client, referred to as a "client," may engage in a series of transactions in which the first client, the second client, or any two of the intermediaries collude to commit the first party's assets (e.g., unspent trading outputs) and the second party's assets until they are released based on the intermediary's calculations based on observations of external conditions, such as the relative values ​​of financial instruments over a particular period of time.

[0032] In other embodiments involving letters of credit, a first and second client may participate in a series of transactions that remain committed until the first client and intermediary release the first client's assets based on observation of external conditions, such as verification of a shipper or delivery to an address.

[0033] In a further embodiment, if no such observation is made, the asset may be refunded according to an expiration timestamp.

[0034] In another embodiment, the commitment of assets may be postponed until a favorable settlement is reached by the arbitrator. [Brief explanation of the drawings]

[0035] [Figure 1] FIG. 1 illustrates an exemplary embodiment of the present invention that uses and includes a transfer mechanism such as a decentralized digital currency (150) in which different participants, such as clients (120, 160, 170), transfer mechanisms (110, 150), a facilitator (100), and a data source (130), are connected by a computer network (140). [Figure 2] FIG. 2 illustrates aspects of one embodiment relating to a swap that includes one or more source trades, a commit trade. [Figure 3] FIG. 3 illustrates aspects of one embodiment related to a swap that includes a commit transaction and a refund transaction. [Figure 4] 4-5 illustrate aspects of one embodiment relating to a relatively simple swap involving principal and collateral. [Figure 5] Same as above. [Figure 6] Figures 6-7 show transaction chains from several example swap embodiments where one party wishes to exit before termination but cannot guarantee the other's consent, and still finds a third party willing to act on behalf of the exiting party. [Figure 7] Same as above. [Figure 8] FIG. 8 illustrates aspects of one embodiment related to a letter of credit that includes a source transaction and a commit transaction. [Figure 9] FIG. 9 illustrates aspects of one embodiment related to letters of credit, including commit transactions and expiry transactions. [Figure 10] 10 and 11 illustrate aspects of one embodiment relating to a relatively simple letter of credit that includes principal and collateral. [Figure 11] Same as above. [Figure 12]Figures 12 to 14 show transaction chains from several example embodiments involving letters of credit that involve party substitution. [Figure 13] Same as above. [Figure 14] Same as above. [Figure 15] 15 and 16 show aspects of an embodiment where the parties to a value transfer set up an intermediary in case of a dispute. [Figure 16] Same as above. [Figure 17] 17-22 illustrate the main steps in performing a value transfer in one embodiment. [Figure 18] Same as above. [Figure 19] Same as above. [Figure 20] Same as above. [Figure 21] Same as above. [Figure 22] Same as above. [Figure 23] FIG. 23 shows the components of an exemplary embodiment, including a client (120) or a facilitator (100). [Figure 24] Figure 24 (Prior Art) shows a simplified chain of ownership in a decentralized digital currency. DETAILED DESCRIPTION OF THE INVENTION

[0036] The present invention is not limited to the following embodiments. The following description is illustrative, not limiting. Other systems, methods, features, and advantages will become apparent to one of ordinary skill in the art upon examination of the drawings and detailed description. All such additional systems, methods, features, and advantages are within the scope of the present subject matter, intended to be included within this description, and protected by the accompanying claims.

[0037] For example, while the Bitcoin protocol is often used in this application as a means of illustration, the present invention is not specifically limited to the Bitcoin protocol. Any technology that makes it sufficiently difficult to recharacterize ownership of assets (virtual or otherwise) unless certain well-defined criteria are met may be substituted. The present invention is not limited to decentralized or centralized transfer mechanisms. For example, in one embodiment, transfers may be recognized (i.e., facilitated) by an authority (centralized), while in another embodiment, transfers may be confirmed by elections (decentralized), etc.

[0038] Furthermore, while the Bitcoin protocol and similar technologies explicitly identify "inputs" and "outputs" in transactions, the present invention is not limited to such transfer mechanisms. Various embodiments of the present invention can be implemented in any context in which asset ownership can be reclassified, provided the transfer mechanism exposes the necessary functionality. This application uses the terms "input" and "output" literally (e.g., with respect to Bitcoin and derivative technologies) and figuratively (e.g., with respect to other technologies, such as double-entry bookkeeping and chain of title). In more traditional models, for example, "input" might refer to some or all of the available "balance" of an account under the control of one entity (e.g., a traditional bank), and "output" might include reference to an account (e.g., account number) at another entity. In such models, asset reclassification involves debiting a first entity's account and crediting a second entity's account (presumably minimally) upon the satisfaction of a predetermined condition. This is merely one example of a proxy transfer mechanism in which the present invention may be implemented.

[0039] Furthermore, this application may use terms such as "display," "user input," "display device," "user input device," and the like to disclose or imply the subject matter of the present invention. However, the present invention is not limited to practice by individuals with typical five-sensory abilities, and "display" is intended to include any device capable of communicating information to a human clearly through any sense or combination of senses. For example, a blind person can use a device with an "audio display" that includes a text-to-speech synthesizer, as well as a Braille terminal. Similarly, "user input" is intended to include any device capable of receiving information from a human. Popular user input devices, known as "ModernSy," include not only keyboards, mice, and touchscreens, but also speech synthesizers, sip-and-push devices, click-and-type devices, and motion or gesture recognition devices. These are just a few examples. A variety of such displays and user input devices are known in the art and can, of course, be used in practicing the present invention.

[0040] In the embodiment shown in FIG. 1, the present invention includes some or all of the illustrated participants on a computer network. The participants typically include a first client (A) operating on behalf of a first party (not shown) connected to the computer network, a second party (not shown) permanently or intermittently coupled to the computer network, a transport mechanism accessible via the computer network, a facilitator accessible to the computer network, and optionally one or more data sources accessible by the facilitator. In a typical embodiment, the computer network includes the Internet and related technologies, although this is not a requirement. Other configurations are possible. For example, the computer network may include multiple independent computer networks for connecting any subset of participants, such as private networks, VPNs, secure tunnels, frame relay, etc. Non-limiting examples of modern equipment include hardwire, firmware, software, and other network technologies such as Ethernet, Wireless Ethernet™ (Wi-Fi), mobile radio (e.g., CDMA, FDMA, SOMA, TDMA, GSM™ (GRPS), UMTS, EDGE, LTE, etc.), Bluetooth™, Firewire, USB, IP, TCP, UDP, SSL, etc., used together.

[0041] In typical embodiments, the first client, second client, and facilitator each comprise a computer processor configured to perform certain steps within the scope of the present invention. In some embodiments, such as those using the Ethereum protocol as the transfer mechanism, the facilitator contains computational instructions that are evaluated by network participants via a proof-of-work protocol, in which case the network participants comprise a computer processor configured to evaluate the instructions for the computation. In many embodiments, the client comprises a display device and an input device for human interaction, although this is not strictly necessary. In other embodiments, the client can be automated to completion without human intervention. In one such embodiment, the computer processor of the first client is configured to monitor the status of the transfer mechanism, facilitator, data source, second client, or some other input, and is configured to automatically interact with various participants based on state changes.

[0042] For example, in one embodiment, the transfer mechanism includes the Bitcoin protocol, with each client and facilitator having a key pair and a persistent data store for storing the first transaction. Upon observing that the first client has acquired new ownership of Bitcoin, the first client is configured to initiate an offer to trade exposure to one financial instrument or security (e.g., Bitcoin) through the facilitator in exchange for exposure to another financial instrument or security (e.g., U.S. Dollars).

[0043] FIG. 1 illustrates an exemplary embodiment of the present invention, particularly for use with a distributed forwarding mechanism, in which the client, transfer mechanism, facilitator, and data source are separate participants. However, the illustrated configuration is not the only configuration contemplated by the present invention. In other embodiments, the facilitator represents some or all aspects of the transfer mechanism. In other embodiments, the facilitator includes some or all aspects of the client. For example, some or all of the client's data store, its ability to initiate or accept offers, etc., may be "embedded" in the facilitator, thereby enabling the facilitator to represent the client. In yet other embodiments (e.g., controlled by the owner of the facilitator or on behalf of a third party that has delegated control to the facilitator), the facilitator comprises the data source. Many configurations contemplated by the present invention are possible and will be apparent to those skilled in the art.

[0044] 2 illustrates aspects of one embodiment of a swap that includes one or more source transactions and a commit transaction. As shown, the commit transaction has a first input for accepting a first amount from a first source transaction (i.e., a first party) and one or more outputs for receiving a second amount from a second source transaction (i.e., from a second party) and directing portions of these amounts to one or more other transactions (not shown), where the first and second amounts are often equal but not necessarily, and in some cases are sums of expected amounts that include a principal amount (P) and an (optional) collateral amount (C), as shown in multiple figures.

[0045] In a typical embodiment, a commit transaction is configured such that some or all of the amount available via its output(s) can be spent only after confirmation from at least two of the first and second parties, the facilitator, and any third party. In other embodiments, a commit transaction is configured such that some or all of the amount available via its output can be spent only after confirmation from either the facilitator or any trusted third party and one of the first and second parties. In other embodiments, a commit transaction is configured such that some or all of the amount available via its output can be transferred after confirmation from either the first party, the second party, a third party, and optionally a trusted third party as needed. These are non-limiting examples, and in addition to the examples provided herein, a commit transaction may be configured such that the output establishes ownership for any number of parties. These transactions are somewhat similar to a checking account, which must be signed by an authorized party.

[0046] Although primary and secondary source transactions are shown in FIG. 2, this should not be construed as limiting the present invention. Amounts may be input into a commit transaction from any number of different sources. Any excess amounts are returned to the original or different party upon completion. The only limitation is that the commit transaction, at least in some embodiments, must be adjusted to compensate for fees (not shown) charged for sending amounts from each source to said inputs. For example, the transfer mechanism may impose transfer fees, withdrawal fees, wire fees, etc. As an example, the Bitcoin protocol may require a "mining fee" to ensure timely transactions on the blockchain.

[0047] FIG. 3 illustrates aspects of one embodiment of a swap that includes a commit transaction and a refund transaction. The commit transaction includes a first principal amount (P A ) to receive the first input, the second principal amount (P B), and a commit output. A refund transaction includes an input for receiving the amount from the commit output, a first refund output to the first party, and a second refund output to the second party. In a typical embodiment, the refund transaction record is generated a fixed period of time after the commit transaction, or is generated such that it is valid only if the commit output has not yet been used after a fixed time in the future. This allows another transaction to use the commit output in preference to another transaction, and if no such other transaction has been created, the refund transaction record can be sent to a forwarding mechanism to restore the parties to their original positions.

[0048] Figures 4-5 illustrate aspects of a swap embodiment involving a relatively simple payment transaction in a swap situation involving principal and collateral. As shown in Figures 2-4, a commit transaction involves a first principal and collateral input from a first party and a second principal and collateral input from a second party. As shown in Figures 2-5, a commit transaction involves a first principal (P A ), first security from the first party (C A ), second principal input from the second party (P B ), and a second security from a second party (C B ) These are just two of many possible configurations that will be apparent to those skilled in the art. For example, a commit transaction may include a principal input from a first party, a collateral input from a second party (e.g., a guarantor for the first party, not shown), and a principal and collateral input from a third party.

[0049] In the embodiments shown in Figures 4 and 5, each payment transaction includes an input for receiving an amount from the commit output. In Figure 4, this includes a modified principal and collateral payment output to the first party, a modified principal and collateral payment output to the second party, and a fee (φ) output to an optional third party. In Figure 5, the payment transaction includes a collateral payment output to the first party, a modified principal payment output to the first party, a modified collateral payment output to the second party, and an optional fee output to the third party. These are just two of many possible configurations that will be apparent to those skilled in the art. For example, similar to the above, a payment transaction could also consist of a modified principal payment output to the first party, a potentially modified collateral payment output (in the event of principal depletion) to a third party (e.g., the first party's guarantor), or a potentially modified collateral payment output (in the event of principal depletion) to the second party.

[0050] In the embodiment shown in Figures 4 and 5, the fee is apportioned from the revised principal and distributed equally between the parties to the transaction, but this is not required. The fee may be paid in any tier or multiple tiers. The allocation can be made in stages. It can be that one party bears all or a large percentage of the payment output. Also, in each of the embodiments shown in Figures 4 and 5, the calculation of the amount of the multiple payment outputs includes a difference (δ) that is positive for one party and negative for the other party. For example, in the payment transaction shown in Figure 5, if the second principal is used up before the expiration date of the swap, an allocation of amount from the collateral is required. In other words:

number

[0051] Some of the various components described above can be used to facilitate a basic swap agreement. To illustrate how, assume the following steps occur in one embodiment in a Bitcoin or similar protocol transfer mechanism where the parties do not trust each other and the facilitator is not trusted to completion by either party: 1. A first client sends an offer with the following conditions, including: (a) a reference to a data source that includes at least one of an underlying security and a quoted security; (b) the principal amount; (c) an expiration timestamp; (d) optionally, a reference to a nominal asset; (e) optionally, the amount of security; (f) Optional payment features. For example, it can be expressed as follows: [Table 1] 2. Optionally, the facilitator verifies aspects of the offer (e.g., the facilitator can interpret the terms, the expiration date is within an acceptable range, etc.) If the verification is not successful, the facilitator can reject the offer and optionally send an error message to the first client. 3. The second client retrieves the offer from the facilitator. 4. The first client creates a first source transaction record that includes the transaction ID to the transport mechanism. 5. The second client creates a second source transaction record that includes the transaction ID to the transfer mechanism. 6. The second client optionally sends the transaction ID of the second source transaction record to the first client via the facilitator (e.g., in the same message, via an offer ID, offer hash, etc.) In another embodiment, the first client sends the transaction ID of the first source transaction record to the second client, and the subsequent steps reflect the following of this embodiment. 7. The second client and one of the facilitators send the second public key to the first client in a manner associated with the offer. 8. The first client signs (i.e., computes and associates a cryptographic signature with) the first principal input of the pending commit transaction record to create a completed commit transaction record. The pending commit transaction record includes: (a) a first principal input to receive a first principal amount from a first source transaction; (b) a second principal input commitment amount to receive a second principal amount from a second source transaction; (c) a commit output that includes, subject to requiring signatures of the private keys of two of (i) the first public key, (ii) the second public key, and (iii) the facilitator's public key. Example of an incomplete commit transaction record: [Table 2] 9. The first client sends the incomplete commit transaction record to the second client, optionally via a facilitator. The facilitator optionally verifies aspects of the initial commit transaction record (e.g., that the initial commit transaction record is signed by the first party and that the first and second principal amounts meet respective conditions). If the verification is not successful, the facilitator can reject the first commit transaction, and optionally an error message is displayed to the first client. The facilitator optionally sends the offer and initial commit transaction record to the second client. 10. The second client optionally verifies that the pending commit transaction record was signed by the first party, etc. 11. The second client creates a completed commit transaction record by signing the incomplete commit transaction record, and optionally stores it in persistent memory. The completed commit transaction record includes: (a) a first principal input to receive a first principal amount from a first original transaction; (b) a second principal input to receive a second principal amount from the second source transaction; (c) a commit output containing the commit amount and (i) the first public key, (ii) the second public key, and (iii) the facilitator's public key, subject to the requirement that the facilitator require a signature of the private keys of two of the public keys. Example of a completed commit transaction record: [Table 3] 12. The second client signs the pending withdrawal transaction record, which includes: (a) the lock time after the expiration timestamp, (b) an input to receive the committed amount from the committed transaction record; (c) a first refund output including a first refund amount and a first condition requiring approval by the first party; (d) a second refund output including a second refund amount and a condition requiring approval by the second party; Example of an incomplete refund transaction [Table 4] 13. The second client sends the completed commit transaction record and the incomplete refund transaction record to the first client, possibly via a facilitator. The facilitator optionally verifies the completed commit transaction record and the incomplete refund transaction record (e.g., whether the completed refund transaction record is signed by the first and second parties, whether the incomplete check refund transaction record is signed by the second party, whether the incomplete refund transaction record and the completed commit transaction record amount descriptions are equal, whether the incomplete refund amount is less than or equal to the first principal amount, whether the second refund amount of the small refund transaction record is less than or equal to the second principal amount, whether the lock time is after the expiration timestamp, etc.). If the validation fails, the facilitator can reject the refund transaction record or the completed commit transaction record and optionally send an error message to the second client. The facilitator optionally sends the completed commit transaction record and the incomplete refund transaction record to the first client. 14. The first client optionally verifies that the completed commit transaction record is as expected and signed by the first party and the second party, that the initial refund transaction record is as expected and signed by the second party, etc. 15. The first client optionally saves a copy of the completed commit transaction record in persistent memory. 16. The first client optionally creates a completed refund transaction record and stores a copy of the completed refund transaction record in persistent memory. The completed refund transaction record includes: (a) the lock time after the expiration timestamp, (b) an input to receive the committed amount from the completed committed transaction; (c) a first refund output including a first refund amount and a first condition requiring approval from a first party, and a second refund output including a second refund amount and a condition requiring approval from a second party; Contains: Example of a completed refund transaction record [Table 5] 17. The first client sends the completed refund transaction record to the second client, possibly via a facilitator. The facilitator optionally verifies aspects of the completed refund transaction record (e.g., that it is signed by both parties, that the completed refund transaction record has not been modified in any other way, that it conforms to the conditions of the completed commit transaction record, etc.). If the verification fails, the facilitator can reject the record of the completed refund transaction or optionally send an error message to the first client. The facilitator optionally sends the completed refund transaction record to the second client. 18. The second client optionally verifies that the completed refund transaction record is as expected and signed by the first and second parties. 19. After creating or receiving both the completed commit transaction and the completed refund transaction, the first client sends a first source transaction record to a transport mechanism for executing the source transaction. 20. After creating or receiving both the completed commit transaction and the completed refund transaction, the second client submits the second source transaction record to a transport mechanism to execute the second source transaction. 21. After confirming that both the first source transaction and the second source transaction have been submitted to the transfer mechanism, one or both of the first client and the second client submit a completed commit transaction record to execute the commit transaction. 22. At or after the expiration timestamp, or at a point defined by the conditions and prior to the lock time of the completed refund transaction record, the facilitator optionally consults one or more data sources (e.g., the current price of a publicly traded financial instrument, the price of the instrument at the time the offer is accepted, etc.) to calculate the conditions for determining the first payment amount and the second payment amount. In one embodiment, the data sources include external data feeds, internal databases, other data sources, etc. In an exemplary embodiment, given a time t, the data source provides a reference asset, a quote product, a nominal asset b as the reference asset, and a t , asset q t or estimate the base meter (e.g., where the base meter or estimating meter is a notional asset). Continuing with the example above, the base commodity is USD, the quote is AUD, and the asset is Bitcoin. b0 is the USD value of Bitcoin at the time the transaction begins, and b f is the USD value of Bitcoin at the time the trade is completed, q0 is the Australian dollar value of Bitcoin at the time the trade is initiated, and q f is the Australian dollar value of Bitcoin at the time the trade is completed. The calculation used by the facilitator to calculate the first payment amount and the second payment amount is res base (b0,q0,b f , q fIn a typical embodiment, a party's losses are proportional to the other party's gains, which implies:

number

[0052] The above is merely one embodiment of value transfer according to the present invention; in other embodiments, equivalent or alternative procedures may be utilized. The following describes an embodiment that includes non-typical, but illustrative, mechanisms. 1. A first client sends an offer to a second client. 2. The first client sends an offer to the facilitator. 3. The facilitator sends the incomplete commit transaction record to the first client for creating a completed commit transaction record. The incomplete commit transaction record includes: (a) a first principal input to receive a first principal amount from a first source transaction; (b) a first input, including a first committed amount, subject to the terms and conditions requiring approval by two of the following three parties: (i) the first party, (ii) the second party, and (iii) the facilitator; Includes: 4. The facilitator sends a second incomplete commit transaction record to the second client for creating a completed commit transaction record, and the second incomplete commit transaction record is (a) a second principal input to receive a second principal amount from a second source transaction; and (b) includes a first input containing a second committed amount subject to conditions requiring approval by two of the following three parties: (i) the first party, (ii) the second party, and (iii) the facilitator; 5. The primary client signs the primary source transaction record. 6. The first client signs the pending commit transaction record (e.g., with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY). First example of an incomplete commit transaction record [Table 7] 7. The first client sends the first incomplete commit transaction record to the facilitator. 8. The second client signs the second source transaction record. 9. The second client completes and signs the second outstanding commit transaction record (e.g., with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY). Second example of an incomplete commit transaction record: [Table 8] 10. The second client sends a second incomplete commit transaction record to the facilitator. 11. The facilitator creates a completed commit transaction record from the first incomplete transaction record and the second incomplete commit transaction record, and the completed commit transaction record is: (a) a first principal input to receive a first principal amount from a first source transaction; and (b) a Committed Output that includes the First Committed Amount and the First Committed Amount subject to terms that require approval by two of (i) the First Party, (ii) the Second Party, and (iii) the Facilitator; (c) a second principal input to receive a second principal amount from a second source transaction; and (d) a second committed amount and a second committed output with terms that require approval by two of (i) the first party, (ii) the second party, and (iii) the facilitator; It consists of: Completed commit transaction record example [Table 9] In another embodiment, before the facilitator sends the first uncompleted commit transaction record and the second uncompleted commit transaction record, the first client provides the facilitator with the transaction ID of the first source transaction record, and the second client provides the facilitator with the transaction ID of the second source transaction record. The facilitator creates a first uncompleted commit transaction record identical to the second uncompleted commit transaction record, each including a first principal input with a placeholder signature and a second principal input with a placeholder signature. As each uncompleted commit transaction record is sent to the respective client, the client signs each principal input (e.g., with SIGHASH_ALL | SIGHASH_ANYONECANPAY) before sending each signed uncompleted commit transaction record back to the facilitator. The facilitator collects the signed uncompleted commit transaction records and merges the signed inputs into a completed commit transaction record. In such an embodiment, the first commit output and the second commit output may be merged, and the corresponding payment transaction record and refund transaction record may omit their respective second inputs. 12. The facilitator sends the completed commit transaction record to the first client, which optionally stores it in persistent memory. 13. The facilitator sends the completed commit transaction record to the second client, which optionally stores it in persistent memory. 14. The first client signs the pending refund transaction record (e.g., with SIGHASH_ALL | SIGHASH_ANYONECANPAY or SIGHASH_SINGLE | SIGHASH_ANYONECANPAY) including: (a) the lock time after the expiration timestamp, (b) a first input for receiving a committed amount from a first committed transaction; (c) a second input for receiving the committed amount from the second committed transaction; (d) a first refund output including a first refund amount and a first condition requiring the approval of the first party; (e) a second refund output containing the second refund amount and any conditions requiring approval by the second party; Example of an incomplete refund transaction record [Table 10] 15. The first client sends the pending refund transaction record and the completed refund transaction record to the second client. 16. The second client creates a completed refund transaction record from the pending refund transaction record (for example, signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY or SIGHASH_SINGLE | SIGHASH_ANYONECANPAY) and stores it in persistent memory. Example of a completed refund transaction record [Table 11] 17. The second client sends a completed refund transaction record to the first client. 18. After creating or receiving both the completed commit transaction record and the completed refund transaction record, the first client submits the first source transaction record to a transport mechanism. 19. After creating or receiving both the completed commit transaction record and the completed refund transaction record, the second client submits the second source transaction record to the transport mechanism. 20. After verifying that both the first source transaction record and the second source transaction record have been submitted, one or both of the first client and the second client submit a completed commit transaction record. 21. At or after the expiration time of the timestamp, or at a predetermined time determined by the conditions, and before the lock time of the completed refund transaction record, the facilitator performs calculations in accordance with the conditions to determine the first and second payment amounts, and optionally requests information from one or more data sources for use in the calculations. 22. The facilitator signs the pending payment transaction record (e.g., with SIGHASH_ALL | SIGHASH_ANYONECANPAY or SIGHASH_SINGLE | SIGHASH_ANYONECANPAY). Example of an incomplete payment transaction record: [Table 12] 23. The facilitator sends the pending payment transaction record to both the first client and the second client, either of which can submit it as in the previous exemplary embodiment.

[0053] For the sake of brevity, various verification steps have been omitted.

[0054] It will be apparent to those skilled in the art that aspects of each of the above embodiments may be mixed. For example, a first client may submit an offer to a facilitator, and a second client may locate and entice the facilitator. As noted above, because the facilitator is required to act on behalf of one or both parties, aspects of one or both of the first and second clients may coincide with the facilitator, allowing the facilitator to omit most of the steps considered redundant. The facilitator may include aspects of one client but not the other. In such cases, the client may optionally independently verify the transaction record received from the facilitator before signing. In such embodiments, the facilitator typically includes a way to control aspects of the clients via an interface, such as a web-based user interface (UI), application programmer interface (API), or the like.

[0055] In such an embodiment, parties delegating authority to the facilitator must trust that the facilitator will act securely and fairly, similar to the expectations many parties already have of traditional third-party intermediaries. Because the first party has independent access to the same key pair for the facilitator to act on its behalf, and similarly the second party has independent access to the same key pair for the facilitator to act on its behalf, if the facilitator is revoked, in the worst case scenario, the first and second parties can recover their assets by submitting the completed refund transaction record after the lock time, provided that they have stored a copy of the completed refund transaction record in persistent memory.

[0056] In one embodiment, when a client detects a new consumable output (e.g., by monitoring changes or updates to the blockchain when using Bitcoin or a protocol with a similar transfer mechanism), it automatically accepts remote offers equivalent to the new consumable output. In another embodiment, when a client detects a second usable output, it attempts to invalidate it. If successful, it issues a new offer that includes some or all of the new consumable output. Other variations are possible. For example, a client could scan available offers and configure them to match consumable outputs. Algorithms are known in the art and vary in complexity. For example, client implementations of the Bitcoin protocol provide simple algorithms for matching transaction inputs with consumable outputs. Such algorithms can be adapted by those of ordinary skill in the art or by implementing similar inventions.

[0057] In embodiments, these terms optionally include the ratio in which the first security and the second security are designated as assets, and the amount each participant must allocate. For example, in one embodiment, these terms may provide for a "sale" of 2 Bitcoins / USD with a required allocation of 3 Bitcoins from each party, in other words, providing exposure to 2 Bitcoins in USD, and requiring participants to allocate 2 Bitcoins as principal and 1 Bitcoin as collateral for the term of the swap (i.e., until expiration or until one party's principal and collateral are exhausted).

[0058] The allocations of each party do not need to be equal. In some embodiments, if the market expects a particular commodity pair to decline over the duration of the swap, the party accepting exposure to that commodity pair may be required to allocate more collateral than the other party. In the above example, the risks between the parties are asymmetric. The most the offeror can lose is 2 Bitcoin (if Bitcoin becomes worthless in US dollars). However, the recipient can lose unlimited amounts (if US dollars become worthless relative to Bitcoin), and therefore:

number

[0059] Alternatives are:

number

[0060] Other embodiments may employ a symmetric model.

number

[0061] where res base (…) is the initial value of the base security at time b0, the initial value of the quote security q0, and the value of the base security at time f b f , the estimated security value at time f q f The resulting profit or loss of the party taking exposure to the base security is the reverse of the resulting profit or loss of the party taking exposure to the quote security.

number

[0062] In this example, the parties' risk equations are symmetric. If the base security goes to zero, the party with the base security exposure loses only principal. Similarly, if the quote security goes to zero, the party with the quote security exposure loses only principal. Note that no collateral is required. Alternatives include:

number

[0063] In this example, the parties' risk calculations are also symmetric. However, if the underlying assets go to zero, the losses of the party taking the underlying assets approach infinity, all else being equal. Similarly, if the quote assets go to zero, the losses incurred by the party taking the quote assets also approach infinity, all else being equal. Note that collateral is required if losses exceed the principal amount. More volatile product pairs may require more collateral to minimize the risk of premature termination. These are basic examples. The conditions affecting the calculations for determining allocation payments can be arbitrarily complex and are limited only by the imagination of the participants. All such variations are contemplated by this invention.

[0064] In some situations, one party may wish to terminate a value transfer (e.g., a swap) before it expires. Both parties may agree to terminate prematurely. In one embodiment, the facilitator facilitates this by creating an incomplete payment transaction record as if the swap had expired when the parties agree to terminate. The party requesting termination signs and sends the incomplete payment transaction record to the agreeing party, who submits it to the transfer mechanism. If the facilitator includes a fee output to a third party, the agreeing party may request that the fee be paid in full or in full by the requesting party.

[0065] If one party wishes to terminate the transfer of value before the deadline but is unable to get the other party to agree, another option is for the terminating party to seek a third-party proxy. Figures 6 and 7 show various examples of swap embodiments that include such a proxy.

[0066] Figure 6 shows the case where the withdrawing party (A) convinces the entrant (C) to transfer value to the remaining party (B) on A's behalf. In addition, the entrant pays the withdrawing party a negotiated amount (ε), which in this embodiment is facilitated by a proxy transaction, a second commit transaction, and a second refund transaction.

[0067] For clarity, the output of a commit transaction and the input of a corresponding proxy transaction are the first principal (P A ) First Collateral (C A ) Second Principal (P B ) Secondary Security (C B ) are shown separately. This is not a limitation of the present invention. As with the previous embodiment, the output of a commit transaction and the input of its corresponding proxy transaction may have any structure deemed valid by the forwarding mechanism. The output of a proxy transaction and the input of a second commit transaction are depicted similarly for clarity. Also, all structures of inputs and outputs between transactions are contemplated by the present invention.

[0068] The delta (δ) is the difference between the first and second payments calculated assuming the trade expired at the time of proxying. As in the embodiment shown in Figure 6, this favors the remaining party. The proxy transaction record is structured so that the withdrawing party absorbs the loss of the difference and the entering party provides assets to fill the vacant position.

[0069] Also, in the embodiment shown in Figure 6, the proxy payout is asymmetric. The entering party is refunded the trade that party committed to (minus the amount negotiated), and the remaining party is refunded the amount they would have received had the swap expired at the time of proxying. Other variations are possible. For example, in one embodiment, the negotiated amount could be transferred in parts to other stages of the value transfer or to other value transfers entirely.

[0070] In the embodiment shown in Figure 7, the proxy favors the withdrawing party. In that embodiment, proxy refunds are symmetrical: the remaining party receives the amount that the original transaction is refunded.

[0071] In one embodiment, delegation is facilitated as follows. 1. The Facilitator performs calculations in accordance with the terms to determine the Withdrawal Amount, and optionally requests information from one or more data sources for that calculation. 2. The facilitator: (a) a first input to receive the amount from the commit transaction; (b) an entry input to receive the entry amount from the source transaction; (c) a withdrawal output, including the withdrawal amount and any conditions requiring the First Party's approval; (d) a proxy output containing a proxy amount and a second condition requiring approval from two of (i) the second party, (ii) the third party, or (iii) the facilitator; Create an incomplete proxy transaction record including: Example of an incomplete proxy transaction record: [Table 13] 3. The facilitator sends the incomplete proxy transaction record to the first and third parties. 4. The first party creates a signed incomplete proxy transaction record by signing the first incomplete proxy transaction record (e.g., signing with SIGHASH_ALL | SIGHASH_ANYONECANPAY) and sends the first incomplete proxy transaction record to the facilitator. 5. The third party creates a second uncompleted proxy transaction record by signing the uncompleted proxy transaction record (e.g., by signing with SIGHASH_ALL | SIGHASH_ANYONECANPAY) and sends the second signed proxy transaction record to the facilitator. 6. The facilitator creates a completed proxy transaction record (e.g., ID:9c8b...4794) using the first and second incomplete proxy transaction records. 7. The facilitator: (a) the lock time after the expiration timestamp, (b) an input to receive the agent amount from the agent transaction; (c) a first refund output containing the first refund amount and the terms and conditions requiring the second party's approval; and (d) a second refund output containing the second refund amount and the terms and conditions requiring the third party's approval; Sign the pending proxy withdrawal transaction record, including: Example of an incomplete proxy withdrawal transaction record: [Table 14] 8. The facilitator signs the outstanding proxy refund transaction record to create a signed proxy refund transaction record, and sends the signed proxy refund transaction record to the second party and the third party. 9. The Facilitator submits the complete Substitute Refund Transaction Record to the Transfer Mechanism.

[0072] Details of the various verifications and procedures involved in the foregoing embodiments have been omitted for brevity. In other embodiments, various transaction records are created or signed by the first party or second party rather than the facilitator. For example, the first party or second party may agree to the amount of the proxy transaction record and sign it without the need for a facilitator. All such variations are contemplated.

[0073] Letters of credit (L / C) are well known in the art; they are essentially an agreement whereby a third party transfers value on behalf of a first party to a second party on or before a predetermined time if pre-agreed conditions are met. This typically involves a costly intermediary financial institution manually reviewing shipping documents before releasing funds to the buyer. However, this expensive approach can be avoided by an embodiment of the present invention in which a facilitator conditions the origination or creation of a payment transaction based on the results of queries such as a known tracking number or other embodiment, such as a shipper's public API, an L / C evaluation inquiry, observing the presence or absence of data at expected locations, checking whether the values ​​of variables or responses from an API are within a set of expected values ​​or match expected patterns, or receiving a signal from a digital device (e.g., temperature sensor, GPS) and verifying that the signal value is within an expected range or tolerance. For example, U.S. Patent Application No. 13 / 970,755 ('755) describes a system and method for efficiently calculating geospatial proximity. Others are known in the art. In one embodiment, the calculation includes the state that an object was "at" or "near" (i.e., within a particular distance) of a particular location (e.g., a self-reporting GPS in the vicinity of a reporting detector or sensor at a known location, an automatic identification and data capture (AIDC) device such as a barcode, quick response (QR) code, radio frequency identification (RFID) tag, etc.). Many possible configurations are contemplated by the present invention and will be apparent to those skilled in the art.

[0074] FIG. 8 illustrates aspects of one embodiment relating to a letter of credit (L / C) with a source transaction and a commit transaction. As illustrated, the commit transaction includes a first input for accepting a first amount from a first source transaction (e.g., a first party) or an output (not shown) for injecting the first amount into one or more transactions. In other embodiments (shown in other figures), the commit transaction includes a second input for accepting a second amount from a second source transaction, where the sum of the first amount and the second amount includes, in some cases, a principal amount (P) and (optionally) a collateral amount (C), as shown in the various figures. Although only the first source transaction is shown in FIG. 8, this should not be construed as a limitation of the present invention.

[0075] Figure 9 shows aspects of one embodiment relating to a commit transaction, an expiry transaction, which is synonymous with the refund transaction shown in the previous embodiment, and a letter of credit. However, refund transactions are exclusively meant for the recovery of funds in the event of an exception (e.g., the facilitator is no longer able to create or sign the payment record), while the use of expiry transactions in addition to funds recovery is envisaged by offers (e.g., the facilitator participated but the conditions set are not met within the expiry timestamp). The difference is largely conceptual; within the scope of this invention, the two are largely functionally the same. A commit transaction is a first principal (P A ) and a first input for receiving a commit output. The expiration transaction includes an input for receiving the amount of the commit output, which is a first output to a first party, and in other embodiments includes a second input for receiving a second amount, and a second output for a second party.

[0076] Figures 10-11 illustrate aspects of an embodiment involving a relatively simple payment transaction involving a letter of credit in a situation involving principal and collateral. Figure 10 illustrates the process of transferring principal and collateral ((P+C)) from a first party. A ) inputs. In other embodiments, the inputs need not be combined, just as in the above. The commit transaction of FIG. 11 includes an initial added principal and collateral input from a first party, and a second collateral (C B) input. These are just two of many possible configurations contemplated by the present invention. For example, a commit transaction could be comprised of collateral input from a third party (e.g., a guarantee from the first party, not shown), which could include a primary input from the first party, and a collateral input from a second party, etc.

[0077] In the embodiment shown in Figures 10-11, the payment transaction includes an input for receiving the amount of each commit output. In Figure 10, the payment transaction includes a first collateral payment output to the first party, a first principal output to the second party, and an optional fee output to be deducted from the collateral. In Figure 11, the payment transaction includes a collateral payment output to the first party, and a participation principal and collateral loan origination output to the second party. Additionally, the commit transaction includes an option fee output to a third party that is borne equally by the parties in the payment transaction. These are only two examples of many possible configurations of the present invention. For example, the optional fee output can be allocated at any stage, and at any number of stages, or borne disproportionately by one of the parties.

[0078] To illustrate by way of example how the various components described above can be used to facilitate a letter of credit agreement, the following steps occur in one embodiment using Bitcoin or a similar protocol as the transfer mechanism. In this embodiment, the parties do not trust each other, and the facilitator is not fully trusted by either party: 1. The first client is (a) payment terms that include one or more references to data sources; payment features that include one or more references to data sources; and payment terms that include one or more references to data sources; (b) the principal amount; (c) expiration timestamp; (d) any first security amount; (e) any secondary security amount; Create an offer with terms that include: Example conditions: [Table 15] 2. The first client signs the first source transaction record. 3. (a) a first input for receiving a first amount from a first source transaction; (b) optionally a second input for receiving a second amount from a second source transaction; (c) a committed output, including a committed amount and any conditions requiring approval by two of the following parties: (i) the first party; (ii) the second party; or (iii) the third party; Create a first pending commit transaction record containing: 4. The first client optionally sends an offer to the facilitator, which validates the offer (e.g., that the expiration timestamp is within an acceptable range, that the conditions can be interpreted, etc.). If validation fails, the facilitator can optionally reject the offer and optionally send an error message to the client. 5. The first client sends an offer to the second client. 6. The second client creates a source transaction record. The second client sends the pending commit transaction record to the first client. 7. The first client creates a completed commit transaction record by signing the incomplete commit transaction record (e.g., with SIGHASH_ALL | SIGHASH_ANYONECANPAY) and optionally stores the complete commit transaction record in persistent memory. Example of a complete commit transaction record: [Table 16] 8. The first client signs an outstanding expiration transaction record that includes: (a) the lock time after the expiration timestamp, (b) an input to receive the committed amount from the committed transaction; (c) a first expiration output comprising a first expiration amount and a condition requiring approval by the first party; (d) optionally, a second expiration output comprising a second expiration amount and a condition requiring approval by the second party; Example of a completed expiration transaction record: [Table 17] 9. The first client sends the completed commit transaction and the pending expiration transaction record to the second client, which optionally stores it in persistent memory. 10. The second client creates a completed expiration transaction record by signing the incomplete expiration transaction record and optionally stores the completed expiration transaction record in persistent memory. 11. The second client sends the completed expiration transaction record to the first client. 12. After creating or receiving the completed expiration transaction record and the completed commit transaction record, the first client submits the first source transaction record to the transport mechanism to execute the first source transaction. 13. After the second client creates or receives the completed expiration transaction record and the completed commit transaction record, it submits the second source transaction record to the transport mechanism to execute the second source transaction. 14. After verifying that both the first source transaction record and the second source transaction record have been submitted, one or both of the first and second clients send the complete commit transaction record to the transport mechanism to execute the commit transaction. 15. At the time defined by the conditions or at the time of enquiry from the first and second clients (optionally including the full committed transaction record, a reference to the committed transaction, and the conditions) (providing one or more of the following) allows the facilitator to perform calculations of the first payment amount and optionally the second payment amount prior to the full lock time of the expiration transaction record, and optionally request information from a data source for use in the calculations (e.g., whether the scheduled shipment has been sent to the shipper). This could be an external API, an internal database query, etc. In a typical embodiment, the payment amount is such that any remaining collateral is returned to the respective provider and the principal is transferred from the provider (payer) to the counterparty (payee). 16. The facilitator: (a) an input to receive the committed amount from the committed transaction; (b) a first payment output including a first payment amount and a first condition requiring approval by a second party; (c) a second payment amount output including the second payment amount and a condition requiring approval by the first party; (d) a third payment output that includes a condition requiring third-party approval; and typically signs an incomplete transaction or transaction record that includes the first payment amount, the second payment amount, and any fee amount, the sum of which does not exceed the committed amount. Example of an incomplete payment transaction record: [Table 18] 17. As in the previous embodiment, the facilitator sends the pending payment transaction record to both the first client and the second client, who can sign the transfer mechanism and submit either.

[0079] In another embodiment, the state of the commit output requires approval from either the first party and the second party, or the second party and one or more service providers (e.g., a shipper, insurance company, prosecutor, etc.). The pending payment transaction record consists of a placeholder for the second party and the service provider. Once all service providers have signed, the second party can sign and submit the payment transaction record to the transport mechanism. In yet another embodiment, if the second party commits assets to the commit transaction to pay the service provider, the service provider is paid from the payment transaction.

[0080] Figures 12 through 14 illustrate various example letter of credit embodiments involving party substitution. Figure 12 illustrates an embodiment in which the payer (A) convinces the assignor (C) to substitute into a transaction with the payee (B). The payer also transfers a negotiated amount (ε) to the assignor. For example, if the payer has committed to purchasing goods from the payee, but unexpected market conditions mean that the payer decides to sell the right to receive the goods to the assignor, anticipating a loss. This is facilitated in the illustrated embodiment by a proxy transaction and a second expiration transaction. In a related embodiment, the payer sells the right to receive a share of the profits, and the negotiated amount may be passed from the assignor to the payer. In the embodiment shown in Figure 12, an optional fee (φ) is paid to a third party and is borne by the payee.

[0081] FIG. 13 illustrates an embodiment in which a recipient (B) convinces an assignor (C) to enter into a transaction with a payer (A). The assignor then transfers a negotiated amount (ε) to the payer. For example, a third party may be interested in receiving a payment in a future payment transaction, perhaps relative to the decreasing value of the assignor's other assets. This is facilitated by an agency transaction in the illustrated embodiment, and in a related embodiment in which the recipient sells the right to receive the payment, the negotiated amount may be paid to the assignor. As in FIG. 12, in FIG. 13 an optional fee (φ) is paid to the third party, which is borne by the assignor.

[0082] FIG. 14 illustrates an embodiment in which a payer (A) has an assignor (C) partially assign a transaction with a payee (B) (as shown, initially covering the collateral paid by the payer). Additionally, the assignor transfers the negotiated amount (ε) to the payer. This is facilitated in the illustrated embodiment by a proxy transaction and a second expiration transaction, and in some embodiments, the proxy output of the proxy transaction includes a condition requiring approval by three of three parties, three of four parties, two of four parties, etc. (e.g., if the assignor is delegated powers of attorney and authorized to approve or sign on behalf of the payer). Many possible configurations are contemplated by the present invention. In such embodiments, a facilitator can act as an umpire in crafting a proxy transaction that satisfies all parties, including maintaining the ability to dispute the transaction with a selected intermediary, as described below.

[0083] For clarity, Figures 12 to 14 show that the output of a commit transaction and the input of its corresponding proxy transaction are the principal and collateral ((P+C)) A ) and the second security (C B ) separately. This is not a limitation of the present invention. The output of the commit transaction and the input of the corresponding proxy transaction may be in any configuration deemed valid by the forwarding mechanism. The output of the proxy transaction and the input to the second commit transaction are shown for illustrative purposes. All valid configurations of inputs and outputs are contemplated by the present invention. In yet another embodiment, any fee may be paid in part or in whole by any party (including a fourth party).

[0084] In a decentralized digital currency used as a transfer mechanism (e.g., Bitcoin protocol, Ethereum protocol, etc.), another embodiment of the present invention allows for the submission of a special transaction record for any swap, letter of credit, or other offer whose terms are expressed or understood by the facilitator, as long as those terms, or a reference to those terms (e.g., a URL or a hash of the terms), or combinations thereof, are encoded in the transaction record itself, rather than in a central authority or shared decentralized data store (e.g., torrent or altcoin), outside the transaction mechanism (referred to as "off-blockchain" in decentralized digital currency).

[0085] In one embodiment, this includes transaction record metadata and inputs or outputs (e.g., <data>ON_DROP <script>、OP_RETURN <data>テクニックを介した単一出力など)の未使用データとして符号化することができる。説明のために、以下のステップではそのような多様な実施形態のうちの数例を記載する:1.一実施形態では、第一のクライアント(提供者)は、関連データを含むオファー取引記録と、任意選択で第一当事者およびファシリテータのうちの一人の承認を必要とするオファー額および条件を含むオファー出力を作成する。関連データは、条件の一つまたは両方と条件に対する参照を含む。任意選択で関連データは、ファシリテータへの参照(例えば、ドメイン名、支払いアドレス、D&B番号、URIなど)を含む。任意選択で第一のクライアントは転送メカニズムにそれを提出する前に、条件、関連データ、オファー取引記録を検証のために(例えば、ファシリテータが用語を解釈することができ、ファシリテータが適切に特定されていることを確実にするために)ファシリテータに送信する。別の実施形態では、第一のクライアントの要求で、ファシリテータは完了オファー取引記録を作成するための第一の未完了オファー取引記録(署名された入力を含まないなど)を作成し、第一のクライアントは任意選択でファシリテータ提供のリファレンス(該当する場合)などで利用可能かどうか、ファシリテータは正確に未完了オファー取引記録を作成したかなどを検証する。未完了オファー取引記録の例:

表19

表20

表21

[0086] 別の実施形態では、オファーは「ハードオファー」を含み、オファー出力の条件は第一当事者およびファシリテータの両方の承認を必要とし、ファシリテータはある時点に設定されたロックタイムと、前記オファー額を受け取る入力と、第一当事者の承認を必要とする有効期限および条件を含む有効期限出力を含むオファー有効期限取引記録に署名し第一当事者に送信する。

[0087] 本発明の他の実施形態では、取引当事者は第三者が紛争の調停役として行動することに同意する。たとえば、ファシリテータが利用できなくなった場合、払い戻しを呼び出すことを選択するのではなく、一方の当事者が 利用できないファシリテータの代わり仲裁人が間に立つ紛争を引き起こす。 コミット取引のコミット出力の条件は、第一当事者、第二当事者、ファシリテータ、およびメディエータのうちの二人の承認を必要とする。有効期限タイムスタンプ時または条件によって定義された時点であり完了払い戻し取引記録のロックタイムの前に、紛争当事者と仲介者はそれぞれ署名し、一方の当事者は第一の当事者、第二の当事者、およびメディエータのうちの二人の承認を必要とする条件及び紛争出力を含む紛争取引記録を提出する。紛争が解決されると、当事者の署名、または仲介者と当事者の一方が、上記の支払い取引記録と同様の決済取引記録に署名するが、それは仲介された和解を反映する。

[0088] 図15から図16は、そのような二つの実施形態の態様を示す。図15の紛争取引はファシリテータの手数料の金額(φX)を含む第一手数料出力とメディエータ手数料の金額(φΜ)を含む第二手数料、当事者間で共有される手数料出力、紛争を開始した当事者(B)が払うメディエータ手数料を含む和解取引から構成される。図16に示すように、紛争取引は当事者間で共有されるファシリテータ料金を含み、和解取引は紛争を開始した当事者(B)によって支払われるメディエータ料金を含む。別の実施形態では、任意のメディエータ料金が和解条件として決定され決済取引に含まれる。

[0089] 任意選択で(そして好ましくは)当事者は、上記と同様の紛争払い戻し取引記録を署名し、送信し、代わりに紛争取引からの入力を取って、和解に至るための十分なロックタイムを設定する。このようにすればメディエータが利用できなくなった場合、当事者は紛争払い戻し取引記録を再度提出することができる。別の実施形態では、紛争処理は「仲介可能」であり、例えば仲介人が利用できなくなった場合に第二の仲介人を命名するなどの紛争の連鎖を可能にすることができ、払い戻し取引記録のロックタイムが近づいている場合仲裁人がロックタイムを延長するなどできる。

[0090] 他の実施形態では、調停を自動化することができる。 例えば、スワップまたは同様の取引に関連する実施形態では、署名されていない支払い取引記録が作成された時点で取引が停止されたかのように、ファシリテータは署名されていない支払い取引記録を定期的に取引者に送信する。署名されていない支払い取引は、それが作成された検証可能な時間、またはそのような時間への参照を含む(例えば、転送メカニズムがビットコインまたは同様のプロトコルであり、スクリプトの一つに埋め込まれた未使用の署名データファシリテータが所有する別個の鍵であり、入力の署名には使用されないなど)。 当事者に送信したり、署名された支払い取引記録を提出したり、有効期限を過ぎても利用できなくなったりする前にファシリテータが利用できなくなると、紛争が開始され、当事者間で条件及びファシリテータからメディエータに受け取った署名されていない支払い取引記録の一部またはすべてを交換する期間がある。(各当事者によって署名されることが好ましいが、当事者が同意する場合、すなわち同じ条件をメディエータに送信する場合は不要である)。メディエータは、両当事者から受領した署名のないまたは署名された条件、および確認可能なすべての署名されていない支払い取引記録を調べる。他の一実施形態では、メディエータは、最新の検証可能な署名されていない支払い取引記録を選択するだけである。別の実施形態では、仲介者は、署名されていない支払い取引記録を順番に「再生」し、署名されていない支払い記録が取引の初期終了を引き起こしたはずであるかどうかを検証する(例えば、一方の当事者の元本および担保が枯渇した場合)。さらに別の実施形態では、メディエータは、一つまたは複数のデータソースからの情報を要求し、独立した条件の評価をファシリテータの代わりに実行する。これは、支払い取引記録にできるだけ近い新しい若い取引が作れるようメディエータが決定できるように、ファシリテータによって作成される。

[0091] 図示の実施形態は、本発明のより基本的なものであることに留意されたい。ソース取引、コミット取引、支払い取引、払い戻し取引、有効期限取引、入力、出力、および、元本、担保または料金のさまざまな組み合わせは、参加間の契約によってのみ制限され、本発明により有効になる 。 さらに、本出願を通して開示される実施形態の特定のステップは、特定のエンティティによって実行されるものとして説明される。 他の実施形態では、本明細書に記載されたものの代わりに、またはそれに加えて、同様または同等のステップを、全部または部分的に、異なる当事者によって実施することができる。そのような実施形態の全ては、本発明の範囲内にあると考えられる。

[0092] 非常に簡単な例として、分散型デジタル通貨を使用する実施形態では、取引はマルチシグナリング取引の代わりにP2SHを使用している。特定の実施形態では、他のステップを省略することができる。例えば、分散型デジタル通貨を使用する実施形態では、署名された完了払い戻しまたは失効取引記録の作成は、ファシリテータまたは相手側が消滅するか非協力的になる場合の損失を避けるための対処法として強く推奨されるが、それは厳密に必要ではない。メディエータを含む本発明の実施形態では署名されていない紛争処理記録は、ファシリテータによって作成され、例えば払い戻し取引または有効期限取引記録が作成されて送信されるときにメディエータと共に使用するために当事者に送信される。

[0093] 図17から図22は、ブロックチェーンを含む分散型デジタル通貨を含む転送メカニズムを使用して、一実施形態内のスワップの形で値転送を行う主要な段階を示す図である。図17、18は第一段階を示し、クライアントは、ファシリテータとの第一の注文(基本証券、見積もり証券、元本、担保、支払い機能、有効期限タイムスタンプ等)を含む第一の注文を確認する。 クライアントは、第一の元本取引を作成するために、その条件に適合する第一の元本取引記録を転送メカニズムに提出(ブロードキャスト)する。ファシリテータは、更新のブロックチェーンを監視し、第一の元本取引が確認されたときに第一の注文を活性化する。図19は、ファシリテータが第一注文を第二注文と照合し、コミット取引記録を作成して転送メカニズムに提出(ブロードキャスト)してコミットを生成することによって第一元本取引および第二元本取引からの出力をコミットする第二段階を示す。任意選択で、ファシリテータは、コミット取引からの出力を費やし、有効期限のタイムスタンプの後まで使用することができない払い戻しまたは「ロールバック」取引記録を作成して各クライアントに提供する。 ファシリテータが壊滅的に失敗した場合、どちらのクライアントも署名して払い戻し取引記録を提出して、両方のクライアントを元のそれぞれの立場に戻すこともできる。図20は、第三段階を示しており、ファシリテータは、データソースから1つ以上の値を受け取り、その値、元本、および担保に支払い機能を適用して評価を監視して、一方の当事者の元本、および担保は枯渇しているかを調べる。任意選択で、各クライアントは、ファシリテータから状況の更新を受け取り、ファシリテータのステータス更新をデータソースから1つ以上の値を独立して受信する。また、図21-22は、有効期限タイムスタンプの後に(またはいずれかの当事者の元本および担保が枯渇した場合、いずれか早い時点で)、ファシリテータはコミット取引の出力を費やす1つまたは複数の支払い額を含む、一つ以上の支払い出力を備えた未完了支払い取引記録を作成する。いずれかのクライアントが完了支払い取引記録を受信し、それを完了(サイン)して、完了支払い取引記録を作成する。 クライアントは、支払い取引を作成するために、転送取引に完了支払い取引記録を提出(ブロードキャスト)し、クライアントの両方の資金を同時に解放する。

[0094] 図23は、クライアント(120)またはファシリテータ(100)を含む典型的な実施形態の構成要素を示す。これは、メモリ(170)およびネットワークインターフェース(190)に結合されたコンピュータプロセッサ(160)を備える。コンピュータプロセッサ(160)は、図示のような単一の処理ユニットに限定されず、当技術分野で知られているように、複数のコア、複数のコンピュータプロセッサ、ネットワーク化されたコンピューティングデバイスのクラスタ、メモリ(170)などを持つ。メモリもハードディスクに限定されるものではなく、ファイルのデータが別個の論理セクタ(180)に格納されることを可能にする固定メモリ技術を持ち(例えば、一つ以上の論理ファイルを含むことができるシステム内の一つ以上の論理記録、ファイルまたはデータベース内の一つ以上の論理記録など)、およびコンピュータプロセッサへの電力供給が中断された場合にデータが持続することができる。ソリッドステートストレージ、フラッシュドライブ、RAID、JBOD、NA8、AmazonのS3のようなリモートストレージサービスやGoogleのクラウドストレージ、メモリのクラスタデバイスなどは当技術分野で知られているような組み合わせの例だが、それのみにとどまらない。クライアント(120)の場合、メモリ(170)は、非対称キーペア(200)を保管するための1つまたは複数のキーペアセクタを含む一つ以上の論理セクタを備える。 ファシリテータ(100)の場合には、メモリ(170)は、一つ以上の鍵ペアのセクタ(200)ならびに1つまたは複数の取引記録を格納するための一つ以上の取引記録のセクタを含む一つ以上の論理セクタを含む。ネットワークインターフェース(190)は、図示のように単一のネットワークインターフェースに限定されない。ネットワークインターフェースには、当技術分野で知られているロードバランサ、2つ以上の多重化ネットワークインターフェースなどがあるがそれだけには限定されず、またはそれらの組み合わせを任意に含む複数のネットワークインターフェースを備えることができる。

[0095] 図24(先行技術)は、分散型デジタル通貨での所有権の単純化された繋がりを示しているが、実際には、取引は複数の入力および複数の出力を有することができる。

産業上の利用可能性

[0096] 本発明は、所有権の移転を考慮する別個の当事者間の合意、ならびにこの発明が価値、重要性をもちうるあらゆる産業に関連する。

[0097] 用語の説明これらは便宜上提供される用語の簡単な説明である。定義を限定することを意図するものではなく、当技術分野で理解されているか、または本明細書の他の箇所に記載されている任意の特徴、特性、挙動、実施形態を補足するものである。

[0098] 「クライアント」(120):コンピュータプロセッサ(160)と、ペアキーのセクタ(200)を有するメモリ(170)を含む非対称キーペアを保管するための装置であり、ネットワークインターフェース(190)、およびその本発明による転送メカニズム(110)を介した価値転送を容易にするための、他のクライアント(120,170)かファシリテータ(100)の少なくとも1つと相互作用するように構成されている。

[0099] 仮想通貨は、「分散型デジタル通貨」を参照。

[0100] 「分散型デジタル通貨」(150):取引の分配元帳を含む転送メカニズム(110)(ビットコインプロトコルおよび子孫など。「ブロックチェーン」と呼ばれることが多い)典型的には一人以上のマイナーを含む一つ以上のネットワークネットワーク参加者を含む。「仮想通貨」とも呼ばれる。

[0101] 「ファシリテータ」(100):第一のクライアント(120,160)を利用する第一当事者と、第二のクライアント(120,170)を利用する第二の当事者との間で転送メカニズム(110)を介して価値転送を容易にするための装置(110)であって、本発明によれば、装置はコンピュータプロセッサ(160)と、取引記録セクタと、非対称キーペアを記憶するためのキーペアセクタ(200)と、ネットワークインターフェース(190)を含むメモリ(170)を備える。

[0102] 「証券」:あらゆる種類の価値のある取引可能なもの。現金、事業体に対する所有持分の証拠、または現金その他の金融商品を受領または提供する契約上の権利のいずれかである。「金融商品」とも呼ばれる。国際財務報告基準によれば、「ある企業の金融資産と他の企業の金融負債または持分証券を生じる契約」である。

[0103] 「ロックタイム」:タイムスタンプが経過するまで、取引が転送メカニズムによって有効であると受け入れられないようにする日付と時刻、任意選択でタイムゾーンを含むタイムスタンプ。

[0104] 「当事者」:所有権を行使することができる法人。例えば、個人または法人。

[0105] 「[デバイス]に取引記録を公開する」:デバイスによる読み取りやコピーのために利用可能な取引記録の作成をすることであり、例えば、ネットワークインターフェース(190)を介してデバイスへの取引·記録を送信すること、または必要に応じてデバイスの読み取りまたはコピーできるように取引記録を書き込むこと、任意選択で取引記録を読み取り及びコピーができるが作成、更新、破壊はできないスキームの認証を実装することなど。非限定的な例には、共有ファイルシステム(例えば、NFS、SSHFSなど)、データベースAPI(例えば、SQL、RESTなど)、専用API、第三者共有ストレージ(例えば、Google Docs、Dropbox、等)などがある。

[0106] 「取引記録を[転送メカニズム(110)]に提出する」:有効な取引記録が取引を実行するために転送メカニズム(110)によって受け入れられるプロセスを指す。分散デジタル通貨(150)の文脈では、典型的には、ネットワーク参加者の過半数によって有効と認められている有効なブロックに取引記録を含む一人以上のマイナーによって受け入れられた取引記録を有する一人以上のネットワーク参加者に取引記録をブロードキャストすることを含む。分散型デジタル通貨(150)の文脈では、多数のネットワーク参加者によって有効とされる取引の受け入れは、永久的かつ不可逆的である(例えば、すでに使用済みのアウトプットを費やそうとしたことなどが後で大部分のネットワーク参加者によってため判明したため取引記録が無効となるなど)

[0107] 「取引」:資産の所有権または管理を(時には特定の条件に基づいて)再特徴付けする移転メカニズム(110)における価値転送の単位。分散型デジタル通貨(150)の文脈では、これは時々、ネットワーク参加者の大多数台帳またはブロック鎖に承認された取引記録を意味する「確認済みの取引」と呼ばれる。

[0108] 「取引記録」:取引を記述するデータ構造であり、取引を実行するために転送メカニズムに提出される。非限定的な例として、分散型デジタル通貨の文脈では、取引記録は典型的には、一つ以上の入力(特別な場合にゼロ入力が可能である)一つ以上の出力、および任意選択で暗号署名を含む。分散型デジタル通貨(150)の文脈ではこれは(時に間違って)「取引」とも呼ばれる。あいまいさを避けるため、この仕様では、ネットワーク参加者間で送受信できるデータ構造を参照するために「取引記録」を使用し、取引記録を含むブロックチェーン内の元帳またはブロックの一部を参照する「取引」を使用して、帳簿またはブロックは、ネットワーク参加者の過半数(すなわち、「確認済み取引」)によって有効であると受け入れられる。

[0109] 「転送メカニズム」(110):取引(例えば成功した取引記録の提出など)が作成され強制される手段(例えば分散型デジタル通貨など)

[0110] 「価値転送」:当事者の間で経済的な価値を有する物(金、物品、サービス、実行する義務など)の(所有権、制御などの)権利を転送するプロセスである。< / script> < / data>

Claims

1. at least one or more networked processing devices, a memory for storing an asymmetric key pair, the asymmetric key pair including a private key and a public key; a network interface for receiving a condition, the condition including a principal data and a reference to at least one data source; at least one computer processor coupled to the memory and the network interface, the computer processor comprising: reading at least a portion of the private key from the memory; Computing a cryptographic signature from said at least a portion of said private key; reading first data from the data source; generating an incomplete data record, the incomplete data record comprising: commit input data for receiving commit data from the commit transaction; one or more output data obtained from the principal data; first information relating to the first data from the data source; generating an incomplete data record, including utilizing the network interface to publish the pending data record and the cryptographic signature to a first client device; Computing and associating a cryptographic signature for the first client device; a computer processor configured to: Including, the first client device is configured to verify the first information; the incomplete data record is configured to have a cryptographic signature calculated and associated therewith by the first client device to obtain a complete data record for publication to a transfer mechanism; the transfer mechanism includes at least one or more networked processing devices that implement an accounting unit, the accounting unit being accessible over a computer network by the at least one or more networked processing devices and the first client device, and enabling transaction processing created by broadcasting complete data records for transmission and reception between network participants within the computer network for recording in a ledger; system.

2. The system of claim 1 , wherein the first data comprises a data reference.

3. 2. The system of claim 1, wherein the condition further includes a timestamp, and the computer processor is further configured to calculate the one or more output data or the first information related to a value upon expiration of the timestamp.

4. 2. The system of claim 1, wherein the computer processor is further configured to publish the incomplete data record and the cryptographic signature to a second client device, the incomplete data record being configured to have a cryptographic signature calculated and associated therewith by the first client device or a second client device to obtain a complete data record for publication to the transfer mechanism.

5. 10. The system of claim 1, wherein the computer processor is further configured to use another private key associated with a second client device to obtain a complete data record and publish the complete data record to the transfer mechanism.

6. The computer processor retrieving second data from the at least one data source; utilizing the complete data record to create a second data record, the second data record including second information related to the second data and a second cryptographic signature derived from the private key or another private key accessible by the computer processor; utilizing the network interface to expose the second data record to the transfer mechanism. The system of claim 1 further configured to:

7. The system of claim 1 further comprising a plurality of networked processing devices.

8. A non-transitory computer-readable medium comprising program code executable by at least one computer processor to perform the following operations: reading at least a portion of the private key from the memory; computing a cryptographic signature from said at least a portion of said private key; using a network interface to receive conditions, the conditions including principal data and a reference to at least one data source; using the network interface to read first data from the data source; generating an incomplete data record, the incomplete data record comprising: commit input data for receiving commit data from the commit transaction; one or more output data obtained from the principal data; first information relating to the first data from the data source; generating an incomplete data record, publishing the pending data record and the cryptographic signature to a first client device utilizing the network interface; Including, the first client device is configured to verify the first information; the incomplete data record is configured to have a cryptographic signature calculated and associated therewith by the first client device to obtain a complete data record for publication to a transfer mechanism; the transfer mechanism includes at least one or more networked processing devices that implement an accounting unit, the accounting unit being accessible over a computer network by the at least one or more networked processing devices and the first client device, and enabling transaction processing created by broadcasting complete data records for transmission and reception between network participants within the computer network for recording in a ledger; Non-transitory computer-readable medium.

9. The non-transitory computer-readable medium of claim 8 , wherein the first data comprises a data reference.

10. 9. The non-transitory computer-readable medium of claim 8, wherein the condition further includes a timestamp, and the program code is further configured to cause the at least one computer processor to calculate the one or more output data or the first information related to a value upon expiration of the timestamp.

11. 9. The non-transitory computer-readable medium of claim 8, wherein the program code is further configured to cause the at least one computer processor to publish the incomplete data record and the cryptographic signature to a second client device, and to calculate and associate a cryptographic signature with the incomplete data record by the first client device or the second client device to obtain a complete data record for publication to the transfer mechanism.

12. 9. The non-transitory computer-readable medium of claim 8, wherein the program code is further configured to cause the at least one computer processor to use another private key associated with a second client device to calculate and associate a cryptographic signature of the incomplete data record to obtain a complete data record, and publish the complete data record to the transfer mechanism.

13. The program code causes the at least one computer processor to: retrieving second data from the at least one data source; utilizing the complete data record to create a second data record, the second data record including second information related to the second data and a second cryptographic signature derived from the private key or another private key accessible by the computer processor; utilizing the network interface to expose the second data record to the transfer mechanism. The non-transitory computer-readable medium of claim 8 , further configured to:

14. 1. A method for processing transactions by a computer, comprising: reading at least a portion of the private key from the memory; computing a cryptographic signature from said at least a portion of said private key; using a network interface to receive conditions, the conditions including principal data and a reference to at least one data source; using the network interface to read first data from the data source; generating an incomplete data record, the incomplete data record comprising: commit input data for receiving commit data from the commit transaction; one or more output data obtained from the principal data; first information relating to the first data from the data source; generating an incomplete data record, publishing the pending data record and the cryptographic signature to a first client device utilizing the network interface; Including, the first client device is configured to verify the first information; the incomplete data record is configured to have a cryptographic signature calculated and associated therewith by the first client device to obtain a complete data record for publication to a transfer mechanism; the transfer mechanism includes at least one or more networked processing devices that implement an accounting unit, the accounting unit being accessible over a computer network by the at least one or more networked processing devices and the first client device, and enabling transaction processing created by broadcasting complete data records for transmission and reception between network participants within the computer network for recording in a ledger; method.

15. The method of claim 14 , wherein the first data comprises a data reference.

16. 15. The method of claim 14, wherein the condition further comprises a timestamp, and the method further comprises calculating the one or more output data or the first information related to a value upon expiration of the timestamp.

17. 15. The method of claim 14, further comprising publishing the incomplete data record and the cryptographic signature to a second client device, the incomplete data record configured to have a cryptographic signature calculated and associated therewith by the first client device or the second client device to obtain a complete data record for publishing to the transfer mechanism.

18. 15. The method of claim 14, further comprising: using another private key associated with a second client device, posting and associating a cryptographic signature of the incomplete data record to obtain a complete data record; and publishing the complete data record to the transfer mechanism.

19. retrieving second data from the at least one data source; and utilizing the complete data record to create a second data record, the second data record including second information related to the second data and a second cryptographic signature derived from the private key or another private key accessible by a computer processor; utilizing the network interface to expose the second data record to the transfer mechanism; 15. The method of claim 14, further comprising:

Images