Prosecution Insights
Last updated: April 19, 2026
Application No. 18/963,945

TRUSTLESS SMART CONTRACT EXECUTION BASED ON PROVABLE ORDERED TRANSACTION HISTORY

Non-Final OA §101§102§103§DP
Filed
Nov 29, 2024
Examiner
JONES, COURTNEY PATRICE
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Market Software Ltd.
OA Round
1 (Non-Final)
67%
Grant Probability
Favorable
1-2
OA Rounds
3y 3m
To Grant
90%
With Interview

Examiner Intelligence

Grants 67% — above average
67%
Career Allow Rate
158 granted / 235 resolved
+15.2% vs TC avg
Strong +23% interview lift
Without
With
+23.3%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
37 currently pending
Career history
272
Total Applications
across all art units

Statute-Specific Performance

§101
11.0%
-29.0% vs TC avg
§103
47.8%
+7.8% vs TC avg
§102
23.5%
-16.5% vs TC avg
§112
7.8%
-32.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 235 resolved cases

Office Action

§101 §102 §103 §DP
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 is first office action on the merits in response to the application filed on 11/29/2024. Claims 1-27 are currently pending and have been examined. Priority Applicant’s claim for continuation-in-part of US Application No. 18/765,670 filed on 07/08/2024 is acknowledged. Applicant’s claim for benefit of a US Provisional Application No. 63/525,695 filed on 07/09/2023 is acknowledged. Applicant's claim for the benefit of US Provisional Application Nos. 63/604,255 filed on 11/30/2023 is acknowledged. Information Disclosure Statement The information disclosure statement (IDS) submitted on 02/14/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1-27 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-28 of copending Application No. 18/765,670 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both claim sets involve providing programming access to a database, wherein the database includes a provable ordered transaction history of a tokenized asset, wherein the provable ordered transaction history is based on a plurality of on-chain transactions from one or more blockchains; developing one or more decision strategies, wherein each decision strategy in the one or more decision strategies is based on the provable ordered transaction history, wherein the one or more decision strategies comprise a program that activates one or more actions for a smart contract; deploying the first decision strategy on a oracle network, wherein the first decision strategy initiates the smart contract on the one or more blockchains; sending one or more action instructions, by the first decision strategy running on the oracle network, to the smart contract; and executing the one or more action instructions, by the smart contract, wherein the executing results in at least one new blockchain transaction, and wherein the executing is trustless. This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented. 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-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Under Step 1 of the Section 101 analysis, claim 1 is directed to a method, claim 26 is directed to a computer program product, and claim 27 is directed to a system (a process, an article of manufacture, and an apparatus). Under Step 2A Prong One, Claims 1, 26, and 27 recite: providing programming access to a database, wherein the database includes a provable ordered transaction history of a tokenized asset, wherein the provable ordered transaction history is based on a plurality of on-chain transactions from one or more blockchains; developing one or more decision strategies, wherein each decision strategy in the one or more decision strategies is based on the provable ordered transaction history, wherein the one or more decision strategies comprise a program that activates one or more actions for a smart contract; selecting a first decision strategy within the one or more decision strategies, wherein the selecting includes one or more execution parameters and one or more protection parameters; deploying the first decision strategy on a public decentralized oracle network (DON), wherein the first decision strategy initiates the smart contract on the one or more blockchains; sending one or more action instructions, by the first decision strategy running on the public DON, to the smart contract; and executing the one or more action instructions, by the smart contract, wherein the executing results in at least one new blockchain transaction, and wherein the executing is trustless. Claims 1, 26, and 27 as drafted include language (see underlined language above) that recite an abstract idea of analyzing past performances of transactions (i.e., trades) to develop a decision strategy for performing transactions (i.e., trades), which falls under certain methods of organizing human activity (i.e., fundamental economic principles, specifically mitigating risk). Under Step 2A Prong Two, the additional claim element(s), considered individually, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. The additional claim elements(s) “database” “public decentralized oracle network,” “smart contract,” “blockchain,” “computer program product,” and “a computer system,” generally “apply” the concept of analyzing past performances of transactions (i.e., trades) to develop a decision strategy for performing transactions (i.e., trades). The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform the abstract idea. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. 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. The claim is directed to an abstract idea. Under Step 2A Prong Two, the additional claim element(s), considered in combination, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using database, public decentralized oracle network, smart contract, blockchain, computer program product, and a computer system amounts to no more than applying the abstract idea of analyzing past performances of transactions (i.e., trades) to develop a decision strategy for performing transactions (i.e., trades). Mere instructions to apply an exception using a generic component cannot provide an inventive concept. The limitation “deploying the decision strategy on a public decentralized oracle network (DON), wherein the first decision strategy initiates the smart contract on the one or more blockchains” adds extra-solution activity to the judicial exception, and is not enough to incorporate the abstract idea into a practical application. The claim is not patent eligible. Under Step 2B, the additional claim element(s), considered individually and in combination, do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself for similar reasons outlined under Step 2A Prong Two. A similar analysis can be applied to dependent claim 2 which claim “wherein the public DON is based on a consensus algorithm, wherein the DON provides, to an on-chain transaction, off-chain information” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 3 which claims “creating the provable ordered transaction history” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 4 which claims “wherein the creating is based on a combined hash, wherein the combined hash is based on one or more blocks from the one or more blockchains which contain the plurality of on-chain transactions from the one or more blockchains” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 5 which claims “wherein the provable ordered transaction history includes an open-high-low-close (OHLC) candle format, wherein the OHLC candle format includes volume” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 6 which claims “wherein the provable ordered transaction history includes a money flow” which merely includes instructions to apply an exception using a generic computer components (i.e., hash). When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 7 which claims “wherein the provable ordered transaction history includes a liquidity” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 8 which claims “wherein the provable ordered transaction history includes a time-ordered transaction history” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 9 which claims “wherein each action instruction within the one or more action instructions comprises a decentralized finance (deFi) transaction” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 10 which claims “wherein the one or more action instructions are based on the one or more execution parameters” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claims 11-14 which claims “wherein the one or more execution parameters include a trade dollar limit, a trade quantity limit, a crypto currency trading pair, a time limit” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 15 which claims “wherein the sending includes validating, by the smart contract, the one or more action instructions, wherein the validating is based on the one or more protection parameters” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 16 which claims “wherein the sending is responsive to one or more on-chain transactions” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 17 which claims “wherein the sending is responsive to off-chain data” which merely includes instructions to apply an exception using a generic computer components (i.e., cryptocurrency). When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 18 which claims “wherein the developing is accomplished by one or more developers” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 19 which claims “wherein the selecting is accomplished by a user” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 20 which claims “transferring funds, from a blockchain wallet owned by the user, to the smart contract” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 21 which claims “wherein the executing includes paying, by the user, a commission to the one or more developers” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 22 which claims “wherein the selecting includes a second decision strategy and a second user” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 23 which claims “wherein the deploying, the sending, and the executing include the second decision strategy” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 24 which claims “verifying that the at least one new blockchain transaction was executed according to the first decision strategy” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. A similar analysis can be applied to dependent claim 25 which claims “wherein the developing includes back testing, by a developer, the first decision strategy, wherein the back testing is based on the provable ordered transaction history” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception. Claim Rejections - 35 USC § 102(a)(1) In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-2, 10, 12, 14-24, and 26-27 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Morais (US 20230136805). Regarding Claims 1, 26, and 27, Morais teaches providing programming access to a database, wherein the database includes a provable ordered transaction history of a tokenized asset, wherein the provable ordered transaction history is based on a plurality of on-chain transactions from one or more blockchains (Paragraph 0046 teaches transaction processor includes database that stores various identifiers associated with computing device; the database may also store account data, including payment instruments and authentication credentials, as well as transaction processing histories and data for processed transactions; account data stored by database may include data for accounts used to generate smart contracts for currency exchange transactions; database may further be used to store data for blockchain and for use in monitoring and/or executing smart contract records; this may include identifiers and/or other data for monitoring smart contract records and/or information associated with currency exchange rates); developing one or more decision strategies, wherein each decision strategy in the one or more decision strategies is based on the provable ordered transaction history, wherein the one or more decision strategies comprise a program that activates one or more actions for a smart contract (Paragraphs 0043-0044 and teach smart contract operations may generate one or more smart contracts, which each may have an amount of funds; a single smart contract may be established by smart contract operations for a currency exchange transaction, which may have one or more trigger conditions; the trigger conditions may correspond to a requested exchange rate, amount, or conversion percentage, as well as an amount of time until either the smart contract is automatically executed, or the funds are returned to the remittance party, the buyer, or the seller; the trigger condition may also include patterns or trends in currency exchange rates, such as changes in moving averages, previous time period rate changes, and the like; additionally, multiple trigger conditions, such as different exchange rates, patterns or trends in exchange rates and changes, and/or amounts of time for wait times may be set for a single smart contract for an amount of funds to exchange portions of the amount of funds, or instead multiple smart contracts may be established for the portions of the amount of funds and the different exchange rates, trends, and/or amounts of times; smart contract operations may the broadcast and/or record the smart contract(s) to blockchain via distributed network participants); selecting a first decision strategy within the one or more decision strategies, wherein the selecting includes one or more execution parameters and one or more protection parameters (Paragraphs 0050-0052 and 0068 teach a sender may desire to send an amount of funds, such as for a transfer, payment, transaction, or the like to a receiver in another country and/or where the sender and receiver may utilize or want different currencies; when providing the amount of funds in first currency, smart contract parameters may be provided that are used to generate, monitor, and/or execute the smart contract; for example, smart contract parameters include the amount of funds for $1,000; the smart contract parameters further include a trigger value for an exchange rate of 0.87 for exchanging or converting first currency to second currency; this trigger value allows for dynamic execution of the smart contract on detection of the trigger value being met; the trigger value may also correspond to a value of a particular currency, such as a cryptocurrency that may be purchased using funds in first currency; the trigger value may also come with additional trigger conditions; for example, the trigger conditions may include patterns or trends in moving averages, percentage changes over a previous time periods, and the like, which may be used to determine when to dynamically execute a smart contract; the smart contracted is generated for the exchange request at a trigger condition of an exchange rate over a time period; the trigger condition may correspond to the rate, value, or the like of the exchange rate necessary to be met or exceeded for conversion of funds between two currencies or more (e.g., from USD to Euros and Pound sterling); however, more complex trigger conditions may also or instead be established, such as patterns, changes, trends, and/or percentage movements in the value of the exchange rate over time and/or as compared to another time period, exchange rate, or other value); deploying the first decision strategy on a public decentralized oracle network (DON), wherein the first decision strategy initiates the smart contract on the one or more blockchains (Paragraphs 0044-0045, 0055-0056, and 0070-0071 teach once recorded, blockchain oracle operations may be used to exchange data and monitor a conversion rate with live exchange operations, such as those exchange rates that may be available with a live currency exchange; blockchain oracle operations may correspond to a secure middleware application and may be used to interface with blockchain for monitoring smart contracts based on exchange rate data from live exchange operations; blockchain oracle operation may monitor exchange rates with different types of currency exchange systems; this may also include values of different currencies in another currency and/or type of currency; for example, when exchanging USD to cryptocurrency, or vice versa, the smart contracts may monitor the value of the cryptocurrency in USD or other fiat currency and may execute a purchase or sale transaction of the cryptocurrency; with fiat currencies, a foreign exchange system may be monitored for the exchange rate between different fiat currencies; if a wait time or expiration time occurs or expires, then transaction processing application may determine whether to void the smart contract, generate a new smart contract, and/or automatically execute the smart contract at a current exchange rate; additional triggers may also void a contract, which may be set by the user requesting the currency exchange and/or determined by transaction processor; for example, a location-based trigger may void a smart contract if a user is detected as in and/or moving to a specific location (e.g., a country), such as one associated with the base currency the funds are provided in. This may occur so that the user may retain the proper currency for the user's location; further, if multiple matching transactions are detected at once, one or more smart contracts may be voided to avoid duplication of transactions and/or fraud; once transfer service generates smart contract, smart contract is broadcasted over distributed computing nodes, devices, servers, and the like of a blockchain for a blockchain protocol associated with recording and persisting smart contract in a distributed ledger and/or records of the blockchain; this may correspond to Ethereum or other smart contract blockchain protocol and network; in order to dynamically execute smart contract, a blockchain oracle may be used, which may correspond to a secure middleware application; blockchain oracle may include operations for determining parameters for smart contract, including the trigger condition(s) and/or wait time, and monitor for these conditions using a live exchange center; blockchain oracle may include an on-chain component and an off-chain component operating simultaneously; blockchain oracle may establish a blockchain connection to the blockchain and send the blockchain data to live exchange center to determine if a trigger condition is met; in this regard, the on-chain component may broadcast data to the blockchain and/or extract blockchain data for the blockchain, which may correspond to the trigger condition(s) and/or wait time for smart contract; the on-chain component may process requests, retrieve and/or format external data for the blockchain, send blockchain data to external systems and/or perform computations associated with currency exchange rates and/or trigger conditions; the smart contract is broadcast for distributed nodes of a blockchain for recording in a blockchain record; the smart contract may be broadcast or otherwise transmitted to computing nodes that are distributed over a blockchain and/or payment network, where the computing nodes maintain, update, verify and make available data for the blockchain; the blockchain may therefore include a distributed and/or decentralized digital ledger that includes different block or records that record data including the smart contracts; the exchange rate is monitored, over the time period, for the trigger condition; monitoring of the exchange rate may work in conjunction with the blockchain and smart contracts recorded in the blockchain; for example, a blockchain oracle, such as a secure middleware application, may be used to push data to the blockchain and/or monitoring operations for the exchange rate and smart contracts, as well as pull data from one or more live exchanges; the blockchain oracle may be used as blockchains may not have functionality to push or pull data from external resources as they function as an isolated network of the distributed computing nodes; instead, the blockchain oracle may correspond to a system that may operate on and off-chain simultaneously in order to facilitate communications between the blockchain and the external live exchange system); sending one or more action instructions, by the first decision strategy running on the public DON, to the smart contract (Paragraphs 0054 and 0072 teach a smart contract rule is provided with smart contract parameter to a transfer service in order for generation of a smart contract; transfer server may correspond to a computing service, platform, and/or application/website of a service provider or transaction processor, such as transaction processor in system; transfer service generates smart contract having the trigger value of 0.87 and establishes alert operations to notify transfer service if a trigger condition is met, exceeded, or otherwise satisfied; it is determined if the trigger condition is met based on the monitored exchange rate; this determination may be based on the exchange rate meeting or exceeding a certain value, percentage conversion, or other rate; however, additional trigger conditions may also depend on trends, changes, or patterns in exchange rates, as well as a remaining amount of time until expiration of the established time period); and executing the one or more action instructions, by the smart contract, wherein the executing results in at least one new blockchain transaction, and wherein the executing is trustless (Paragraphs 0045, 0052, and 0072-0073 teach if a trigger condition is met, a currency exchange transaction may be processed to execute the corresponding smart contract; the smart contract may instead be automatically executed at the expiration of the wait time and the funds may be paid in second currency to receiver, or instead the funds in first currency may be provided to receiver; thus, if it is determined that the trigger condition is met, the smart contract is executed to convert the amount of funds from the first currency to the second currency; executing the smart contract may correspond to processing a currency exchange transaction that converts the amount of funds from the first currency to the second currency and releasing the amount of funds in that second currency to the recipient of the funds; after the smart contract is executed, the smart contract may be marked as executed, voided, and/or otherwise completed so that the corresponding blockchain is updated with a record for the execution of the smart contract; this may be used so that the blockchain oracle no longer monitors the smart contract's exchange rate for contract execution; however, if the trigger condition is not met, then it is determined whether to void the smart contract and return the amount to the user or automatically execute the smart contract at the exchange rate on the last day of the waiting time (e.g., for the smart contract)). Regarding Claim 1, Morais teaches a processor-implemented method for data analysis (Paragraph 0066 teaches FIG. 4 is a flowchart 400 for dynamic execution of distributed records based on trigger conditions, according to an embodiment; note that one or more steps, processes, and methods described herein of flowchart 400 may be omitted, performed in a different sequence, or combined as desired or appropriate). Regarding Claim 26, Morais teaches a computer program product embodied in a non-transitory computer readable medium for data analysis, the computer program product comprising code which causes one or more processors to perform operations (Paragraphs 0030 and 0076 teach data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein; for example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system; logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s) for execution; such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media; in various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus; the logic is encoded in non-transitory computer readable medium). Regarding Claim 27, Morais teaches a computer system for data analysis comprising: a memory which stores instructions; one or more processors attached to the memory wherein the one or more processors, when executing the instructions which are stored, are configured to perform operations (Paragraph 0030 teaches computing device, distributed network participants, and transaction processor may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein). Regarding Claim 2, Morais teaches all the limitations of claim 1 above; and Morais further teaches wherein the public DON is based on a consensus algorithm, wherein the DON provides, to an on-chain transaction, off-chain information (Paragraphs 0056 and 0071 teach the blockchain oracle may include an on-chain component and an off-chain component operating simultaneously; blockchain oracle may establish a blockchain connection to the blockchain and send the blockchain data to live exchange center to determine if a trigger condition is met; in this regard, the on-chain component may broadcast data to the blockchain and/or extract blockchain data for the blockchain, which may correspond to the trigger condition(s) and/or wait time for smart contract; the on-chain component may process requests, retrieve and/or format external data for the blockchain, send blockchain data to external systems and/or perform computations associated with currency exchange rates and/or trigger conditions; the exchange rate is monitored, over the time period, for the trigger condition; monitoring of the exchange rate may work in conjunction with the blockchain and smart contracts recorded in the blockchain; for example, a blockchain oracle, such as a secure middleware application, may be used to push data to the blockchain and/or monitoring operations for the exchange rate and smart contracts, as well as pull data from one or more live exchanges; the blockchain oracle may be used as blockchains may not have functionality to push or pull data from external resources as they function as an isolated network of the distributed computing nodes; instead, the blockchain oracle may correspond to a system that may operate on and off-chain simultaneously in order to facilitate communications between the blockchain and the external live exchange system). Regarding Claim 10, Morais teaches all the limitations of claim 1 above; and Morais further teaches wherein the one or more action instructions are based on the one or more execution parameters (Paragraphs 0071-0072 teach the exchange rate is monitored, over the time period, for the trigger condition; monitoring of the exchange rate may work in conjunction with the blockchain and smart contracts recorded in the blockchain; for example, a blockchain oracle, such as a secure middleware application, may be used to push data to the blockchain and/or monitoring operations for the exchange rate and smart contracts, as well as pull data from one or more live exchanges; the blockchain oracle may be used as blockchains may not have functionality to push or pull data from external resources as they function as an isolated network of the distributed computing nodes; instead, the blockchain oracle may correspond to a system that may operate on and off-chain simultaneously in order to facilitate communications between the blockchain and the external live exchange system; it is determined if the trigger condition is met based on the monitored exchange rate; this determination may be based on the exchange rate meeting or exceeding a certain value, percentage conversion, or other rate; however, additional trigger conditions may also depend on trends, changes, or patterns in exchange rates, as well as a remaining amount of time until expiration of the established time period). Regarding Claim 12, Morais teaches all the limitations of claim 10 above; and Morais further teaches wherein the one or more execution parameters include a trade quantity limit (Paragraph 0043 teaches the trigger conditions may correspond to a requested exchange rate, amount, or conversion percentage, as well as an amount of time until either the smart contract is automatically executed, or the funds are returned to the remittance party, the buyer, or the seller; the trigger condition may also include patterns or trends in currency exchange rates, such as changes in moving averages, previous time period rate changes, and the like). Regarding Claim 14, Morais teaches all the limitations of claim 10 above; and Morais further teaches wherein the one or more execution parameters include a time limit (Paragraph 0043 teaches the trigger conditions may correspond to an amount of time until either the smart contract is automatically executed, or the funds are returned to the remittance party, the buyer, or the seller). Regarding Claim 15, Morais teaches all the limitations of claim 1 above; and Morais further teaches wherein the sending includes validating, by the smart contract, the one or more action instructions, wherein the validating is based on the one or more protection parameters (Paragraphs 0071-0072 teach the exchange rate is monitored, over the time period, for the trigger condition; monitoring of the exchange rate may work in conjunction with the blockchain and smart contracts recorded in the blockchain; for example, a blockchain oracle, such as a secure middleware application, may be used to push data to the blockchain and/or monitoring operations for the exchange rate and smart contracts, as well as pull data from one or more live exchanges; the blockchain oracle may be used as blockchains may not have functionality to push or pull data from external resources as they function as an isolated network of the distributed computing nodes; instead, the blockchain oracle may correspond to a system that may operate on and off-chain simultaneously in order to facilitate communications between the blockchain and the external live exchange system; it is determined if the trigger condition is met based on the monitored exchange rate; this determination may be based on the exchange rate meeting or exceeding a certain value, percentage conversion, or other rate; however, additional trigger conditions may also depend on trends, changes, or patterns in exchange rates, as well as a remaining amount of time until expiration of the established time period). Regarding Claim 16, Morais teaches all the limitations of claim 1 above; and Morais further teaches wherein the sending is responsive to one or more on-chain transactions (Paragraphs 0054 and 0072 teach a smart contract rule is provided with smart contract parameter to a transfer service in order for generation of a smart contract; transfer server may correspond to a computing service, platform, and/or application/website of a service provider or transaction processor, such as transaction processor in the system; transfer service generates smart contract having the trigger value of 0.87 and establishes alert operations to notify transfer service if a trigger condition is met, exceeded, or otherwise satisfied; it is determined if the trigger condition is met based on the monitored exchange rate; this determination may be based on the exchange rate meeting or exceeding a certain value, percentage conversion, or other rate; however, additional trigger conditions may also depend on trends, changes, or patterns in exchange rates, as well as a remaining amount of time until expiration of the established time period). Regarding Claim 17, Morais teaches all the limitations of claim 1 above; and Morais further teaches wherein the sending is responsive to off-chain data (Paragraph 0055 and 0057 teach the blockchain oracle may include operations for determining parameters for smart contract, including the trigger condition(s) and/or wait time, and monitor for these conditions using a live exchange center; live exchange center may provide live data for exchange rates and other conversion data between different currencies; blockchain oracle may therefore monitor different data after persisting smart contract on the blockchain in a record, which may occur live, in real-time or near real-time, and/or at certain time intervals; thus, blockchain oracle may pull data from live exchange center for the exchange rate and/or may push data to a distributed digital ledger for smart contract for dynamic execution of smart contract; in the trigger condition is met within the wait time, a converted amount may be provided to receiver in second currency; the converted amount may be based on smart contract parameters and based on executing one or more currency exchange transactions based on smart contract). Regarding Claim 18, Morais teaches all the limitations of claim 1 above; and Morais further teaches wherein the developing is accomplished by one or more developers (Paragraph 0023 teaches trigger conditions may also be suggested by the system to the user based on user data and the transaction, such as amount of the transaction (where a lower exchange rate may be more important to the user than a smaller amount transaction), importance of the transaction to the user (e.g., setting trigger conditions that are more likely to be met so that the user does not lose the transaction or have the smart contract and the transaction voided)). Regarding Claim 19, Morais teaches all the limitations of claim 18 above; and Morais further teaches wherein the selecting is accomplished by a user (Paragraph 0023 teaches trigger conditions may be set by any party to the transaction). Regarding Claim 20, Morais teaches all the limitations of claim 19 above; and Morais further teaches transferring funds, from a blockchain wallet owned by the user, to the smart contract (Paragraphs and 0018 and 0029 teach once completed and/or digitally signed, the account and/or digital wallet may then broadcast the digitally signed currency exchange transaction over the layer one or layer two network for the blockchain protocol used by the smart contract for currency exchange; computing device may be used to process payments, such as through a payment platform, application, and/or application extension, which may be facilitated through digital accounts and wallets that allow for establishing smart contracts on a blockchain for currency conversion or exchange transaction processing through distributed network participants). Regarding Claim 21, Morais teaches all the limitations of claim 20 above; and Morais further teaches wherein the executing includes paying, by the user, a commission to the one or more developers (Paragraph 0013 teaches when persisting the transaction to a digital ledger associated with the blockchain protocol, a smart contract may be generated that corresponds to a digital contract having computer coded instructions to execute operations to process a transaction automatically and dynamically; these coded instructions may include a trigger condition, such as a currency exchange rate, fee for currency exchange, and other costs and/or rates associated with exchanging currency from one currency type or standard to another; the smart contract and/or trigger condition(s) may also have an expiration time period or wait time where the smart contract is valid and exchange rates, fees, and costs associated with currency exchange are monitored for if the trigger condition(s) are met). Regarding Claim 22, Morais teaches all the limitations of claim 19 above; and Morais further teaches wherein the selecting includes a second decision strategy and a second user (Paragraph 0045 teaches additional triggers may also void a contract, which may be set by the user requesting the currency exchange and/or determined by transaction processor; for example, a location-based trigger may void a smart contract if a user is detected as in and/or moving to a specific location (e.g., a country), such as one associated with the base currency the funds are provided in; this may occur so that the user may retain the proper currency for the user's location; further, if multiple matching transactions are detected at once, one or more smart contracts may be voided to avoid duplication of transactions and/or fraud). Regarding Claim 23, Morais teaches all the limitations of claim 22 above; and Morais further teaches wherein the deploying, the sending, and the executing include the second decision strategy (Paragraph 0045 teaches transaction processing application may further execute a privacy and/or risk detection system in order to determine whether a smart contract should be voided based on detected risk, user privacy, and/or potential fraud). Regarding Claim 24, Morais teaches all the limitations of claim 1 above; and Morais further teaches verifying that the at least one new blockchain transaction was executed according to the first decision strategy ((Paragraphs 0072-0073 teaches thus, if it is determined that the trigger condition is met, the smart contract is executed to convert the amount of funds from the first currency to the second currency; executing the smart contract may correspond to processing a currency exchange transaction that converts the amount of funds from the first currency to the second currency and releasing the amount of funds in that second currency to the recipient of the funds; after the smart contract is executed, the smart contract may be marked as executed, voided, and/or otherwise completed so that the corresponding blockchain is updated with a record for the execution of the smart contract; this may be used so that the blockchain oracle no longer monitors the smart contract's exchange rate for contract execution; however, if the trigger condition is not met, then it is determined whether to void the smart contract and return the amount to the user or automatically execute the smart contract at the exchange rate on the last day of the waiting time (e.g., for the smart contract)). 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. Claims 3, 5-8, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Morais (US 20230136805) in view of Schneider (US 20210334866). Regarding Claim 3, Morais teaches all the limitations of claim 1 above; however, the Morais does not explicitly teach creating the provable ordered transaction history. Schneider from same or similar field of endeavor teaches creating the provable ordered transaction history (Paragraphs 0060 and 0158-0159 teach the charting engine can be integrated into software, electronic applications, programs, interfaces, and other functional tools that can be applied to charting; such products can be downloadable, web-based, mobile phone-based, or via a mobile application as well as server based, cloud based, or in a virtual environment; such charting products can be accessed via a sole charting subscription or can be integrated in conjunction with an online brokerage account to trade, simulate, and back-test the trade of assets; the methods shown above can be employed from points of view of a publisher/provider and a subscriber/user; for instance, the data provider device of a publisher can receive a request to download an enhanced candlestick chart data feed and send a flash object that includes the enhanced candlestick chart to the network access device of a user or a subscriber that can be opened and displayed in a browser or embedded into an electronic document; further, the network access device can store in a memory, an enhanced candlestick price chart display applet that runs in a standard Java virtual machine (JVM) executing within a browser or make API calls to receive real-time streaming enhanced OHLC data and/or enhanced candlestick chart publishing data from the charting engine of the data provider device; further, API connections can integrate a real-time streaming enhanced candlestick chart or a OHLC price bar chart module directly with brokerage trading software including trading portfolios, order management systems, and accounting systems; a cloud server can serve as a publisher platform for a Charting as a Service (CaaS) for subscribers to gain access to such new enhanced price charts that can further be integrated into interfaces of trading software and systems for market participants). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Morais to incorporate the teachings of Schneider to create the provable ordered transaction history. There is motivation to combine Schneider into Morais because the present disclosure enables enhanced OHLC data to assist a user with research, analysis, and back-testing with historical data to visualize enhanced candlestick chart data over longer time periods of years or even decades. The present disclosure provides enhanced OHLC and HLC bar charts that include a separate upper price bar and lower price bar instead of a conventional centerline high-low price bar and further include an open-close bar and a close bar, respectively, that can widen proportional to the percentage of traversal of the time period (Schneider Paragraph 0011). The present disclosure enables for the calculating and updating of the highest symbol position value, the lowest symbol position value, and the symbol partial-width value as prices fluctuate during the course of a time period as well as the storing of such data values into an enhanced OHLC data structure. The present disclosure enables ghost price range symbols to be generated and displayed (dimmed to distinguish from actual symbols) to provide more price chart continuity estimating last price in the event of illiquid stocks or options pricing that have infrequent last price data updates. The present disclosure enables a user to receive news, advertisements, estimated pricing and other context sensitive content displayed in the empty time gaps during closed markets whether overnight, the weekend or holidays and further display such enhanced content in between price gaps independent of time gaps. The present disclosure enables a variable symbol width between a minimum and maximum width for price range symbols that each have the same time period. The present disclosure provides bar charts or histograms of volume or technical indicators to be displayed within a candle body (Schneider Paragraph 0014). Regarding Claim 5, the combination of Morais and Schneider teaches all the limitations of claim 3 above; however, the combination does not explicitly teach wherein the provable ordered transaction history includes an open-high-low-close (OHLC) candle format, wherein the OHLC candle format includes volume. Schneider further teaches wherein the provable ordered transaction history includes an open-high-low-close (OHLC) candle format, wherein the OHLC candle format includes volume (Paragraph 0133 teaches FIG. 4-B illustrates a portion of a data structure for market data such as OHLC data; the data structure can include data fields including a date/time, an open price, a high price, a low price, a close price, and a volume.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Morais and Schneider to incorporate the further teachings of Schneider for the provable ordered transaction history to include an open-high-low-close (OHLC) candle format, wherein the OHLC candle format includes volume. There is motivation to further combine Schneider into the combination of Morais and Schneider because OHLC (Open-High-Low-Close) charts offer several significant advantages for traders and analysts due to their ability to condense comprehensive price information into a single data point for any given time period. Regarding Claim 6, the combination of Morais and Schneider teaches all the limitations of claim 3 above; however, the combination does not explicitly teach wherein the provable ordered transaction history includes a money flow. Schneider further teaches wherein the provable ordered transaction history includes a money flow (Paragraph 0133 teaches FIG. 4-B illustrates a portion of a data structure for market data such as OHLC data; the data structure can include data fields including a date/time, an open price, a high price, a low price, a close price, and a volume; each data record is representative of such data for a given time period, and in turn, is used to represent a plurality of intra-time periods within a larger given time period). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Morais and Schneider to incorporate the further teachings of Schneider for the provable ordered transaction history to include a money flow. There is motivation to further combine Schneider into the combination of Morais and Schneider because candlestick patterns are commonly used in technical analysis to describe price movements over time of traded objects of value such as securities (e.g., stocks, bonds, ETFs, mutual funds, etc.), derivatives (e.g., options, forwards, futures, swaps, etc.), indices, commodities, or currencies further including cryptocurrencies as a class of digital asset. Other digital assets can include tokens, non-fungible tokens (NFTs), and the tokenization of contracts, physical assets such as real property, intangible property, and intellectual property. Such candlestick symbols and patterns can further depict the ratio of price movements between a plurality of assets, currency pairs including cryptocurrency pairs and token pairs, or traded objects of value (Schneider Paragraph 0135). Regarding Claim 7, the combination of Morais and Schneider teaches all the limitations of claim 3 above; and Morais further teaches wherein the provable ordered transaction history includes a liquidity (Paragraph 0051 teaches an amount of funds, money, or the like (including assets such as contracts, stocks, derivatives, and/or virtual assets including virtual and/or cryptocurrency) may be provided in a first currency, where the amount of funds is to be returned in a second currency; when providing the amount of funds in first currency, smart contract parameters may be provided that are used to generate, monitor, and/or execute the smart contract). Regarding Claim 8, the combination of Morais and Schneider teaches all the limitations of claim 3 above; however, the combination does not explicitly teach wherein the provable ordered transaction history includes a time-ordered transaction history. Schneider further teaches wherein the provable ordered transaction history includes a time-ordered transaction history (Paragraphs 0133 and 0239 teach FIG. 4-B illustrates a portion of a data structure for market data such as OHLC data; for instance, each data record shows the OHLC data for a one minute interval based on the time data which can define a first intra-time period, a second intra-time period, a third intra-time period, and can continue to an endless number of intra-time periods up to a last or final intra-time period; for instance, if the given time period of interest is a five minute interval, then five data records of one minute intervals would be used to as five intra-time periods; FIG. 33-A is a flowchart illustrating the steps performed for generating a data structure used to generate a HLC or OHLC type symbol in accordance with the present disclosure; when a network access device receives real-time market price data a device processor in operative communication with a charting engine can process the stream of fluctuating prices, each price occurring at a different corresponding to a unique time within a time period and determine from the received plurality of the prices). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Morais and Schneider to incorporate the further teachings of Schneider for the provable ordered transaction history to include a time-ordered transaction history. There is motivation to further combine Schneider into the combination of Morais and Schneider because of the same reasons listed above for claim 3. Regarding Claim 25, Morais teaches all the limitations of claim 1 above; however, Morais does not explicitly teach wherein the developing includes back testing, by a developer, the first decision strategy, wherein the back testing is based on the provable ordered transaction history. Schneider from same or similar field of endeavor teaches wherein the developing includes back testing, by a developer, the first decision strategy, wherein the back testing is based on the provable ordered transaction history (Paragraphs 0157 and 0160 teach there are different types of market data available used to render and display an enhanced candlestick chart such as real-time streaming live data when a given market is open and historical data used for research, technical analysis, and back-testing; such charting products can be accessed via a sole charting subscription or can be integrated in conjunction with an online brokerage account to trade, simulate, and back-test the trade of assets). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Morais to incorporate the teachings of Schneider for the developing to include back testing, by a developer, the first decision strategy, wherein the back testing is based on the provable ordered transaction history. There is motivation to combine Schneider into Morais because enhanced OHLC data will be particularly useful for historical data to enable users to visualize enhanced candlesticks over longer time periods spanning years or decades if need be (Schneider Paragraph 0157). Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Morais (US 20230136805) in view of Schneider (US 20210334866) in further view of Cordi (US 12,118,127). Regarding Claim 4, the combination of Morais and Schneider teaches all the limitations of claim 3 above; however, the combination does not explicitly teach wherein the creating is based on a combined hash, wherein the combined hash is based on one or more blocks from the one or more blockchains which contain the plurality of on-chain transactions from the one or more blockchains. Cordi from same or similar field of endeavor teaches wherein the creating is based on a combined hash, wherein the combined hash is based on one or more blocks from the one or more blockchains which contain the plurality of on-chain transactions from the one or more blockchains (Col. 19, lines 5-16 teaches FIG. 15 shows an example staggered blockchain data architecture for efficient storing and retrieval of hash data by the machine data validation system, according to some example embodiments; at a high level, in the approach of FIG. 15, hashes and batch hashes are stored in a lightweight, relatively less immutable but inexpensive to access blockchain (e.g., permissioned chain, a permissionless chain with low crypto-costs per transaction) while groups of batch hashes are combined to generate combined batch hashes, which are stored in a more robust, highly immutable but more expensive blockchain (e.g., Bitcoin, Ethereum)). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Morais and Schneider to incorporate the teachings of Cordi for the creating to be based on a combined hash, wherein the combined hash is based on one or more blocks from the one or more blockchains which contain the plurality of on-chain transactions from the one or more blockchains. There is motivation to combine Cordi into the combination of Morais and Schneider because in this way, the costs of hash management via blockchain interactions is made more efficient while ensuring that the data is secure and trustworthy (e.g., via storage in the highly immutable chain). In particular, and in accordance with some example embodiments, each of the machine data items (e.g., raw items 605A-N) is hashed to generate the respective hashes (e.g., item hashes 610A-N) that are stored in a first tier of immutable storage, which is configured as a low-cost and fast data store that has weak immutability (e.g., object storage database such as Amazon S3, a relational database) (Cordi Col. 19, lines 16-26). Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Morais (US 20230136805) in view of Schneider (US 20210334866) in further view of Negron (US 20240046352). Regarding Claim 9, the combination of Morais and Schneider teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein each action instruction within the one or more action instructions comprises a decentralized finance (deFi) transaction. Negron from same or similar field of endeavor teaches wherein each action instruction within the one or more action instructions comprises a decentralized finance (deFi) transaction (Paragraph 0024 teaches blockchain networks may utilize different consensus mechanisms to validate and verify transactions or data blocks, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS); a blockchain network accommodates the use of self-executing contracts (e.g., “smart contracts”), and decentralized finance (“DeFi”) protocols). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Morais and Schneider to incorporate the teachings of Negron for each action instruction within the one or more action instructions to comprise a decentralized finance (deFi) transaction. There is motivation to combine Negron into the combination of Morais and Schneider because DeFi's main advantages are permissionless access (anyone with internet can join), transparency (public ledger), user control (custody of assets), lower costs, faster transactions, and innovation via composable "money legos," all achieved by removing traditional banks and using smart contracts for automation, leading to greater financial inclusion and sovereignty. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Morais (US 20230136805) in view of Heitkotter (US 20220318911). Regarding Claim 11, Morais teaches all the limitations of claim 10 above; however, Morais does not explicitly teach wherein the one or more execution parameters include a trade dollar limit. Heitkotter from same or similar field of endeavor teaches wherein the one or more execution parameters include a trade dollar limit (Paragraph 0058 teaches some of the parameters during recommendation, for consideration by the user may be customized based on the user selection criteria or preference and the past performance estimate; one such parameter may include position size; the position size is determined based on the total risk the user chooses to take based on his or her aversion or attraction for risk; the user's total investible cash in his or her account is placed against a calculatable risk taking capacity which is based on the total maximum stop loss which is possible should the security move in a direction against the hopes of the user's desired direction; position size may be calculated as risk amount divided by the stop loss (risk amount/stop loss)). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Morais to incorporate the teachings of Heitkotter for the one or more execution parameters to include a trade dollar limit. There is motivation to combine Heitkotter into Morais because disclosed is a technical solution for recommending securities for trading. Broadly, the solution uses momentum indicators of securities to identify securities that may be considered for recommendation. Securities that satisfy certain criteria relating to momentum indicators are processed to determine whether they have reached certain trigger points, and those which have, may be considered investment worthy. Historical data corresponding to such investment-worthy securities is processed to identify optimized exit prices for profit target and stop loss. Further, those investment-worthy securities that meet user criteria at least based on historical performance, which may be derived using certain factors used for identifying the optimized exit prices, may be recommended to the user. Detailed explanation of the solution follows (Heitkotter Paragraph 0027). Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Morais (US 20230136805) in view of Jang (US 20210056628). Regarding Claim 13, Morais teaches all the limitations of claim 10 above; however, the combination does not explicitly teach wherein the one or more execution parameters include a crypto currency trading pair. Jang from same or similar field of endeavor teaches wherein the one or more execution parameters include a crypto currency trading pair (Paragraphs 0073-0074 teach the cryptocurrency exchange allows buy/sell for each pair of a trading coin and a market coin [trading coin/market coin]; for example, if Ethereum (ETH) and Link (LN) are listed on the BTC market that allows trading using Bitcoin (BTC), trading may be allowed for each pair, for example, a pair of ETH coin and BTC coin [ETH/BTC] and a pair of LN coin and BTC coin [LN/BTC]; since the cryptocurrency exchange allows trading for each pair of a market cryptocurrency (market coin) and a trading cryptocurrency (trading coin) (hereinafter, also, referred to as market-and-coin pair or market coin-and-trading coin pair), a user may not be allowed to exchange a trading coin by simply selecting the trading coin alone without selecting a market (or a market coin) in the related art). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Morais to incorporate the teachings of Jang for the one or more execution parameters to include a crypto currency trading pair. There is motivation to combine Jang into Morais because provide optimization trading information that allows the user to buy/sell coins at the most favorable price or to buy/sell a largest number of coins through an automation logic (Jang Paragraph 0081). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Abdelrahman (US 20240330080) teaches a method for generating a bridge to facilitate cross-chain transactions is disclosed. The method includes monitoring transactions on a first and second blockchain and classifying the monitored transactions. For each transaction type of a plurality of transaction types, the method includes generating, with a generative artificial intelligence model, a smart contract defining a bridge to link the first blockchain with the second blockchain based on the classified transaction type and deploying the smart contract defining the bridge. Hall et al. (US 11,934,425) teaches a system and method for capturing changes in trade information that impact trade authorization and for updating a chain state on a distributed chain database that is used to authorize trades are disclosed herein. In some embodiments, the system comprises: a trade controller configured to obtain a current state from a local database; a rules engine configured to be invoked by the trade controller to apply a ruleset to data extracted from the local database to generate an updated state; an operation auto detector configured to generate a plan to update a chain state on the distributed chain database based at least in part on the updated state; and an execution engine configured to execute the plan and to generate an updated chain state that is used to authorize trades. Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th). Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. /COURTNEY P JONES/Primary Examiner, Art Unit 3699
Read full office action

Prosecution Timeline

Nov 29, 2024
Application Filed
Dec 16, 2025
Non-Final Rejection — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12597018
DECENTRALIZED IDENTITY-BASED COMMUNICATION SERVICE
2y 5m to grant Granted Apr 07, 2026
Patent 12591894
FRAUD PREVENTION VIA BENEFICIARY ACCOUNT VALIDATION
2y 5m to grant Granted Mar 31, 2026
Patent 12586077
SYSTEMS AND METHODS FOR END TO END ENCRYPTION UTILIZING A COMMERCE PLATFORM FOR CARD NOT PRESENT TRANSACTIONS
2y 5m to grant Granted Mar 24, 2026
Patent 12579543
HIERARCHICAL DIGITAL ISSUANCE TOKENS AND CLAIM TOKENS
2y 5m to grant Granted Mar 17, 2026
Patent 12572936
QR CODE PAYOR TRACKING AND REPEAT PAYMENT PREVENTION
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
67%
Grant Probability
90%
With Interview (+23.3%)
3y 3m
Median Time to Grant
Low
PTA Risk
Based on 235 resolved cases by this examiner. Grant probability derived from career allow 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