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 office action for the 19/003720 application is in response to the communications filed April 23, 2026.
Claims 1-3, 5-11, and 13-20 were amended April 23, 2026.
Claims 4 and 12 were cancelled April 23, 2026.
Claims 21 and 22 were added as new April 23, 2026.
Claims 1-3, 5-11, and 13-22 are currently pending and considered below.
Claim Rejections - 35 USC § 112
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 and 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 3 and 11,
These claims recite the limitation of “the medical comprises”. This limitation lacks antecedent basis and is therefore considered to be indefinite. For the purposes of examination, the Examiner will interpret this limitation as “the medical context comprises”.
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-3, 5-11, and 13-22 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.
As per claim 1,
Step 1: The claim recites subject matter within a statutory category as a machine.
Step 2A is a two-prong inquiry, in which Prong 1 determines whether a claim recites a judicial exception. Prong 2 determines if the additional limitations of the claim integrates the recited judicial exception into a practical application. If the additional elements of the claim fail to integrate the judicial exception into a practical application, claim is directed to the recited judicial exception, see MPEP 2106.04(II)(A).
Step 2A Prong 1: The claim contains subject matter that recites an abstract idea, with the steps of receives Fast Healthcare Interoperability Resources (FHIR), the FHIR including unstructured medical report text associated with medical reports and extracts unstructured information for the medical reports from the unstructured medical report text and generates structured data representing extracted entities from the medical reports based on the unstructured information, and integrates the structured data into original FHIR resources. These steps, as drafted, under the broadest reasonable interpretation recite:
certain methods of organizing human activity (e.g., fundamental economic principles or practices including: hedging; insurance; mitigating risk; etc., commercial or legal interactions including: agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations; etc., managing personal behavior or relationships or interactions between people including: social activities; teaching; following rules or instructions; etc.) but for recitation of generic computer components. That is, other than reciting steps as performed by the generic computer components, nothing in the claim element precludes the step from being directed to certain methods of organizing human activity. The identified abstract idea, law of nature, or natural phenomenon identified above, in the context of this claim, encompasses a certain method of organizing human activity, namely managing personal behavior or relationships or interactions between people. This is because each of the limitations of the abstract idea recites a list of rules or instructions that a human person can follow in the course of their personal behavior. If a claim limitation, under its broadest reasonable interpretation, covers at least the recited methods of organizing human activity above, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. See MPEP 2106.04(a).
Step 2A Prong 2: The claim does not recite additional elements that integrate the judicial exception into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements amount to no more than limitations which:
amount to mere instructions to apply an exception, see MPEP 2106.05(f), such as:
“A system comprising: a memory configured to store computer-executable components; and a processor that executes at least one of the computer-executable components that”, “JavaScript Object Notation (JSON)”, “JSON”, “as FHIR extension elements” which corresponds to merely using a computer as a tool to perform an abstract idea. Paragraph [00121] of the as-filed specification describes that the hardware that implements the steps of the abstract idea amount to nothing more than a generic computer. Implementing an abstract idea on a generic computer, does not integrate the abstract idea into a practical application in Step 2A Prong Two or add significantly more in Step 2B, similar to how the recitation of the computer in the claim in Alice amounted to mere instructions to apply the abstract idea of intermediated settlement on a generic computer.
add insignificant extra-solution activity to the abstract idea, see MPEP 2106.05(g), such as:
“from a FHIR server” and “by using pre-designed a tree of large language model (LLM) prompts and logic for navigating the tree as a function of prompt responses, wherein given a medical report, a first prompt from the tree is submitted to an LLM service and an answer from the LLM service is used to automatically select a subsequent prompt in the tree without human intervention” which corresponds to mere data gathering and/or output.
Accordingly, this claim is directed to an abstract idea.
Step 2B: The claim does not recite additional elements that amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and/or generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, identified as insignificant extra-solution activity to the abstract idea, amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields such as:
computer functions that have been identified by the courts as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity, see MPEP 2106.05(d)(II), such as:
“from a FHIR server” which corresponds to receiving or transmitting data over a network.
computer functions that have been identified by the examiner as being well‐understood, routine, and conventional functions in light of the prior art, wherein the examiner has provided multiple references as evidence as required by Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018), see MPEP 2106.05(d)(I), such as:
“by using pre-designed a tree of large language model (LLM) prompts and logic for navigating the tree as a function of prompt responses, wherein given a medical report, a first prompt from the tree is submitted to an LLM service and an answer from the LLM service is used to automatically select a subsequent prompt in the tree without human intervention” is well-known, routine and conventional computer and machine learning activity applied in a medical context in view of:
Mishra et al. (US 2025/0086405; herein referred to as Mishra) at Paragraphs [0003] and [0004]: “Some implementations disclosed herein are directed to at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.”
Ma et al. (US 2025/0173043; herein referred to as Ma) at Paragraphs [0080] and [0081]: “The input prompt is broken down into a plurality of sub-prompts, in this example two sub-prompts, in a second layer of nodes 304 of the prompt tree. In this example, the sub-prompts are “Plan daily itineraries” 304A and “Identify key dates and duration for the Tokyo trip” 304B. In this case, one of the prompts is broken down into further sub-prompts, so this prompt in the first layer of nodes 304 in this example includes a branch node 304A. The other of the sub-prompts in the first layer of nodes 304 in this example is a leaf node 304B that corresponds to sub-prompt that cannot be (or is not) broken down further. In some implementations, there may be a limit on the number of layers in the prompt tree 300, the number of total nodes in the prompt tree 300, and/or the number of nodes in each layer of the prompt tree 300. One or more of the sub-prompts that form the second layer of the prompt tree 300 may be further broken down into a third layer 306 of sub-prompts. Each node in the third layer 306 may itself be a branch node (i.e., correspond to a sub-prompt that can be (or is) broken down further into simpler sub-prompts) or a leaf node (e.g., correspond to a sub-prompt that cannot be (or is not) broken down further, i.e., a simple sub-prompt, or a sub-prompt that is actionable by an external application). In the example shown, the third layer 306 of sub-prompts has two leaf nodes 306A and 306B, corresponding to the simple sub-prompts “Identify user interests” 306A, “Identify dietary requirements” 306B.”
Dong et al. (US 2025/0363156; herein referred to as Dong.) at Paragraph [0013]: “This system may also improve long-term output quality by utilizing a cascading series of prompts in which the system iteratively inputs a prompt to the model at-issue, analyzes the model output to determine a next prompt, inputs this next prompt, and analyzes the model output to determine a next prompt. In this manner, the system may reference a “tree” of prompts, with each prompt serving as an end node (e.g., the output of the model in response to that prompt is a final output) or as a decision node to further prompts (e.g., the output of the model in response to that prompt is analyzed by the system to determine the subsequent prompt node). In some embodiments, a given tree of prompts, and the logic governing the progression from prompt to prompt within the tree, may be pre-determined and specific to a particular domain, such that the same tree may be repeatedly used to elicit high-quality output from the model within that domain. In some embodiments, the prompt tree may be used by a deployed system. In other embodiments, the final outputs (e.g., the outputs generated in response to end nodes in the tree) may be used to train the model at-issue, and this retrained model may be used in deployment without the prompt tree, which may offer a faster deployed system.”
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 2,
Claim 2 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 2 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“further comprising …extracts medical-related entities from the medical reports, wherein the medical-related entities are provided as input.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“a Natural Language Processing (NLP) system that” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“to the tree of LLM prompts” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and computer functions that have been identified by the examiner as being well‐understood, routine, and conventional functions in light of the prior art.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 3,
Claim 3 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 3 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein each prompt is associated to medical context of an input and a patient to improve accuracy… and wherein the medical context comprises at least one of report type, treatment phase, cancer type, or patient state” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“wherein the at least one of the computer-executable components”, “from the tree of prompts”, and “to improve accuracy of the LLM” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“generates prompts from the tree of LLM prompts” and “of the LLM” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and computer functions that have been identified by the examiner as being well‐understood, routine, and conventional functions in light of the prior art.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 5,
Claim 5 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 5 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the first prompt is designed to extract patient treatment type and clinical phase from the medical report” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“automatically” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 6,
Claim 6 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 6 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein subsequent prompts target specific subsets of extracted entities for refinement or clarification.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and computer functions that have been identified by the examiner as being well‐understood, routine, and conventional functions in light of the prior art.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 7,
Claim 7 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 7 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein subsequent prompts address ambiguities or conflicts in extracted data and add fine tuning to a core specialty.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and computer functions that have been identified by the examiner as being well‐understood, routine, and conventional functions in light of the prior art.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 8,
Claim 8 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 8 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the tree of LLM prompts is fixed, and answers to prompts at a root level of the tree are used to select prompts from one or more lower levels of the tree such that the tree is dynamically expanded.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 9,
Claim 9 is substantially similar to claim 1. Accordingly, claim 9 is rejected for the same reasons as claim 1.
As per claim 10,
Claim 10 is substantially similar to claim 2. Accordingly, claim 10 is rejected for the same reasons as claim 2.
As per claim 11,
Claim 11 is substantially similar to claim 3. Accordingly, claim 11 is rejected for the same reasons as claim 3.
As per claim 13,
Claim 13 is substantially similar to claim 5. Accordingly, claim 13 is rejected for the same reasons as claim 5.
As per claim 14,
Claim 14 is substantially similar to claim 6. Accordingly, claim 14 is rejected for the same reasons as claim 6.
As per claim 15,
Claim 15 is substantially similar to claim 7. Accordingly, claim 15 is rejected for the same reasons as claim 7.
As per claim 16,
Claim 16 is substantially similar to claim 8. Accordingly, claim 16 is rejected for the same reasons as claim 8.
As per claim 17,
Claim 17 is substantially similar to claim 1. Accordingly, claim 17 is rejected for the same reasons as claim 1.
As per claim 18,
Claim 18 is substantially similar to claim 2. Accordingly, claim 18 is rejected for the same reasons as claim 2.
As per claim 19,
Claim 19 is substantially similar to claim 3. Accordingly, claim 19 is rejected for the same reasons as claim 3.
As per claim 20,
Claim 20 is substantially similar to claim 5. Accordingly, claim 20 is rejected for the same reasons as claim 5.
As per claim 21,
Claim 21 is substantially similar to claim 6. Accordingly, claim 21 is rejected for the same reasons as claim 6.
As per claim 22,
Claim 22 is substantially similar to claim 7. Accordingly, claim 22 is rejected for the same reasons as claim 7.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-11, and 13-22 are rejected under 35 U.S.C. 103 as being unpatentable over Santiago (US 2025/0046407) in view of Mishra.
As per claim 1,
Santiago teaches a system comprising: a memory configured to store computer-executable components; a processor that executes at least one of the computer-executable components:
(Paragraph [0157] of Santiago. The teaching describes machine 600 may include processors 604, memory 606, and input/output I/O components 608, which may be configured to communicate with each other via a bus 610. In an example, the processors 604 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) Processor, a Complex Instruction Set Computing (CISC) Processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 612 and a processor 614 that execute the instructions 602. The term “processor” is intended to include multi-core processors that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. Although FIG. 6 shows multiple processors 604, the machine 600 may include a single processor with a single-core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiples cores, or any combination thereof.)
Santiago further teaches receives Fast Healthcare Interoperability Resources (FHIR) from a FHIR server, the FHIR including unstructured medical report text associated with medical reports:
(Paragraphs [0003], [0004], [0016], [0105] and [0114] of Santiago. The teaching describes that Fast Healthcare Interoperability Resources (FHIR, pronounced “fire”) is an innovative, next-generation standards framework developed by Health Level Seven International (HL7), a not-for-profit standards developing organization that's dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information. FHIR leverages contemporary web-based suite of API technology for user interface integration. This FHIR interoperability framework is designed to simplify implementation without sacrificing information integrity, being capable of modeling complex healthcare relationships and processes. FHIR is a standards framework for the exchange, integration, sharing, and retrieval of electronic health information. FHIR is built upon the concept of “Resources,” which are modular components of interoperable health data. These Resources can represent clinical data like patients, practitioners, medications, and observations, or non-clinical data like devices, locations, and organizations. FHIR uses web-based technologies such as HTTP, HTML, CSS, JSON, XML, and RDF for data representation, which simplifies implementation and ensures greater interoperability between disparate health IT systems. The AI system implements touchless sensors & IoT integration by conversion of electromagnetic waveform perturbations from touchless sensors into FHIR-compatible content, enabling comprehensive monitoring by EMRs or FHIR servers via IoT-enabled devices. This allows for real-time, remote monitoring of patient status and early detection of adverse events useful in phase 1 and 2 research trials as well as remote monitoring for home bound individuals with subacute or chronic diseases. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs.)
Santiago further teaches an extraction component that extracts unstructured information for medical reports by using a tree of large language model (LLM) prompts:
(Paragraphs [0060], [0111]-[0114] and [0121] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions.)
Santiago further teaches generates JavaScript Object Notation (JSON) structured data representing extracted entities from the medical reports based on the unstructured information, and integrates the JSON structured data into original FHIR resources as FHIR extension elements”
(Paragraphs [0016] and [0102] of Santiago. The teaching describes FHIR is a standards framework for the exchange, integration, sharing, and retrieval of electronic health information. FHIR is built upon the concept of “Resources,” which are modular components of interoperable health data. These Resources can represent clinical data like patients, practitioners, medications, and observations, or non-clinical data like devices, locations, and organizations. FHIR uses web-based technologies such as HTTP, HTML, CSS, JSON, XML, and RDF for data representation, which simplifies implementation and ensures greater interoperability between disparate health IT systems. the AI system provides a comprehensive, full-focused healthcare framework that harnesses machine learning and natural language processing (NLP) to integrate seamlessly with Fast Healthcare Interoperability Resources (FHIR) and blockchain technology, realtime updates, enhancing interoperability and data security. This means that the system can generate updates for the FHIR and structure these updates in a compatible format such as JSON.)
Santiago does not explicitly teach extracts unstructured information for the medical reports from the unstructured medical report text by using pre-designed a tree of large language model (LLM) prompts and logic for navigating the tree as a function of prompt responses, wherein given a medical report, a first prompt from the tree is submitted to an LLM service and an answer from the LLM service is used to automatically select a subsequent prompt in the tree without human intervention.
However, Mishra teaches extracts unstructured information from text by using pre-designed a tree of large language model (LLM) prompts and logic for navigating the tree as a function of prompt responses, wherein given a prompt, a first prompt from the tree is submitted to an LLM service and an answer from the LLM service is used to automatically select a subsequent prompt in the tree without human intervention:
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the LLM of Santiago, the prompt tree of Mishra. Paragraph [0004] of Mishra teaches that the use of prompt trees in LLMs provide improved performance of the model with complex prompts. One of ordinary skill in the art in possession of Santiago would have looked to this prompt tree advantage and incorporated it into Santiago. One of ordinary skill in the art would have added to the teaching of Santiago, the teaching of Mishra based on this incentive without yielding unexpected results.
The combined teaching of Santiago and Mishra would have then taught extracts unstructured information for the medical reports from the unstructured medical report text by using pre-designed a tree of large language model (LLM) prompts and logic for navigating the tree as a function of prompt responses, wherein given a medical report, a first prompt from the tree is submitted to an LLM service and an answer from the LLM service is used to automatically select a subsequent prompt in the tree without human intervention:
(Paragraphs [0060], [0111]-[0114] and [0121] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions.)
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
As per claim 2,
The combined teaching of Santiago and Mishra teaches the limitations of claim 1.
The combined teaching of Santiago and Mishra further teaches further comprising a Natural Language Processing (NLP) system that extracts medical-related entities from the medical reports, wherein the medical-related entities are provided as input to the tree of LLM prompts:
(Paragraphs [0060], [0111]-[0114] and [0121] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions.)
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
As per claim 3,
The combined teaching of Santiago and Mishra teaches the limitations of claim 1.
The combined teaching of Santiago and Mishra further teaches wherein the at least one of the computer-executable components further generates prompts from the tree of prompts, where each prompt is associated to medical context of an input and a patient to improve accuracy of the LLM, and wherein the medical context comprises at least one of report type, treatment phase, cancer type, or patient state:
(Paragraphs [0060], [0111]-[0114] and [0121] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions.)
(Paragraphs [0016] and [0102] of Santiago. The teaching describes FHIR is a standards framework for the exchange, integration, sharing, and retrieval of electronic health information. FHIR is built upon the concept of “Resources,” which are modular components of interoperable health data. These Resources can represent clinical data like patients, practitioners, medications, and observations, or non-clinical data like devices, locations, and organizations. FHIR uses web-based technologies such as HTTP, HTML, CSS, JSON, XML, and RDF for data representation, which simplifies implementation and ensures greater interoperability between disparate health IT systems. the AI system provides a comprehensive, full-focused healthcare framework that harnesses machine learning and natural language processing (NLP) to integrate seamlessly with Fast Healthcare Interoperability Resources (FHIR) and blockchain technology, realtime updates, enhancing interoperability and data security. This means that the system can generate updates for the FHIR and structure these updates in a compatible format such as JSON.)
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
As per claim 5,
The combined teaching of Santiago and Mishra teaches the limitations of claim 1.
Santiago further teaches wherein the first prompt is designed to extract patient treatment type and clinical phase automatically from the medical report:
(Paragraphs [0060], [0105], [0111]-[0114], [0121] and [0202] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions. Query data 928 is provided as an input to the trained machine-learning program 902, and the trained machine-learning program 902 generates the prediction/inference data 922 as output, responsive to receipt of the query data 928. Query data can include a prompt, such as a user entering a textual question or speaking a question audibly. In some cases, the system generates the query based on an interaction function occurring in the system, such as a user interacting with a virtual object, a user sending another user a question in a chat window, or an object detected in a camera feed. the AI system implements touchless sensors & IoT integration by conversion of electromagnetic waveform perturbations from touchless sensors into FHIR-compatible content, enabling comprehensive monitoring by EMRs or FHIR servers via IoT-enabled devices. This allows for real-time, remote monitoring of patient status and early detection of adverse events useful in phase 1 and 2 research trials as well as remote monitoring for home bound individuals with subacute or chronic diseases)
As per claim 6,
The combined teaching of Santiago and Mishra teaches the limitations of claim 1.
The combined teaching of Santiago and Mishra further teaches wherein subsequent prompts target specific subsets of extracted entities for refinement or clarification:
(Paragraphs [0060], [0111]-[0114], [0121] and [0202] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions. Query data 928 is provided as an input to the trained machine-learning program 902, and the trained machine-learning program 902 generates the prediction/inference data 922 as output, responsive to receipt of the query data 928. Query data can include a prompt, such as a user entering a textual question or speaking a question audibly. In some cases, the system generates the query based on an interaction function occurring in the system, such as a user interacting with a virtual object, a user sending another user a question in a chat window, or an object detected in a camera feed.)
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
As per claim 7,
The combined teaching of Santiago and Mishra teaches the limitations of claim 1.
The combined teaching of Santiago and Mishra further teaches wherein subsequent prompts address ambiguities or conflicts in extracted data and add fine tuning to a core specialty:
(Paragraphs [0060], [0111]-[0114], [0121] and [0202] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions. Query data 928 is provided as an input to the trained machine-learning program 902, and the trained machine-learning program 902 generates the prediction/inference data 922 as output, responsive to receipt of the query data 928. Query data can include a prompt, such as a user entering a textual question or speaking a question audibly. In some cases, the system generates the query based on an interaction function occurring in the system, such as a user interacting with a virtual object, a user sending another user a question in a chat window, or an object detected in a camera feed.)
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
As per claim 8,
The combined teaching of Santiago and Mishra teaches the limitations of claim 1.
The combined teaching of Santiago and Mishra further teaches wherein the tree of prompts is fixed and answers to prompts at a root level of the tree are used to select prompts from one or more lower levels of the tree such that the tree is dynamically expanded:
(Paragraphs [0060], [0111]-[0114] and [0121] of Santiago. The teaching describes that the AI system samples and/or builds the LLM. The AI system chooses an existing LLM or creates a new one. The AI system can select an appropriate pre-trained model, which can be a good starting point, one that is already trained to understand general language patterns. Such models can be further fine-tuned for specific tasks using additional training data. The AI system refines the LLM by training the LLM with medical language NPL. The AI system refines the LLM with Medical Language NLP by fine-tuning the model to better understand and process medical language. Medical language can be quite different from common language due to its specific terms, abbreviations, and phrase structures. The refinement process involves training the model on medical datasets, which may include electronic health records, medical literature, clinical trial reports, etc. This allows the LLM to understand medical terminology, recognize the context in which terms are used, understand complex medical sentences, and make accurate predictions or classifications based on these inputs. The LLM is trained to process disease specific treatment algorithms to generate expression logic models (such as CQL models) compatible for FHIR. In some cases, the AI system applies a language model integration framework that connects one or more LLMs together. Moreover, the language model integration framework enables physicians to provide their own disease specific treatment algorithms and/or modifications to standard or predefined disease specific treatment algorithms, such as algorithms specific to their practice or patients. In some examples, one or more LLMs are used in order to receive one or more disease specific treatment algorithms, such as for a patient with multiple diseases. The language model integration framework is configured to apply prompt templates to determine the intent of the physicians based on a physician's prompt. As such, these language model integration frameworks better understand what physicians are asking for. Treatment guidelines, often formulated by medical experts and health organizations, provide detailed protocols to manage a particular disease. These guidelines can be seen as a series of decision trees-based on the current state of a patient, a decision (like prescribing a specific drug or running a particular test) is made, which further leads to other decisions.)
(Paragraphs [0003] and [0004] of Mishra. The teaching describes at least augmenting a training and/or evaluation dataset with LLM prompts (e.g., derived from user queries) based on a prompt complexity. An input prompt, for example derived from a user query, is received. The input prompt is decomposed into a prompt tree comprising a plurality of nodes. The plurality of nodes comprise: a plurality of leaf nodes corresponding to simple sub-prompts of the input query; a plurality of branch nodes of sub-prompts each corresponding to multiple simple sub-prompts; and a root node corresponding to the input prompt. A prompt complexity is determined based on a path length of the prompt tree. The prompt complexity is compared to a threshold complexity. If the prompt complexity is above the threshold complexity, the input prompt is included in a set of training prompts and/or a set of evaluation prompts. In these, and other, manners, the complexity of prompts for an LLM can be quantified. The quantification can be utilized to identify hard prompts for inclusion in a set of training prompts and/or evaluation prompts. Such training sets can be used to train LLMs (e.g., fine tune an existing LLM or train a new LLM) that have improved performance on complex prompts. Furthermore, the prompt complexity can be utilized to: (1) form hierarchies in the evaluation dataset to better understand the strength and weakness of an LLM; (2) control a degree of prompt hardness while filtering prompts from logs to continuously update the evaluation/training dataset; and/or (3) balance an instruction-tuning mixture, and control the distribution of prompt complexity to match with a user prompt distribution as evident from logs. Notably, utilization of the length of the prompt tree in determining the prompt complexity can, for various prompt pairs, result in determining a prompt complexity, for a shorter text-length of the prompts, that indicates greater complexity than does a determined prompt complexity for a longer text-length text of the prompts. Put another way, utilization of the length of the prompt tree of a prompt in determining prompt complexity, as opposed to only utilization of a text-length of the prompt, results in more accurate quantification of the complexity of the prompt.)
As per claim 9,
Claim 9 is substantially similar to claim 1. Accordingly, claim 9 is rejected for the same reasons as claim 1.
As per claim 10,
Claim 10 is substantially similar to claim 2. Accordingly, claim 10 is rejected for the same reasons as claim 2.
As per claim 11,
Claim 11 is substantially similar to claim 3. Accordingly, claim 11 is rejected for the same reasons as claim 3.
As per claim 13,
Claim 13 is substantially similar to claim 5. Accordingly, claim 13 is rejected for the same reasons as claim 5.
As per claim 14,
Claim 14 is substantially similar to claim 6. Accordingly, claim 14 is rejected for the same reasons as claim 6.
As per claim 15,
Claim 15 is substantially similar to claim 7. Accordingly, claim 15 is rejected for the same reasons as claim 7.
As per claim 16,
Claim 16 is substantially similar to claim 8. Accordingly, claim 16 is rejected for the same reasons as claim 8.
As per claim 17,
Claim 17 is substantially similar to claim 1. Accordingly, claim 17 is rejected for the same reasons as claim 1.
As per claim 18,
Claim 18 is substantially similar to claim 2. Accordingly, claim 18 is rejected for the same reasons as claim 2.
As per claim 19,
Claim 19 is substantially similar to claim 3. Accordingly, claim 19 is rejected for the same reasons as claim 3.
As per claim 20,
Claim 20 is substantially similar to claim 5. Accordingly, claim 20 is rejected for the same reasons as claim 5.
As per claim 21,
Claim 21 is substantially similar to claim 6. Accordingly, claim 21 is rejected for the same reasons as claim 6.
As per claim 22,
Claim 22 is substantially similar to claim 7. Accordingly, claim 22 is rejected for the same reasons as claim 7.
Response to Arguments
Applicant's arguments filed April 23, 2026 have been fully considered.
Applicant’s arguments pertaining to rejections made under 35 U.S.C. 101 are not persuasive.
The Applicant argues that the limitations of the independent claims provide a technical solution to a technical problem. Specifically, by decomposing information extracted into conditional prompt paths instead of a single monolithic prompt or a flat set of prompts, the system reduces hallucinations, improves extraction accuracy for nuanced oncology concepts, and produces standardized, interoperable structured data that can reliably consumed by CDS tools, patient dashboards and other downstream applications.
The Examiner respectfully disagrees. From what the Examiner has been able to ascertain, these argued improvements stem from prompt trees, which are well-known, routine and conventional elements in the field of LLMs. Such evidence of it conventionality is provided in the rejection above. The Applicant has asserted that through these prompt trees, technical advantage is being leveraged. However, it would appear that the Applicant is merely applying known methods of LLM functions and applying them to the field of healthcare informatics to achieve the advantages that have already been attained in other fields of computing as opposed to providing an improvement to technology as a whole. Accordingly, the Examiner is not persuaded by this argument.
The Applicant further argues that the pending claims do not recite a judicial exception. Specifically, the generation component is not recited as producing human-readable summaries or workflow reminders, it must generate JSON structured data and integrate the JSON data into the original FHIR resources. Such functions cannot reasonably be treated as managing personal behavior.
The Examiner respectfully disagrees. The generation of data is the element in question as it pertains to the recitation of the abstract idea. The elements and context of JSON and FHIR formats provide the additional elements to this generation element. Generation of data per se is abstract because data in of itself is inherently abstract. A human person is more than capable of generating data, if for no other reason, the Examiner is writing this response to the Applicant as a process of his own faculty and personal behavior. This, in of itself, does not establish the abstract idea recited by the claim as the claim being directed to it; the context of the kind of data is missing. Since this data is particular to a computer environment (despite the fact that a human can code in the required formats), the context of JSON and FHIR formatting provide reason for these additional elements to be applied to a computer.
The Applicant further argues that the pending claims provide additional elements to the abstract idea that integrate the abstract idea into a practical application. Specifically, Clinical Decision Support systems cannot directly use unstructured medical information. By implementing Natural Language Processing algorithms, the CDS systems can process this unstructured data and transform it into actionable insights.
The Examiner respectfully disagrees. The mere use of NLP to address a technical problem involving CDS system is not enough to constitute an improvement to technology. Looking at paragraph [0072] of the as-filed specification, the applicant is essentially using NLP in a nominal way. NLP algorithms have existed for decades and yet the Applicant is presenting such a feature as a technical improvement. Even NLP’s implementation with the claims LLM algorithms have been shown to be well-known, routine and conventional. There is no reason for the Examiner to conclude that technology is being improved here.
The Applicant further argues that the generation component must create JSON structured data and integrate it into the original FHIR resources, yielding capabilities that improve processing speed, memory utilization, and energy consumption.
The Examiner respectfully disagrees. The basis for this argument is found in paragraph [0051] of the as-filed specification which grounds the improvement in the prompt tree of the LLM. As can be seen above, the claimed prompt tree is nothing more than well-known, routine and conventional activity. The as-filed specification provides no further detail to differentiate its functions beyond a known prompt tree. Accordingly, the Examiner does not find this argument persuasive.
The Applicant further argues that the claimed LLM is not an off-the-shelf LLM but uses a particular prompt-tree architecture tied to FHIR resource enrichment.
The Examiner respectfully disagrees. The Applicant has provided no detail about what the structure of the prompt tree is beyond what has ben found to be well-known, routine and conventional. The particular application to “FHIR enrichment” is not relevant to this discussion as it pertains to what data is being analysed by the LLM, not how.
Applicant’s arguments pertaining to rejections made under 35 U.S.C. 102 are persuasive but ultimately rendered moot in light of the new combination of references used in the current rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD A NEWTON whose telephone number is (313)446-6604. The examiner can normally be reached M-F 8:00AM-4:00PM (EST).
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, PETER H. CHOI can be reached at (469) 295-9171. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAD A NEWTON/Primary Examiner, Art Unit 3681
Prosecution Insights