Acknowledgements
This communication is in response to applicant’s response filed on 01/15/2026.
Claims 1, 3-5, 8, 10-12, and 15-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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/15/2026 has been entered.
Response to Arguments
Regarding applicant’s arguments:
Applicant’s arguments, see pgs. 8-9, filed 01/15/2026, with respect to the rejection(s) of claims 1, 8, and 15 under Claim Rejections - 35 USC § 102 that Ozbay does not teach the amended limitations, specifically, “a payload including instructions that are executable on the distributed ledger for completing an action” is sent to an off-ledger system by a node of the distributed ledger, and that the instructions that were included in the payload are executed “responsive to receiving the digital signature of the second party applied to the instructions” 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 Leong (US 20200092106).
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 01/15/2026 and 09/18/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 Leong (US 20200092106).
Regarding Claims 1, 8, and 15, Leong 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 (Paragraphs 0062-0063, 0043, and 0037 teach a message flow takes place between a requestor, an off-chain entity, an on-chain entity and an authority as described with reference to FIGS. 1 and 2; a requestor, which may correspond to one of the data processing computers, an on-chain entity running a smart contract, initiates a transfer of an amount X from the off-chain entity; a 3rd party blockchain account is used to form a transaction request on behalf of an off-chain entity; the transaction request is formed with parameters provided by the off-chain entity; in order to confirm the transaction request originated from the off-chain entity, a digital signature from off-chain entity is included; an example of this is illustrated in the example of FIG. 4 at 406-408), wherein the second party does not operate a node of the distributed ledger (Paragraph 0028 teaches a user device may be an off-chain entity (e.g., an off-chain device), which is not part of the blockchain provider computer arrangement; an off-chain entity (e.g., device) may, for example, be understood as an entity (e.g., computing device), which is not involved in tasks related to the provision of the blockchain, for example an entity which does not generate new blocks of the blockchain, e.g. does not verify transactions or calculate hashes of blocks, while an on-chain entity may be understood as an entity (e.g., device) which performs such tasks); pushing, by the node, the payload to an off-ledger system associated with the second party (Paragraph 0063 teaches the requestor initiates a transfer of an amount X from the off-chain entity to a smart contract running on the on-chain entity by sending the request to the off-chain entity; the requestor may, for example, be the off-chain entity itself); receiving, from the off-ledger system, a digital signature of the second party applied to the instructions (Paragraphs 0064-0065 teaches the off-chain entity signs an indication of the request with its secret key and freezes (locks) the amount X of its credit, possibly under the condition that there are sufficient funds; the off-chain entity sends the digital signature and an indication of the request to the smart contract, e.g. by means of a Send message); 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 (Paragraphs 0066-0067 teach the smart contract may optionally check whether the digital signature is valid; if it the digital signature is valid (or if the smart contract does not perform a check of the digital signature of the request), an indication of the request is transmitted from the smart contract to the authority, e.g. by means of a Get message by the authority and the smart contract waits for approval from the authority; the message sent by the smart contract may include a value of an age parameter as described in context of FIG. 2; the message may also include the digital signature of the transaction request if a signature verification is performed by the authority).
Regarding Claim 1, Leong teaches a computer-implemented method (Paragraph 0061 teaches FIG. 4 shows a message flow diagram illustrating a message flow for an off-chain to on-chain transaction initiated by a requestor according to an aspect of the present disclosure).
Regarding Claim 8, Leong 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 (Paragraph 0025 teaches the blockchain provider computer arrangement may include multiple blockchain provider computers wherein each one includes components for data processing, such as a computer readable medium coupled to the processor, the computer readable medium including code, executable by the processor for performing the functionality described herein).
Regarding Claim 15, Leong 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 0025 and 0098 teach the blockchain provider computer arrangement may include multiple blockchain provider computers wherein each one includes components for data processing, such as a processor and a computer readable medium coupled to the processor, the computer readable medium including code, executable by the processor for performing the functionality described herein; the blockchain provider computer arrangement may be communicatively coupled to the data processing computers and to the user devices, e.g. via communication network; a computing device may also act as blockchain provider computer and as a user terminal at the same time; the blockchain entity, off-chain entity and certification device and their various components may each be implemented by one or more processors; a “processor” may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof; thus a “processor” may be a hard-wired logic processor or a programmable logic processor such as a programmable processor, e.g. a microprocessor; a “processor” may also be a processor executing software, e.g. any kind of computer program).
Regarding Claims 2, 9, and 21, Leong teaches all the limitations of claims 1, 8, and 15; and Leong further teaches wherein the distributed ledger is a blockchain (Paragraphs 0020-0021 teach FIG. 1 shows a block diagram of a blockchain network, i.e. a computer network for managing and operating a blockchain; the network may include one or more user devices and a blockchain provider computer arrangement and one or more data processing computers; each of these devices and computers may be communicatively coupled with each other via a communication network such as the Internet using a suitable communication protocol).
Regarding Claims 3, 10, and 16, Leong teaches all the limitations of claims 1, 8, and 15; and Leong further teaches storing the digital signature and instructions for completing the action in a smart contract on the distributed ledger (Paragraphs 0067-0069 teach if it the digital signature is valid, an indication of the request is transmitted from the smart contract to the authority, e.g. by means of a Get message by the authority and the smart contract waits for approval from the authority; the message sent by the smart contract may include a value of an age parameter as described in context of FIG. 2; the message may also include the digital signature of the transaction request if a signature verification is performed by the authority ; it may also include information to check the identity of off-chain entity; the authority receives the indication of the request and the value of the age parameter from the smart contract; it checks the request and, for example, if the off-chain entity is not blacklisted, as explained with reference to FIG. 2, approves the request by signing it with its secret key to generate a digital signature, which may also be based on the value of the age parameter, and sends the digital signature to the on-chain entity; the smart contract of on-chain entity checks whether the digital signature is valid; if it is valid the on-chain entity increases the value of the age parameter (e.g., by one) and increases the credit (by the amount X) on the smart contract).
Regarding Claims 4, 11, and 17, Leong teaches all the limitations of claims 3, 10, and 16; and Leong further teaches validating, by the off-ledger system, the implementation of the transaction using the information about the transaction stored in the smart contract on the distributed ledger (Paragraphs 0070-0071 teach the digital signature is transmitted from the smart contract from the smart contract to the off-chain device, e.g. by means of a Get message by the off-chain device; the off-chain device retrieves the digital signature from the smart contract; if the digital signature is valid, it increases the value of the age parameter and decreases its credit by the locked amount X; the off-chain device can also generate a receipt information, e.g. based on the digital signature, for example to later prove that the amount X has been paid).
Regarding Claims 5, 12, and 18, Leong teaches all the limitations of claims 4, 11, and 17; and Leong further teaches wherein validating the implementation of the transaction comprises comparing the information about the transaction that was pushed to the off-ledger system to the information about the transaction stored in the smart contract on the distributed ledger (Paragraph 0071 teaches the off-chain device retrieves the digital signature from the smart contract; if the digital signature is valid, it increases the value of the age parameter and decreases its credit by the locked amount X; the off-chain device can also generate a receipt information, e.g. based on the digital signature, for example to later prove that the amount X has been paid).
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 Leong (US 20200092106) in view of Coleman (US 20250077625).
Regarding Claims 7, 14, and 20, Leong teaches all the limitations of claims 1, 8, and 15; however, Leong 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 Leong 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 Leong 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 Leong (US 20200092106) in view of Martin (US 20210243036).
Regarding Claim 22, Leong teaches all the limitations of claim 1; however, Leong 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 Leong to
incorporate the teachings of Martin for the payload to be an application programming interface (API) payload.
There is motivation to combine Martin into Leong 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.
Kreder et al. (US 20200394651) teaches a system enables cryptocurrency payment transactions between devices using off-chain asset data that is related to blockchain assets within a blockchain but without committing the payment transaction to the blockchain until a later time. A device selects a settlement model to determine if a payment transaction is valid. When valid, the device adjusts a value of off-chain asset data stored in its memory. The device may aggregate multiple transactions, which may involve the same or different cryptocurrencies, adjusting the value of the off-chain asset data stored in its memory after each transaction. Subsequently, the device may commit at least a portion of the off-chain asset data to the blockchain.
Unger et al. (US 20220103378) teaches systems and methods for off-chain verification of cryptographic transactions are disclosed. The system receives a first transaction from a first blockchain, wherein the first transaction is associated with a first address of a first user device and receives a notification of an analysis of a whitelist status for the first transaction. The system performs a first off-chain check on the first transaction to determine validity of the first transaction and if the first off-chain check fails, determines whether a second off-chain check is required. If the second off-chain check is required the system performs the second off-chain check and if the second off-chain check fails, determines whether a supervised check is required. If the supervised check is required, the system sends transaction parameters of the first transaction to a second user device and submits transaction details to the first blockchain if an approval is received from the supervisor user device.
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