Acknowledgements
This communication is in response to applicant’s response filed on 11/05/2025.
Claims 6, 10, and 14 have been cancelled. Claims 21-23 have been added. Claims 1, 7-9, 13, 16-20 have been amended.
Claims 1-5, 7-9, 11-13, and 15-23 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Regarding applicant’s arguments:
Applicant’s arguments see pgs. 9-10, filed 11/05/2025, with respect to the rejection(s) of claim(s) under Claim Rejections - 35 USC § 101 that the hub computer solves the throughput and usability limitations of blockchains in everyday commerce by maintaining separate off-chain channels with an issuer and custodian computers, interfacing with a processing network, and coordinating signed off-chain interaction requests and responses to update channel states have been considered and are persuasive. Therefore, the rejection has been withdrawn.
Applicant’s arguments see pgs. 10-11, filed 11/05/2025, with respect to the rejection(s) of claim(s) 1, 9, and 17 under Claim Rejections - 35 USC § 103 that the currently cited prior art does not teach a process associated with an interaction between a user and a resource provider, and further claims 1 and 9 do not teach the amended limitations “determining, by the hub computer, a cryptocurrency custodian computer based on the resource provider identifier transmitting, by the hub computer, to the cryptocurrency custodian computer, a second off-chain interaction request comprising the interaction value, the resource provider identifier, and a second hub computer cryptographic signature and receiving, by the hub computer, from the cryptocurrency custodian computer, a second off-chain interaction response comprising a cryptocurrency custodian computer cryptographic signature, wherein the second off-chain interaction request occurs in a second off- chain interaction channel between the hub computer and the cryptocurrency custodian computer, the second off-chain interaction channel formed at least by a second initial recordation between the hub computer and the cryptocurrency custodian computer on the blockchain managed by the blockchain network” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Ravinathan (US 20210406871).
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 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 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.
Claims 1-5, 7-9, 11-13, 15-20, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Dunlevy (US 20170372300) in view of Fletcher (US 20200211003) in further view of Ravinathan (US 20210406871).
Regarding Claims 1 and 9, Dunlevy teaches a processor; and a non-transitory computer readable medium coupled to the processor, the non-transitory computer readable medium comprising code, executable by the processor, for performing steps ("[0028] As shown in FIG. 3, the registration processes 300 may include the smart-contract 106 registering with an off-chain host system 104 by calling an off-chain resource proxy smart-contract (FIG. 5-OffChainHostSystemProxy) method that passes in the address of the smart-contract itself (process 1 in FIG. 3 and register(walletAddress) in FIG. 5 when the smart contract is a consumer wallet use case) and receives via the resource proxy smart-contract (FIG. 5-respondTo(walletAddress, tokenSignature, token)) a unique token that is digitally signed by the off-chain host system 104 to provide data or side-effects. The token and signature are cryptographically verified (process 3 in FIG. 3) by the smart-contract 106 to validate the source of the off-chain access token (FIG. 6-verifyTokenSignature(tokenSignature)). [0029] As part of the registration process shown in FIG. 3, the off-chain host system 104 watches the blockchain transaction log (using a known process that may be performed by the transaction manager element of the off-chain host system 104) for events (such as register (walletAddress) shown in FIG. 3) created by the specific proxy smart-contract representing the off-chain resource. The off-chain host system 104 may then find the off-chain system account associated with the passed in blockchain wallet account address or creates a new off-chain system account and associates the passed in blockchain wallet address with the existing or new off-chain system account (as shown in FIG. 3, process 2.1-findOrCreateAccount(walletAddress)). The off-chain host system 104 may then generate a unique token (as shown in FIG. 3, process 2.2-createTokenFor(walletAddress)) and generate a digital signature of the token using the private key of the blockchain account (address of the proxy smart-contract) associated with the off-chain system (as shown in FIG. 3, process 2.3-signToken( ). The off-chain host system 104 may then store the token with the associated on-chain account address of the requesting smart-contract by invoking the proxy smart-contract with the smart-contract wallet address received, the token signature and the token (as shown in FIG. 5-respondTo(walletAddress, tokenSignature, token)). The proxy smart-contract may then invoke the smart-contract to save the token (as shown in FIG. 3-saveToken(tokenSignature, token) process)."); receiving, by a hub computer, an access token and an interaction value in an interaction (See Dunlevy in [0028]-[0029]); determining, by the hub computer, a cryptocurrency issuer address using the access token, the cryptocurrency issuer address associated with a cryptocurrency issuer computer (See Dunlevy in [0028]-[0029]); transmitting, by the hub computer, to the cryptocurrency issuer computer, a first off-chain interaction request comprising the interaction value (See Dunlevy in [0028]-[0029]); transmitting, by the hub computer, an authorization response message for the interaction ("Once the off-chain host system 104 has verified that the request is valid, the off-chain host system 104 may satisfy the data request or execute the desired side-effect/action (as shown in FIG. 4, process 4.1-processRequest(requestData.request_method) and generate a response, responseData (an example of which is shown in FIG. 11), which includes the requestData (responseData.request). The off-chain host system 104 may also generate a corresponding digital signature (responseData.data_signature) for the response payload (responseData.response_data) concatenated with the correlation identifier (requestData.correlation_id) of the request using the private key of the blockchain account for the off-chain system (as shown in FIG. 4, process 4.2-signResponse( ). The off-chain host system 104 may then initiate a blockchain transaction (FIG. 4, process 5-sendResponse(signedData) and FIG. 6-offChainResponse(responseData)) targeted to the address of the requesting smart-contract. In the blockchain transaction, the data parameter passed back to the requestor (responseData.response_data) is a use-case specific data element (generated in step 4 shown in FIG. 4 above)" See Dunlevy in [0033]).
However, Dunlevy does not explicitly teach receiving, by the hub computer, from the cryptocurrency issuer computer, a first off-chain interaction response comprising a cryptocurrency issuer computer cryptographic signature, wherein the first off-chain interaction request occurs in a first off-chain interaction channel between the hub computer and the cryptocurrency issuer computer, the first off-chain interaction channel formed by at least a first initial recordation between the hub computer and the cryptocurrency issuer computer on a blockchain.
Fletcher from the same or similar field of endeavor teaches receiving, by the hub computer, from the cryptocurrency issuer computer, a first off-chain interaction response comprising a cryptocurrency issuer computer cryptographic signature, wherein the first off-chain interaction request occurs in a first off-chain interaction channel between the hub computer and the cryptocurrency issuer computer, the first off-chain interaction channel formed by at least a first initial recordation between the hub computer and the cryptocurrency issuer computer on a blockchain ("To accommodate higher transaction volumes, off-chain (i.e., off-blockchain) payment channels have been proposed. For example, an off-chain payment channel called the "Lightning Network" is described by Poon and Dryja in "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments", Jan. 14, 2016. The Lightning Network allows transactions of value to occur off-blockchain. The Lightning Network describes a technique in which, in the event of certain uncooperative or hostile behavior off-chain after a payment channel has been opened, half-signed commitment transactions previously exchanged off-chain can be fully signed and broadcast on the blockchain." See Fletcher in [0007]; "[0052] The congress 110 may be used to facilitate setup of an off-blockchain payment channel 120 between nodes. This off-blockchain payment channel may be referred to herein as an off-chain payment channel, an off-chain channel, or a payment channel. The payment channel allows for the exchange of value off of the blockchain. The payment channel allows the current state of the payment channel (i.e., the respective balances of the nodes involved in the payment channel) to be committed to the blockchain at any time. That is, the parties may transfer value in multiple off-blockchain transactions and may, at some point, update the blockchain to reflect the final state of the payment channel. [0053] In the example embodiment, a payment channel 120 is set up between two nodes-a first node 102a and a second node 102b. While FIG. 1 illustrates a single payment channel, in practice numerous payment channels may be set up between nodes. For example, the first node 102a or the second node 102b may be a hub. The hub may connect to other nodes to provide a hub and spoke (HAS) arrangement in which a central hub (such as the first node 102a) establishes payment channels with both a second node 102b and another node (such as a third node, etc.). This HAS arrangement allows any node connected to the hub to transfer value off-chain to any other nodes connected to that hub or to receive value off-chain from any other nodes connected to the hub. For example, the second node 102b may transfer value to or receive value from the third node off-chain." See Fletcher in [0052]-[0053]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified Dunlevy to incorporate the teachings of Fletcher to receive, by the hub computer, from the cryptocurrency issuer computer, a first off-chain interaction response comprising a cryptocurrency issuer computer cryptographic signature, wherein the first off-chain interaction request occurs in a first off-chain interaction channel between the hub computer and the cryptocurrency issuer computer, the first off-chain interaction channel formed by at least a first initial recordation between the hub computer and the cryptocurrency issuer computer on a blockchain.
There is motivation to combine Fletcher into Dunlevy because the system enables the secure transfer from one node to another, as part of securing a record in a blockchain.
However, the combination of Dunlevy and Fletcher does not explicitly teach receiving, by a hub computer from a processing network computer, a resource provider identifier, and an interaction value in an interaction between a resource provider associated with the resource provider identifier and a user operating a mobile device; transmitting, by the hub computer to the processing network computer, an authorization response message for the interaction, wherein the method further comprises: determining, by the hub computer, a cryptocurrency custodian computer based on the resource provider identifier; transmitting, by the hub computer, to the cryptocurrency custodian computer, a second off-chain interaction request comprising the interaction value, the resource provider identifier, and a second hub computer cryptographic signature ; and receiving, by the hub computer, from the cryptocurrency custodian computer, a second off-chain interaction response comprising a cryptocurrency custodian computer cryptographic signature, wherein the second off-chain interaction request occurs in a second off-chain interaction channel between the hub computer and the cryptocurrency custodian computer, the second off-chain interaction channel formed at least by a second initial recordation between the hub computer and the cryptocurrency custodian computer on the blockchain managed by the blockchain network.
Ravinathan from same or similar field of endeavor teaches receiving, by a hub computer from a processing network computer, a resource provider identifier, and an interaction value in an interaction between a resource provider associated with the resource provider identifier and a user operating a mobile device (Paragraphs 0054-0055 teach a point of sale device may read a payment card presented by the consumer for use in funding a fiat payment transaction; as part of the reading of the payment card, the point of sale device may obtain at least a transaction account number stored or otherwise encoded therein, and any other payment details that may be used in the processing of a fiat payment transaction; the point of sale device may submit an authorization request, or data for inclusion therein, to the issuer processing server via an acquirer processing server and the payment network; the authorization request may be formatted pursuant to one or more standards and include at least a transaction amount, the transaction account number, and a merchant identifier associated with the point of sale device; the receiving device of the issuer processing server may receive the authorization request, which may be routed to the issuer processing server by the payment network using payment rails thereof); transmitting, by the hub computer to the processing network computer, an authorization response message for the interaction, wherein the method further comprises: determining, by the hub computer, a cryptocurrency custodian computer based on the resource provider identifier (Paragraphs 0053 and 0055 teach the point of sale device may register itself as a blockchain wallet with the exchange server for the receipt of alternative payments for a fiat payment transaction through cryptocurrency in a blockchain network; as part of the registration, the point of sale device may provide a merchant identifier and public key of a blockchain wallet to the exchange server; the exchange server may receive the merchant identifier and public key and store the merchant identifier and public key therein, such as in a profile associated with the merchant and/or point of sale device; the querying module of the issuer processing server may execute a query on the account database thereof to identify an account profile stored therein that is associated with the transaction account used by the consumer, identified using the transaction account number included in the authorization request; the account profile may indicate that the consumer has accepted payment via blockchain); transmitting, by the hub computer, to the cryptocurrency custodian computer, a second off-chain interaction request comprising the interaction value, the resource provider identifier, and a second hub computer cryptographic signature (Paragraphs 0055-0057 and 0036 teach the transmitting device of the issuer processing server may electronically transmit a data request to the exchange server using a suitable communication network and method, where the data request includes the merchant identifier included in the received authorization request; the exchange server may receive the data request with the merchant identifier included therein; the exchange server may identify that the merchant associated with the merchant identifier has previously registered to accept blockchain payments and provided their public key and may generate a recipient blockchain address using the public key; the exchange server may electronically transmit the generated recipient blockchain address back to the issuer processing server as a response to the data request; the response may also include a network identifier associated with the blockchain network; the receiving device of the issuer processing server may receive the data request; the transmitting device of the issuer processing server may electronically transmit a new blockchain transaction to a node in the blockchain network; the new blockchain transaction may include at least a digital signature (e.g., generated by the generation module of the issuer processing server using a private key in the identified account profile), one or more unspent transaction outputs, the recipient blockchain address, and a cryptocurrency amount based on the transaction amount; the blockchain network may receive the new blockchain transaction; the blockchain node may confirm the new blockchain transaction and include it in a new block that is generated, confirmed by other nodes in the blockchain network, and added to the blockchain; the blockchain network may provide a notification of successful processing of the blockchain transaction to the issuer processing server, which may include the transaction identifier; the blockchain transaction may include the cryptocurrency amount, the blockchain address for receipt by the merchant, one or more unspent transaction outputs, and a digital signature generated using the private key of the blockchain wallet from which payment is being made; the blockchain transaction may include the cryptocurrency amount, the blockchain address for receipt by the merchant, one or more unspent transaction outputs, and a digital signature generated using the private key of the blockchain wallet from which payment is being made); and receiving, by the hub computer, from the cryptocurrency custodian computer, a second off-chain interaction response comprising a cryptocurrency custodian computer cryptographic signature, wherein the second off-chain interaction request occurs in a second off-chain interaction channel between the hub computer and the cryptocurrency custodian computer, the second off-chain interaction channel formed at least by a second initial recordation between the hub computer and the cryptocurrency custodian computer on the blockchain managed by the blockchain network (Paragraphs 0058 and 0062 teach the receiving device of the issuer processing server may receive the transaction identifier from the blockchain network; the transmitting device of the issuer processing server may electronically transmit the transaction identifier for the blockchain data value to the exchange server as a reporting of the successful processing of the blockchain transaction; the exchange server may receive the transaction identifier; the exchange server may then transmit a notification to the point of sale device regarding successful payment for the fiat payment transaction via the blockchain transaction, and may include the transaction identifier or other data.; may further include identifying, by the processor of the processing server, a private key of a cryptographic key pair; and generating, by the processor of the processing server, the digital signature using the private key; the authorization response may be formatted pursuant to a standard governing the exchange of financial transaction messages).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy and Fletcher to incorporate the teachings of Ravinathan to transmit, by the cryptocurrency issuer computer, to the hub computer, an off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature.
There is motivation to combine Ravinathan into the combination of Dunlevy and Fletcher because the system enables a consumer to use blockchain to pay for a transaction while utilizing legacy point of sale systems (Ravinathan Paragraph 0003).
Regarding Claim 17, Dunlevy teaches receiving, by a cryptocurrency issuer computer, an off-chain interaction request comprising an interaction value from a hub computer interacting with a processing network computer in communication with an access device, wherein the hub computer determines the cryptocurrency issuer computer using an access token that is transmitted from the access device to the hub computer, and wherein the off-chain interaction request occurs in an off-chain interaction channel between the hub computer and the cryptocurrency issuer computer, the off-chain interaction channel formed by at least an initial recordation between the hub computer and the cryptocurrency issuer computer on a blockchain managed by a blockchain network (See Dunlevy in [0028]-[0029]); signing, by the cryptocurrency issuer computer, interaction data including the interaction value to form a cryptocurrency issuer computer cryptographic signature (See Dunlevy in [0028]-[0029]); transmitting, by the cryptocurrency issuer computer, a confirmation message to an application on the mobile device for an interaction between the mobile device and the access device (See Dunlevy in [0034]).
However, Dunlevy does not explicitly teach transmitting, by the cryptocurrency issuer computer, to the hub computer, an off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature.
Fletcher from same or similar field of endeavor teaches transmitting, by the cryptocurrency issuer computer, to the hub computer, an off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature (See Fletcher in [0007], and [0052]-[0053]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified Dunlevy to incorporate the teachings of Fletcher to transmit, by the cryptocurrency issuer computer, to the hub computer, an off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature.
There is motivation to combine Fletcher into Dunlevy because to secure the transfer from one node to another, as part of securing a record in a blockchain.
However, the combination of Dunlevy and Fletcher does not explicitly teach receiving, by a cryptocurrency issuer computer, an off-chain interaction request comprising an interaction value from a hub computer interacting with a processing network computer in communication with an access device, the interaction value received by the hub computer via the processing network computer from the access device operated by a resource provider interacting with a mobile device operated by a user.
Ravinathan from same or similar field of endeavor teaches receiving, by a cryptocurrency issuer computer, an off-chain interaction request comprising an interaction value from a hub computer interacting with a processing network computer in communication with an access device, the interaction value received by the hub computer via the processing network computer from the access device operated by a resource provider interacting with a mobile device operated by a user (Paragraphs 0054-0055 teach a point of sale device may read a payment card presented by the consumer for use in funding a fiat payment transaction; as part of the reading of the payment card, the point of sale device may obtain at least a transaction account number stored or otherwise encoded therein, and any other payment details that may be used in the processing of a fiat payment transaction; the point of sale device may submit an authorization request, or data for inclusion therein, to the issuer processing server via an acquirer processing server and the payment network; the authorization request may be formatted pursuant to one or more standards and include at least a transaction amount, the transaction account number, and a merchant identifier associated with the point of sale device; the receiving device of the issuer processing server may receive the authorization request, which may be routed to the issuer processing server by the payment network using payment rails thereof).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy and Fletcher to incorporate the teachings of Ravinathan to receive, by a cryptocurrency issuer computer, an off-chain interaction request comprising an interaction value from a hub computer interacting with a processing network computer in communication with an access device, the interaction value received by the hub computer via the processing network computer from the access device operated by a resource provider interacting with a mobile device operated by a user.
There is motivation to combine Ravinathan into the combination of Dunlevy and Fletcher because the system enables a consumer to use blockchain to pay for a transaction while utilizing legacy point of sale systems (Ravinathan Paragraph 0003).
Regarding Claim 2, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; and Dunlevy further teaches wherein the first off-chain interaction request comprises a request to authorize the interaction ("Once the off-chain host system 104 has verified that the request is valid, the off-chain host system 104 may satisfy the data request or execute the desired side-effect/action (as shown in FIG. 4, process 4.1-processRequest(requestData.request_method) and generate a response, responseData (an example of which is shown in FIG. 11), which includes the requestData (responseData.request). The off-chain host system 104 may also generate a corresponding digital signature (responseData.data_signature) for the response payload (responseData.response_data) concatenated with the correlation identifier (requestData.correlation_id) of the request using the private key of the blockchain account for the off-chain system (as shown in FIG. 4, process 4.2-signResponse( ). The off-chain host system 104 may then initiate a blockchain transaction (FIG. 4, process 5-sendResponse( signedData) and FIG. 6-offChainResponse(responseData)) targeted to the address of the requesting smart-contract. In the blockchain transaction, the data parameter passed back to the requestor (responseData.response_data) is a use-case specific data element (generated in step 4 shown in FIG. 4 above). Once the off-chain host system 104 has verified that the request is valid, the off-chain host system 104 may satisfy the data request or execute the desired side-effect/action (as shown in FIG. 4, process 4.1-processRequest(requestData.request_method) and generate a response, responseData (an example of which is shown in FIG. 11), which includes the requestData (responseData.request). The off-chain host system 104 may also generate a corresponding digital signature responseData.data_signature) for the response payload (responseData.response_data) concatenated with the correlation identifier (requestData.correlation_id) of the request using the private key of the blockchain account for the off-chain system (as shown in IG. 4, process 4.2-signResponse( ). The off-chain host system 104 may then initiate a blockchain transaction (FIG. 4, process 5-sendResponse( signedData) and FIG. 6-offChainResponse(responseData)) targeted to the address of the requesting smart-contract. In the blockchain transaction, the data parameter passed back to the requestor (responseData.response_data) is a use-case specific data element (generated in step 4 shown in FIG. 4 above)." See Dunlevy in [0033]).
Regarding Claim 3, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; and Dunlevy further teaches wherein the first off-chain interaction response comprises interaction data including at least the interaction value, and wherein the cryptocurrency issuer computer cryptographic signature corresponds to the interaction data (See Dunlevy in [0033]).
Regarding Claim 4, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; and Dunlevy further teaches wherein the first off-chain interaction request additionally comprises the access token (See Dunlevy in [0028]-[0029]).
Regarding Claim 5, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; and Dunlevy further teaches wherein the first off-chain interaction request additionally comprises a first hub computer cryptographic signature (See Dunlevy in [0028]-[0029]).
Regarding Claim 7, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; however, the combination does not explicitly teach transmitting, by the hub computer, to the cryptocurrency custodian computer, the first off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature.
Fletcher further teaches transmitting, by the hub computer, to the cryptocurrency custodian computer, the first off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature (See Fletcher in [0028]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the further teachings of Fletcher to transmit, by the hub computer, to the cryptocurrency custodian computer, the first off-chain interaction response comprising the cryptocurrency issuer computer cryptographic signature.
There is motivation to further combine Fletcher into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 1.
Regarding Claim 8, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; and Dunlevy further teaches wherein the cryptocurrency custodian computer is associated with an acquirer computer, which holds an account of the resource provider corresponding to the resource provider identifier, and wherein the access token is received by the hub computer from the acquirer computer via the processing network computer (See Dunlevy in [0033]-[0034]).
Regarding Claim 11, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 9 above; and Dunlevy further teaches prior to determining the cryptocurrency issuer address, determining, by the processing network computer, based on the access token that the interaction comprises a cryptocurrency-based interaction (See Dunlevy in [0028]-[0029]).
Regarding Claim 12, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 9 above; however, the combination does not explicitly teach closing the first off-chain interaction channel by broadcasting a closing recordation to the blockchain.
Fletcher further teaches closing the first off-chain interaction channel by broadcasting a closing recordation to the blockchain ("At operation 310, in response to detecting confirmation of the second funding transaction and the first funding transaction, the node 102 may broadcast a first encapsulated commitment transaction. The first encapsulated commitment transaction is a transaction for nominal digital assets (e.g., digital assets only sufficient to cover mining fees to have the transaction added to the blockchain). The purpose of the first encapsulated commitment transaction is not to exchange value (i.e., to transfer digital assets to another party), but rather to act as a public record of a commitment transaction. A commitment transaction is a record of a state of a payment channel and allows a node to close a channel and receive digital assets back if another party were to become uncooperative. More particularly, a commitment transaction records current balances of the parties to a payment channel. The first encapsulated commitment transaction is a transaction which includes a commitment transaction (i.e., an initial commitment transaction) as metadata. Commitment transactions are configured so that the party receiving the commitment transaction may, at any point, sign and broadcast the commitment transaction to the blockchain network to commit the current state of the payment channel to the blockchain. That is, commitment transactions may be continually exchanged by the parties in a payment channel off-chain and, at any point one of those parties may add their signature to the commitment transaction and broadcast it to attempt to commit the current state of the payment channel to the blockchain." See Fletcher in [0085]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the further teachings of Fletcher to close the first off-chain interaction channel by broadcasting a closing recordation to the blockchain.
There is motivation to further combine Fletcher into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 9.
Regarding Claim 13, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 9 above; and Dunlevy further teaches wherein the access token is stored in the processing network computer, and the mobile device (See Dunlevy in [0028]-[0029]).
Regarding Claim 15, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 13 above; however, the combination does not explicitly teach wherein the non-transitory computer readable medium further comprises a blockchain/off-chain module.
Fletcher further teaches wherein the non-transitory computer readable medium further comprises a blockchain/off-chain module (See Fletcher in [0052]-[0053] and [0055]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the further teachings of Fletcher for the non-transitory computer readable medium further to comprise a blockchain/off-chain module.
There is motivation to further combine Fletcher into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 9.
Regarding Claim 16, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 13 above; however, the combination does not explicitly teach wherein the access token and the interaction value are received from the processing network computer after communicating with an access device, and wherein the hub computer transmits the authorization response message to the access device via the processing network computer.
Fletcher further teaches wherein the access token and the interaction value are received from the processing network computer after communicating with an access device, and wherein the hub computer transmits the authorization response message to the access device via the processing network computer (See Fletcher in [0053] and [0055]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the further teachings of Fletcher for the access token and the interaction value to be received from the processing network computer after communicating with an access device, and wherein the hub computer transmits the authorization response message to the access device via the processing network computer.
There is motivation to further combine Fletcher into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 9.
Regarding Claim 18, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 17 above; however, the combination does not explicitly teach receiving, by the cryptocurrency issuer computer, a communication comprising an initial value from the application on the mobile device of the user for interaction, the application associated with the cryptocurrency issuer computer, wherein the initial value is equal to the interaction value.
Fletcher further teaches receiving, by the cryptocurrency issuer computer, a communication comprising an initial value from the application on the mobile device of the user for interaction, the application associated with the cryptocurrency issuer computer, wherein the initial value is equal to the interaction value (See Fletcher in [0052]-[0053] and [0055]).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the further teachings of Fletcher to receive, by the cryptocurrency issuer computer, a communication comprising an initial value from the application on the mobile device of the user for interaction, the application associated with the cryptocurrency issuer computer, wherein the initial value is equal to the interaction value.
There is motivation to further combine Fletcher into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 17.
Regarding Claim 19, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 17 above; and Dunlevy further teaches transmitting, by the cryptocurrency issuer computer, a request for a digital wallet license to the processing network computer (See Dunlevy in [0028]); receiving, by the cryptocurrency issuer computer, from the processing network computer, the digital wallet license ("In the system 100 in FIG. 1, the blockchain system 102 may interact with each off-chain host system 104. Each off-chain host system 104 is a system that is not part of the blockchain system 102 and does not host the distributed blockchain ledger. However, it is desirable to be able to permit the blockchain smart contract to interact with one or more of the off-chain host systems in order to: 1) retrieve data from an off-chain host system (such as third party data inputs); and/or 2) cause real-world side-effects (resource actions) that are carried out by the off-chain host system 104. For example, as described below with reference to FIGS. 7-9 in more detail, the data that is accessed by the smart contract may be private healthcare data of a consumer that is stored/hosted on a third party system that is not part of the blockchain system or healthcare ASC X12N 5010 transaction data that is stored/hosted on a third party system that is not part of the blockchain system. As another example that is below with reference to FIGS. 7-9 in more detail, the resource action may be an action to be taken by a third party system of the off-chain system based on the interaction with the blockchain system 102." See Dunlevy in [0021]); obtaining, by the cryptocurrency issuer computer, the access token associated with a user account of the user operating the mobile device (See Dunlevy in [0028]).
Regarding Claim 20, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 17 above; and Dunlevy further teaches wherein the off-chain interaction request additionally comprises the access token, and wherein the method further comprises: identifying, by the cryptocurrency issuer computer, a user account corresponding to the access token and the mobile device (See Dunlevy in [0028]-[0029); and subtracting, by the cryptocurrency issuer computer, the interaction value from an account value associated with the user account (See Dunlevy in [0033]).
Regarding Claim 22, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein the processing network computer forwards the authorization response message to an access device operated by the resource provider.
Ravinathan further teaches wherein the processing network computer forwards the authorization response message to an access device operated by the resource provider (Paragraph 0058 teaches the transmitting device of the issuer processing server may electronically transmit an authorization response for the fiat payment transaction to the point of sale device, as routed through the payment network and the payment rails thereof; the point of sale device may receive the authorization response).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the further teachings of Ravinathan for the processing network computer to forward the authorization response message to an access device operated by the resource provider.
There is motivation to further combine Ravinathan into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 1.
Claim 21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Dunlevy (US 20170372300) in view of Fletcher (US 20200211003) in further view of Ravinathan (US 20210406871) in further view of Gaur (US 20220172198).
Regarding Claim 21, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein prior to receiving the access token, the processing network computer receives an authorization request message comprising a cryptogram, decrypts the cryptogram, and determines the access token based on the decrypted cryptogram.
Gaur from same or similar field of endeavor teaches wherein prior to receiving the access token, the processing network computer receives an authorization request message comprising a cryptogram, decrypts the cryptogram, and determines the access token based on the decrypted cryptogram (Paragraphs 0086-0087 teach receiving, via a payment network, a request to detokenize a payment token to process a payment transaction between a source and a target; for example, the request may be received via an entity (e.g., acquirer, payment gateway, payment processor, etc.) of a payment network; the payment token may be an EMV payment token storing transaction details between a consumer (e.g., mobile wallet) and a merchant; the method may include detokenizing the payment token based on mapping data stored in a token vault; the detokenizing of the payment token may decrypt the details of the payment card (e.g., PAN, expiry, etc.), and also reveal the transaction details, attributes of the payment token (e.g., type, denomination, etc.); the method may further include transmitting information about the detokenized payment token to a computing device associated with the request to process the payment transaction via the payment network).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the teachings of Guar for prior to receiving the access token, the processing network computer to receive an authorization request message comprising a cryptogram, decrypts the cryptogram, and determines the access token based on the decrypted cryptogram.
There is motivation to combine Guar into the combination of Dunlevy, Fletcher, and Ravinathan because the blockchain settlement network which runs parallel to a payment network, which enables a payment transaction to be settled in real-time rather than a traditional overnight settlement process (Gaur Paragraph 0028).
Regarding Claim 23, the combination of Dunlevy, Fletcher, and Ravinathan teaches all the limitations of claim 22 above; however, the combination does not explicitly teach wherein the processing network computer receives the interaction value and the resource provider identifier from the access device before the hub computer receives the access token, the resource provider identifier, and the interaction value from the processing network computer.
Guar from same or similar field of endeavor teaches wherein the processing network computer receives the interaction value and the resource provider identifier from the access device before the hub computer receives the access token, the resource provider identifier, and the interaction value from the processing network computer (Paragraph 0083-0084 teach the merchant terminal transmits the transaction details to an acquiring bank of the merchant; in response, the payment network transmits a detokenization request to the TSP; the TSP may detokenize the payment token based on mapping information stored in the token vault and transmit payment card (PAN, expiry, etc.) to the payment network for further processing of the transaction; here, the acquirer may submit a transaction authorization request to an issuer of the payment card, and receive an authorization response from the issuer; the acquirer transmits the response results (approve/deny) to the merchant terminal to finalize the payment transaction with the user; in parallel with the payment transaction being processed on the payment network, the TSP can trigger a settlement process on a blockchain settlement network at the same time; the TSP can extract data from the payment token (including detokenized data) and data of the source (issuer) and the target (acquirer) and input the information into a settlement token; in other words, the detokenization request from the payment network may simultaneously trigger detokenization of the payment token, and initiating of a settlement process on a separate and independent blockchain settlement network; furthermore, the TSP may transmit the settlement token to a blockchain peer of the blockchain settlement network).
It would have been prima facie obvious to one or ordinary skill in the art
before the effective filing date of the claimed invention to have modified the combination of Dunlevy, Fletcher, and Ravinathan to incorporate the teachings of Guar for the processing network computer to receive the interaction value and the resource provider identifier from the access device before the hub computer receives the access token, the resource provider identifier, and the interaction value from the processing network computer.
There is motivation to combine Guar into the combination of Dunlevy, Fletcher, and Ravinathan because of the same reasons listed above for claim 21.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Balaraman et al. (US 20190164157) teaches systems and methods for transaction authorizations using a distributed database are disclosed. The system may allow registered transaction account holders and merchants to interact and complete transactions according to workflows enforced by smart contracts. The system may include an issuer system that receives a transaction authorization request comprising a merchant ID, a transaction account number, a transaction amount, and a transaction ID. The issuer system may retrieve a merchant public key and a smart contract based on the merchant ID, and a user public key based on the transaction account number. The issuer system may invoke the smart contract by passing the user public key and the transaction ID to the smart contract. The system may propagate transaction data (e.g., the merchant ID, the transaction account number, the payment amount, a transaction status, etc.) to a blockchain network for writing to a blockchain according to the invoked smart contract.
Yan (US 20210398091) teaches systems and methods are provided for processing credit token and debit token based transactions in a blockchain supported network.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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 at (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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights