Detailed Action
Continued Examination Under 37 CFR 1.114
A request for continued examination (RCE) under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 3, 2025 has been entered.
Acknowledgements
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the RCE filed on December 3, 2025.
Claims 1-20 are pending.
Claims 1-20 are examined.
This Office Action is given Paper No. 20260306 for references purposes only.
Claim Objections
Claims 1 and 18 are objected to because they recite “validation process involving multiple network nodes.” Examiner assumes that Applicant intended “validation process involving the multiple network nodes.” Appropriate correction is required.
Claim 18 recites “executed by a computer processor.” Examiner assumes that Applicant intended “executed by the computer processor.” Appropriate correction is required.
Claim Rejections - 35 USC § 112b
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION - The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-5, 7-9, and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 3-5 and 7 recite “the one or more changes to the elements.” This phrase is vague and indefinite because it is unclear whether this refers to “the contract state changes” or to “the state transitions in elements.” For purposes of applying the prior art only, Examiner will interpret as “the state transitions in elements.”
Claim 17 recites “the liability.” There is lack of antecedent basis for this term. For purposes of applying the prior art only, Examiner will interpret as “a liability.”
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 a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 2A Prong 1: The claims recite an abstract idea of creating and tracking changes to a contract, which is a certain method of organizing human activity (e.g. fundamental economic principles or practices including hedging, insurance, mitigating risk; commercial or legal interactions including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, business relations; managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions).
Claim 1, representative of claim 18, includes the following limitations:
receiving a smart contract code for a smart contract formed by a set of rules related to one type of user activities;
broadcasting the compiled smart contract bytecode;
determining that the compiled smart contract has been accepted by a ledger consensus through a cryptographic validation process;
generating a cryptographic hash function for the smart contract that creates immutable fingerprints of contract state changes, wherein the hash function tracks state transitions in elements included in the set of rules;
broadcasting the updated hash values representing the modified contract states.
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
compiling the smart contract code into bytecode for distributed consensus validation;
a distributed ledger network.
These additional elements are not indicative of integration into a practical application because:
Regarding “compiling the smart contract code into bytecode for distributed consensus validation”, it generally links the use of the judicial exception to a particular technological environment or field of use. See MPEP 2106.05(h).
Regarding “a distributed ledger network”, this adds the words “apply it” (or an equivalent) with the judicial exception, or are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05(f).
Step 2B: The claim limitations do not recite additional elements, or an ordered combination of additional elements, that are sufficient to amount to significantly more than the judicial exception.
As discussed with respect to step 2A prong 2 above, the additional element of “a distributed ledger network” is mere instructions to apply an exception, and does not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional element of “a distributed ledger network” is re-evaluated to determine whether it constitutes significantly more. Examiner finds that the additional element of “a distributed ledger network” is simply the use of a computer in its ordinary capacity and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262 and MPEP 2106.05(f). For example, the additional elements only provide a result-oriented solution and lack details as to how the computer performs the modifications, which is equivalent to “apply it”. See Alice Corp. v. CLS Bank, 134 S. Ct. 2347, 2357 and MPEP 2106.05(f).
As discussed with respect to step 2A prong 2 above, the additional element of “compiling the smart contract code into bytecode for distributed consensus validation” generally links the use of the judicial exception to a particular technological environment or field of use, and does not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the 2019 PEG, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional element of “compiling the smart contract code into bytecode for distributed consensus validation” is re-evaluated to determine whether it constitutes significantly more. Examiner finds that the additional element of “compiling the smart contract code into bytecode for distributed consensus validation” is merely an attempt to limit the use of the abstract idea to a particular technological environment. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05(h). Additionally, “compiling the smart contract code into bytecode for distributed consensus validation” merely limits the claims to the computer field. See FairWarning v. Iatric Sys., 839 F.3d 1089, 1094-95 and MPEP 2106.05(h).
Therefore, when considering all the additional claim elements both individually and as an ordered combination, Examiner finds that the claim does not amount to significantly more than the exception.
The dependent claims fail to cure this deficiency and are rejected accordingly.
Claim 2 recites defining the set of rules as a digital token representing a liability, which is merely describing data and further defining the abstract idea.
Claims 3-4 recite modifying a value or term, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 5 recites broadcasting updated elements, which generally links the use of the judicial exception to a particular technological environment or field of use (e.g. merely an attempt to limit the use of the abstract idea to a particular technological environment). See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05(h).
Claim 6 recites the token comprises a string of bytes, which is merely describing data and further defining the abstract idea.
Claim 7 recites causing the string of bytes to change from one state to another state, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 8 recites tracking criteria, which is insignificant extra-solution activity (e.g. mere data gathering). See CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, and MPEP 2106.05(g).
Claim 9 recites the token comprises a tangible value, which is merely describing data and further defining the abstract idea.
Claim 10 recites the rules comprise terms of a contract, which is merely describing data and further defining the abstract idea.
Claims 11 and 13 recite the token dynamically adjusts a liability value, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
Claim 12 recites the different types of financial liability value, which is merely describing data and further defining the abstract idea.
Claims 14-16 recite the rules relate to one type of user activities, which is merely describing data and further defining the abstract idea.
Claim 17 recites triggering another rule, which is insignificant extra-solution activity (e.g. selecting a particular data source or type of data to be manipulated). See Electric Power Group, and MPEP 2106.05(g).
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ketchel, III (US 2021/0342909) in view of Chow et al. (US 2019/0087792).
Claims 1, 18
Ketchel discloses:
receiving a smart contract code for a smart contract (smart contract, see [0020]) formed by a set of rules (e.g. patient lifecycle events, see [0167]) related to one type of user activities;
compiling the smart contract code into bytecode executable by a distributed ledger network (distributed ledger, DL, see [0012, 0058]) using a blockchain-specific compiler that transforms high-level contract logic into machine-readable instructions (programming languages, see [0263, 0481]) for distributed consensus validation (verified by consensus, see [0090]);
broadcasting (broadcast, see [0012, 0058]) the compiled smart contract bytecode into the distributed ledger network through a peer-to-peer protocol that propagates the bytecode to multiple network nodes (one or more computer-implemented node, see [0100]);
determining that the compiled smart contract has been accepted by a ledger consensus (verified by consensus, see [0090, 0098]) through a cryptographic validation process (transactions verified based on hashing each token header and verifying the owner signature, see [0098]) involving multiple network nodes verifying the bytecode integrity and executing consensus algorithms.
Ketchel does not disclose:
generating… rules;
automatically… nodes.
Chow teaches:
generating a cryptographic hash function (cryptographic hash, see [0025]) for the smart contract (contracts, see [0070]) that creates immutable fingerprints of contract state changes (terms updated due to change in status, see [0128, 0137]), wherein the hash function is configured to interact with the smart contract bytecode to automatically detect and track state transitions (changes to the document, see [0128]) in elements included in set of rules (established rules, see [0072]);
automatically broadcast updated hash values representing modified contract states to the distributed ledger network (changes to the document are recorded on the distributed ledger, see [0128]) for across all network nodes.
Ketchel discloses receiving a smart contract code, compiling the smart contract code into bytecode, broadcasting the bytecode into the distributed ledger network, and determining the compiled smart contract was accepted by the ledger consensus. Ketchel does not disclose generating a cryptographic hash function and broadcasting the updated hash values, but Chow does. It would have been obvious to one of ordinary skill in the art at the effective filing date of the invention to combine the creating digital health assets of Ketchel with the generating a cryptographic hash function and broadcasting the updated hash values of Chow because 1) a need exists for encoding a digital asset representing a service bundle, where the asset may be a token that can transfer possession or ownership, verify ownership, change state, or access a bundled service (see Ketchel [0010]); and 2) a need exists for tracking assets in secure, high-risk and sensitive contexts (see Chow [0003]). Generating a cryptographic hash function and broadcasting the updated hash values can help verify transfer of possession or ownership or changed states.
Claims 2, 19
Furthermore, Ketchel discloses:
the smart contract code for the smart contract formed by the set of rules comprises pieces of software that define the set of rules as a digital token (digital token, see [0089]) as a tokenized representation of a liability between two entities (e.g. providers, consumers, administrators, insurers, see [0102]).
Claims 3, 20
Furthermore, Ketchel discloses:
in response to the one or more changes to the elements included in the set of rules, modifying a value of the liability (e.g. based on asset class, see [0112]) associated with the digital token.
Claim 4
Furthermore, Ketchel discloses:
in response to the one or more changes to the elements included in the set of rules, modifying one or more terms (modifying a contract, see [0101]) in the smart contract associated with the digital token.
Claim 5
Furthermore, Ketchel discloses:
in response to the one or more changes to the elements included in the set of rules, broadcasting updated elements (broadcast, see [0101]) to the distributed ledger network including the distributed ledger for reconciliation.
Claim 6
Furthermore, Ketchel discloses:
the digital token (digital token, see [0464]) comprises a string of bytes (e.g. header, payload, see [0464]) for entering into the distributed ledger (distributed ledger, see [0464]).
Claim 7
Furthermore, Ketchel discloses:
the digital token comprises computer executable instructions that cause a change of the string of bytes from one state to another state (change state, see abstract, [0010]) in response to the one or more changes to the elements included in the set of rules.
Claim 8
Furthermore, Ketchel discloses:
the computer executable instructions comprise a script that tracks criteria and modify the computer executable instructions in response to a change in the criteria (status changes, see [0111]).
Claim 9
Furthermore, Ketchel discloses:
the digital token comprises a tangible value that appreciates or depreciates (deflationary or inflationary, see [0456, 0460]) based on the change of the string of bytes from one state to another state.
Claim 10
Furthermore, Ketchel discloses:
the set of rules comprise terms of a contract (smart contract obligating resource to provide the service, see [0016]) between an issuer (providers, see [0102]) and a creditor (insurers, see [0102]).
Claim 11
Furthermore, Ketchel discloses:
the digital token is configured to dynamically adjust (inflationary or deflationary, see [0456, 0460]) a financial liability value of a liability (price adjusted based on supply and demand, see [0237]) based on actuarial redemption assumptions (e.g. more medically relevant additional procedures, bundled set of services vs. uninsured, see [0194, 0275]) built into a rule included in the set of rules.
Claim 12
Furthermore, Ketchel discloses:
the financial liability value of the liability is a customer loyalty incentive value included in a customer loyalty incentive program (patients in network vs. uninsured vs. high deductible insurance plan, see [0275]).
Claim 13
Furthermore, Ketchel discloses:
the digital token is configured to dynamically adjust (e.g. discount, reduce cost, inflationary or deflationary, see [0194, 0456, 0460]) a liability redemption value based on one or more of a bearer’s identity (primary service ordered by a doctor, see [0189]), previous financial and non-financial behavior (patient lifecycle event, see [0194]).
Claim 14
Furthermore, Chow teaches:
the set of rules related to one type of user activities include a built-in rule that periodically pings a Global Positioning System (GPS) device or beacon (sensor devices, see [0116-0118]) for detecting whether a user is in proximity to a physical location (location, see [0116-0118]).
Claim 15
Furthermore, Ketchel discloses:
the set of rules related to one type of user activities further include a rule that offers an incentive value based on the user’s patronizing a business in the physical location (specific location, see [0032]).
Claim 16
Furthermore, Ketchel discloses:
the set of rules related to one type of user activities further include a rule that offers an incentive value based on a frequency of the user’s patronizing a business in the physical location (services within same facility, see [0189]).
Claim 17
Furthermore, Ketchel discloses:
one or more user activities (services within same or similar facility or time slot, see [0189]) performed by the user trigger another rule that adjusts a value of the liability (reduced cost, see [0189]) associated with the digital token.
Response to Arguments
101 arguments
Please see revised rejection in light of the amendments. Applicant argues that using the hash function to track or monitor changes allows for dynamic liability management, which is significantly more than the abstract idea.
Examiner disagrees. Tracking changes is part of the abstract idea of creating and tracking changes to a contract, which is a certain method of organizing human activity. It does not add significantly more to the abstract idea.
Claim Interpretation
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure (see attached form PTO-892).
Forbes, Jr. et al. (US 2017/0358041) discloses systems and methods for advanced energy settlements, network-based messaging, and applications supporting the same on a blockchain platform.
Examiner hereby adopts the following definitions under the broadest reasonable interpretation standard. In accordance with In re Morris, 127 F.3d 1048, 1056, 44 USPQ2d 1023, 1029 (Fed. Cir. 1997), Examiner points to these other sources to support her interpretation of the claims.1 Additionally, these definitions are only a guide to claim terminology since claim terms must be interpreted in context of the surrounding claim language. Finally, the following list is not intended to be exhaustive in any way:
configuration “(1) (A) (software) The arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts.” “(C) The physical and logical elements of an information processing system, the manner in which they are organized and connected, or both. Note: May refer to hardware configuration or software configuration.” IEEE 100 The Authoritative Dictionary of IEEE Standards Terms, 7th Edition, IEEE, Inc., New York, NY, Dec. 2000.
Conclusion
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from Examiner should be directed to Chrystina Zelaskiewicz whose telephone number is 571-270-3940. Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Neha Patel can be reached at 571-270-1492.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov>. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free).
/CHRYSTINA E ZELASKIEWICZ/Primary Examiner, Art Unit 3699
1 While most definition(s) are cited because these terms are found in the claims, Examiner may have provided additional definition(s) to help interpret words, phrases, or concepts found in the definitions themselves or in the prior art.