Prosecution Insights
Last updated: August 17, 2026
Application No. 18/501,876

CONDITIONAL TRANSFERS OF DIGITAL ASSETS

Final Rejection §101§103
Filed
Nov 03, 2023
Priority
Jul 26, 2022 — provisional 63/392,208 +2 more
Examiner
KHATRI, NILESH B
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Block Inc.
OA Round
2 (Final)
61%
Grant Probability
Moderate
3-4
OA Rounds
5m
Est. Remaining
86%
With Interview

Examiner Intelligence

Grants 61% of resolved cases
61%
Career Allowance Rate
111 granted / 183 resolved
+8.7% vs TC avg
Strong +26% interview lift
Without
With
+25.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
20 currently pending
Career history
208
Total Applications
across all art units

Statute-Specific Performance

§101
30.4%
-9.6% vs TC avg
§103
41.1%
+1.1% vs TC avg
§102
5.5%
-34.5% vs TC avg
§112
17.7%
-22.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 183 resolved cases

Office Action

§101 §103
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 . Status of Claims This communication is responsive to the submission filed November 5, 2025. Claims 1-20 are amended. Claims 1-20 are pending. Information Disclosure Statement The information disclosure statement(s) (IDS) submitted on October 8, 2025, March 16, 2026, May 26, 2026, and July 20, 2026, is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) has/have been considered by the examiner. Response to Remarks 35 U.S.C. § 112 Applicant’s amendments to the claims have overcome this ground of rejection. Accordingly, this ground of rejection is withdrawn. 35 U.S.C. § 101 Applicant contends that the claims are directed towards patent eligible subject matter. Applicant initially contends that using a private key to sign a transaction would overcome this rejection, as discussed in the interview. Examiner respectfully disagrees as including public key cryptography into the claims could overcome this ground of rejection. Simply signing a transaction using an encryption key does not incorporate public key cryptography. Applicant also contends that the claims are not directed towards an abstract idea. Specifically, Applicant analogizes the claims to Finjan and that the claimed “private key” is analogous to the file that helped to provide a non-abstract improvement in computer functionality. Examiner respectfully disagrees. The claims recite obtaining a set of transactions that were signed using a private key. In other words, the claimed system does not sign the transactions with the private key or perform any function using the private key. Rather, some other unclaimed system is performing actions with the private key. Therefore, the private key in the claims does not correspond to the file in Finjan. Therefore, Applicant’s contention is unpersuasive. Applicant next contends that the claims recite a practical application of the abstract ideas. Applicant first analogizes the claims to those in CosmoKey and that the claimed “private key” is analogous to the multifactor authentication in CosmoKey. Examiner respectfully disagrees. As noted above, the claims recite obtaining a set of transactions that were signed using a private key. In other words, the claimed system does not sign the transactions with the private key or perform any function using the private key. Rather, some other unclaimed system is performing actions with the private key. Therefore, the private key in the claims does not correspond to the multifactor authentication in CosmoKey. Therefore, Applicant’s contention is unpersuasive. Applicant also analogizes the pending claims to those in Cooperative Entertainment. Specifically, Applicant analogizes the distributed ledger and cryptocurrency network of the pending claims to the virtualized computer peer-based content sharing in Cooperative Entertainment. Examiner respectfully disagrees because the distributed ledger and cryptocurrency network in the pending claims are the technological context in which the abstract ideas are being applied. In other words, they amount to an instruction to apply the abstract ideas using computers which make up the distributed ledger and cryptocurrency network. Therefore, Applicant’s contention is unpersuasive. Applicant also contends that the claimed invention improves the functioning of a computer, technology, or technical field. Examiner respectfully disagrees. Examiners evaluate integration into a practical application by: (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (2) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application. See MPEP 2106.04(d)(II). Further, it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. See MPEP 2106.05(a)(II). Here, the additional elements fail to recite a practical application because, when considering the claim as a whole, they are an instruction to apply the abstract ideas. Further, the improvements appear to be directed towards commercial interactions, i.e., Certain Methods of Organizing Human Activities, and improvements to abstract ideas is not an improvement to technology. Therefore, Applicant’s contention is unpersuasive. Applicant also contends that the claims recite a practical application as the claims recite using the concept in conjunction with a particular machine. However, as noted above, the particular machines are simply computers that are being used to implement the abstract ideas. Therefore, Applicant’s contention is unpersuasive. Applicant next contends that the claims recite significantly more than the abstract ideas as the claims recite a significant amount of details of how the various processes in the claimed solution are accomplished. Examiner respectfully disagrees as an abstract idea recited in details still recites an abstract idea. Therefore, Applicant’s contention is unpersuasive. Accordingly, this ground of rejection is maintained. 35 U.S.C. §§102/103 Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more. There are two criteria for subject matter eligibility. The first is that the claimed invention must be to one of the four statutory categories, i.e., a process, machine, manufacture, or composition of matter. See MPEP 2106(I). Second, the claimed invention also must qualify as patent-eligible subject matter, i.e., the claim must not be directed to a judicial exception unless the claim as a whole includes additional limitations amounting to significantly more than the exception. See MPEP 2106(I). Here, claims 1-14 are directed towards a process and claims 15-20 are directed towards a machine. Therefore, the analysis proceeds to determine whether the claims recite abstract ideas. Per Claim 1: Claim 1, as a whole, is directed towards the abstract idea of selectively publishing transactions to a ledger. In particular, the claim recites obtaining a set of transactions from a source address, i.e., account, to a destination address, i.e., account, that is executed in multiple stages using an intermediate address, i.e., account. The set of transactions is then stored. The process monitors for a condition to occur and then selectively publishes transactions based on whether the condition occurs and whether the conditions for finalizing a transaction is satisfied. In other words, the claim recites Certain Methods of Organizing Human Activities recognized as reciting abstract ideas. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). obtaining a set of transactions to transfer digital assets from a source address in a cryptocurrency network to one or more destination addresses in the cryptocurrency network, at least a subset of the set of transactions being signed using at least one private key, wherein the set of transactions is configured to be executed in multiple stages including (i) a first transaction configured to transfer the digital assets from the source address to an intermediate address and (ii) one or more second transactions configured to transfer the digital assets from the intermediate address to the one or more destination addresses; storing the set of transactions while withholding the set of transactions from execution in the cryptocurrency network, wherein transactions in the set of transactions as stored are signed such that (i) the first transaction is finalized and in condition to be executed in the cryptocurrency network and (ii) the one or more second transactions are unfinalized and are not in condition to be executed in the cryptocurrency network; monitoring a data source to identify that a predetermined event has occurred, wherein the predetermined event corresponds to a loss of control by a user over the source address; and publishing, in a distributed ledger, at least the subset of the set of transactions in response to identification that the predetermined event has occurred and the one or more second transactions being in condition to be finalized. Because the claim recites abstract ideas, the analysis proceeds to determine whether the claim recites additional elements that recite a practical application of the abstract ideas. According to MPEP 2106.04(d), additional elements that recite an instruction to apply the abstract ideas using a computer, that recite insignificant extra-solution activities, or that generally link the use of the abstract ideas to a particular technological environment or field of use are not indicative of a practical application. Here, the additional elements of digital assets and cryptocurrency network are instructions to implement the abstract ideas using computers. In other words, the additional elements fail to recite a practical application of the abstract ideas as they are instructions to apply the abstract ideas using computers. Therefore, the claim as a whole fails to recite a practical application of the abstract ideas. The analysis then proceeds to determine whether the additional elements, when considered individually and in combination, recite significantly more than the abstract ideas. According to MPEP 2106.05, additional elements that recite an instructions to apply the abstract ideas using a computer, that recite insignificant extra-solution activities, that generally link the use of the abstract ideas to a particular technological environment or field of use, or that recite well-understood, routine, and conventional activities are not indicative of reciting significantly more than the abstract ideas. Claim elements previously considered to recite insignificant extra-solution activities are reevaluated at this step to determine whether they recite well-understood, routine, and conventional activities. Such findings must be supported by the evidentiary requirements set forth in the Berkheimer Memo. Here, the additional elements of digital assets and cryptocurrency network are instructions to implement the abstract ideas using computers. In other words, the additional elements fail to recite significantly more than the abstract ideas as they are instructions to apply the abstract ideas using computers. Therefore, the additional claim elements, when considered individually and in combination, fail to recite significantly more than the abstract ideas. Accordingly, claim 1 is rejected as being directed towards patent ineligible subject matter. Per Claim 5: Claim 5, as a whole, is directed towards the abstract idea of generating and storing transactions. In particular, the claim recites identifying a source address, i.e., account, and generating an intermediate address and an associated private key, i.e., creating an account. The claim generates a set of transactions that are partially signed. After generating the set of transactions but before any of the transactions are published on a ledger, the process stores the transactions. The process also deletes the intermediate address private key. In other words, the claim recites Certain Methods of Organizing Human Activities recognized as reciting abstract ideas. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). identifying a source address that is associated with a source address private key; generating an intermediate address and an intermediate address private key that is associated with the intermediate address; generating a set of transactions that are at least partially signed, the set of transactions including: a first transaction to transfer digital assets recorded on a distributed ledger from the source address to the intermediate address, wherein the first transaction is signed using the source address private key; and a second transaction to transfer a predetermined amount of the digital assets from the intermediate address to a destination address, wherein the second transaction is signed using the intermediate address private key, and wherein the second transaction has a constraint that prevents transfer of the predetermined amount of the digital assets to the destination address until a predetermined event has occurred, wherein the predetermined event corresponds to a loss of control by a user over the source address; storing the set of transactions without broadcasting the set of transactions to a network associated with the distributed ledger; and discarding the intermediate address private key to limit generation of further transactions to transfer digital assets from the intermediate address unless the further transactions are signed using the source address private key; monitoring a data source to identify that the predetermined event has occurred; and publishing at least a subset of the set of transactions in the distributed ledger in response to identification that the predetermined event has occurred. Here, the additional elements of digital assets, a blockchain, and a blockchain network are tools used to apply the abstract ideas using a computer. In other words, the additional elements, when considered individually and in combination, fail to recite a practical application of the abstract ideas or significantly more than the abstract ideas as they are instructions to apply the abstract ideas using computers. Accordingly, claim 15 is rejected as being directed towards patent ineligible subject matter. Per Claim 15: Claim 15, as a whole, is directed towards the abstract idea of generating an intermediate address with an associate intermediate address private key, i.e., generating an account. The process then generates a set of transactions that have each been signed by one key. The set of transactions transfers assets from a source address, i.e., account, to a destination address, i.e., account in a series of stages from a source address to the intermediate address and from the intermediate address to the destination address. After generating the set of transactions, the process discards the intermediate address private key so that no new transactions are generated. In other words, the claim recites Certain Methods of Organizing Human Activities recognized as reciting abstract ideas. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). one or more computers; and one or more computer-readable media storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising: generating an intermediate address in a cryptocurrency network, wherein the intermediate address has an intermediate address private key associated with the intermediate address, and wherein transactions transferring of digital assets from the intermediate address require at least one signature using at least one private key of a user or the intermediate address private key; generating a set of transactions that have each been signed by the at least one private key, the set of transactions being configured to transfer digital assets from a source address to one or more destination addresses in a series of stages, wherein the set of transactions includes: a first transaction to transfer the digital assets from the source address to the intermediate address, wherein the first transaction is finalized for execution in a cryptocurrency network; and a second transaction to transfer the digital assets from the intermediate address to the one or more destination addresses, wherein the second transaction is signed using the intermediate address private key but is not finalized for execution in the cryptocurrency network until a predetermined event has occurred, wherein the predetermined event corresponds to a loss of control by a user over the source address; discarding the intermediate address private key to block generation of new transactions that transfer digital assets from the intermediate address; monitoring a data source to identify that the predetermined event has occurred; and publishing at least a subset of the set of transactions in a distributed ledger in response to identification that the predetermined event has occurred. Here, the additional elements of one or more computers, one or more computer-readable media, cryptocurrency network, and digital assets are used as tools to implement the abstract ideas. In other words, the additional elements, when considered individually and in combination, fail to recite a practical application of the abstract ideas or significantly more than the abstract ideas as they recite instructions to apply the abstract ideas using computers. Accordingly, claim 15 is rejected as being directed towards patent ineligible subject matter. Per Claims 2-4, 6-14, and 16-20: Claims 2-5, 6-14, and 16-20 have also been analyzed for subject matter eligibility. However, these claims also fail to recite patent eligible subject matter for the following reasons: Claim 2 recites the abstract idea that the transactions require a signature from either the source address or intermediate address and discarding the intermediate address private key, which is a Certain Method of Organizing Human Activities. Claim 3 recites the abstract idea that publication of a first transaction is conditional upon detecting the event and that the second transaction is subject to a timelock relative to execution of the first transaction, which is a Certain Method of Organizing Human Activities. Claim 4 recites the abstract idea publishing the first transaction when the condition is detected, determining that conditions for executing the second transaction are satisfied, and publishing the second transaction in response, which is a Certain Method of Organizing Human Activities. Claim 6 recites the abstract idea of detecting a condition associated with the source address and publishing the first transaction based on the detection, which is a Certain Method of Organizing Human Activities. Claim 7 recites the abstract idea of publishing the second transaction in response to detecting the condition, which is a Certain Method of Organizing Human Activities. Claim 8 recites the abstract idea of detecting a condition for a third transaction and in response, publishing the third transaction, which is a Certain Method of Organizing Human Activities. Claim 9 recites the abstract idea of identifying one or more other accounts designated to approve the second transaction that is conditional on a signature using a private key for the one or more other accounts, which is a Certain Method of Organizing Human Activities. Claim 10 recites the abstract idea that the third transaction is conditional on a subsequent signature using the source address private key, which is a Certain Method of Organizing Human Activities. Claim 11 recites the abstract idea generating multiple second transactions that have different conditions for execution, which is a Certain Method of Organizing Huma Activities. Claim 12 recites the abstract idea that the multiple second transactions have different timing delays and different requirements for whether a third party signature is required or not, which is a Certain Method of Organizing Human Activities. Claim 13 recites the abstract idea that the timing constraint of the second transaction is relative to a time of execution of the first transaction, which is a Certain Method of Organizing Human Activities. Claim 14 recites the abstract idea of generating multiple different transactions that are signed using the intermediate address private key, require an additional signature to be executed, and are stored, which is a Certain Method of Organizing Human Activities. Claim 16 recites the abstract idea of storing the transactions without transmitting them, which is a Certain Method of Organizing Human Activities. Claim 17 recites the abstract idea of permitting transfers of assets under some conditions and not permitting transfers when the conditions are not met, which is a Certain Method of Organizing Human Activities. Claim 18 recites the abstract idea that the condition is a timelock that delays execution of the second transaction, which is a Certain Method of Organizing Human Activities. Claim 19 recites the abstract idea of detecting a condition associated with the source address and publishing the first transaction, which is a Certain Method of Organizing Human Activities. Claim 20 recites the abstract idea of identifying other addresses that are designated to approve the second transaction and execution of the second transaction is conditional on a signature using the other addresses, which is a Certain Method of Organizing Human Activities. 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim(s) 1 and 3-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over NPL “Bitcoin Has a Huge Scaling Problem – Lightning Could be the Solution” by Timothy B. Lee (published February 4, 2018) (hereinafter, “Bitcoin Lightning”) in view of U.S. Patent Pub. No. 2024/0048387 to Fletcher et al. Per Claim 1: Bitcoin Lightning discloses: A method of facilitating conditional transfers of cryptocurrency in response to a triggering event, the method being performed by one or more computers and comprising: (see Bitcoin Lightning at p. 14: Now Alice and Bob sign a cryptographic contract (the HTLC) that says Alice will pay Bob if Bob can produce a value that hashes to H.) obtaining a set of transactions to transfer digital assets from a source address in a cryptocurrency network to one or more destination addresses in the cryptocurrency network, at least a subset of the set of transactions being signed using at least one private key, wherein the set of transactions is configured to be executed in multiple stages including (i) a first transaction configured to transfer the digital assets from the source address to an intermediate address and (ii) one or more second transactions configured to transfer the digital assets from the intermediate address to the one or more destination addresses; (see Bitcoin Lightning at p. 13: So Alice might have payment channels open with Bob and Bethany, while Bob has payment channels to Charlie and Connie, Charlie has payment channels with Donald, Daisy, and Doug, and so forth. If Alice wants to pay Daisy, she asks Bob and Charlie to help-and offers to pay them something for their trouble. She sends bitcoins to Bob over their mutual payment channel. Bob sends the same number of bitcoins to Charlie (minus agreed-upon fees), who in tum sends bitcoins to Daisy. See also p. 14: Now Alice and Bob sign a cryptographic contract (the HTLC) that says Alice will pay Bob if Bob can produce a value that hashes to H. Hash functions are designed to be irreversible, so Bob will only be able to satisfy this requirement if Daisy or Charlie tell him P. See also p. 15: When Alice signs an HTLC contract agreeing to pay Bob if he can produce P, what actually happens is that she creates a new commitment transaction with three outputs. Two of the outputs go to Alice and Bob just as in a basic commitment transaction. But now there's a third output containing the funds that are under contract.) storing the set of transactions while withholding the set of transactions from execution in the cryptocurrency network, wherein transactions in the set of transactions as stored are signed such that (i) the first transaction is finalized and in condition to be executed in the cryptocurrency network and (ii) the one or more second transactions are unfinalized and are not in condition to be executed in the cryptocurrency network; (see Bitcoin Lightning at p. 9: Then-and this is the crucial step-they only submit the first transaction to the network. This effectively puts 10 bitcoins into a shared account jointly controlled by Alice and Bob. If either one of them ever decides they want their bitcoins back, they can submit that second transaction to the network. But as long as neither of them does this, the channel remains open, and Alice and Bob can effectively send bitcoins to one another without putting anything on the blockchain.) monitoring a data source to identify that a predetermined event has occurred, [[wherein the predetermined event corresponds to a loss of control by a user over the source address]]; and (see Bitcoin Lightning at p. 14: Now these contracts can be cashed out in the opposite order. Daisy tells the secret value P to Charlie, and the two of them settle their contract. Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice.) publishing, in a distributed ledger, at least the subset of the set of transactions in response to identification that the predetermined event has occurred and the one or more second transactions being in condition to be finalized. (see Bitcoin Lightning at p. 6: The IOUs are actually cleverly-formatted bitcoin transactions called commitment transactions that haven't yet been submitted to the bitcoin network. A user always has an option to "cash out" by posting the current commitment transaction to the blockchain and collecting the money she's owed.) However, Bitcoin Lightning fails to disclose but Fletcher, an analogous art of losing access to a cryptocurrency account, discloses: wherein the predetermined event corresponds to a loss of control by a user over the source address (see Fletcher at ¶ 30: The method comprises: accessing the one or more digital assets using the threshold signature scheme when the congress receives a transaction indicating a desire to recover the one or more digital assets by a user when they have lost their private key for accessing the assets.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that it monitors whether the counterparty to an HTLC has lost control of their account using the techniques disclosed in Fletcher. One of ordinary skill in the art would have been motivated to do so to recover the money committed in the HTLC. Per Claim 3: The combination of Bitcoin Lightning and Fletcher discloses the subject matter of claim 1, from which claim 3 depends. Bitcoin Lightning further discloses: wherein selectively publishing the transactions comprises making publication of the first transaction in the cryptocurrency network conditional upon detecting the predetermined event or condition; and (see Bitcoin Lightning at p. 6: The IOUs are actually cleverly-formatted bitcoin transactions called commitment transactions that haven't yet been submitted to the bitcoin network. A user always has an option to "cash out" by posting the current commitment transaction to the blockchain and collecting the money she's owed.) wherein the set of transactions is generated such that at least one of the one or more second transactions is subject to a timelock that delays execution for a period of time measured relative to an execution of the first transaction. (see Bitcoin Lightning at p. 15: This third output can be redeemed in two different ways, as codified in bitcoin's custom scripting language. It can be cashed out by Bob if he can produce a value that hashes to H. Otherwise, it can be cashed out by Alice-but only at a fixed point in time several days in the future.) Per Claim 4: The combination of Bitcoin Lightning and Fletcher discloses the subject matter of claim 1, from which claim 4 depends. Bitcoin Lightning further discloses: in response to identification of the predetermined event, publishing the first transaction to the cryptocurrency network for execution to cause the digital assets to be transferred to the intermediate address; (see Bitcoin Lightning at p. 14: Daisy tells the secret value P to Charlie, and the two of them settle their contract.) after publishing the first transaction, determining that a condition for executing the one or more second transactions are satisfied; and (see Bitcoin Lightning at p. 14: Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice.) in response to determining that the condition for executing the one or more second transactions are satisfied, publishing the one or more second transactions to distribute the digital assets to the one or more destination addresses. (see Bitcoin Lightning at p. 14: Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice.) Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bitcoin Lightning and Fletcher as applied to claim 1 above, and further in view of U.S. Patent Pub. No. 2016/0203572 to McConaghy et al. Per Claim 2: The combination of Bitcoin Lightning and Fletcher discloses the subject matter of claim 1, from which claim 2 depends. Bitcoin Lightning further discloses: wherein the set of transactions is generated such that transactions from the intermediate address require signature using at least one of (i) a private key of an owner of the source address or (ii) an intermediate address private key for the intermediate address; (see Bitcoin Lightning at p. 14: Now Alice and Bob sign a cryptographic contract (the HTLC) that says Alice will pay Bob if Bob can produce a value that hashes to H. Hash functions are designed to be irreversible, so Bob will only be able to satisfy this requirement if Daisy or Charlie tell him P. Next, Bob signs the same kind of contract with Charlie, promising that Bob will pay Charlie if Charlie produces a value that hashes to H. Finally, Charlie signs a contract with Daisy with the same terms.) However, the combination of Bitcoin Lightning and Fletcher fails to disclose but McConaghy, an analogous art of cryptocurrency transactions, discloses: wherein the intermediate address private key is discarded after the set of transactions is generated, such that, without the private key of the owner, only transactions in the set of transactions can be used to transfer digital assets from the intermediate address. (see McConaghy at ¶ 51: If the agent obtained the private key and the public key, the agent can give the key pair to the artist, and deletes his copy of the private key.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the intermediary’s private key is deleted using the techniques disclosed in McConaghy. One of ordinary skill in the art would have been motivated to do so to increase the security by preventing the intermediary from fraudulently conducting transactions. Claim(s) 5-7, 11, 15-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bitcoin Lightning, Fletcher, McConaghy, and U.S. Patent Pub. No. 2015/0310424 to Myers. Per Claim 5: Bitcoin Lightning discloses: A method performed by one or more computers, the method comprising: (see Bitcoin Lightning at p. 14: Now Alice and Bob sign a cryptographic contract (the HTLC) that says Alice will pay Bob if Bob can produce a value that hashes to H.) identifying a source address that is associated with a source address private key; (see Bitcoin Lightning at p. 8: But in a nutshell, a bitcoin transaction is a list of inputs and outputs, with each input pointing to the output of an earlier bitcoin transaction. Suppose Alice wants to send a payment to Bob. Alice could create a bitcoin transaction that says "Send three bitcoins to Bob." To spend those three bitcoins, Bob creates a new transaction whose input points back to Alice's transaction and whose output sends the bitcoins on to someone else. He uses his private key to sign this new transaction and submit it to the bitcoin network. If the signature is valid, the transaction becomes part of the blockchain.) generating a set of transactions that are at least partially signed, the set of transactions including: a first transaction to transfer digital assets recorded on a distributed ledger from the source address to the intermediate address, wherein the first transaction is signed using the source address private key; and a second transaction to transfer a predetermined amount of the digital assets from the intermediate address to a destination address, wherein the second transaction is signed using the intermediate address private key, and wherein the second transaction has a constraint that prevents transfer of the predetermined amount of the digital assets to the destination address until a predetermined event has occurred, [[wherein the predetermined event corresponds to a loss of control by a user over the source address]]; and (see Bitcoin Lightning at p. 13: So Alice might have payment channels open with Bob and Bethany, while Bob has payment channels to Charlie and Connie, Charlie has payment channels with Donald, Daisy, and Doug, and so forth. If Alice wants to pay Daisy, she asks Bob and Charlie to help-and offers to pay them something for their trouble. She sends bitcoins to Bob over their mutual payment channel. Bob sends the same number of bitcoins to Charlie (minus agreed-upon fees), who in tum sends bitcoins to Daisy. See also p. 14: But Lightning payments use a mechanism called a hashed time lock contract (HTLC) that guarantees that Bob and Charlie can't cheat. Bob can't get Alice's coins unless he pays Charlie, and Charlie can't get Bob's coins without paying Daisy. See also p. 16: Bob's contract with Charlie and Charlie's contract with Daisy have similar clauses, but the time limits are progressively shorter. Alice is entitled to reclaim her funds after three days if Bob doesn't produce P first. Bob gets his funds back if Charlie can't complete the contract within two days. Charlie gets his funds back after one day.) storing the set of transactions without broadcasting the set of transactions to a network associated with the distributed ledger; (see Bitcoin Lightning at p. 9: Then-and this is the crucial step-they only submit the first transaction to the network. This effectively puts 10 bitcoins into a shared account jointly controlled by Alice and Bob. If either one of them ever decides they want their bitcoins back, they can submit that second transaction to the network. But as long as neither of them does this, the channel remains open, and Alice and Bob can effectively send bitcoins to one another without putting anything on the blockchain.) publishing at least a subset of the set of transactions in the distributed ledger in response to identification that the predetermined event has occurred. (see Bitcoin Lightning at p. 6: The IOUs are actually cleverly-formatted bitcoin transactions called commitment transactions that haven't yet been submitted to the bitcoin network. A user always has an option to "cash out" by posting the current commitment transaction to the blockchain and collecting the money she's owed.) However, Bitcoin Lightning fails to disclose but Fletcher discloses: wherein the predetermined event corresponds to a loss of control by a user over the source address (see Fletcher at ¶ 30: The method comprises: accessing the one or more digital assets using the threshold signature scheme when the congress receives a transaction indicating a desire to recover the one or more digital assets by a user when they have lost their private key for accessing the assets.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that it monitors whether the counterparty to an HTLC has lost control of their account using the techniques disclosed in Fletcher. One of ordinary skill in the art would have been motivated to do so to recover the money committed in the HTLC. However, the combination of Bitcoin Lightning and Fletcher fails to disclose but McConaghy discloses: discarding the intermediate address private key to limit generation of further transactions to transfer digital assets from the intermediate address unless the further transactions are signed using the source address private keys monitoring a data source to identify that the predetermined event has occurred; and (see McConaghy at ¶ 51: If the agent obtained the private key and the public key, the agent can give the key pair to the artist, and deletes his copy of the private key.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the intermediary’s private key is deleted using the techniques disclosed in McConaghy. One of ordinary skill in the art would have been motivated to do so to increase the security by preventing the intermediary from fraudulently conducting transactions. However, the combination of Bitcoin Lightning, Fletcher, and McConaghy fails to disclose but Myers, an analogous art of generating blockchain addresses, discloses: generating an intermediate address and an intermediate address private key that is associated with the intermediate address; (see Myers at ¶ 39: Specifically, the key-address may be a string of characters generated by a hashing function and having an associated private key, a controller of the private key being able to transfer a value of the cryptographic currency associated with the key-address to another key-address.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the intermediaries in the chained payment channels generate addresses using the techniques disclosed in Myers. One of ordinary skill in the art would have been motivated to do so to enable the intermediary to generate an address to receive and send bitcoins. Per Claim 6: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 6 depends. Bitcoin Lightning further discloses: wherein the predetermined event occurs a predetermined amount of time after the first transaction is completed, and (see Bitcoin Lightning at p. 15: This third output can be redeemed in two different ways, as codified in bitcoin's custom scripting language. It can be cashed out by Bob if he can produce a value that hashes to H. Otherwise, it can be cashed out by Alice-but only at a fixed point in time several days in the future.) wherein the subset of the set of transactions includes the first transaction. (see Bitcoin Lightning at p. 15: This third output can be redeemed in two different ways, as codified in bitcoin's custom scripting language. It can be cashed out by Bob if he can produce a value that hashes to H. Otherwise, it can be cashed out by Alice-but only at a fixed point in time several days in the future.) Per Claim 7: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 7 depends. Bitcoin Lightning further discloses: wherein the subset of the set of transactions includes the second transaction. (see Bitcoin Lightning at p. 16: These staggered time limits ensure that a failed payment chain can be unwound in an orderly fashion. Suppose Daisy disappears from the Internet after signing her contract with Charlie but before telling Charlie P. Without P, Charlie can't collect his payment from Bob. So after one day has passed, Charlie will have no choice but to close his payment channel with Daisy by broadcasting the current commitment transaction to the blockchain-reclaiming the bitcoins that had been tied up by the contract.) Per Claim 11: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 11 depends. Mastering Bitcoin further discloses: generating multiple second transactions that are each configured to separately transfer the predetermined amount of the digital assets to the destination address, wherein the multiple second transactions have different conditions for execution including different constraints, wherein the multiple second transactions include the second transaction, and wherein the different constraints include the constraint. (see Bitcoin Lightning at p. 14: Now these contracts can be cashed out in the opposite order. Daisy tells the secret value P to Charlie, and the two of them settle their contract. Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice. See also p. 16: If Bob fails to produce P then Alice gets to reclaim her funds. Bob's contract with Charlie and Charlie's contract with Daisy have similar clauses, but the time limits are progressively shorter. Alice is entitled to reclaim her funds after three days if Bob doesn't produce P first. Bob gets his funds back if Charlie can't complete the contract within two days. Charlie gets his funds back after one day.) Per Claim 15: Bitcoin Lightning discloses: A system comprising: one or more computers; and one or more computer-readable media storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising: (see Bitcoin Lightning at p. 14: Now Alice and Bob sign a cryptographic contract (the HTLC) that says Alice will pay Bob if Bob can produce a value that hashes to H.) [[generating an intermediate address in a cryptocurrency network,]] wherein the intermediate address has an intermediate address private key associated with the intermediate address, and wherein transactions transferring of digital assets from the intermediate address require at least one signature using at least one private key, wherein the at least one private key includes at least one of a user private key of a user or the intermediate address private key; (see Bitcoin Lightning at p. 9: Alice and Bob also construct a second transaction, called a commitment transaction, that reverses the effect of the first transaction. This new transaction takes the 10 bitcoins from the previous transaction as its input. It has one output sending five bitcoins back to Alice and a second output sending the other five bitcoins back to Bob. Alice and Bob each sign both transactions.) generating a set of transactions that have each been signed by the at least one private key, the set of transactions being configured to transfer digital assets from a source address to one or more destination addresses in a series of stages, wherein the set of transactions includes: a first transaction to transfer the digital assets from the source address to the intermediate address, wherein the first transaction is finalized for execution in a cryptocurrency network; and a second transaction to transfer the digital assets from the intermediate address to the one or more destination addresses, wherein the second transaction is signed using the intermediate address private key but is not finalized for execution in the cryptocurrency network until a predetermined event has occurred, [[wherein the predetermined event corresponds to a loss of control by a user over the source address]]; (see Bitcoin Lightning at p. 13: So Alice might have payment channels open with Bob and Bethany, while Bob has payment channels to Charlie and Connie, Charlie has payment channels with Donald, Daisy, and Doug, and so forth. If Alice wants to pay Daisy, she asks Bob and Charlie to help-and offers to pay them something for their trouble. She sends bitcoins to Bob over their mutual payment channel. Bob sends the same number of bitcoins to Charlie (minus agreed-upon fees), who in tum sends bitcoins to Daisy. See also p. 9: Then-and this is the crucial step-they only submit the first transaction to the network. This effectively puts 10 bitcoins into a shared account jointly controlled by Alice and Bob. If either one of them ever decides they want their bitcoins back, they can submit that second transaction to the network. But as long as neither of them does this, the channel remains open, and Alice and Bob can effectively send bitcoins to one another without putting anything on the blockchain.) monitoring a data source to identify that the predetermined event has occurred; and (see Bitcoin Lightning at p. 14: Now these contracts can be cashed out in the opposite order. Daisy tells the secret value P to Charlie, and the two of them settle their contract. Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice.) publishing at least a subset of the set of transactions in a distributed ledger in response to identification that the predetermined event has occurred. (see Bitcoin Lightning at p. 6: The IOUs are actually cleverly-formatted bitcoin transactions called commitment transactions that haven't yet been submitted to the bitcoin network. A user always has an option to "cash out" by posting the current commitment transaction to the blockchain and collecting the money she's owed.) However, Bitcoin Lightning fails to disclose but Fletcher discloses: wherein the predetermined event corresponds to a loss of control by a user over the source address (see Fletcher at ¶ 30: The method comprises: accessing the one or more digital assets using the threshold signature scheme when the congress receives a transaction indicating a desire to recover the one or more digital assets by a user when they have lost their private key for accessing the assets.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that it monitors whether the counterparty to an HTLC has lost control of their account using the techniques disclosed in Fletcher. One of ordinary skill in the art would have been motivated to do so to recover the money committed in the HTLC. However, the combination of Bitcoin Lightning and Fletcher fails to disclose but McConaghy discloses: discarding the intermediate address private key to block generation of new transactions that transfer digital assets from the intermediate address; (see McConaghy at ¶ 51: If the agent obtained the private key and the public key, the agent can give the key pair to the artist, and deletes his copy of the private key.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the intermediary’s private key is deleted using the techniques disclosed in McConaghy. One of ordinary skill in the art would have been motivated to do so to increase the security by preventing the intermediary from fraudulently conducting transactions. However, the combination of Bitcoin Lightning, Fletcher, and McConaghy fails to disclose but Myers discloses: generating an intermediate address in a cryptocurrency network (see Myers at ¶ 39: Specifically, the key-address may be a string of characters generated by a hashing function and having an associated private key, a controller of the private key being able to transfer a value of the cryptographic currency associated with the key-address to another key-address.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the intermediaries in the chained payment channels generate addresses using the techniques disclosed in Myers. One of ordinary skill in the art would have been motivated to do so to enable the intermediary to generate an address to receive and send bitcoins. Per Claim 16: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 15, from which claim 16 depends. Bitcoin Lightning further discloses: wherein the operations further comprise storing the set of transactions without transmitting the set of transactions to the cryptocurrency network. (see Bitcoin Lightning at p. 9: Then-and this is the crucial step-they only submit the first transaction to the network. This effectively puts 10 bitcoins into a shared account jointly controlled by Alice and Bob. If either one of them ever decides they want their bitcoins back, they can submit that second transaction to the network. But as long as neither of them does this, the channel remains open, and Alice and Bob can effectively send bitcoins to one another without putting anything on the blockchain.) Per Claim 17: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 15, from which claim 17 depends. Bitcoin Lightning further discloses: wherein the intermediate address permits transfers of digital assets from the intermediate address under multiple different sets of conditions, and blocks transfers of digital assets from the intermediate address that do not satisfy at least one of the multiple different sets of conditions. (see Bitcoin Lightning at p. 14: Now these contracts can be cashed out in the opposite order. Daisy tells the secret value P to Charlie, and the two of them settle their contract. Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice. At no point in this sequence is anyone at risk of being left holding the bag. Alice knows Daisy won't reveal P to anyone until the full payment chain is completed-otherwise Daisy won't get her payment. So Alice can safely sign the contract with Bob. Bob's contract with Alice guarantees that he'll get his money if he learns P, giving him confidence to make the same promise to Charlie. Charlie, in turn, then feels confident promising to pay Daisy in exchange for P.) Per Claim 19: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 15, from which claim 19 depends. Bitcoin Lightning further discloses: wherein the subset of the set of transactions include the first transaction. (see Bitcoin Lightning at p. 15: This third output can be redeemed in two different ways, as codified in bitcoin's custom scripting language. It can be cashed out by Bob if he can produce a value that hashes to H. Otherwise, it can be cashed out by Alice-but only at a fixed point in time several days in the future.) Claim(s) 8-10, 12-14, 18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bitcoin Lightning, Fletcher, McConaghy, and Myers as applied to claims 5 and 15 above, and further in view of U.S. Patent Pub. No. 2019/0213586 to Baratam. Per Claim 8: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 8 depends. Bitcoin Lightning further discloses: publishing the first transaction to the network associated with the distributed ledger; (see Bitcoin Lightning at p. 6: The IOUs are actually cleverly-formatted bitcoin transactions called commitment transactions that haven't yet been submitted to the bitcoin network. A user always has an option to "cash out" by posting the current commitment transaction to the blockchain and collecting the money she's owed.) detecting a predetermined condition associated with a third transaction before identification that the predetermined event has occurred; and (see Bitcoin Lightning at p. 14: Now these contracts can be cashed out in the opposite order. Daisy tells the secret value P to Charlie, and the two of them settle their contract. Now Charlie knows P, so he can settle his contract with Bob in the same way. Finally, Bob uses P to settle his contract with Alice.) However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam, an analogous art of conditional cryptocurrency transfers, discloses publishing the third transaction to the network associated with the distributed ledger to cause the digital assets to be transferred to least one of the source address or an alternative address that is not the destination address. (see Baratam at ¶ 71: The escrow uses option 1, 2, 3, 7 or 8 as depicted in FIG. 8 to transfer the funds/tokens to another secure address or back to the First Party.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the cryptocurrency across the payment channels is sent back to the sender using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the system. Per Claim 9: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 9 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: identifying one or more other addresses that are different from the destination address and that are designated to approve the second transaction, (see Baratam at ¶ 16: Consequently, the first party device and/or the second party device is enabled to transfer the available funds/token away from the multi-signature address using the second partially signed provisional transaction template and/or the first partially signed provisional transaction template in possession of the first party device and second party device respectively using the various options provided by the corresponding Provisional Transaction output, in case the first-party/second-party private-keys/secrets and/or hardware tokens are lost/stolen, thereby preventing theft.) wherein the second transaction is generated to make execution of the second transaction conditional on signature of the second transaction using a private key for at least one of the one or more other addresses, and wherein the second transaction is stored without signature using the one or more other addresses. (see Baratam at ¶ 16: Consequently, the first party device and/or the second party device is enabled to transfer the available funds/token away from the multi-signature address using the second partially signed provisional transaction template and/or the first partially signed provisional transaction template in possession of the first party device and second party device respectively using the various options provided by the corresponding Provisional Transaction output, in case the first-party/second-party private-keys/secrets and/or hardware tokens are lost/stolen, thereby preventing theft.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that another entity is required to approve the transaction using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the system. Per Claim 10: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 10 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: wherein a third transaction is generated such that execution of the third transaction is conditional on subsequent signature using the source address private key, and wherein the third transaction is stored without signature using the source address private key. (see Baratam at ¶ 57: At step 216, the first party device 106 facilitates the provisional transaction by adding the signature generated using the first party private key and the signature generated by the first party hardware token to the second partially signed provisional transaction template in its possession. This forms a fully signed provisional transaction template signed using all of the signature generated using the first party private key of first party (depositor), the signature generated using the second party private key of second party (depository) and the signature generated by the first party hardware token.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that the third transaction message is based on the sender of the cryptocurrency signing it using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction. Per Claim 12: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 11, from which claim 12 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: one of the multiple second transactions (i) has a timing constraint that delays execution for a first time period and (ii) requires subsequent signature using an additional private key of an additional party; and (see Baratam at ¶ 82: Additionally, it provides a digital currency escrow which enforces settlement albeit with a predefined delay and the escrow does not need exclusive custody of the funds/tokens beforehand to guarantee settlement.) wherein another of the multiple second transactions (i) has a timing constraint that delays execution for a second time period that is longer than the first time period and (ii) does not require a subsequent signature using the additional private key of the additional party. (see Baratam at ¶ 82: Additionally, it provides a digital currency escrow which enforces settlement albeit with a predefined delay and the escrow does not need exclusive custody of the funds/tokens beforehand to guarantee settlement.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that there is a time delay using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the system. Per Claim 13: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 13 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: wherein the predetermined event occurs according to a timing relative to a time of execution of the first transaction. (see Baratam at ¶ 82: Additionally, it provides a digital currency escrow which enforces settlement albeit with a predefined delay and the escrow does not need exclusive custody of the funds/tokens beforehand to guarantee settlement.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that there is a time delay using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the system. Per Claim 14: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 5, from which claim 14 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: before discarding the intermediate address private key, generating multiple different transactions that respectively transfer the digital assets from the intermediate address to different destinations, the multiple different transactions including the second transaction and a third transaction; (see Baratam at ¶65: In yet another embodiment, the second party device 108 acts as custodial escrows for the first party and a fourth party during a transaction/trade to minimize counter party risk and guarantee settlement.) wherein each of the multiple different transactions is signed using the intermediate address private key; (see Baratam at ¶ 53: Also, at step 212, the second party device 108 adds a signature generated using a second party private key corresponding to the first party private key, to the unsigned copy of the provisional transaction template received in step 208. This generates a second partially signed provisional transaction template.) wherein each of the multiple different transactions requires an additional signature using a private key for at least one other address in order to be executed; and (see Baratam at ¶ 50: A multi-signature address, in general, requires signatures or unique inputs associated with multiple parties to authenticate and allow a transfer of funds from the multi-signature address.) wherein each of the multiple different transactions is stored in off-chain storage in a state without the additional signature needed for transaction execution. (see Baratam at ¶ 53: Then, the first partially signed provisional transaction template is transmitted to the second party device 108. The second party device 108 keeps this first partially signed provisional transaction template safe and stores for use in future.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that payments are made to multiple payees using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to enable a single payor to pay multiple payees. Per Claim 18: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 17, from which claim 18 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: wherein at least one of the multiple different sets of conditions includes a timelock that delays execution of the second transaction for a predetermined amount of time after execution of the first transaction. (see Baratam at ¶ 66: In yet another embodiment, the present invention can enforce settlement albeit with a predefined delay and does not require exclusive custody of the said funds/tokens beforehand to guaranteed settlement.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that there is a delay using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the system. Per Claim 20: The combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers discloses the subject matter of claim 15, from which claim 20 depends. However, the combination of Bitcoin Lightning, Fletcher, McConaghy, and Myers fails to disclose but Baratam discloses: identifying one or more other addresses that are different from the one or more destination addresses and that are designated to approve the second transaction, (see Baratam at ¶ 16: Consequently, the first party device and/or the second party device is enabled to transfer the available funds/token away from the multi-signature address using the second partially signed provisional transaction template and/or the first partially signed provisional transaction template in possession of the first party device and second party device respectively using the various options provided by the corresponding Provisional Transaction output, in case the first-party/second-party private-keys/secrets and/or hardware tokens are lost/stolen, thereby preventing theft.) wherein the second transaction is generated to make execution of the second transaction conditional on signature of the second transaction using a private key for at least one of the one or more other addresses, and wherein the second transaction is stored without signature using the one or more other addresses. (see Baratam at ¶ 16: Consequently, the first party device and/or the second party device is enabled to transfer the available funds/token away from the multi-signature address using the second partially signed provisional transaction template and/or the first partially signed provisional transaction template in possession of the first party device and second party device respectively using the various options provided by the corresponding Provisional Transaction output, in case the first-party/second-party private-keys/secrets and/or hardware tokens are lost/stolen, thereby preventing theft.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin Lightning so that another entity is required to approve the transaction using the techniques disclosed in Baratam. One of ordinary skill in the art would have been motivated to do so to increase the security of the system. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Patent Pub. No. 2019/0340586 discloses methods and apparatuses are described for conducting cross-blockchain currency transactions. A server receives, from a client device, a request for a conversion of an amount of a first currency to an amount of a second currency. The amount of the first currency is stored in an electronic wallet associated with a user of the client device. The server determines one or more sequences of currency transactions executable that achieves the conversion from the amount of the first currency to the amount of the second currency, the one or more sequences of currency transactions comprising converting between cryptocurrencies operating on different blockchains. The server identifies one of the one or more sequences of currency transactions associated with an optimal value. The server executes the identified sequence of currency transactions associated with the optimal value. U.S. Patent Pub. No. 2019/0220859 discloses a computing system that includes at least one processor and at least one memory communicatively coupled to the at least one processor is disclosed. The computing system also includes at least one network interface communicatively coupled to the at least one processor and configured to communicate with at least one vault system, each of the at least one vault system storing a respective one of N private keys or key components associated with a customer. The at least one processor is configured to generate, at the customer device, a sweeping transaction that transfers all funds from at least one input transaction address in a customer wallet to a new transaction address. The at least one processor is also configured to sign the sweeping transaction using at least M of N private keys or key components. 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 NILESH B KHATRI whose telephone number is (571)270-7083. The examiner can normally be reached 8:30 AM - 5:30 PM Monday-Friday, alternating Fridays off. 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 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. /NILESH B KHATRI/Primary Examiner, Art Unit 3699
Read full office action

Prosecution Timeline

Nov 03, 2023
Application Filed
Jan 31, 2024
Response after Non-Final Action
Aug 06, 2025
Non-Final Rejection mailed — §101, §103
Oct 01, 2025
Interview Requested
Oct 10, 2025
Examiner Interview Summary
Oct 10, 2025
Applicant Interview (Telephonic)
Nov 05, 2025
Response Filed
Aug 04, 2026
Final Rejection mailed — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12705618
VALIDATION SERVICE FOR ACCOUNT VERIFICATION
1y 12m to grant Granted Aug 11, 2026
Patent 12688911
SYSTEM FOR PROVIDING A DATA MARKET FOR HEALTH DATA AND FOR PROVIDING REWARDS TO DATA MARKET PARTICIPANTS
2y 2m to grant Granted Jul 21, 2026
Patent 12682350
IDENTITY CONVEYANCE SYSTEMS
2y 10m to grant Granted Jul 14, 2026
Patent 12671679
SYSTEMS AND METHODS FOR GENERATING AND USING SECURE SHARDED ONBOARDING USER INTERFACES
2y 6m to grant Granted Jun 30, 2026
Patent 12651256
ASSET TRANSACTION METHOD, STORAGE MEDIUM, AND COMPUTER DEVICE
5y 8m to grant Granted Jun 09, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
61%
Grant Probability
86%
With Interview (+25.6%)
3y 2m (~5m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 183 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month