DETAILED ACTION
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 .
Acknowledgements
This Office Action addresses the response filed on 01/12/2026.
Claims 1, 4, 6, 7 and 17-20 were amended.
Claims 2 and 8-16 were previously withdrawn.
Claims 1, 3-7 and 17-20 are pending.
Claims 1, 3-7 and 17-20 were examined.
Claim Rejections - 35 USC § 101
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3-7 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claims 1 and 17 recite “wherein the balance proof comprises balance of each of the first participant and the second participant and the digital signatures”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claims 1 and 17 recite “establishing… channel… for enabling off-chain transactions”; “the balance proof in the proposed funding transaction in the first distinct ledger is to be signed by the second participant or by both of the first participant and the second participant...”; “wherein the processor is configured to… (claim 17)...” , statements of intended use or field use. See MPEP 2114 II. Lastly, claims 1 and 17 recite “terminating the payment channel and releasing a plurality of tokens in the blockchain system on one or more of the first participant and the second participant deciding to leave the payment channel” , language directed to contingent limitations. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04.
With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 1 and 3-7 are directed to a method, and claims 17-20 are directed to a system. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
a. establishing a payment channel between a first participant of a first distinct ledger and a second participant of a second distinct ledger in a blockchain system, for enabling off-chain transactions, wherein establishing the payment channel comprises: broadcasting a proposed funding transaction between the first participant and the second participant, after the first participant and the second participant mutually agree on a balance of the payment channel off-chain, wherein the proposed funding transaction comprises a balance proof, wherein the balance proof comprises balance of each of the first participant and the second participant and the digital signatures, and wherein the balance proof in the proposed funding transaction in the first distinct ledger is to be signed by the second participant or by both of the first participant and the second participant, and the balance proof in the proposed funding transaction in the second distinct ledger is to be signed by the first participant or by both the first participant and the second participant; andb. terminating the payment channel and releasing a plurality of tokens in the blockchain system on one or more of the first participant and the second participant deciding to leave the payment channel.
Therefore, the portions highlighted in bold above recite escrowing funds, which is an abstract idea grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A. The claims are grouped within certain methods of organizing human activity because the steps recited describe the fundamental economic practice of establishing an escrow mechanism and conditionally terminating it. Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using processor coupled to a memory to perform the recited steps/functions, this additional element perform the steps or functions such as: “establishing… channel…”, “terminating… channel…”. This additional element is recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, this element does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of a blockchain system amount to generally linking the use of the judicial exception to a particular technological environment or field of use. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer elements, such as processor coupled to a memory, a blockchain system. The processor coupled to a memory performs the steps/functions of “establishing… channel…”, “terminating… channel…”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of escrowing funds. The additional element(s) of a blockchain system amount to generally linking the use of the judicial exception to a particular technological environment or field of use.. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of escrowing funds. Therefore, the independent claims are not eligible.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. processor coupled to a memory), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Dependent claims 3-7 and 18-20 further recite the following additional language, in which elements which merely further define the identified abstract idea are marked in bold below:
c) wherein the first distinct ledger is a first blockchain and the second distinct ledger is a second blockchain, wherein the first blockchain and the second blockchain belong to two distinct blockchain networks. d) wherein establishing the payment channel comprises: locking the plurality of tokens in the proposed funding transaction for a pre-defined time period, wherein the pre-defined time period is defined in terms of number of blocks; one of communicating the balance proof by the first participant and the second participant, the balance proof to each other, or obtaining the balance proof from the distinct ledger of a partner and sending a confirm funding transaction to their respective distinct ledger with a valid proof, wherein a waiting period is started by the blockchain system for the confirm funding transaction to be submitted by the first and the second distinct ledgers; and establishing the payment channel once a valid confirm funding transaction is committed on each of the first and the second distinct ledgers; wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's. e) wherein, in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the method comprises allowing a smart contract to release a funding discarded event by calling a dedicated function, wherein the dedicated function releases locked tokens for the participant where the timeout of the proposal occurred. f) wherein terminating the payment channel by one of the first participant and the second participant comprises: initiating a withdrawal by a proposer, with an initiate withdraw transaction, wherein the initiate withdraw transaction comprises a valid and up-to-date balance proof signed by the proposer, wherein the proposer is one of the first participant and the second participant wishing to withdraw from the payment channel, wherein a proposal to withdraw from the payment channel is treated as a pending withdraw transaction in the distinct ledger that has not initiated the withdrawal; implementing a waiting period to allow the participant that has not initiated the withdrawal to propose another valid balance proof, wherein the waiting period corresponds to a transaction made after at least K blocks from the pending withdraw transaction; releasing the locked tokens and terminating the payment channel, once confirm withdraw transaction is committed on the distinct ledger that has not initiated the withdrawal; and challenging the pending withdraw transaction, in case the participant that has not initiated the withdrawal suspects malicious withdrawal request from the proposer, wherein challenging the pending withdraw transaction comprises generating a withdrawal discarded event on presenting a valid balance proof in challenge transaction. g) wherein terminating the payment channel by both the first and the second participants comprises: initiating a propose withdraw request in their respective distinct ledgers, using same balance proof and presenting a partially completed withdrawal,; by sharing Merkle proof of the proposal with each other, and providing a final confirmation of the withdraw request by including Merkle proof of a partial confirmation from the other distinct ledger. h) broadcasting a proposed funding transaction between the first participant and the second participant, wherein, in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the processor is configured to allow a smart contract to release a funding discarded event by calling a dedicated function, wherein the dedicated function releases locked tokens for the participant where the timeout of the proposal occurred; locking the plurality of tokens in the proposed funding transaction for a pre-defined time period, wherein the pre-defined time period is defined in terms of number of blocks; one of communicating the balance proof by the first participant and the second participant, the balance proof to each other, or obtaining the balance proof from the distinct ledger of a partner and sending a confirm funding transaction to their respective distinct ledger with a valid proof, wherein a waiting period is started by the blockchain system for the confirm funding transaction to be submitted by the first and the second distinct ledgers; and establishing the payment channel once a valid confirm funding transaction is committed on each of the first and the second distinct ledgers,; wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's.
With respect to the eligibility analysis of claim 3, the claim recites item c) above, which does not introduce additional elements/functions. The additional language merely represents statements directed to non-functional descriptive material by describing what the ledgers "are" and description of where first/second blockchains "belong". Those statements are insufficient to significantly alter the eligibility analysis. Therefore, the additional language c) of dependent claims 3 do not alter the analysis provided with respect to independent claims 1 and 17. In other words, the claims do not introduce additional elements that would alter the analysis with respect to Steps 2A or 2B above in any meaningful way. Therefore, these dependent claims are also ineligible.
Examiner notes that claim 4 recites “establishing the payment channel once a valid confirm funding transaction is committed…”, language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04. With respect to the eligibility analysis of claim 4, the claim recites item d) above, which represents the additional elements/functions of locking tokens and exchanging information as part of establishing the payment channel. This language further elaborates the abstract idea of escrowing funds identified in the analysis of independent claims 1 and 17. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer. Examiner notes the claims merely further describe the concept of "establishing a payment channel", evaluated in conjunction with independent claims 1 and 17.
Examiner notes that claim 5 recites “in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the method comprises allowing a smart contract to release...”, language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04. With respect to the eligibility analysis of claim 5, the claim recites item e) above, which represents the contingent elements/functions of allowing a contract to release. This language further elaborates the abstract idea of escrowing funds identified in the analysis of independent claims 1 and 17. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
Examiner notes that claims 6 and 19 recite “releasing the locked tokens and terminating the payment channel, once confirm withdraw transaction is committed on the distinct ledger that has not initiated the withdrawal; and”; “challenging the pending withdraw transaction, in case the participant that has not initiated the withdrawal suspects malicious withdrawal request from the proposer”, language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04. With respect to the eligibility analysis of claims 6 and 19, the claims recite item f) above, which represents the contingent elements/functions of initiating a withdrawal, implementing a waiting period, releasing tokens and terminating the channel. This language further elaborates the abstract idea of escrowing funds identified in the analysis of independent claims 1 and 17. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
With respect to the eligibility analysis of claims 7 and 20, the claims recite item g) above, which represents the additional elements/functions of initiating a request and providing a confirmation. This language further elaborates the abstract idea of escrowing funds identified in the analysis of independent claims 1 and 17. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
Examiner notes that claim 18 recites “broadcasting a proposed funding transaction between the first participant and the second participant, wherein, in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the processor is configured to allow a smart contract to release a funding discarded event by calling a dedicated function, wherein the dedicated function releases locked tokens for the participant where the timeout of the proposal occurred;” , language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04. With respect to the eligibility analysis of claim 18, the claim recites item h) above, which represents the additional elements/functions of allowing a contract to release. This language further elaborates the abstract idea of escrowing funds identified in the analysis of independent claims 1 and 17. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because the additional elements/functions do not pertain to an improvement to the functioning of a computer or to another technology. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because the additional elements/functions merely further recite additional instructions to implement the abstract idea on a computer.
Therefore, while the additional language d)-h) of dependent claims 4-7, and 18-20 slightly modify the analysis provided with respect to independent claims 1 and 17, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 7, 18 and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 7 and 20 were amended to recite “wherein terminating the payment channel by both the first and the second participants comprises: initiating a propose withdraw request in their respective distinct ledgers, using same balance proof and presenting a partially completed withdrawal by sharing Merkle proof of the proposal with each other, wherein, in case of the first and the second distinct ledgers being two different blockchains...”. The specification as filed recites, inter alia:
“[00103] One or both participants may decide to leave the channel at any time, so the CSPC protocol should allow for this functionality in a multi-shard system. However, closing the channel and releasing the funds back to the blockchain must be handled carefully to ensure that any partially committed withdrawal does not result in an inconsistent system. Embodiments herein disclose two different possible scenarios for attempting a withdrawal in detail... case 2 is when both the participants propose the withdrawal...
[00107] In case 2, where both the participants agree to close the channel cooperatively, they can initiate a ‘Propose Withdraw’ request in their respective shards, using the same balance proof. To achieve a partially completed withdrawal, both participants are required to share the Merkle proof of their proposal with each other.
[00108] FIG. 18 depicts an example scenario, wherein both participants participate and cooperate to withdraw from the channel, according to the embodiments herein. This approach ensures that both participants have completed the necessary steps to withdraw funds from the payment channel without leaving any partially committed withdrawals, thereby maintaining the integrity of the system.
[00121] According to the embodiments herein, the cross chain payment channel formation module 2210 initiates one or more proposed funding transactions on the first blockchain network and the second blockchain network involving a plurality of participants, locking specified amounts of tokens.... The cross chain payment channel termination module 2212 enables initiation of a withdrawal request by a participant on both the first and second blockchain networks, for unlocking the specified amounts of tokens. The cross chain payment channel termination module 2212 enables sharing and validation of Merkle Proofs for withdrawal transactions to prove the authenticity and legitimacy of the withdrawal request on both the first and second blockchain networks. Blockchain systems should support Turing-complete smart contracts which shall later be used to verify proof showing the locking of tokens in the other blockchain. The smart contract handling the CCPC stores block headers of the other blockchain with the help of relay nodes. Block headers of the other chain are maintained on smart contracts from both blockchains. In cross chain payment channel protocol, the relay node system sends across the merkle root information from one chain to the other. The cross chain payment channel termination module 2212 enables release of the locked tokens based on validated proofs, following one of a predefined block distance, or challenge period. The cross chain payment channel termination module 2212 allows the one or more participants to challenge malicious or fraudulent withdrawal attempts, using Merkle Proofs to demonstrate proof of rejection.”
Therefore, the specification as filed does not recite presenting a partially completed withdrawal by sharing Merkle proof of the proposal with each other. Specifically, this appears to be a feature of the CSPC protocol and is not recited in conjunction with the CCPC protocol, which was the species elected on 08/11/2025 (species represented by Fig. 20). Therefore, the attempt to incorporate aspects of the CSPC protocol in claims 7 and 20, in order to narrow claims 1 and 17, elected as directed to a CCPC protocol, is not sufficiently disclosed in the specification as filed. Therefore, the specification as filed does not provide sufficient written description for the claimed language (see MPEP 2161.01). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed.
Claim 18 was amended to recite “broadcasting a proposed funding transaction between the first participant and the second participant” (i.e. a second broadcasting function). The specification as filed does not recite this second broadcasting step. Examiner notes claim 17 was amended to recite "wherein the processor is configured to establishing the payment channel by: broadcasting a proposed funding transaction between the first participant and the second participant", and, as a consequence, claim 18 now requires two distinct "broadcasting" functions. Therefore, the specification as filed does not provide sufficient written description for the claimed language (see MPEP 2161.01). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-7 and 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 17 recite the language “the digital signatures” in lines 10 and 13. There is insufficient antecedent basis for this language in the claims. Dependent claims 3-7 and 18-20 are also rejected since they depend on claims 1 and 17, respectively.
Claims 1 and 17 recite the language “ the balance proof in the proposed funding transaction in the first distinct ledger” in lines 12 and 15. There is insufficient antecedent basis for this language in the claims. Examiner notes the claims recite "wherein the proposed funding transaction comprises a balance proof, wherein the balance proof comprises balance of each of the first participant and the second participant and the digital signatures". In other words, the claims introduce a (single) balance proof "comprises... the digital signatures" (plural). The claims, however, do not introduce a balance proofs in the first distinct ledger, and therefore the antecedent basis for this claimed term is insufficient.. Dependent claims 3-7 and 18-20 are also rejected since they depend on claims 1 and 17, respectively.
Claims 1 and 17 recite the language “the balance proof in the proposed funding transaction in the second distinct ledger” in lines 14 and 17. There is insufficient antecedent basis for this language in the claims. Examiner notes the claims recite "wherein the proposed funding transaction comprises a balance proof, wherein the balance proof comprises balance of each of the first participant and the second participant and the digital signatures". In other words, the claims introduce a (single) balance proof "comprises... the digital signatures" (plural). The claims, however, do not introduce a balance proof in the second distinct ledger, and therefore the antecedent basis for this claimed term is insufficient.. Dependent claims 3-7 and 18-20 are also rejected since they depend on claims 1 and 17, respectively.
Claims 4 and 18 recite the language “the distinct ledger of a partner” in lines 17 and 21. There is insufficient antecedent basis for this language in the claims.
Claims 4 and 18 recite the language “wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's.” in lines 6 and 13. This language is unclear as it is unclear what "their partner's" refers to. Specifically, the apostrophe indicates possession and the omission of a noun renders unclear what the "partner" possesses. Even assuming, arguendo, that the omitted noun is "ledger", the use of "their" would still raise a clarity issue as it would be unclear whether the language refers to each other’s ledgers (i.e. the ledger of the other participant) or whether it refers to a partner of both first and second participants.
Claims 5 and 18 recite the language “the participant where the timeout of the proposal occurred.” in lines 6 and 13. There is insufficient antecedent basis for this language in the claims.
Claims 5 and 18 recite the language “the proposal” in lines 6 and 13. There is insufficient antecedent basis for this language in the claims.
Claims 7 and 20 recite the language “the proposal” in lines 5 and 5. There is insufficient antecedent basis for this language in the claims.
Claim 7 recites “wherein, in case of the first and the second distinct ledgers being two different blockchains; and providing…”. This language is unclear as the wherein clause offers a condition but no further description of what the condition promotes. It appears the language was inadvertently not removed from the claim by amendment, given the language in corresponding claim 20. For examination purposes, Examiner adopts the language as recited by claim 20.
Claim Rejections - 35 USC § 102
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3, 5-7, 17, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Watanabe et al. (NPL 2018, listed in PTO-892 as reference "U"), hereinafter Watanabe.
With respect to claims 1 and 17, Watanabe teaches a blockchain system for forming and terminating payment channels between two distinct ledger environments, wherein the blockchain system comprises: a processor coupled to a memory; and a method for forming and terminating payment channels between two distinct ledger environments (Niji: Bitcoin Bridge Utilizing Payment Channels) comprising:
establishing a payment channel between a first participant of a first distinct ledger and a second participant of a second distinct ledger in a blockchain system, for enabling off-chain transactions (see page 2, column 1: "A. Payment Channels: The payment channels achieve end-to-end secure payment for off-blockchain trading. Niji utilizes a payment channel as a sub-protocol on the cross-chain protocol..."; page 3, column 1, "To begin with, let us identify the roles representing different functionalities in the Niji system: a) Networks: Each node of the Niji system has connections to two blockchain networks: the Bitcoin blockchain and a consortium blockchain", page 3, column 2, "b) Nodes: The user and service provider represent the parties in this protocol. The user is a payer node which pays bitcoins to the service provider for usage of the services operated on the consortium chain. The user makes Bitcoin payments which trigger execution of a smart contract on the consortium chain while the payment channel is open. The last state of payments is broadcasted as a settlement transaction by the service provider and is eventually stored in the blockchain. The service provider is a payee node with the intention to earn money by providing some kind of service (e.g., sharing a resource like energy for microgrids [7]) on the consortium chain. The service provider creates a service contract for providing the service and shares it via the consortium chain. It receives a Bitcoin payment from the user as the usage fee of this contract via the Niji protocol.").
wherein establishing the payment channel comprises: broadcasting a proposed funding transaction between the first participant and the second participant, after the first participant and the second participant mutually agree on a balance of the payment channel off-chain (see transaction templates and table 1, page 3, col. 2 to page 4 col. 1: The protocol itself is designed as follows. The core idea is to automate the process of updating a payment non-interactively. This is achieved using incomplete Bitcoin transactions, which we name transaction templates, where information on the remittance amount and signatures are missing. The service provider registers a transaction template to the bridging contract during the setup phase and publishes it on the consortium chain in advance..." page 4, col.1, setup: B. Protocol details "Figure 1 shows the three major phases of the Niji protocol from setup to settlement... 1) Setup: The setup involves opening the Bitcoin simple payment channel and registering a transaction template in the consortium chain. First, to open the typical simple payment channel shown in section II-A, the user and service provider create a 2-of-2 multi-signature address am and broadcast a funding transaction T f to the Bitcoin network. This transaction T f sends the user's bitcoins to the multi-signature accounts, where the amount is denoted as sf . For a refund on T f , we use a relative time-lock by applying OP CSV [16] to the multi-signature accounts; if the time-lock expires, the user can securely return all deposits to his/her wallet..."),
wherein the proposed funding transaction comprises a balance proof, wherein the balance proof comprises balance of each of the first participant and the second participant and the digital signatures, and wherein the balance proof in the proposed funding transaction in the first distinct ledger is to be signed by the second participant or by both of the first participant and the second participant, and the balance proof in the proposed funding transaction in the second distinct ledger is to be signed by the first participant or by both the first participant and the second participant (see page 4 . col. 2: "Then, the user broadcasts a transaction CT (setDeposit(am, sf , au)) as proof of opening the channel, where CT (func) is a consortium chain transaction calling a function of the bridging contact. The function setDeposit(am, sf , a u) stores deposit information including the multi-signature address am, deposit amount sf in the consortium chain, and an address a u. Here, a u is a special Ethereum-style address which is derived from the Bitcoin public key. How au is used for verification is explained in the next subsection. Next, after making enough confirmations (e.g., six confirmations), the service provider confirms that T f is stored in the Bitcoin blockchain and generates a transaction template T , which is a deformed transaction lacking signatures and the remittance amount. T specifies T f as input and corresponds to the complete transaction T s , which represents a valid Bitcoin transaction sending s bitcoins from the multi-signature address to the service provider's address. The subscripts u and s represent that T s has the signatures of the user u and the service provider s."; Examiner notes the reference discloses both using a simple payment channel (i.e. unidirectional, requiring the first user to sign every channel update) and also bi-directional payment channels (i.e. requiring both parties to exchange their signatures each time a channel state is updated). See also page 2, "To transfer funds from the multi-signature account, the transaction requires signatures of both the payer and payee. Therefore, only the payee has the right to sign and broadcast the last state of the channel (i.e., settlement transaction with 0.5 BTC) at an arbitrary timing"); and
terminating the payment channel and releasing a plurality of tokens in the blockchain system on one or more of the first participant and the second participant deciding to leave the payment channel (see page 2, col. 2, To transfer funds from the multi-signature account, the transaction requires signatures of both the payer and payee. Therefore, only the payee has the right to sign and broadcast the last state of the channel (i.e., settlement transaction with 0.5 BTC) at an arbitrary timing. "; settlement, page 5, col. 2, "3) Settlement: In the settlement phase, the service provider obtains an update transaction from the bridging contract, signs it, and broadcasts it to the Bitcoin network as a settlement transaction.").
With respect to the BRI of the claims, Examiner notes that claims 1 and 17 recite “wherein the balance proof comprises balance of each of the first participant and the second participant and the digital signatures”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claims 1 and 17 recite “establishing… channel… for enabling off-chain transactions”; “wherein the balance proof in the proposed funding transaction in the first distinct ledger is to be signed by the second participant or by both of the first participant and the second participant...”; “the balance proof in the proposed funding transaction in the second distinct ledger is to be signed by the first participant or by both the first participant and the second participant...”; “wherein the processor is configured to… (claim 17)...” , statements of intended use or field use. See MPEP 2114 II. Lastly, claims 1 and 17 recite “terminating the payment channel and releasing a plurality of tokens in the blockchain system on one or more of the first participant and the second participant deciding to leave the payment channel” , language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04.
With respect to claim 3, Watanabe et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Watanabe discloses a method wherein the first distinct ledger is a first blockchain and the second distinct ledger is a second blockchain, wherein the first blockchain and the second blockchain belong to two distinct blockchain networks (see Bitcoin, consortium chain, Abstract page 1: "...we present Niji, a new cross-chain protocol that allows parties to perform virtual Bitcoin payment securely on a consortium chain, without any trusted third-party or mediators."). Regarding the BRI of the claim, Examiner notes that claim 3 recites “wherein the first distinct ledger is a first blockchain and the second distinct ledger is a second blockchain, wherein the first blockchain and the second blockchain belong to two distinct blockchain networks”, language directed to non-functional descriptive material.
With respect to claim 5, Watanabe et al. teaches all the subject matter of the method as described above with respect to claim 4. Furthermore, Watanabe discloses a method wherein, in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the method comprises allowing a smart contract to release a funding discarded event by calling a dedicated function, wherein the dedicated function releases locked tokens for the participant where the timeout of the proposal occurred (see page 2, "To protect the payer from the risk that the payee does not respond and does not cooperate by broadcasting any state of the channel, a time-lock that refunds the whole 1.0 BTC to the payer is applied to the output's script of the funding transaction. There are two different types of time-lock; CheckLockTimeVerify (CLTV), which is an opcode specified in BIP65 [16], allows users to create a transaction whose outputs are available until a concrete time in the future. On the other hand, CheckSequenceVerify (CSV), introduced in BIP112 [17], specifies a relative time. When a transaction output including OP CSV is stored in the blockchain, it is necessary to wait for the specified block confirmations until the transaction is spendable again."; page 4, " if the time-lock expires, the user can securely return all deposits to his/her wallet. Then, the user broadcasts a transaction CT (setDeposit(am, sf , a u)) as proof of opening the channel, where CT (func) is a consortium chain transaction calling a function of the bridging contact. "). Regarding the BRI of the claim, Examiner notes that claim 5 recites “allowing a smart contract to release a funding discarded event by calling a dedicated function, wherein the dedicated function releases locked tokens for the participant where the timeout of the proposal occurred”, statements of intended use or field use. See MPEP 2114 II. In addition, claim 5 recites “in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the method comprises allowing a smart contract to release...”, language directed to contingent limitations. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. See Ex parte Schulhauser and also MPEP 2111.04.
With respect to claims 6 and 19, Watanabe et al. teaches all the subject matter of the method and system as described above with respect to claims 1 and 17. Furthermore, Watanabe discloses a method and system wherein
terminating the payment channel by one of the first participant and the second participant comprises: initiating a withdrawal by a proposer, with an initiate withdraw transaction, wherein the initiate withdraw transaction comprises a valid and up-to-date balance proof signed by the proposer, wherein the proposer is one of the first participant and the second participant wishing to withdraw from the payment channel, wherein a proposal to withdraw from the payment channel is treated as a pending withdraw transaction in the distinct ledger that has not initiated the withdrawal (see pages 5 and 6, " 3) Settlement: In the settlement phase, the service provider obtains an update transaction from the bridging contract, signs it, and broadcasts it to the Bitcoin network as a settlement transaction. Algorithm 2 lists the pseudo-code of the bridging contract. getUpdateTx(), a function of the bridging contract, returns the update transaction T s (the service provider's signature is replaced with , which represents not yet signed) to the service provider. After signing T s with its own secret key, the service provider broadcasts the complete transaction T s , i.e., the settlement transaction for Bitcoin. Finally, the service provider broadcasts a transaction CT (closing()) that makes any further payments to the bridging contract unacceptable.");
implementing a waiting period to allow the participant that has not initiated the withdrawal to propose another valid balance proof, wherein the waiting period corresponds to a transaction made after at least K blocks from the pending withdraw transaction (see page 7, col. 1, "The service provider can move the gained remittance to its own wallet by using condition 1 in the first output. However, it is impossible for the service provider to immediately fulfill the condition as it is encumbered with the time-lock. It can obtain the funds only after the time-lock expires. In the example in Figure 2, T L is denoted as the time until the transaction becomes spendable again; if T L = 110, it takes 110 blocks from the point where the transaction occurred. The time-lock gives the user a period for preventing any dishonesty on the part of the service provider... Additionally, the deadline of the time-lock TLu of an update transaction is always set to be after the time-lock TLf of a funding transaction. For example, if TLf is set to 100 blocks, TLu must be set to 101 blocks or later. These time- lock settings definitely guarantee that the service provider cannot move the gained funds until the channel expires. Therefore, the user does not have to monitor the Bitcoin network continuously while the channel is alive in order to be sure that the service provider has not committed fraud; therefore, these restrictions result in the fulfillment of the second requirement (Req. 2).");
releasing the locked tokens and terminating the payment channel, once confirm withdraw transaction is committed on the distinct ledger that has not initiated the withdrawal (see Fig. 1, settlement, pages 5 and 6, " 3) Settlement: In the settlement phase, the service provider obtains an update transaction from the bridging contract, signs it, and broadcasts it to the Bitcoin network as a settlement transaction. Algorithm 2 lists the pseudo-code of the bridging contract. getUpdateTx(), a function of the bridging contract, returns the update transaction T s (the service provider's signature is replaced with , which represents not yet signed) to the service provider. After signing T s with its own secret key, the service provider broadcasts the complete transaction T s , i.e., the settlement transaction for Bitcoin. Finally, the service provider broadcasts a transaction CT (closing()) that makes any further payments to the bridging contract unacceptable."); and
challenging the pending withdraw transaction, in case the participant that has not initiated the withdrawal suspects malicious withdrawal request from the proposer, wherein challenging the pending withdraw transaction comprises generating a withdrawal discarded event on presenting a valid balance proof in challenge transaction (see pages 8 and 9, security: "The major security risk we consider is an act of betrayal of the service provider. The service provider could potentially behave dishonestly in three ways. 1. No settlement is made at all. 2. Despite that a cancellation was approved, the service provider broadcasts an old update transaction...In the first case, the service provider abandons the protocol itself and refuses to broadcast a settlement transaction within the channel expiration. To prevent such a deadlock of funds, the output script of a funding transaction allows the user to return all deposits to his/her wallet after the funding transaction's time-lock expires; that is, the user can broadcast the settlement transaction with only the user's signature. The second case is that the service provider does not broadcast the latest channel state that reflects cancellation and instead broadcasts an old channel state which has more incentives. This fraud can be prevented by using the disclosed pre-image at the end of the cancellation procedure, as described in the previous section. With the user's signature and disclosed pre- image, the user can spend the output of a settlement transaction under condition 2 described in section IV-A.).
Regarding the BRI of the claims, Examiner notes that claims 6 and 19 recite “wherein the initiate withdraw transaction comprises a valid and up-to-date balance proof signed by the proposer,”, language directed to non-functional descriptive material. In addition, claims 6 and 19 recite “implementing a waiting period to allow the participant that has not initiated the withdrawal to propose another valid balance proof” , statements of intended use or field use. See MPEP 2114 II. Lastly, claims 6 and 19 recite “releasing the locked tokens and terminating the payment channel, once confirm withdraw transaction is committed on the distinct ledger that has not initiated the withdrawal’”; “challenging the pending withdraw transaction, in case the participant that has not initiated the withdrawal suspects malicious withdrawal request from the proposer” , language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 4 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Watanabe (NPL 2018, listed in PTO-892 as reference "U"), in view of Stone (NPL 2021)
With respect to claim 4, Watanabe et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Watanabe discloses a method wherein
establishing the payment channel comprises: locking the plurality of tokens in the proposed funding transaction for a pre-defined time period, wherein the pre-defined time period is defined in terms of number of blocks (see page 7: "Additionally, the deadline of the time-lock TLu of an update transaction is always set to be after the time-lock TLf of a funding transaction. For example, if TLf is set to 100 blocks, TLu must be set to 101 blocks or later. These time- lock settings definitely guarantee that the service provider cannot move the gained funds until the channel expires. Therefore, the user does not have to monitor the Bitcoin network continuously while the channel is alive in order to be sure that the service provider has not committed fraud; therefore, these restrictions result in the fulfillment of the second requirement (Req. 2).");
one of communicating the balance proof by the first participant and the second participant, the balance proof to each other, or obtaining the balance proof from the distinct ledger of a partner and sending a confirm funding transaction to their respective distinct ledger with a valid proof, wherein a waiting period is started by the blockchain system for the confirm funding transaction to be submitted by the first and the second distinct ledgers (see page 4, Fig. 1, settlement, getUpdateTx() from consortium chain, Sign and send transaction to blockchain, page 5, algorithm 2 and pages 5-6: " 3) Settlement: In the settlement phase, the service provider obtains an update transaction from the bridging contract, signs it, and broadcasts it to the Bitcoin network as a settlement transaction. Algorithm 2 lists the pseudo-code of the bridging contract. getUpdateTx(), a function of the bridging contract, returns the update transaction T s (the service provider's signature is replaced with , which represents not yet signed) to the service provider. After signing T s with its own secret key, the service provider broadcasts the complete transaction T s , i.e., the settlement transaction for Bitcoin. Finally, the service provider broadcasts a transaction CT (closing()) that makes any further payments to the bridging contract unacceptable."); and
establishing the payment channel once a valid confirm funding transaction is committed on each of the first and the second distinct ledgers, (see Fig. 1, Setup, page 4, " 1) Setup: The setup involves opening the Bitcoin simple payment channel and registering a transaction template in the consortium chain. First, to open the typical simple payment channel shown in section II-A, the user and service provider create a 2-of-2 multi-signature address am and broadcast a funding transaction T f to the Bitcoin network... At the end of setup, the service provider broadcasts a transaction CT (setTmpl(T)) to the consortium chain network. A function setTmpl(T) stores T in the storage space of the bridging contract on the consortium blockchain")
Watanabe does not explicitly disclose a method comprising: wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's. However, Stone discloses a method (Trustless, privacy-preserving blockchain bridges) comprising:
wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's (see page 4: "2.3 Merkle Trees We utilize binary, merkle trees as the foundation of our mixing protocols. We denote preimages of leaves in our merkle tree as z ∈ {0,1}∗. Leaves in the tree are elements y = H(z) ∈ Fp for a collision-resistant hash function H $←− H. Building the tree follows the standard algorithm of repeatedly hashing pairs of child elements until a single element, the merkle root, remains."; page 6: "We require the existence of light-clients on A and B of one another, such that an external user can verify proofs of transactions and state of blockchain B on A and vice versa with high probability of success 1−negl(λ)… 4 Protocol: We let S be a smart contract that supports a light-client functionality and bridge functionality. Light client functionality means that S can process and verify proofs of work or finality of other blockchains, in order to track their consensus states. In a bridged network with S, light-client relayers share proofs of work as well as information about bridge operations– deposits and withdrawals– for A,SA on SB and vice versa.").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the succinct zero-knowledge proofs for private bridge transfers as disclosed by Stone in the method of Watanabe, the motivation being to verify the validity of withdrawals and prevent double-spending (see Stone, 1.3 Our Contributions, page 2). Regarding the BRI of the claim, Examiner notes that claim 4 recites “establishing the payment channel once a valid confirm funding transaction is committed…”, language directed to contingent limitations. See Ex parte Schulhauser and also MPEP 2111.04.
With respect to claim 18, Watanabe et al. teaches all the subject matter of the system as described above with respect to claim 17. Furthermore, Watanabe discloses a system comprising:
broadcasting a proposed funding transaction between the first participant and the second participant, wherein, in the event of the proposed funding transaction confirmed in one of the first and the second distinct ledgers and timing out in the other distinct ledger, wherein the other distinct ledger is one of the first and the second distinct ledgers where the proposed funding transaction has timed out, wherein the processor is configured to allow a smart contract to release a funding discarded event by calling a dedicated function, wherein the dedicated function releases locked tokens for the participant where the timeout of the proposal occurred (see page 2, "To protect the payer from the risk that the payee does not respond and does not cooperate by broadcasting any state of the channel, a time-lock that refunds the whole 1.0 BTC to the payer is applied to the output's script of the funding transaction. There are two different types of time-lock; CheckLockTimeVerify(CLTV), which is an opcode specified in BIP65 [16], allows users to create a transaction whose outputs are available until a concrete time in the future. On the other hand, CheckSequenceVerify(CSV), introduced in BIP112 [17], specifies a relative time. When a transaction output including OP CSV is stored in the blockchain, it is necessary to wait for the specified block confirmations until the transaction is spendable again."; page 4, " if the time-lock expires, the user can securely return all deposits to his/her wallet. Then, the user broadcasts a transaction CT (setDeposit(am, sf , a u)) as proof of opening the channel, where CT(func) is a consortium chain transaction calling a function of the bridging contact. ");
locking the plurality of tokens in the proposed funding transaction for a pre-defined time period, wherein the pre-defined time period is defined in terms of number of blocks (see page 7: "Additionally, the deadline of the time-lock TLu of an update transaction is always set to be after the time-lock TLf of a funding transaction. For example, if TLf is set to 100 blocks, TLu must be set to 101 blocks or later. These time- lock settings definitely guarantee that the service provider cannot move the gained funds until the channel expires. Therefore, the user does not have to monitor the Bitcoin network continuously while the channel is alive in order to be sure that the service provider has not committed fraud; therefore, these restrictions result in the fulfillment of the second requirement (Req. 2).");
one of communicating the balance proof by the first participant and the second participant, the balance proof to each other, or obtaining the balance proof from the distinct ledger of a partner and sending a confirm funding transaction to their respective distinct ledger with a valid proof, wherein a waiting period is started by the blockchain system for the confirm funding transaction to be submitted by the first and the second distinct ledgers (see page 4, Fig. 1, settlement, getUpdateTx() from consortium chain, Sign and send transaction to blockchain, page 5, algorithm 2 and pages 5-6: " 3) Settlement: In the settlement phase, the service provider obtains an update transaction from the bridging contract, signs it, and broadcasts it to the Bitcoin network as a settlement transaction. Algorithm 2 lists the pseudo-code of the bridging contract. getUpdateTx(), a function of the bridging contract, returns the update transaction T s (the service provider's signature is replaced with , which represents not yet signed) to the service provider. After signing T s with its own secret key, the service provider broadcasts the complete transaction T s , i.e., the settlement transaction for Bitcoin. Finally, the service provider broadcasts a transaction CT (closing()) that makes any further payments to the bridging contract unacceptable."); and
establishing the payment channel once a valid confirm funding transaction is committed on each of the first and the second distinct ledgers, (see Fig. 1, Setup, page 4, " 1) Setup: The setup involves opening the Bitcoin simple payment channel and registering a transaction template in the consortium chain. First, to open the typical simple payment channel shown in section II-A, the user and service provider create a 2-of-2 multi-signature address am and broadcast a funding transaction T f to the Bitcoin network... At the end of setup, the service provider broadcasts a transaction CT (setTmpl(T)) to the consortium chain network. A function setTmpl(T) stores T in the storage space of the bridging contract on the consortium blockchain").
Watanabe does not explicitly disclose a system comprising: wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's.
However, Stone discloses a system (Trustless, privacy-preserving blockchain bridges) comprising: wherein establishing the payment channel in the form of the confirm funding transaction comprises broadcasting Merkle proof of the first and the second participants to distinct ledger of their partner's (see page 4: "2.3 Merkle Trees We utilize binary, merkle trees as the foundation of our mixing protocols. We denote preimages of leaves in our merkle tree as z ∈ {0,1}∗. Leaves in the tree are elements y = H(z) ∈ Fp for a collision-resistant hash function H $←− H. Building the tree follows the standard algorithm of repeatedly hashing pairs of child elements until a single element, the merkle root, remains."; page 6: "We require the existence of light-clients on A and B of one another, such that an external user can verify proofs of transactions and state of blockchain B on A and vice versa with high probability of success 1−negl(λ)… 4 Protocol: We let S be a smart contract that supports a light-client functionality and bridge functionality. Light client functionality means that S can process and verify proofs of work or finality of other blockchains, in order to track their consensus states. In a bridged network with S, light-client relayers share proofs of work as well as information about bridge operations– deposits and withdrawals– for A,SA on SB and vice versa."). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the succinct zero-knowledge proofs for private bridge transfers as disclosed by Stone in the system of Watanabe, the motivation being to verify the validity of withdrawals and prevent double-spending (see Stone, 1.3 Our Contributions, page 2).
Prior Art Analysis
The prior art of record does not appear to reasonably disclose the subject matter of claims 7 and 20, especially in context of a cross-chain payment channel. Claims 7 and 20 appear to be allowable if rewritten in independent form including all of the limitations of the base claim and if rewritten to overcome any pending rejections.
Examiner notes that further search and consideration will be required upon presentation of the rewritten claims. Reasons for allowance, if applicable, will be the subject of a separate communication to the Applicant or patent owner, pursuant to 37 CFR § 1.104 and MPEP § 1302.14.
Response to Arguments/Amendments
Claim Objections
Applicant’s amendments and arguments (see remarks, page 13, filed on 01/12/2026), with respect to the objections of claims 7 and 20 have been fully considered and are persuasive, therefore the objections were withdrawn.
Claim rejections - 35 USC § 101
Applicant’s amendments and arguments (see remarks, pages 13-16, filed on 01/12/2026), with respect to the rejection of claims 1, 3-7 and 17-20 under 35 USC § 101 as being directed to an abstract idea have been fully considered but are unpersuasive. Specifically, Applicant asserts “The claimed invention provides secure cross-ledger coordination, and therefore are not abstract at step 2A, prong One (see remarks, page 15). Examiner respectfully disagrees. The claims do not appear to be directed to secure coordination as they recite the abstract idea of an escrow (i.e. establishing a payment channel and terminating this channel). This is a concept analog to opening and closing a tab upon request at a restaurant. With respect to step 2A, prong two, Applicant asserts “that the amended claims provide practical application” and that “the recited steps impose concrete technical constraints that ensure correctness, security, and fault tolerance in a distributed environment (Blockchain networks). Examiner respectfully disagrees as the broadest reasonable interpretation of the claims do not encompass these “constraints”. With respect to step 2B (see remarks, page 16, Applicant asserts “the claimed invention recite non-conventional arrangements that go beyond routine use of generic computing elements”, further reciting what the claimed invention “deals with”. Examiner respectfully disagrees. “The Supreme Court has identified a number of considerations as relevant to the evaluation of whether the claimed additional elements amount to an inventive concept” (see MPEP 2106.05 I A). As indicated in the analysis, generally linking the use of the judicial exception to a particular technological environment or field of use is insufficient to qualify as "significantly more" when recited in a claim with a judicial exception. Therefore, upon analysis of the amended claims, these do not offer significantly more than the abstract idea itself, therefore the claims are still rejected under 35 USC § 101 as further detailed above.
Claim rejections - 35 USC § 112(b)
Applicant’s amendments and arguments (see remarks, page 16, filed on 01/12/2026), with respect to the rejection of claims 1, 3-7 and 17-20 under 35 USC § 112(b) have been fully considered and are persuasive. Therefore, the rejections were withdrawn. However, upon further consideration, new grounds of rejection under 35 USC § 112(b) were made in view of the amended language.
Claim rejections - 35 USC § 102/103
Applicant’s amendments and arguments (see remarks, pages 16-19, filed on 01/12/2026), with respect to the rejection of claims 1, 3-7 and 17-20 under 35 USC § 102/103 have been fully considered, but are moot because the arguments do not apply to the references being used in the current rejection of the amended claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Non-Patent Literature
Dziembowski et al. (NPL 2019, listed in PTO-892 as page 1, reference "V") disclose Perun: Virtual Payment Hubs over Cryptocurrencies, including establishing virtual payment channels.
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 EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights