DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 16, 2025 has been entered.
Response to Amendment
Applicant amended claims 1, 2, 5, and 6.
Applicant cancelled claim 3.
Applicant previously cancelled claim 4.
Claims 1, 2, 5, and 6 are pending and have been examined.
Response to Arguments
Applicant's arguments filed December 16, 2025 have been fully considered but they are not persuasive.
Regarding Claim Objections
Examiner initially objected to claim 6 for a grammatical error. While Applicant’s arguments indicated they amended the limitation to address the issue; the limitation was not amended. Applicant’s other amendments did not address the issue either. In view of Applicant’s arguments/amendments, Examiner maintains this objection.
Regarding 101 Rejections
Examiner initially rejected claims 1-3, 5, and 6 under 35 USC 101 as being directed to non-statutory subject matter.
Applicant argued that the claims do not recite an abstract idea. Examiner does not find this argument persuasive. Applicant merely alleges the claims do not recite an abstract idea and provides no analysis as to why the claims are not directed to Certain Methods of Organizing Human Activity. Merely having a different opinion as to how to describe the thrust of the claims does not change what the claims actually recite. Examiner identified the limitations which define the abstract idea and how they are directed to commercial/legal interactions. Since they are a commercial interaction the claims fall into the grouping of Certain Methods of Organizing Human Activity and therefore constitute an abstract idea (and thus a judicial exception).
Applicant argued that the claims cannot be performed in the human mind. Examiner does not find this argument persuasive. The basis of Examiner’s rejection is the claims recite Certain Methods of Organizing Human Activity, not that they are an Mental Process. It is not a valid argument that the claims cannot be performed mentally when the basis is the claims recite Certain Methods of Organizing Human Activity. Whether or not the claims can be performed solely in the mind is not a consideration as to whether they are directed to a commercial/legal interaction. Furthermore Applicant’s claims could be performed mentally as the claims are merely the collection of transaction data, analysis of that data and processing the transaction. The computer implementation of the abstract idea does not change the abstract nature of the claims.
Applicant argued that the claims a recite a practical application of the judicial exception. Examiner does not find this argument persuasive. Applicant merely alleges its claims recite a practical application and provides no analysis as to how the claims meet this standard. Applicant’s claims do not improve technology; the underlying technology remains unaffected by the claims. Applicant is addressing a business problem (processing a transaction) with a business solution. Applicant is merely using existing technology (for its intended purpose) to implement the business solution. Any improvements lie in the abstract idea itself, not in underlying technology. Outside of the abstract idea there remains only the computer implementation of the abstract idea and extra-solution activity. Neither of these are indicative of a practical application. Applicant’s claims do not address a technical limitation/deficiency in the art and thus does not amount to a practical application.
Applicant argued that they recite a combination of steps which recite something other than what is well understood, routine, and conventional. Examiner does not find this argument persuasive. Applicant merely alleges they meet this standard and provides no analysis as to the claims amount to something other than well-understood, routine and conventional. Applicant merely points out the utility of the claims and their computer implementation. Applicant is mistaken that Examiner must provide evidence that the underlying abstract idea is well-understood, routine and conventional. It is the additional elements that must be shown to be well-understood, routine and conventional. Outside of the abstract idea, there is only the computer implementation of the abstract idea and extra-solution activity. Examiner provided evidence that these are well-understood, routine and conventional limitations. Examiner has provided the proper evidence as required by Berkheimer.
Examiner maintains this rejection.
Regarding Prior Art Rejections
Examiner initially rejected claims 1-3, 5, and 6 as being unpatentable over the prior art.
Applicant argued that Vladi does not use the same signature information when issuing transaction to multiple blockchains. This argument is not commensurate in scope with Applicant’s claims. The claims do not require this limitation. The only transaction that utilizes the signature information is the transaction regarding the token. The transfer regarding the coin does not specify that the same signature information is used in that transaction. Furthermore, Vladi teaches that the transaction is digitally signed (has signature information) and that transaction can include additional transactions within it. Therefore the same signature information for the cross-chain transaction is used across the multiple blockchains.
Examine relies on the below 102 rejection to demonstrate that Vladi teaches the limitations that Applicant generally alleged it does not teach.
Examiner maintains this rejection.
Claim Objections
Claim 6 is objected to because of the following informalities: in the limitation “which is transmitted for a provision of a commercial products or services”; “a commercial products or services” is grammatically incorrect. Examiner respectfully suggests mirroring language in claim 1 and reciting “which is transmitted for a provision of commercial products or services” Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5, and 6 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite the abstract idea which may be summarized as transferring ownership of tokens and coins.
Step 1 Analysis
Applicants claims are directed to a process (claims 6) and machine (claims1-3, 5).
Step 2A, Prong 1 Analysis
Claims 1 and 6 recite the abstract idea/limitations of:
a coin [ledger] for managing a coin associated with a cash currency;
a token [ledger] for managing a token associated with the coin,
accepting a payment instruction including signature information, which is transmitted for a provision of a commercial products or services from a second user to a first user, to transfer the coin, from the first user to the second user;
detecting that the provision of commercial products or services from the second user to the first user is completed;
and transmitting an order for a transaction including the signature information as a transfer instruction to transfer the token, to the token [ledger], in accordance with the accepted payment instruction in a case where completion of the provision of goods or services is detected,,
receive the order for the transaction including the signature information, the order for the transaction instructs;
verify the order for the transaction using the signature information in the order for the transaction;
transfer the coin associated with the token within the coin [ledger] in accordance with transfer of the token within the token [ledger] in a case where the order for the transaction is verified.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. Specifically, the claims recite transferring coins and tokens on a blockchain. This is a commercial/legal interaction which is a category of “Certain Methods of Organizing Human Activity”. If a claim limitation, under its broadest reasonable interpretation, recites “Certain Methods of Organizing Human Activity”, then it recites an abstract idea.
Step 2A, Prong 2 Analysis
This judicial exception is not integrated into a practical application because the claims only recites system components for implementing the abstract idea and extra-solution activity. The claims recite the additional limitations of an information processing apparatus, a management business operator, an electronic currency management system, a coin blockchain network, a token blockchain network, a network interface, a user apparatus, a relay node, processor circuit, a memory, instructions; and they are recited at a high level of generality. These system components amount to no more than mere instructions to apply the exception using one or more generic computers. These limitations generally link the use of the judicial exception to the technological environment. They are not indicative of integration into a practical application. The limitations of:
and transmitting an order for a transaction,
receive the order for the transaction;
transfer the coin associated with the token,
transfer of the token.
amount to insignificant extra-solution activity. These steps are mere sending and receiving of data, which courts have recognized as insignificant extra-solution activities see MPEP 2106.05(d)(II)(i). These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims as a whole do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea without a practical application.
Step 2B Analysis
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of an information processing apparatus, a management business operator, an electronic currency management system, a coin blockchain network, a token blockchain network, a network interface, a user apparatus, a relay node, processor circuit, a memory, instructions; amount to no more than mere instructions to apply the abstract idea using a vehicle with generic components and/or generally link the abstract idea to a particular technological environment. The limitations of:
and transmitting an order for a transaction,
receive the order for the transaction;
transfer the coin associated with the token,
transfer of the token.
amount to the sending and receiving data between devices, claimed at a high level of generality. These insignificant extra-solution activities are also well-understood, routine, and conventional as recognized by the federal courts See MPEP 2106.05(d)(II)(i). See also, Applicant’s specification paragraphs [0050-0054], [0037-0058], about implementation of the abstract idea using general purpose or special purpose computing devices; and MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not amount to significantly more than the abstract idea because they do not impose any meaningful limits on practicing the abstract idea. Thus Applicant’s claims are not patent eligible.
Dependent Claims Analysis
As for dependent claim 5 this claim recites limitations that further define the same abstract idea noted in independent claim 1. Therefore, claim 5 is considered ineligible subject matter for the reasons given above.
As for dependent claims 2 these claims recite limitations that further define the same abstract idea noted in independent claim 1. In addition, the recite the additional elements of
transmits an instruction to transfer the token;
This is considered insignificant extra-solution activity, because as drafted the limitations are mere data gathering and storing of information. These limitations do not qualify as a practical application of the judicial exception or significantly more. See MPEP 2106.05(g). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, claims 2 are considered ineligible subject matter.
Thus, the dependent claims 2 and 5 are not patent-eligible either.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of pre-AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
Claims 1, 2, 5, and 6 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vladi, US Patent Application Publication NO 2021/0019737.
Regarding claims 1 and 6;
(Claim 1) An electronic currency management system including:
a coin blockchain network for managing a coin associated with a cash currency;
a token blockchain network for managing a token associated with the coin;
See Vladi [0068] The system 700 may include a main-chain blockchain network 102, which may include one or more transaction 104 and one or more smart contracts 106. The main-chain blockchain network 102 may be similar to the blockchain network 102 of the FIG. 1. The main-chain blockchain network 102 may include the digital stable token as a native token. The system 700 may include a side-chain blockchain network 702. The side-chain blockchain network 702 may be similar to the main-chain blockchain network 102 in that it may include a blockchain network with one or more nodes that maintain a side-chain blockchain, one or more transactions 704, and one or more smart contracts 706. To distinguish between the nodes of the different blockchain networks 102, 702, the nodes of the main-chain blockchain network 102 are now referred to as “main-chain nodes,” and the nodes of the side-chain blockchain network 102 are now referred to as “side-chain nodes.” The side-chain blockchain maintained by the side-chain network 702 may be different than the main-chain blockchain of the main-chain blockchain network 102. The side-chain blockchain may track users' transfers and receipts of a cryptocurrency other than the digital stable token tracked by the main-chain blockchain. This other cryptocurrency may be native to the side-chain blockchain network 702. For example, the side-chain blockchain network 702 may include the Bitcoin network, the Ethereum blockchain network (with its native Ethereum token), or some other cryptocurrency network.
an information processing apparatus that is managed by a management business operator that manages the token, and a relay node
See Vladi [0015] Disclosed herein are systems and methods for blockchain-based transaction settlement. These systems and methods offer improvements to conventional payment transaction settlement processes and systems, some of which have been described above, thereby eliminating inherent complexity and associated economic and opportunity costs incurred by parties in conventional settlement networks. As a general overview of the systems and methods of the present invention, a consumer user may send fiat currency to a trust entity, such as a bank.
[0022] As used herein, the term “distributed ledger” may include a data storage of transactions replicated across and synchronized by multiple computing devices, called “nodes,” in communication with each other. In some embodiments, the one or more nodes may be owned, controlled, or operated by a single party. The single party may include a person, an organization, a business, or some other type of entity. In other embodiments, the nodes may be owned, controlled, or operated by multiple parties, and at least a portion of the parties may be independent from each other (i.e., one party does not control another or exert a significant amount of influence directly on another). The nodes may synchronize the data of the distributed ledger, including which transactions are added to the ledger and in what order, using a consensus mechanism. The transactions may be cryptographically secured such that once a transaction is added to the distributed ledger, the transaction cannot be later modified. Basic encryption or cryptography principles—such a public key infrastructure, digital signatures, and other cryptographic technologies—underlie the application of distributed ledger technology. When a user adds a distributed ledger transaction, the user may digitally sign the transaction such that other parties can verify that the transaction did, in fact, originate from that user. One example implementation of a distributed ledger includes a blockchain.
[0036] FIG. 1 depicts one embodiment of a system 100. The system 100 may include a system for blockchain-based transaction settlement. As an overview, in one embodiment, the system 100 may include a blockchain network 102. The blockchain network 102 may include one or more blockchain transactions 104 and one or more smart contracts 106. The system 100 may include a trust entity 108. The system 100 may include a consumer user device 110. The system 100 may include a merchant user device 112. The system may include a data network 114. The blockchain network 102, the trust entity 108, the consumer user device 110, or the merchant user device 112 may be in data communication with each other over the data network 114. It should be noted that the system 100 may include any number of transactions 104, smart contracts 106, trust entities 108, consumer user devices 110, or merchant user devices 112, however, only a portion of them are shown in FIG. 1 for the sake of simplicity.
the information processing apparatus comprising:
a network interface; and at least one processor circuit with a memory comprising instructions, that when executed by the at least one processor circuit of the information processing apparatus, causing the at least one processor circuit of the information processing apparatus to at least:
See Vladi [0036] FIG. 1 depicts one embodiment of a system 100. The system 100 may include a system for blockchain-based transaction settlement. As an overview, in one embodiment, the system 100 may include a blockchain network 102. The blockchain network 102 may include one or more blockchain transactions 104 and one or more smart contracts 106. The system 100 may include a trust entity 108. The system 100 may include a consumer user device 110. The system 100 may include a merchant user device 112. The system may include a data network 114. The blockchain network 102, the trust entity 108, the consumer user device 110, or the merchant user device 112 may be in data communication with each other over the data network 114. It should be noted that the system 100 may include any number of transactions 104, smart contracts 106, trust entities 108, consumer user devices 110, or merchant user devices 112, however, only a portion of them are shown in FIG. 1 for the sake of simplicity.
[0043] Returning to FIG. 1, in one embodiment, the consumer user device 110 may include an apparatus. The apparatus may include a computing device. The consumer user device 110 may include a processor and a computer-readable storage medium. The computer-readable storage medium may include a cryptocurrency wallet. The cryptocurrency wallet may include a downloadable mobile application executable by the consumer user device 110. The mobile application may include a set of computer-readable instructions. The set of instructions may include software, such as a software application, that may be configured to perform functionality related to interacting with the blockchain network 102. The software may include a password to protect against misuse of the application, private key, or other data. The cryptocurrency wallet may include an address, a public key, or a private key. The address, public key, or private key may be used in generating cryptographically secure blockchain transactions. In some embodiments, the merchant user device 112 may include an apparatus. The apparatus may be similar to the apparatus of the consumer user device 110 (e.g., include a cryptocurrency wallet with an address, public key, and private key).
accept, from a first user apparatus associated with a first user, a payment instruction including signature information, which is transmitted for a provision of commercial products or services from a second user to the first user, to transfer the coin, from the first user to the second user via the network interface;
See Vladi [0015] The trust entity may notify a blockchain network to issue a corresponding amount of digital stable tokens to the consumer's cryptocurrency wallet. The consumer may spend its digital stable tokens, via a blockchain transaction, at a merchant who is willing to accept digital stable tokens as payment for goods or services. Later, the merchant user may send the digital stable tokens to a smart contract of the blockchain network, and the smart contract may automatically burn the received tokens and notify the trust entity to deposit a corresponding amount of fiat currency in an account owned by the merchant. In some embodiments, instead of sending fiat currency to the trust entity, the consumer user may exchange another type of cryptocurrency for the digital stable tokens using a token cross-chain bridge. The blockchain network may track transactions involving the issuance and exchange of the digital stable token. The digital stable token may be backed by a fiat currency, which may help prevent the risk of price fluctuations of the digital stable token since the digital stable token may be exchanged for fiat currency at a consistent price.
[0071] The token cross-chain bridge 708 may receive notifications from or detect events on the different blockchain networks 102, 702 and, in response, facilitate the exchange of cryptocurrency and digital stable tokens. In one embodiment, the token cross-chain bridge 708 may receive a first notification from a smart contract of the side-chain blockchain network 702. The first notification may include data identifying the user wishing to exchange cryptocurrency for digital stable tokens (e.g., the cryptocurrency wallet address of the user on the side-chain blockchain network 702). The first notification may include the amount of cryptocurrency the user wishes to exchange.
detect that the provision of commercial products or services from the second user to the first user is completed; and
See Vladi [0087] In some embodiments, a consumer user or a merchant user may use the main-chain blockchain network 102 to obtain a loan. The consumer user device 108 or the merchant user device 110 may be configured to send an amount of the digital stable token to a smart contract of the smart contracts 106 of the main-chain blockchain network 102. The consumer user or merchant user may send this amount of the digital stable token as collateral for the loan. The smart contract may send an instruction to the trust entity computing system 202 indicating that the trust entity 108 is to loan the user a certain amount of fiat currency. The smart contract may send the collateral digital stable token amount to a cryptocurrency wallet controlled by the trust entity 108. In response, the trust entity 108 may send the fiat currency to the consumer trust entity account 210 or the merchant trust entity account 212. In response to the consumer user or merchant user paying off the loan, the trust entity computing system 202 may send an indication to the smart contract that the user has paid off the loan. The smart contract may release the collateral and send the amount of the digital stable token back to the relevant user. In response to the consumer user or merchant user defaulting on the loan, the trust entity computing system 202 may send an indication to the smart contract, and the smart contract may send the collateral to the cryptocurrency wallet controlled by the trust entity 108, or the trust entity 108 may keep the collateral in the trust entity's 108 cryptocurrency wallet (e.g., if the trust entity 108 previously received the collateral in the trust entity's 108 cryptocurrency wallet).
and transmit an order for a transaction including the signature information as a transfer instruction to transfer the token, to the token blockchain network via the network interface in accordance with the accepted payment instruction in a case where completion of the provision of commercial products or services is detected,
See Vladi [0071] In response to receiving the first notification, the token cross-chain bridge 708 may send a second notification to a smart contract of the main-chain blockchain network 102. The second notification may include data identifying the user wishing to exchange cryptocurrency for digital stable tokens (e.g., the cryptocurrency wallet address of the user on the main-chain blockchain network 102). The second notification may include the corresponding amount of digital stable tokens the user should receive in exchange for the cryptocurrency.
[0067] The system 700 may include a system for blockchain-based transaction settlement. The system 700 may allow a user to exchange cryptocurrency for digital stable tokens without the user having to use a cryptocurrency exchange.
[0087] In some embodiments, a consumer user or a merchant user may use the main-chain blockchain network 102 to obtain a loan. The consumer user device 108 or the merchant user device 110 may be configured to send an amount of the digital stable token to a smart contract of the smart contracts 106 of the main-chain blockchain network 102. The consumer user or merchant user may send this amount of the digital stable token as collateral for the loan. The smart contract may send an instruction to the trust entity computing system 202 indicating that the trust entity 108 is to loan the user a certain amount of fiat currency. The smart contract may send the collateral digital stable token amount to a cryptocurrency wallet controlled by the trust entity 108. In response, the trust entity 108 may send the fiat currency to the consumer trust entity account 210 or the merchant trust entity account 212. In response to the consumer user or merchant user paying off the loan, the trust entity computing system 202 may send an indication to the smart contract that the user has paid off the loan. The smart contract may release the collateral and send the amount of the digital stable token back to the relevant user. In response to the consumer user or merchant user defaulting on the loan, the trust entity computing system 202 may send an indication to the smart contract, and the smart contract may send the collateral to the cryptocurrency wallet controlled by the trust entity 108, or the trust entity 108 may keep the collateral in the trust entity's 108 cryptocurrency wallet (e.g., if the trust entity 108 previously received the collateral in the trust entity's 108 cryptocurrency wallet).
wherein the relay node comprises at least one processor circuit with a memory comprising instructions, that when executed by the at least one processor circuit of the relay node, causing the at least one processor circuit of the relay node to at least:
See Vladi [0022] As used herein, the term “distributed ledger” may include a data storage of transactions replicated across and synchronized by multiple computing devices, called “nodes,” in communication with each other. In some embodiments, the one or more nodes may be owned, controlled, or operated by a single party. The single party may include a person, an organization, a business, or some other type of entity. In other embodiments, the nodes may be owned, controlled, or operated by multiple parties, and at least a portion of the parties may be independent from each other (i.e., one party does not control another or exert a significant amount of influence directly on another). The nodes may synchronize the data of the distributed ledger, including which transactions are added to the ledger and in what order, using a consensus mechanism. The transactions may be cryptographically secured such that once a transaction is added to the distributed ledger, the transaction cannot be later modified. Basic encryption or cryptography principles—such a public key infrastructure, digital signatures, and other cryptographic technologies—underlie the application of distributed ledger technology. When a user adds a distributed ledger transaction, the user may digitally sign the transaction such that other parties can verify that the transaction did, in fact, originate from that user. One example implementation of a distributed ledger includes a blockchain.
receive the order for the transaction including the signature information, the order for the transaction instructs;
See Vladi [0022] Basic encryption or cryptography principles—such a public key infrastructure, digital signatures, and other cryptographic technologies—underlie the application of distributed ledger technology.
[0027] As used herein, the term “transaction” includes a piece of data that is includable in a blockchain. A transaction may include metadata describing the transaction. The metadata may include data indicating the author of the transaction, the time and date the transaction was generated, a digital signature of the transaction, or other data. In some embodiments, a transaction may include data indicating activity between parties of the blockchain network.
[0031] As used herein, a first party “sending” an amount of digital stable tokens to a second party may include the first party generating a blockchain transaction describing the transfer of the amount of digital stable tokens. The transaction may include data such as the amount of digital stable tokens being sent, a source cryptocurrency wallet address, a destination cryptocurrency wallet address, a digital signature authenticating that the first party generated the transaction, or other data. The transaction may be received and validated by the blockchain network that tracks the digital stable token, as described above. This “sending” may not necessarily include sending data from the a device of the first party to a device of the second party. For example, a first party sending cryptocurrency to a second party does not necessarily include the first party sending data from its device to a device of the second party, but may involve adjusting the cryptocurrency balance of each of the two parties on the applicable blockchain.
verify the order for the transaction using the signature information in the order for the transaction;
See Vladi [0023] As used herein, the term “blockchain” may include a distributed ledger whose transactions, as defined below, are gathered into blocks, and the nodes of the blockchain may append a block of transactions to the blocks that are already a part of the blockchain. A node or a client device may generate a transaction to be added to a blockchain. The node or client device may send the transaction to one or more nodes, and the one or more nodes may validate the transaction. Validating the transaction may include the node verifying the digital signature(s) of the transaction, verifying that the transaction does not involve any double-spending of a cryptocurrency, or verifying that the transaction's author has sufficient cryptocurrency to spend in the transaction.
and transfer the coin associated with the token within the coin blockchain network in accordance with transfer of the token within the token blockchain network in a case where the order for the transaction is verified.
See Vladi [0069] The system 700 may include a token cross-chain bridge 708. The token cross-chain bridge 708 may allow for users on the different blockchain networks 102, 702 to exchange cryptocurrency for digital stable tokens, or vice versa, without the use of a cryptocurrency exchange. This may allow users to exchange cryptocurrency and digital stable tokens without the added complexity of a cryptocurrency exchange, the delays associated with cryptocurrency exchanges, and without cryptocurrency exchange fees.
Regarding claim 2;
The electronic currency management system according to claim 1, wherein the payment instruction includes signature information associated with the first user,
See Vladi [0022] Basic encryption or cryptography principles—such a public key infrastructure, digital signatures, and other cryptographic technologies—underlie the application of distributed ledger technology.
[0027] As used herein, the term “transaction” includes a piece of data that is includable in a blockchain. A transaction may include metadata describing the transaction. The metadata may include data indicating the author of the transaction, the time and date the transaction was generated, a digital signature of the transaction, or other data. In some embodiments, a transaction may include data indicating activity between parties of the blockchain network.
[0031] The transaction may include data such as the amount of digital stable tokens being sent, a source cryptocurrency wallet address, a destination cryptocurrency wallet address, a digital signature authenticating that the first party generated the transaction, or other data.
and the instructions cause the processor circuit of the information processing apparatus to generate and transmit an instruction to transfer the token, based on the signature information.
See Vladi [0031] As used herein, a first party “sending” an amount of digital stable tokens to a second party may include the first party generating a blockchain transaction describing the transfer of the amount of digital stable tokens. The transaction may include data such as the amount of digital stable tokens being sent, a source cryptocurrency wallet address, a destination cryptocurrency wallet address, a digital signature authenticating that the first party generated the transaction, or other data. The transaction may be received and validated by the blockchain network that tracks the digital stable token, as described above. This “sending” may not necessarily include sending data from the a device of the first party to a device of the second party. For example, a first party sending cryptocurrency to a second party does not necessarily include the first party sending data from its device to a device of the second party, but may involve adjusting the cryptocurrency balance of each of the two parties on the applicable blockchain.
Regarding claim 5;
The electronic currency management system according to claim 1, wherein the payment instruction includes a condition related to transfer of the token that includes a condition related to a timing for transferring the token.
See Vladi [0087] In some embodiments, a consumer user or a merchant user may use the main-chain blockchain network 102 to obtain a loan. The consumer user device 108 or the merchant user device 110 may be configured to send an amount of the digital stable token to a smart contract of the smart contracts 106 of the main-chain blockchain network 102. The consumer user or merchant user may send this amount of the digital stable token as collateral for the loan. The smart contract may send an instruction to the trust entity computing system 202 indicating that the trust entity 108 is to loan the user a certain amount of fiat currency. The smart contract may send the collateral digital stable token amount to a cryptocurrency wallet controlled by the trust entity 108. In response, the trust entity 108 may send the fiat currency to the consumer trust entity account 210 or the merchant trust entity account 212. In response to the consumer user or merchant user paying off the loan, the trust entity computing system 202 may send an indication to the smart contract that the user has paid off the loan. The smart contract may release the collateral and send the amount of the digital stable token back to the relevant user. In response to the consumer user or merchant user defaulting on the loan, the trust entity computing system 202 may send an indication to the smart contract, and the smart contract may send the collateral to the cryptocurrency wallet controlled by the trust entity 108, or the trust entity 108 may keep the collateral in the trust entity's 108 cryptocurrency wallet (e.g., if the trust entity 108 previously received the collateral in the trust entity's 108 cryptocurrency wallet).
[0029] As used herein, the term “smart contract” may include computer-executable instructions that may be executed by a node. The smart contract may automatically execute in response to detecting a specified condition or in response to receiving specified data. For example, a smart contract may be configured to read transactions of blocks that are added to a blockchain. In response to detecting, from the read transactions, that a predetermined cryptocurrency wallet's cryptocurrency balance exceeds a predetermined threshold, the smart contract may be configured to send a message. The code for the smart contract may be copied and synchronized across multiple nodes of the blockchain network, and each node may execute the smart contract to obtain the same result as the other nodes independently.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights