Patent Application 18549430 - UNIVERSAL PAYMENT CHANNEL

Title: UNIVERSAL PAYMENT CHANNEL
Application Information

Invention Title: UNIVERSAL PAYMENT CHANNEL
Application Number: 18549430
Submission Date: 2025-04-10T00:00:00.000Z
Effective Filing Date: 2023-09-07T00:00:00.000Z
Filing Date: 2023-09-07T00:00:00.000Z
National Class: 705
National Sub-Class: 075000
Examiner Employee Number: 94575
Art Unit: 3699
Tech Center: 3600
Rejection Summary

102 Rejections: 0
103 Rejections: 1
Cited Patents

No patents were cited in this rejection.
Office Action Text



    DETAILED ACTION
Claim Status
This is first office action on the merits in response to the application filed on 9/7/2023.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are currently pending and have been examined.

Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 9/7/2023 and 9/6/2024 is(are) in compliance with the provisions of 37 CFR 1.97.  Accordingly, the information disclosure statement is being considered by the examiner.

Claim Objections
Claims 4-5 and 16-20 are objected to because of the following informalities:
In claim 4, line 6, “the previously” should read --a previously--. 
In claim 16, line 8, “transmit” should read --transmits--.
In claim 16, line 11, “the secret” should read --a secret--.
In claim 16, line 12, “the previously” should read --a previously--.
In claim 16, line 15, “the first smart contract” should read --a first smart contract--.  
In claim 18, line 2, “the first blockchain network” should read --a first blockchain network--.
In claim 18, line 3, “the first blockchain” should read --a first blockchain--.
Claims 5 and 17-20 are further objected due to their dependency.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. 
Under the Step 1 of the Section 101 analysis, Claims 1-14 and 16-20 are drawn to a method which is within the four statutory categories (i.e., a process), and Claim 15 is drawn to a system which is within the four statutory categories (i.e. a machine).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 1-20 are determined to be directed to an abstract idea. The rationale for this determination is explained below:  

Regarding Claims 1 and 15:
Claims 1 and 15 are drawn to an abstract idea without significantly more. The claims recite “receiving, by a hub computer, a first user account identifier from a first service provider computer in communication with a first user device, and in communication with a first blockchain network, the first service provider computer thereafter transferring an amount of a first digital currency to a first smart contract on the first blockchain network; receiving, by the hub computer, a second user account identifier from a second service provider computer in communication with a second user device, and also a second blockchain network containing a second smart contract, wherein the hub computer is separately in communication with the first blockchain network and the second blockchain network, and the hub computer is in communication with the first service provider computer via a first interaction channel and the hub computer is in communication with the second service provider computer via a second interaction channel; receiving, by the hub computer, a first amount of the first digital currency from the first service provider computer via the first interaction channel; and transferring, by the hub computer, a second amount of a second digital currency to the second service provider computer via the second interaction channel.” 
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “computer”, “device”, “blockchain network”, “digital currency”, “smart contract”, and “interaction channel” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical sales activities or behaviors, because the entities such as the hub, first/second user, and service provider interact and exchange data or information, including account identifiers, amount of currencies with one another for transactions.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A method comprising:”, “A hub computer comprising: a processor; and a non-transitory computer readable medium comprising instructions executable by the processor to perform operations including:”, “computer”, “device”, “blockchain network”, “digital currency”, “smart contract”, and “interaction channel”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea.  Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception.  Accordingly, these additional elements, individually or in 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 are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.

Regarding Claim 16:
Claim 16 is drawn to an abstract idea without significantly more. The claims recite “generating, by a first service provider computer, a sender promise comprising a first amount of a first digital currency and first parameters, wherein the first parameters include a hashed secret of an interaction proposal; transmitting, by the first service provider computer to a hub computer through a first interaction channel, the sender promise, wherein the hub computer thereafter generates a server promise comprising a second amount of a second digital currency and transmit the server promise to a second service provider computer; receiving, by the first service provider computer from the hub computer, the secret of the hashed secret, wherein the first service provider computer verifies the secret by hashing the secret and comparing the hashed secret to the previously received hashed secret; generating, by the first service provider computer, a server receipt comprising first parameters of the first smart contract; and transmitting, by the first service provider computer to the hub computer, the server receipt.” 
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “computer”, “digital currency”, “hashed secret”, “interaction channel”, “server”, “hashing”, and “smart contract” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical sales activities or behaviors, because the entities such as the hub and first/second service providers interact and exchange data or information, including account identifiers, amount of currencies with one another for transactions.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A method comprising:”, “computer”, “digital currency”, “hashed secret”, “interaction channel”, “server”, “hashing”, and “smart contract”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea.  Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception.  Accordingly, these additional elements, individually or in 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 are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.

Regarding Claims 2-14 and 17-20:
Dependent claims 2-14 and 17-20 include additional limitations, for example, “smart contract”, “interaction channel”, “device”, and “computer” (Claim 2); “computer”, “digital currency”, “interaction channel”, “server”, and “device” (Claim 3); “device”, “computer”, “hashed secret”, and “hash” (Claim 4); “computer”, “smart contract”, “device”, “interaction channel”, and “server” (Claim 5); “smart contract” (Claim 6); “smart contract”, “blockchain network”, and “computer” (Claim 7); “smart contract” (Claim 8); “digital currency” (Claim 9); “smart contract” (Claim 10); “computer”, “digital currency”, and “blockchain network” (Claim 11); “computer” (Claim 12); “digital currency” (Claim 13); “device” and “mobile phones” (Claim 14); “digital currency”, “computer”, “smart contract”, and “blockchain network” (Claim 17); “smart contract”, “blockchain network”, “computer”, and “blockchain” (Claim 18); “smart contract” and “channel” (Claim 19); and “computer”, “device”, and “hash” (Claim 20), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
	Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer. 
Therefore, whether taken individually or as an ordered combination, claims 2-14 and 17-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.


Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA  to pre-AIA ) 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.  
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary.  Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.



Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vladi (US 20210019737 A1; already of record in IDS) in view of Gueye (US 20190303807 A1).

Regarding Claims 1 and 15, Vladi teaches A method comprising (Vladi: Abstract): A hub computer comprising: a processor; and a non-transitory computer readable medium comprising instructions executable by the processor to perform operations including (Vladi: Paragraph(s) 0043): A hub computer comprising (Vladi: Abstract): a processor; and a non-transitory computer readable medium comprising instructions executable by the processor to perform operations including (Vladi: Paragraph(s) 0043):
receiving, by a hub computer, a first user account identifier from a first service provider computer in communication with a first user device, and in communication with a first blockchain network, the first service provider computer thereafter transferring an amount of a first digital currency to a first smart contract on the first blockchain network (Vladi: Paragraph(s) 0015-0016, 0030, 0041 teach(es) 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; the consumer user may exchange another type of cryptocurrency for the digital stable tokens using a token cross-chain bridge; a user can generate a cryptocurrency wallet address via a quick response (QR) code and smart phone scanning capabilities and send payments via blockchain transactions; The digital stable token may be a type of cryptocurrency tracked by a blockchain network); receiving, by the hub computer, a second user account identifier from a second service provider computer in communication with a second user device, and also a second blockchain network containing a second smart contract, wherein the hub computer is separately in communication with the first blockchain network and the second blockchain network, and the hub computer is in communication with the first service provider computer via a first interaction … and the hub computer is in communication with the second service provider computer via a second interaction … (Vladi: Paragraph(s) 0015-0016, 0077, 0091 teach(es) 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; the system may include the trust entity, the consumer user device, merchant user device, or data network. The various components of the system may be in data communication with each other over the data network; the trust entity computing system being in data communication with the blockchain network via one or more smart contracts); receiving, by the hub computer, a first amount of the first digital currency from the first service provider computer via the first interaction …; and transferring, by the hub computer, a second amount of a second digital currency to the second service provider computer via the second interaction … (Vladi: Paragraph(s) 0030, 0032, 0035 teach(es) The digital stable token may be a type of cryptocurrency tracked by a blockchain network; a first amount of a cryptocurrency or fiat currency “corresponding” to a second amount of a cryptocurrency or fiat currency may include the first amount being substantially equivalent to the second amount; The trust entity may notify a blockchain network about the deposited fiat currency, and the blockchain network may transfer a corresponding amount of digital stable token to a cryptocurrency wallet of the first user).
However, Vladi does not explicitly teach interaction channels.
Gueye from same or similar field of endeavor teaches interaction channels (Gueye: Paragraph(s) 1807, 1827, 1829, 1832, 1834 teach(es) Payments from wallets to service gateways will use zero trust state channel based payments; After all parties are identified and authenticated a direct channel between cloud wallet service and service gateway serving access point may be established to reduce latency overhead of indirect communications).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Vladi to incorporate the teachings of Gueye for interaction channels. 
There is motivation to combine Gueye into Vladi because Gueye’s teachings of interaction channels would facilitate reducing latency overhead of indirect communications (Gueye: Paragraph(s) 1807, 1827, 1829, 1832, 1834).

Regarding Claim 16, Vladi teaches A method comprising (Vladi: Abstract): 
generating, by a first service provider computer, a sender promise comprising a first amount of a first digital currency and first parameters, wherein the first parameters include a … secret of an interaction proposal (Vladi: Paragraph(s) 0015-0016, 0030, 0028, 0043 teach(es) 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; the consumer user may exchange another type of cryptocurrency for the digital stable tokens using a token cross-chain bridge; a user can generate a cryptocurrency wallet address via a quick response (QR) code and smart phone scanning capabilities and send payments via blockchain transactions; The digital stable token may be a type of cryptocurrency tracked by a blockchain network; the term “cryptocurrency wallet” may include a software program, a service, a device, or other media that stores cryptographic information used in interacting with the blockchain network. The cryptographic information may include a public and private key pair used in a public key infrastructure (PKI)); transmitting, by the first service provider computer to a hub computer through a first interaction …, the sender promise, wherein the hub computer thereafter generates a server promise comprising a second amount of a second digital currency and transmit the server promise to a second service provider computer; receiving, by the first service provider computer from the hub computer, the secret of the … secret, wherein the first service provider computer verifies the secret by … the secret and comparing the … secret to the previously received hashed secret (Vladi: Paragraph(s) 0031, 0017, 0027, 0089 teach(es) 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; Some of the further benefits of the systems and methods for blockchain-based transaction settlement include security and fraud protection. The combination of smart phone devices with biometrics security, two-factor authentication, and the consensus mechanism of the blockchain network provide for cryptographically secure transactions); generating, by the first service provider computer, a server receipt comprising first parameters of the first smart contract; and transmitting, by the first service provider computer to the hub computer, the server receipt (Vladi: Paragraph(s) 0069, 0071-0073 teach(es) The token cross-chain bridge may include functionality that receives notifications from the different blockchain networks or that detects events on the different blockchain networks and, in response, facilitates the exchange of cryptocurrency and digital stable tokens).
However, Vladi does not explicitly teach hashed secret, hashing the secret, and interaction channel.
Gueye from same or similar field of endeavor teaches hashed secret, hashing the secret (Gueye: Paragraph(s) 1816, 1830 teach(es) IUNGO will reuse the identity mechanism employed in the Ethereum network: each entity will generate an Elliptic Curve key pair. A truncated hash of public key will serve as an entity identifier and also as an account number on the Token contract; The message contains the sender's address, the receiver's address, the per sender-receiver pair tracked serial number of the offer, the amount sent, a hash of previous attributes, the sender's digital signature over hash and an opaque, unsigned bytestring to carry the reason for payment), and interaction channel (Gueye: Paragraph(s) 1807, 1816, 1827, 1829, 1832, 1834 teach(es) Payments from wallets to service gateways will use zero trust state channel based payments; After all parties are identified and authenticated a direct channel between cloud wallet service and service gateway serving access point may be established to reduce latency overhead of indirect communications).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Vladi to incorporate the teachings of Gueye for interaction channels. 
There is motivation to combine Gueye into Vladi because Gueye’s teachings of interaction channel and hashing would facilitate reducing latency overhead of indirect communications (Gueye: Paragraph(s) 1807, 1827, 1829-1830, 1832, 1834).

Regarding Claim 2, the combination of Vladi and Gueye teaches all the limitations of claim 1 and interaction channels above; and Vladi further teaches wherein the first smart contract implements the first interaction … that connects the first user device to the hub computer via the first service provider computer and the second smart contract implements the second interaction … that connects the second user device to the hub computer via the second service provider computer (Vladi: Paragraph(s) 0080; Figs. 1 and 7-8).

Regarding Claim 3, the combination of Vladi and Gueye teaches all the limitations of claim 1, wherein receiving, by the hub computer, a first amount of a first digital currency from the first service provider computer via the first interaction channel, and transferring, by the hub computer, a second amount of a second digital currency to the second service provider computer via the second interaction channel comprises: and interaction channels above; and Vladi further teaches receiving, by the hub computer, a sender promise from the first service provider computer via the first interaction …, wherein the sender promise comprises first parameters (Vladi: Paragraph(s) 0015-0016, 0030, 0028, 0043 teach(es) 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; the consumer user may exchange another type of cryptocurrency for the digital stable tokens using a token cross-chain bridge; a user can generate a cryptocurrency wallet address via a quick response (QR) code and smart phone scanning capabilities and send payments via blockchain transactions; The digital stable token may be a type of cryptocurrency tracked by a blockchain network; the term “cryptocurrency wallet” may include a software program, a service, a device, or other media that stores cryptographic information used in interacting with the blockchain network. The cryptographic information may include a public and private key pair used in a public key infrastructure (PKI)); generating, by the hub computer, a server promise comprising second parameters; and transmitting, by the hub computer, the server promise to the second user device via the second service provider computer via the second interaction … (Vladi: Paragraph(s) 0031, 0017, 0027, 0089 teach(es) 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; Some of the further benefits of the systems and methods for blockchain-based transaction settlement include security and fraud protection. The combination of smart phone devices with biometrics security, two-factor authentication, and the consensus mechanism of the blockchain network provide for cryptographically secure transactions).

Regarding Claim 4, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the second user device transmits an interaction proposal comprising a … of a secret to the first user device, and wherein the method further comprises: receiving, by the hub computer, the secret from the second service provider computer, wherein the hub computer verifies the secret by … the secret and comparing the … secret to the previously received … (Vladi: Paragraph(s) 0031, 0017, 0027, 0089 teach(es) 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; Some of the further benefits of the systems and methods for blockchain-based transaction settlement include security and fraud protection. The combination of smart phone devices with biometrics security, two-factor authentication, and the consensus mechanism of the blockchain network provide for cryptographically secure transactions).
However, Vladi does not explicitly teach a hash of a secret, hashing the secret, hashed secret, and interaction channel.
Gueye from same or similar field of endeavor teaches a hash of a secret, hashing the secret, and hashed secret (Gueye: Paragraph(s) 1816, 1830 teach(es) IUNGO will reuse the identity mechanism employed in the Ethereum network: each entity will generate an Elliptic Curve key pair. A truncated hash of public key will serve as an entity identifier and also as an account number on the Token contract; The message contains the sender's address, the receiver's address, the per sender-receiver pair tracked serial number of the offer, the amount sent, a hash of previous attributes, the sender's digital signature over hash and an opaque, unsigned bytestring to carry the reason for payment), and interaction channel (Gueye: Paragraph(s) 1807, 1816, 1827, 1829, 1832, 1834 teach(es) Payments from wallets to service gateways will use zero trust state channel based payments; After all parties are identified and authenticated a direct channel between cloud wallet service and service gateway serving access point may be established to reduce latency overhead of indirect communications).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Vladi to incorporate the teachings of Gueye for a hash of a secret, hashing the secret, hashed secret, and interaction channel. 
There is motivation to combine Gueye into Vladi because Gueye’s teachings of hashing the secret would facilitate reducing latency overhead of indirect communications (Gueye: Paragraph(s) 1807, 1827, 1829-1830, 1832, 1834).

Regarding Claim 5, the combination of Vladi and Gueye teaches all the limitations of claim 4 and interaction channels above; and Vladi further teaches further comprising: generating, by the hub computer, a receiver receipt comprising second parameters of the second smart contract; transmitting, by the hub computer, the receiver receipt to the second user device via the second service provider computer through the second interaction … (Vladi: Paragraph(s) 0069, 0071-0073 teach(es) The token cross-chain bridge may include functionality that receives notifications from the different blockchain networks or that detects events on the different blockchain networks and, in response, facilitates the exchange of cryptocurrency and digital stable tokens); transmitting, by the hub computer, the secret to the first service provider computer through the first interaction …, wherein the first service provider computer generates a server receipt comprising first parameters of the first smart contract; and receiving, by the hub computer, the server receipt from the first user device via the first service provider computer through the first interaction … (Vladi: Paragraph(s) 0015-0016, 0080, 0069-0070; Figs. 1 and 7-8).

Regarding Claim 6, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the first smart contract and the second smart contract are associated with a plurality helper functions including one or more of a generate promise function, a verify promise function, a generate receipt function, a verify receipt function, or an update local state function (Vladi: Paragraph(s) 0024, 0094).

Regarding Claim 7, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the first smart contract is deployed to the first blockchain network by the hub computer, and wherein the second smart contract is deployed to the second blockchain network by the hub computer (Vladi: Paragraph(s) 0080, 0069-0070; Figs. 1 and 7-8).

Regarding Claim 8, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the first smart contract and the second smart contract comprise a contract status, wherein the contract status is an active status, a cooperative closing status, a unilateral closing status, or a closed status (Vladi: Paragraph(s) 0029, 0050-0051).

Regarding Claim 9, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein a value of the second amount of the second digital currency is equivalent to a value of the first amount of the first digital currency (Vladi: Paragraph(s) 0015-0016).

Regarding Claim 10, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the first smart contract and the second smart contract comprise contract functions and protocols including one or more of a initialization function, a get parameters function, a get state function, a deposit function, an initialize close function, a withdraw function, and a claim protocol (Vladi: Paragraph(s) 0029, 0050-0051).

Regarding Claim 11, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the hub computer receives the first amount of the first digital currency and transmit the second amount of the second digital currency without connection to either the first blockchain network or the second blockchain network (Vladi: Paragraph(s) 0015-0016, 0031).

Regarding Claim 12, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein a first service provider identifier is provided to the first service provider computer by a first certificate authority computer and a second service provider identifier is provided to the second service provider computer by a second certificate authority computer (Vladi: Paragraph(s) 0039, 0048, 0023).

Regarding Claim 13, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the first digital currency is different from the second digital currency (Vladi: Paragraph(s) 0015-0016).

Regarding Claim 14, the combination of Vladi and Gueye teaches all the limitations of claim 1 above; and Vladi further teaches wherein the first user device and the second user device are mobile phones (Vladi: Paragraph(s) 0020; Fig. 1).

Regarding Claim 17, the combination of Vladi and Gueye teaches all the limitations of claim 16 above; and Vladi further teaches wherein the first digital currency is different from the second digital currency, and wherein the hub computer also generates a receiver receipt comprising second parameters of a second smart contract deployed on a second blockchain network and transmits the receiver receipt to the second service provider computer (Vladi: Paragraph(s) 0015-0016, 0080, 0069-0070; Figs. 1 and 7-8).

Regarding Claim 18, the combination of Vladi and Gueye teaches all the limitations of claim 16 above; and Vladi further teaches wherein the first smart contract deployed on the first blockchain network connects the first service provider computer to the hub computer without connection to the first blockchain (Vladi: Paragraph(s) 0015-0016, 0031).

Regarding Claim 19, the combination of Vladi and Gueye teaches all the limitations of claim 16 and interaction channels above; and Vladi further teaches wherein the first parameters of the first smart contract include one or more of a … identifier, a user account identifier, a hub identifier, or a dispute time (Vladi: Paragraph(s) 0029, 0050-0051).

Regarding Claim 20, the combination of Vladi and Gueye teaches all the limitations of claim 16 and a hash of a secret above; and Vladi further teaches further comprising: receiving, by the first service provider computer from a first user device in communication with a second user device, the interaction proposal comprising a … of a secret (Vladi: Paragraph(s) 0020, 0043, 0048).


Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Paya (US 11501370 B1) teaches Systems, Methods, And Program Products For Non-custodial Trading Of Digital Assets On A Digital Asset Exchange, including a digital asset exchange, and transferring an amount of digital assets from a seller wallet to at least one buyer wallet.
James (US 20220253842 A1) teaches System, Method And Program Product For Modifying A Supply Of Stable Value Digital Asset Tokens, including converting into fiat some or all of existing digital assets held at the digital asset exchange, hash, and digital wallet.
Isaacson (US 20200382480 A1) teaches System And Method For Providing A Social Media Shopping Experience, including converted into the corresponding value of the respective cryptocurrency, hash, and digital wallet.

Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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, Neha Patel can be reached on (571)270-1492. 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.





/CLAY C LEE/Primary Examiner, Art Unit 3699