Acknowledgements
This communication is in response to applicant’s response filed on 06/13/2026.
Claims 4-5, 11-12, and 17-18 have been amended. Claims 6, 13, and 19 have been cancelled.
Claims 1-5, 7-12, 14-18, and 20-22 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. 8-10, filed 06/13/2026, with respect to the rejection(s) of claims 1, 8, and 15 under Claim Rejections - 35 USC § 102 that Leong does not teach a distributed ledger node providing a payload to an off-chain system that includes instructions for completing an action on the distributed ledger as claimed, specifically, Leong does not disclose either “pushing, by the node, the payload [that includes instructions that are executable on the distributed ledger]) to an off-ledger system” or “responsive to receiving the digital signature of the second party applied to the instructions [from the off-ledger system], executing the instructions in the payload, by the node,” as claimed have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is in view of Dunlevy (US 20170372300).
Claim Rejections - 35 USC § 102(a)(1)
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 8-12, 15-18, and 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dunlevy (US 20170372300).
Regarding Claims 1, 8, and 15, Dunlevy teaches generating, by a node of a distributed ledger operated by a first party, a payload including instructions that are executable on the distributed ledger for completing an action on the distributed ledger on behalf of a second party, wherein the second party does not operate a node of the distributed ledger (Paragraph 0032 teaches in an invocation process, a smart contract may publish a transaction targeted to the off-chain host system (as shown in FIG. 4 process 1—createRequestEvent (Requestdata) and FIG. 6—OffChainRequest(requestData)) with a request for data or a side-effect, where the request data (an example of which is shown in FIG. 10) includes the request method itself (must include: requestData.request_uri, and may include: requestData.request_method, and/or requestData.request_data), the contract's token (requestData.contract_auth_token), a timestamp (unixtime, number of seconds since Jan. 1, 1970 UTC, with some number of least significant digits zeroed out, requestData.request_time), and a correlation identifier (a unique identifier, may be a UUID as defined by IETF RFC 4122, requestData.correlation_id); in one embodiment, the request method may be the URI of an idempotent system specific request/response; during the invocation method, the off-chain host system may watch a blockchain transaction log for events (as shown in FIG. 5—Request(senderAddress, requestData) and FIG. 4, process 2—filterForRequests( ) created by the specific proxy smart-contract representing the off-chain resource that was determined by the registration method described above); pushing, by the node, the payload to an off-ledger system associated with the second party (Paragraph 0032 teaches the off-chain host system may receive the request, verifies that the sender address is associated with the off-chain system account and passed in token in the request (as shown in FIG. 4, process 3.1—verifySenderToken(token, senderAddress), and checks that the timestamp of the request has not been exceeded (as shown in FIG. 4, process 3.2—verifyTimestamp(requestData.request_time))); receiving, from the off-ledger system, a digital signature of the second party applied to the instructions (Paragraph 0033 teaches once the off-chain host system has verified that the request is valid, the off-chain host system 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 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 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)); and responsive to receiving the digital signature of the second party applied to the instructions, executing the instructions in the payload, by the node operated by the first party, thereby implementing the action on the distributed ledger on behalf of the second party using the instructions (Paragraph 0034 teaches once the response is received by the smart-contract, it may verify that the signature (responseData.data_signature) corresponds to the data (responseData.response_data) and the correlation identifier of the request (responseData.request.correlation_id) and was signed by the key associated with the on-chain wallet address of the off-chain host system (as shown in FIG. 4, process 6—verifyDataSigner(signedData) and FIG. 6—offChainResponse(responseData)); the above method provides a deterministic and cryptographically verifiable chain of transactions, recorded on a blockchain (distributed ledger) system with irrefutable public accounting of the transactions involved in incorporating on-chain contract execution with off-chain data and side-effects (resource actions)).
Regarding Claim 1, Dunlevy teaches a computer-implemented method (Paragraph 0031 teaches FIG. 4 illustrates an example of a smart contract invocation process of off-chain resources in an example in which the smart contract is a consumer wallet; the process may be implemented using the same off-chain host system and the blockchain smart contract already described above in FIG. 3; the invocation processes shown in FIG. 4 may be performed by the off-chain host system or the blockchain smart contract, a combination of both of these systems or by a separate invocation system or management element that is coupled to both of the systems).
Regarding Claim 8, Dunlevy teaches one or more non-transitory computer-readable media comprising stored instructions that, when executed, a computing system comprising a node of a distributed ledger operated by a first party and an off-ledger system associated with a second party, cause the computing system to perform operations (Paragraphs 0056-0057 teach aspects of the system and method may be achieved via or performed by logic and/or logic instructions including program modules, executed in association with such components or circuitry, for example; in general, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein; the inventions may also be practiced in the context of distributed software, computer, or circuit settings where circuitry is connected via communication buses, circuitry or links; the software, circuitry and components herein may also include and/or utilize one or more type of computer readable media; computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and/or computing components; by way of example, and not limitation, computer readable media may comprise computer storage media and communication media; computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data).
Regarding Claim 15, Dunlevy teaches a computing system comprising: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the computing system to perform operations (Paragraphs 0023 and 0031 teach in the system, each of the blockchain system and off-chain host system may, in one embodiment, have at least one processor that may be used to execute a plurality of instructions or computer code that implement the methods described below with reference to FIGS. 3-4; the invocation processes shown in FIG. 4 may be implemented in hardware or software; when the invocation processes are implemented in software, the invocation processes may be a plurality of lines of instructions or computer code that may be executed by a processor associated with the off-chain host system, the blockchain smart contract, a combination of both of these systems, a separate invocation system of the transaction manager element so that the processor is thus configured to perform the invocation processes).
Regarding Claims 2, 9, and 21, Dunlevy teaches all the limitations of claims 1, 8, and 15; and Dunlevy further teaches wherein the distributed ledger is a blockchain (Paragraph 0020 teaches the block chain system may have one or more computing resources, such as one or more server computers, that are part of the block chain system and host the well-known distributed blockchain ledger system (an example of which is shown in FIG. 2)).
Regarding Claims 3, 10, and 16, Dunlevy teaches all the limitations of claims 1, 8, and 15; and Dunlevy further teaches storing the digital signature and instructions for completing the action in a smart contract on the distributed ledger (Paragraphs 0033-0034 teach the off-chain host system 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 response is received by the smart-contract, it may verify that the signature (responseData.data_signature) corresponds to the data (responseData.response_data) and the correlation identifier of the request (responseData.request.correlation_id) and was signed by the key associated with the on-chain wallet address of the off-chain host system (as shown in FIG. 4, process 6—verifyDataSigner(signedData) and FIG. 6—offChainResponse(responseData))).
Regarding Claims 4, 11, and 17, Dunlevy teaches all the limitations of claims 3, 10, and 16; and Dunlevy further teaches validating, by the off-ledger system, that the implementation of the action matches an intent of the second party using the information about the action stored in the smart contract on the distributed ledger (Paragraph 0032-0033 teach the off-chain host system may receive the request, verifies that the sender address is associated with the off-chain system account and passed in token in the request (as shown in FIG. 4, process 3.1—verifySenderToken(token, senderAddress), and checks that the timestamp of the request has not been exceeded (as shown in FIG. 4, process 3.2—verifyTimestamp(requestData.request_time)); once the off-chain host system has verified that the request is valid, the off-chain host system 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)).
Regarding Claims 5, 12, and 18, Dunlevy teaches all the limitations of claims 4, 11, and 17; and Dunlevy further teaches wherein validating the implementation of the action comprises verifying that the digital signature of the second party is valid for the information about the action stored in the smart contract, thereby indicating that there is no variation between the instructions that were signed off-chain and the information about the action stores in the smart contract (Paragraph 0034 teaches once the response is received by the smart-contract, it may verify that the signature (responseData.data_signature) corresponds to the data (responseData.response_data) and the correlation identifier of the request (responseData.request.correlation_id) and was signed by the key associated with the on-chain wallet address of the off-chain host system (as shown in FIG. 4, process 6—verifyDataSigner(signedData) and FIG. 6—offChainResponse(responseData); the above method provides a deterministic and cryptographically verifiable chain of transactions, recorded on a blockchain (distributed ledger) system with irrefutable public accounting of the transactions involved in incorporating on-chain contract execution with off-chain data and side-effects (resource actions)).
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.
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 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dunlevy (US 20170372300) in view of Coleman (US 20250077625).
Regarding Claims 7, 14, and 20, Dunlevy teaches all the limitations of claims 1, 8, and 15; however, Dunlevy does not explicitly teach wherein receiving the digital signature of the party comprises retrieving the digital signature using a webhook of the off-ledger system.
Coleman from same or similar field of endeavor teaches wherein receiving the digital signature of the party comprises retrieving the digital signature using a webhook of the off-ledger system (Paragraph 0175 teaches upon successful storage of the electronically signed document contract, electronic signature system triggers a notification event to inform smart contract generation system about the completed signing process and the location of the document at the off-chain address; the electronic signature system sends the notification to smart contract generation system through a predefined communication channel, such as a webhook; the notification includes relevant details, such as the off-chain address where the document contract is stored, and any additional metadata associated with the document).
It would have been prima facie obvious to one of ordinary skill in the art
before the effective filing data of the claimed invention to have modified Dunlevy to
incorporate the teachings of Coleman for a master relay identifier to be generated as a result of the relay of the single relay amount.
There is motivation to combine Coleman into Dunlevy because this integration allows the smart contract to reference and access the electronically signed digital document contract during its execution. By sending a notification to smart contract generation system with the off-chain address and associated metadata, electronic signature system enables the seamless integration of the electronically signed digital document contract into the smart contract ecosystem. This integration ensures that the smart contract can refer to and utilize the signed document as needed, providing a comprehensive and reliable framework for enforcing the rights and conditions outlined in the contract (Coleman Paragraph 0175).
Examiner Note: The provisional applications do not teach the concept of “receiving the digital signature of the party comprises retrieving the digital signature using a webhook of the off-ledger system” recited in claims 7, 14, and 20. The prior art was effectively filed before the effective filing date of the instant claims 10/23/2023.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Dunlevy (US 20170372300) in view of Martin (US 20210243036).
Regarding Claim 22, Dunlevy teaches all the limitations of claim 1; however, Dunlevy does not explicitly teach wherein the payload is an application programming interface (API) payload.
Martin further teaches wherein the payload is an application programming interface (API) payload (Paragraph 0028 and 0030 teach FIG. 2 shows example data flows and interactions between a blockchain network and other systems and networks during processing of a communication directed to an off-chain user device via on-chain logic of a carrier system; a message origin on the blockchain network may generate blockchain message data; the blockchain message data may represent an application programming interface (“API”) request to send a telephony-based message to the user device; the message origin may include on-chain logic, such as a smart contract that monitors for some event and transfers value to an account of the user in response to occurrence of the event; the blockchain message data may also include a payload, such as data representing an API request to executed by the carrier system).
It would have been prima facie obvious to one of ordinary skill in the art
before the effective filing data of the claimed invention to have modified Dunlevy to
incorporate the teachings of Martin for the payload to be an application programming interface (API) payload.
There is motivation to combine Martin into Dunlevy because the user device may be a mobile phone that has access to the telephony network, and a user of the user device may have an account on the blockchain network. The user may wish to receive messages that originate from the blockchain network or are otherwise transmitted via the blockchain network, such as messages confirming the transfer of value from one account to another account (Martin Paragraph 0029).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kulkarni et al. (US 20220084013) teaches a user information system, a transaction machine instructions generator to produce machine instructions of a blockchain transaction, a signing module, a blockchain communications system that sends system-signed messages to a blockchain system, and a transaction mediating system that receives user input comprising a transaction data structure representing the blockchain transaction. The transaction mediating system can send machine instructions to other elements of the system in response to user input and machine instructions of the blockchain transaction for execution on a blockchain system. The signature module can generate a system-signed message with a digital signature associated with the digital asset system, (a) machine instructions of a transaction for execution on a blockchain system received from the transaction instructions generator or (b) a user-signed machine instructions of a transaction for execution on a blockchain system received from the transaction mediating system.
Meng et al. (CN110648228A) teaches an on-chain asset transfer system and method for settlement through on-chain digital currency, and relates to the technical field of digital assets. One embodiment of the system comprises: the asset application terminal system of the transferor generates an on-chain asset transfer instruction and then sends the instruction to the asset ledger system; the asset account book system executes a first intelligent contract in the asset transfer instruction on the chain to generate asset information to be transferred; the asset application terminal system of the receiving party generates a corresponding on-chain digital money transfer instruction and a synchronous transfer instruction of the assets to be transferred, and then the two instructions are sent to the asset account book system; the asset ledger system executes a second intelligent contract in the digital currency transfer instruction on the chain and a third intelligent contract in the synchronous transfer instruction of the assets to be transferred, completes the transfer of the digital currency on the chain and generates the transferred assets at the same time. The embodiment realizes the on-chain asset transfer process through on-chain digital currency settlement based on the intelligent contract, and reduces the transaction risk.
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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights