DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice to Applicant
This communication is in response to the amendment filed 2/6/26. Claims 1, 6, 9-11, 16, 19, and 20 have been amended. Claims 2-5, 12-15, 21, and 22 are canceled. Claims 1, 6-11, and 16-20 are pending.
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.
Claim(s) 1, 6-11, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Reicher et al. (US 2016/0364528 A1) in view of Gupta et al. (US 2024/0029848 A1), in view of Jain (US 11,200,967 B1), in view of Aravamudan et al. (US 12,182,179 B1), and further in view of Marossero et al. (US 2005/0267377 A1).
(A) Referring to claim 1, Reicher discloses An apparatus for generating diagnostic hypotheses based on biomedical signal data, the apparatus comprising (see Fig. 1 and para. 7 of Reicher):
at least a processor (para. 39 of Reicher); and
a memory communicatively connected to the at least a processor, wherein the memory contains instructions configuring the at least a processor to (para. 39 of Reicher):
generate, using a model trained on a corpus, a set of diagnostic hypotheses, wherein generating the set of diagnostic hypotheses comprises (para. 38, 45, 46, & 67 of Reicher; providing training information to a learning engine to properly train the learning engine to automatically analyze medical images and provide diagnosis support. In particular, embodiments of the invention provide improvements to existing machine learning image processing technology by providing a learning engine with training information that informs the learning engine what portions of an image to analyze and information regarding findings (e.g., the contained normal/abnormal finding), diagnoses (e.g., a diagnosis or a differential diagnosis), confidence or probability rating of observations, and combinations thereof. Similarly, the training information provided to a learning engine may specify relevant images or portions of images from comparison imaging exams. The learning engine may use this information to detect diagnostic changes over time and to learn to compare images to derive diagnostic information. The training information may take various forms, and in some embodiments, the training information includes data stored in the data sources 112):
creating a plurality of labels, wherein each label of the plurality label represents at least one diagnostic feature associated with one or more diagnostic hypotheses within the set of diagnostic hypotheses (para. 9,76, 82, and 99 of Reicher; the learning engine 110 may label images stored in a PACS system as “normal,” “abnormal,” or “indeterminate,” and a diagnosing physician or other healthcare professional may use this information to triage images (e.g., prioritize images categorized as “abnormal” or “indeterminate”). The learning engine 110 determines subset of images included in the training information that were displayed to a diagnosing physician based on what images included in an image study were associated with an annotation. The annotation may include a graphical marker designating a portion of an image as described above. In other embodiments, the annotation may include other forms of diagnostic information associated with an image);
receive a biomedical signal comprising electrocardiogram (ECG) data pertaining to a patient; identify at least one biomedical feature comprising at least one ECG feature as a function of the ECG data, wherein identifying the at least one ECG feature comprises: inputting the ECG data into at least a generative model; and outputting the at least one ECG feature as a function of the at least a generative model and the ECG data (para. 84-86, 107, 36-38, & 46 of Reicher; the models may be used in place of a diagnosing physician, such as in reading ECG data, where the models may provide a high level of accuracy akin to that of a diagnosing physician. The models developed using the training information described above may be used for many purposes, including, for example and without limitation, automatically identifying lesions as suspicious for melanoma based on skin images (e.g., photographs), automatically reading ECG data to a greater accuracy than a human diagnosing physician or eliminating the need for human review of some ECG data. The learning engine 110 may also be configured to determine when additional information is needed or beneficial to generate a diagnosis. For example, the learning engine 110 may have certain diagnoses (e.g., differential diagnoses) that the learning engine 110 knows can be refined with certain additional information, such as an additional image, patient demographic information, medical history information, a laboratory result, and the like. Accordingly, when the learning engine 110 receives an image for analysis, the learning engine 110 may determine whether additional information is needed (e.g., using the models). When the additional information is needed, the learning engine 110 may ask a user whether he or she wants to provide the additional information to refine the diagnosis);
select at least one diagnostic hypothesis from the set of diagnostic hypotheses for the patient by matching the at least one ECG feature against the at least one diagnostic feature (para. 84-86 & 88-92 of Reicher; the learning engine 110 updates the set of initial diagnoses based on the additional information, such as by reducing the number of diagnoses included in the set or updating a probability of one or more diagnoses included in the set. The set of initial diagnoses, the updated set of diagnoses, or both may be displayed to a user (e.g., with the associated probabilities and optional bases) as a diagnosis. This process may also be repeated (e.g., automatically or in response to a user request) to further refine a diagnosis. The learning engine 110 generates the diagnosis.);
query, as a function of the at least one ECG feature matched against the at least one diagnostic feature, a medical repository, in communication with the processor, to validate the at least one matched diagnostic hypothesis, wherein the medical repository comprises a plurality of electronic health records (EHRs) comprising a plurality of electrocardiograms (ECGs) associated with a plurality of patients; (para. 92, 59, 95, 73, 107, 84, 46, and 8 of Reicher; The learning engine 110 also automatically determines, based on the diagnosis, at least one additional image for supplementing the diagnosis (at block 606) and automatically locates the at least one additional image for the patient (at block 608). For example, when the initial diagnosis is inconclusive findings, the learning engine 110 may apply criteria, such as Appropriate Use Criteria (“AUC”), to determine what other type of imaging is recommended and then query one or more systems storing the determined type of imaging. In some embodiments, the learning engine 110 accesses one or more PACSs, vendor neutral archives, RISs, EMRs, HISs, image study ordering systems, computer assisted detection (CAD) systems, or a combination thereof to locate the additional image. When the learning engine 110 receives an image, the learning engine 110 may query one or more devices or systems, such as a HIS, an EMR, and the like, for imaging procedure or examination information or patient information. The learning engine 110 may be configured to output the diagnosis in an interoperable manner (e.g., to a PACS or a reporting system) such that reports (e.g., structured DICOM reports) are pre-populated with the diagnosis. The learning engine 110 may develop different models for different types of anatomy. The learning engine 110 may similarly develop different models for different types of images (e.g., ECG data, ultrasounds, CT scans, sonograms, and the like). Accordingly, the learning engine 110 may apply rules to pre-process a received image to identify what models should be applied to the image. For example, in some embodiments, the learning engine 110 may pre-process a received image using associated clinical and historical information to identify what abnormalities may be found in the image); receive, as a function of the query, query results from the medical repository comprising the plurality of EHRs; output the at least one diagnostic hypothesis and the query results through a user interface (para. 42, 59, 92, 95, 71, 73, & 8 of Reicher; when the learning engine 110 receives an image, the learning engine 110 may query one or more devices or systems, such as a HIS, an EMR, and the like, for imaging procedure or examination information or patient information.).
Reicher does not expressly disclose that the model is a large language model (LLM) trained on a corpus comprising a set of medical literatures, wherein each diagnostic hypothesis of the set of diagnostic hypotheses comprises one or more of at least an inclusion criterion and at least an exclusion criterion; and outputting the set of diagnostic hypotheses using the LLM; wherein: the user interface is configured to visually highlight related segments on the ECG data that contributed to the selection of the at least one diagnostic hypothesis; and the user interface comprises an event-handler-driven interface comprising a cross-session state variable, wherein the at least a processor stores an identifier of the at least one diagnostic hypothesis in the cross-session state variable as an obfuscated data element within a cookie that further contains an identifier of a requesting entity, and upon a subsequent session, automatically repopulates the user interface with the stored hypothesis to reduce repeated data entry.
Gupta discloses that the model is a large language model (LLM) trained on a corpus comprising a set of medical literatures (para. 137, 144, 189, 195, and 224 Gupta; The larger volume of training data may comprise, for example, a larger external library of related data, e.g. for generating medical reports, a larger corpus of PubMed scientific literature may be used to pre-train the models. In this way, the training module 130 can take advantage of general pre-training based on the language of the field, and reserve the specific training data for fine tuning the models. The system employs Generative Large-Language-Models (G-LLMs) for generating responses on the queries received from the clinicians. The Generative Large-Language-Models (G-LLMs) are deep learning algorithms trained on a large amount of data. For example, the Generative Large-Language-Models (G-LLMs) assist the clinicians in identifying the clinical features related to a target disease, in diagnostic evaluation or in generating a patient report based on test reports.); and outputting the set of diagnostic hypotheses using the LLM (para. 224 and 227 of Gupta; The Generative Large-Language-Models (G-LLMs) assist the clinician at each step of patient journey and generate the summaries of patient journey. In this regard, the patient journey comprises some steps that are normally followed by the clinicians in evaluating the patients such as patient history evaluation, conducting physical examination, differential diagnosis, targeted clinical investigations, diagnosis, evaluation of diagnosis and then define a plan and monitoring the patient. For example, the Generative Large-Language-Models (G-LLMs) assist the clinicians in identifying the clinical features related to a target disease, in diagnostic evaluation or in generating a patient report based on test reports.).
Jain discloses wherein each diagnostic hypothesis of the set of diagnostic hypotheses comprises one or more of at least an inclusion criterion and at least an exclusion criterion (col. 9, line 7– col. 10, line 34 of Jain; The Application allows visualization of all the factors 132, 134, 136, their detail scoring 143, 145, 147 along the three axis and their assigned odds ratios 160 by a medical professional to create a probability of a hypothesized diagnosis 170. The medical professional will make and enter a best guess based on at least one of experience, their knowledge of medical literature, or on any other basis, and the prevalence of each disease diagnosis hypothesis that they create. The prevalence 129 of a disease hypothesis entered by the medical professional along with the various factors 132, 134, 136 and their odds ratios 160 that affect the probability of that hypothesis 170 is used by the Application for mathematical analysis using Bayesian Statistics or Bayes theorem based or other types of calculations to output the posterior probability of that disease hypothesis. The Application can display the updated probabilities for multiple diagnoses 170 along with the prevalence criteria, the factors 132, 134, 136, the detail scores along severity, the quality and the time, and the odds ratios 160 selected by the medical professional to obtain those probabilities. In the case of multiple hypotheses 170, the conditional probabilities of having at least one hypothesis 170 or disease at the same time are also displayed.).
Aravamudan discloses the user interface comprises an event-handler-driven interface comprising a cross-session state variable, wherein the at least a processor stores an identifier of the at least one diagnostic hypothesis in the cross-session state variable as an obfuscated data element within a cookie that further contains an identifier of a requesting entity, and upon a subsequent session, automatically repopulates the user interface with the stored hypothesis to reduce repeated data entry (col. 33, line 20 - col. 34, line 15, col. 36, line 27 – col. 37, line 26, and col. 8, lines 11-15 of Aravamudan; With continued reference to FIG. 1, in some cases, event handler may include a cross-session state variable. As used herein, a “cross-session state variable” is a variable recording obfuscated data elements generated by processor 104 during a previous session. Such data may include, for instance, previously entered text, previous selections of one or more elements as described above, or the like. For instance, and without limitation, cross-session state variable data may represent a request (of subset of obfuscated data elements 140) a requesting entity initiated in a past session. Cross-session state variable may be saved using any suitable combination of client-side data storage on remote device and server-side data storage connected to processor 104. In some cases, subset of obfuscated data elements 140 and/or obfuscated training data may be saved wholly or in part as a “cookie” which may include data or an identification of requesting entity to prompt provision of cross-session state variable by processor 104, which may be store in a data store at the requesting entity. In some cases, cross-session state variable may include at least a prior session datum. A “prior session datum” may include any element of data that may be stored in a cross-session state variable. In an embodiment, visual interface may be configured to display the at least a prior session datum, for instance and without limitation auto-populating user query data from previous sessions. In a non-limiting example, visual interface may include set of finalized obfuscated data elements, obfuscated training data, and/or the like. Advantageously, processor 104 may store previous selections of obfuscated data elements such that requesting entity does not have to request for finalized obfuscated data elements each time.).
Marossero discloses wherein: the user interface is configured to visually highlight related segments on the ECG data that contributed to the selection of the at least one diagnostic hypothesis (para. 180 & 181 of Marossero; the fetal ECG (and maternal ECG) waveforms can be plotted on a graded figure so as to enable the user to extract the different ECG intervals and segments that are useful in diagnosis/determining clinical strategy. Similarly, the ECG intervals can be calculated automatically by the processing means. The storage means can collect and/or display via the graphical user interface, ECG waveform reconstruction operations output (i.e., ECG reconstructed waveforms having both P and T waves) as well as ICA operations output (i.e., ECG with highlighted QRS spikes and P and T wave removal with other noises).).
Before the effective filing date of the claimed invention, it would have been obvious to person of ordinary skill in the art to modify the corpus of Reicher to include a set of medical literatures, as taught by Gupta, to modify the hypotheses generating in Reicher to include the aforementioned features of Gupta and Jain, and to modify the user interface of Reicher to include the aforementioned features of Aravamudan and Marossero. The motivation for doing so would have been to use a large amount of data in the medical/scientific field and take advantage of general pre-training based on the language of the field (para. 195 of Gupta), to maximize the use of the available training data and assist the clinicians in identifying the clinical features related to a target disease, in diagnostic evaluation (para. 195 & 224 of Gupta), to allow improvements in the hypothesis generation (col. 10, lines 5-11 of Jain), to save time (col. 34, lines 5-15 of Aravamudan), and to enable the user to extract the different ECG intervals and segments that are useful (para. 180 of Marossero).
(B) Referring to claims 6 and 16, Reicher does not disclose wherein each diagnostic hypothesis of the set of diagnostic hypotheses represents a cohort defined by the one or more of the at least an inclusion criterion and the at least an exclusion criterion; and the query results represent a subset of EHRs belonging to the cohort.
Gupta discloses wherein each diagnostic hypothesis of the set of diagnostic hypotheses represents a cohort defined by the one or more of the at least an inclusion criterion and the at least an exclusion criterion; and the query results represent a subset of EHRs belonging to the cohort (para. 227 & 234-236 of Gupta).
Before the effective filing date of the claimed invention, it would have been obvious to person of ordinary skill in the art to combine the aforementioned features of Gupta within Reicher’s diagnosing system. The motivation for doing so would have been to define positive and negative cohorts for each disease in the training and testing set and to differentiate the positive and negative EHRs (para. 234 & 235 of Gupta).
(C) Referring to claim 7, Reicher discloses wherein identifying the at least one biomedical feature comprises: extracting a plurality of biomedical features from the biomedical signal; ranking the plurality of biomedical features based on a set of pre-determined criteria; and identifying the at least one biomedical feature from the plurality of biomedical features based on the rank of the plurality of biomedical features (para. 77, 51, 52, and 102 of Reicher).
(D) Referring to claim 8, Reicher discloses wherein selecting the at least one diagnostic hypothesis comprises: determining, for each diagnostic hypothesis within the set of diagnostic hypotheses, a confidence level as a function of the at least one biomedical feature; and selecting the at least one diagnostic hypothesis from the set of diagnostic hypotheses as a function of the confidence levels (para. 38, 52, and 59 of Reicher).
(E) Referring to claim 9, Reicher discloses wherein: validating the at least one diagnostic hypothesis comprises: retrieving, from the medical repository, one or more EHRs of the plurality of EHRs as a function of the at least one ECG feature; and comparing the at least one diagnostic hypothesis with one or more reference biomedical signals encapsulated in the one or more EHRs; and outputting the at least one diagnostic hypothesis comprises outputting the at least one diagnostic hypothesis as a function of the comparison (para. 46, 59, 62, 76, 82, 85, 38, 152, and 73 of Reicher).
(F) Referring to claim 10, Reicher does not disclose wherein outputting the at least one diagnostic hypothesis comprises: retrieving one or more medical literatures in relation to the at least one ECG feature; generating, at the LLM, a diagnostic response as a function of the one or more medical literatures; and displaying, through the user interface at a display device, the diagnostic response.
Gupta discloses wherein outputting the at least one diagnostic hypothesis comprises: retrieving one or more medical literatures in relation to the at least one ECG feature; generating, at the LLM, a diagnostic response as a function of the one or more medical literatures; and displaying, through the user interface at a display device, the diagnostic response (para. 144, 189, 204, 218, 222, and 224 of Gupta).
Before the effective filing date of the claimed invention, it would have been obvious to person of ordinary skill in the art to modify the outputting in Reicher to include the aforementioned features of Gupta. The motivation for doing so would have been so that a final outcome including patient's disease diagnosis and treatment is provided to the one or more patients based on using a larger external corpus in the medical/scientific field (para. 189 & 204 of Gupta).
(G) Referring to claim 11, Reicher discloses A method for generating diagnostic hypotheses based on electrocardiogram (ECG) data, the method comprising (para. 84, 85, and 107 of Reicher):
generating, by at least a processor, a set of diagnostic hypotheses using a model trained on a corpus, wherein generating the set of diagnostic hypotheses comprises (para. 38, 45, 46, and 67 of Reicher; providing training information to a learning engine to properly train the learning engine to automatically analyze medical images and provide diagnosis support. In particular, embodiments of the invention provide improvements to existing machine learning image processing technology by providing a learning engine with training information that informs the learning engine what portions of an image to analyze and information regarding findings (e.g., the contained normal/abnormal finding), diagnoses (e.g., a diagnosis or a differential diagnosis), confidence or probability rating of observations, and combinations thereof. Similarly, the training information provided to a learning engine may specify relevant images or portions of images from comparison imaging exams. The learning engine may use this information to detect diagnostic changes over time and to learn to compare images to derive diagnostic information. The training information may take various forms, and in some embodiments, the training information includes data stored in the data sources 112): creating a plurality of labels, wherein each label of the plurality of labels represents at least one diagnostic feature associated with one or more diagnostic hypotheses within the set of diagnostic hypotheses (para. 9, 76, 82, and 99 of Reicher; the learning engine 110 may label images stored in a PACS system as “normal,” “abnormal,” or “indeterminate,” and a diagnosing physician or other healthcare professional may use this information to triage images (e.g., prioritize images categorized as “abnormal” or “indeterminate”). The learning engine 110 determines subset of images included in the training information that were displayed to a diagnosing physician based on what images included in an image study were associated with an annotation. The annotation may include a graphical marker designating a portion of an image as described above. In other embodiments, the annotation may include other forms of diagnostic information associated with an image);
receiving, by the at least a processor, a biomedical signal comprising electrocardiogram (ECG) data pertaining to a patient; identifying, by the at least a processor, at least one biomedical feature comprising at least one ECG feature as a function of the ECG data, wherein identifying the at least one ECG feature comprises: inputting the ECG data into at least a generative model; and outputting the at least one ECG feature as a function of the at least a generative model and the ECG data (para. 84-86, 107, 36-38, & 46 of Reicher; the models may be used in place of a diagnosing physician, such as in reading ECG data, where the models may provide a high level of accuracy akin to that of a diagnosing physician. The models developed using the training information described above may be used for many purposes, including, for example and without limitation, automatically identifying lesions as suspicious for melanoma based on skin images (e.g., photographs), automatically reading ECG data to a greater accuracy than a human diagnosing physician or eliminating the need for human review of some ECG data. The learning engine 110 may also be configured to determine when additional information is needed or beneficial to generate a diagnosis. For example, the learning engine 110 may have certain diagnoses (e.g., differential diagnoses) that the learning engine 110 knows can be refined with certain additional information, such as an additional image, patient demographic information, medical history information, a laboratory result, and the like. Accordingly, when the learning engine 110 receives an image for analysis, the learning engine 110 may determine whether additional information is needed (e.g., using the models). When the additional information is needed, the learning engine 110 may ask a user whether he or she wants to provide the additional information to refine the diagnosis);
selecting, by the at least a processor, at least one diagnostic hypothesis from the set of diagnostic hypotheses for the patient by matching the at least one ECG feature against the at least one diagnostic feature (para. 84-86 & 88-92 of Reicher; the learning engine 110 updates the set of initial diagnoses based on the additional information, such as by reducing the number of diagnoses included in the set or updating a probability of one or more diagnoses included in the set. The set of initial diagnoses, the updated set of diagnoses, or both may be displayed to a user (e.g., with the associated probabilities and optional bases) as a diagnosis. This process may also be repeated (e.g., automatically or in response to a user request) to further refine a diagnosis. The learning engine 110 generates the diagnosis.);
querying, by the at least a processor, as a function of the at least one ECG feature matched against the at least one diagnostic feature, a medical repository in communication with the processor as a function of at least a matched label to validate the at least one diagnostic hypothesis, wherein the medical repository comprises a plurality of electronic health records (EHRs) associated with a plurality of patients; receive, as a function of the query, query results from the medical repository comprising the plurality of EHRs; and outputting, by the at least a processor and through a user interface, the at least one diagnostic hypothesis and the query results upon a positive validation of the at least one diagnostic hypothesis (para. 42, 71, 92, 59, 95, 73, 107, 84, 46, and 8 of Reicher; The learning engine 110 also automatically determines, based on the diagnosis, at least one additional image for supplementing the diagnosis (at block 606) and automatically locates the at least one additional image for the patient (at block 608). For example, when the initial diagnosis is inconclusive findings, the learning engine 110 may apply criteria, such as Appropriate Use Criteria (“AUC”), to determine what other type of imaging is recommended and then query one or more systems storing the determined type of imaging. In some embodiments, the learning engine 110 accesses one or more PACSs, vendor neutral archives, RISs, EMRs, HISs, image study ordering systems, computer assisted detection (CAD) systems, or a combination thereof to locate the additional image. When the learning engine 110 receives an image, the learning engine 110 may query one or more devices or systems, such as a HIS, an EMR, and the like, for imaging procedure or examination information or patient information. The learning engine 110 may be configured to output the diagnosis in an interoperable manner (e.g., to a PACS or a reporting system) such that reports (e.g., structured DICOM reports) are pre-populated with the diagnosis. The learning engine 110 may develop different models for different types of anatomy. The learning engine 110 may similarly develop different models for different types of images (e.g., ECG data, ultrasounds, CT scans, sonograms, and the like). Accordingly, the learning engine 110 may apply rules to pre-process a received image to identify what models should be applied to the image. For example, in some embodiments, the learning engine 110 may pre-process a received image using associated clinical and historical information to identify what abnormalities may be found in the image. When the learning engine 110 receives an image, the learning engine 110 may query one or more devices or systems, such as a HIS, an EMR, and the like, for imaging procedure or examination information or patient information.).
Reicher does not expressly disclose that the model is a large language model (LLM) trained on a corpus comprising a set of medical literatures; and outputting the set of diagnostic hypotheses using the LLM; wherein each diagnostic hypothesis of the set of diagnostic hypotheses comprises one or more of at least an inclusion criterion and at least an exclusion criterion; wherein: the user interface is configured to visually highlight related segments on the ECG data that contributed to the selection of the at least one diagnostic hypothesis; and the user interface comprises an event-handler-driven interface comprising a cross-session state variable, wherein the at least a processor stores an identifier of the at least one diagnostic hypothesis in the cross-session state variable as an obfuscated data element within a cookie that further contains an identifier of a requesting entity, and upon a subsequent session, automatically repopulates the user interface with the stored hypothesis to reduce repeated data entry.
Gupta discloses that the model is a large language model (LLM) trained on a corpus comprising a set of medical literatures (para. 137, 144, 189, 195, and 224 Gupta; The larger volume of training data may comprise, for example, a larger external library of related data, e.g. for generating medical reports, a larger corpus of PubMed scientific literature may be used to pre-train the models. In this way, the training module 130 can take advantage of general pre-training based on the language of the field, and reserve the specific training data for fine tuning the models. The system employs Generative Large-Language-Models (G-LLMs) for generating responses on the queries received from the clinicians. The Generative Large-Language-Models (G-LLMs) are deep learning algorithms trained on a large amount of data. For example, the Generative Large-Language-Models (G-LLMs) assist the clinicians in identifying the clinical features related to a target disease, in diagnostic evaluation or in generating a patient report based on test reports.); and outputting the set of diagnostic hypotheses using the LLM (para. 224 and 227 of Gupta; The Generative Large-Language-Models (G-LLMs) assist the clinician at each step of patient journey and generate the summaries of patient journey. In this regard, the patient journey comprises some steps that are normally followed by the clinicians in evaluating the patients such as patient history evaluation, conducting physical examination, differential diagnosis, targeted clinical investigations, diagnosis, evaluation of diagnosis and then define a plan and monitoring the patient. For example, the Generative Large-Language-Models (G-LLMs) assist the clinicians in identifying the clinical features related to a target disease, in diagnostic evaluation or in generating a patient report based on test reports.).
Jain discloses wherein each diagnostic hypothesis of the set of diagnostic hypotheses comprises one or more of at least an inclusion criterion and at least an exclusion criterion (col. 9, line 7– col. 10, line 34 of Jain; The Application allows visualization of all the factors 132, 134, 136, their detail scoring 143, 145, 147 along the three axis and their assigned odds ratios 160 by a medical professional to create a probability of a hypothesized diagnosis 170. The medical professional will make and enter a best guess based on at least one of experience, their knowledge of medical literature, or on any other basis, and the prevalence of each disease diagnosis hypothesis that they create. The prevalence 129 of a disease hypothesis entered by the medical professional along with the various factors 132, 134, 136 and their odds ratios 160 that affect the probability of that hypothesis 170 is used by the Application for mathematical analysis using Bayesian Statistics or Bayes theorem based or other types of calculations to output the posterior probability of that disease hypothesis. The Application can display the updated probabilities for multiple diagnoses 170 along with the prevalence criteria, the factors 132, 134, 136, the detail scores along severity, the quality and the time, and the odds ratios 160 selected by the medical professional to obtain those probabilities. In the case of multiple hypotheses 170, the conditional probabilities of having at least one hypothesis 170 or disease at the same time are also displayed.).
Aravamudan discloses the user interface comprises an event-handler-driven interface comprising a cross-session state variable, wherein the at least a processor stores an identifier of the at least one diagnostic hypothesis in the cross-session state variable as an obfuscated data element within a cookie that further contains an identifier of a requesting entity, and upon a subsequent session, automatically repopulates the user interface with the stored hypothesis to reduce repeated data entry (col. 33, line 20 - col. 34, line 15, col. 36, line 27 – col. 37, line 26, and col. 8, lines 11-15 of Aravamudan; With continued reference to FIG. 1, in some cases, event handler may include a cross-session state variable. As used herein, a “cross-session state variable” is a variable recording obfuscated data elements generated by processor 104 during a previous session. Such data may include, for instance, previously entered text, previous selections of one or more elements as described above, or the like. For instance, and without limitation, cross-session state variable data may represent a request (of subset of obfuscated data elements 140) a requesting entity initiated in a past session. Cross-session state variable may be saved using any suitable combination of client-side data storage on remote device and server-side data storage connected to processor 104. In some cases, subset of obfuscated data elements 140 and/or obfuscated training data may be saved wholly or in part as a “cookie” which may include data or an identification of requesting entity to prompt provision of cross-session state variable by processor 104, which may be store in a data store at the requesting entity. In some cases, cross-session state variable may include at least a prior session datum. A “prior session datum” may include any element of data that may be stored in a cross-session state variable. In an embodiment, visual interface may be configured to display the at least a prior session datum, for instance and without limitation auto-populating user query data from previous sessions. In a non-limiting example, visual interface may include set of finalized obfuscated data elements, obfuscated training data, and/or the like. Advantageously, processor 104 may store previous selections of obfuscated data elements such that requesting entity does not have to request for finalized obfuscated data elements each time.).
Marossero discloses wherein: the user interface is configured to visually highlight related segments on the ECG data that contributed to the selection of the at least one diagnostic hypothesis. (para. 180 & 181 of Marossero; the fetal ECG (and maternal ECG) waveforms can be plotted on a graded figure so as to enable the user to extract the different ECG intervals and segments that are useful in diagnosis/determining clinical strategy. Similarly, the ECG intervals can be calculated automatically by the processing means. The storage means can collect and/or display via the graphical user interface, ECG waveform reconstruction operations output (i.e., ECG reconstructed waveforms having both P and T waves) as well as ICA operations output (i.e., ECG with highlighted QRS spikes and P and T wave removal with other noises).).
Before the effective filing date of the claimed invention, it would have been obvious to person of ordinary skill in the art to modify the corpus of Reicher to include a set of medical literatures, as taught by Gupta, to modify the hypotheses generating in Reicher to include the aforementioned features of Gupta and Jain, and to modify the user interface of Reicher to include the aforementioned features of Aravamudan and Marossero. The motivation for doing so would have been to use a large amount of data in the medical/scientific field and take advantage of general pre-training based on the language of the field (para. 195 of Gupta), to maximize the use of the available training data and assist the clinicians in identifying the clinical features related to a target disease, in diagnostic evaluation (para. 195 & 224 of Gupta), to allow improvements in the hypothesis generation (col. 10, lines 5-11 of Jain), to save time (col. 34, lines 5-15 of Aravamudan), and to enable the user to extract the different ECG intervals and segments that are useful (para. 180 of Marossero).
(H) Claims 17-20 repeat substantially the same limitations as claims and 7-10, and are therefore rejected for the same reasons given above.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 LENA NAJARIAN whose telephone number is (571)272-7072. The examiner can normally be reached Monday - Friday 9:30 am-6 pm.
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, Mamon Obeid can be reached at (571)270-1813. 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.
/LENA NAJARIAN/Primary Examiner, Art Unit 3687
Prosecution Insights