DETAILED ACTION
Status of Claims
This action is in reply to the application filed on 04/30/2025.
Claims 1-18 are currently pending and have been examined.
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 .
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-18 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-6 are directed to a method (i.e., a process), claims 7-12 are directed to a system (i.e., a machine) and claim 13-18 are directed to non-transitory computer readable medium (i.e., a manufacture). Accordingly, claims 1-18 are all within at least one of the four statutory categories.
Step 2A - Prong One:
An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Representative independent claim 7 includes limitations that recite an abstract idea. Note that independent claim 7 is the system claim, while claim 1 covers a method claim and claim 13 covers the matching computer readable medium.
Specifically, independent claim 7 recites:
A computing system comprising:
one or more processors; and
a memory storing instructions that, when executed by the one or more processors, cause the computing system to:
access historical medical data associated with a plurality of patients, the historical medical data comprising at least one of medical histories, laboratory results, diagnostic tests, medication histories, or treatment histories;
access current medical data associated with a specific patient;
generate a suspected diagnosis for the specific patient by applying a first machine learning model to the current medical data;
determine, based at least in part on the suspected diagnosis, whether a clinical assessment for the specific patient is to be performed during a clinical visit, using at least one of the first machine learning model and a second machine learning model;
generate a user interface for presentation during the clinical visit, the user interface comprising:
an indication of the suspected diagnosis, and at least one of:
a medication associated with the specific patient, a gap in care associated with the specific patient, and a clinical recommendation associated with the specific patient;
receive, via the user interface, provider input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation; and
update, based on the provider input, a structured medical record associated with the specific patient.
The Examiner submits that the foregoing underlined limitations constitute: (a) “certain methods of organizing human activity” because assisting a medical provider during a clinical visit, accessing historical and current medical data such as medical histories, laboratory results, diagnostic tests, medication histories, or treatment histories for patients, generating a suspected diagnosis for the specific patient, determining based on the suspected diagnosis, whether a clinical assessment for the specific patient is to be performed during a clinical visit, presenting the suspected diagnosis, presenting a medication associated with the specific patient, a gap in care associated with the specific patient, and a clinical recommendation associated with the specific patient and indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation are a part of a medical workflow and offering healthcare services, which relate to managing human behavior/interactions between people. Furthermore, these limitations constitute (b) “a mental process” because determining based on the suspected diagnosis, whether a clinical assessment for the specific patient is to be performed during a clinical visit is an observation/evaluation/analysis that can be performed in the human mind or with a pen and paper. The foregoing underlined limitations also relate to claims 1 and 13 (similarly to claim 7).
Accordingly, the claim describes at least one abstract idea.
In relation to claims 2, 4-6, 8, 10-12, 14 and 16-18, these claims merely recite determining steps such as: claims 2, 8 & 14 - receiving provider input confirming the suspected diagnosis and associating the confirmed suspected diagnosis with a coded diagnosis entry in the structured medical record, claim 4 - determining based at least in part on both structured and unstructured portions of the current medical data, claims 10 & 16 - generating the suspected diagnosis comprises applying the first machine learning model to both structured and unstructured portions of the current medical data associated with the specific patient, claims 5, 11 & 17 - the user interface further comprises evidence supporting the suspected diagnosis, the evidence extracted from at least one of clinical notes, imaging reports, laboratory results, or medication histories, and claims 6, 12 &18 - determining whether a clinical assessment is to be performed further comprises: identifying a clinical visit type or provider specialty associated with the specific patient; and adjusting the determination based at least in part on the identified clinical visit type or provider specialty.
Step 2A - Prong Two:
Regarding Prong Two of Step 2A, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. As noted, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The limitations of claims 1, 7 and 13, as drafted is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the human mind but for the recitation of generic computer components. That is, other than reciting a system, a computing device, a user interface, one or more processors, a memory, an application integrated with an electronic health record (EHR) system and a non-transitory, computer-readable medium storing instructions to perform the limitations, nothing in the claim elements precludes the steps from practically being performed in the human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation within a health care environment in the human mind but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” and “Mental Process” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
The judicial exception is not integrated into a practical application. In particular, the system, computing device, user interface, one or more processors, memory, application integrated with an electronic health record (EHR) system and non-transitory, computer-readable medium storing instructions are recited at high levels of generality (i.e., as generic computer components performing generic computer functions of receiving data/inputs, determining and providing data) such that it amounts no more than mere instructions to apply the exception using the generic computer components.
Regarding the additional limitations “by applying a first machine learning model to the current medical data”, and “using at least one of the first machine learning model and a second machine learning model” the Examiner submits that this additional limitation amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)). Regarding the additional limitation “receive, via the user interface, provider input” the Examiner submits that this additional limitation merely adds insignificant pre-solution activity (data gathering; selecting data to be manipulated) to the at least one abstract idea (see MPEP § 2106.05(g)).
Thus, taken alone, the additional elements do not amount to significantly more than the above identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvements in the functioning of a computer or an improvement to another technology or technical field, apply or us the above-noted implement/use to above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (see 2019 PEG and MPEP §2106.05). Their collective functions merely provide conventional computer implementation.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer component provide an inventive concept. The claims are not patent eligible.
Step 2B:
Regarding Step 2B, in representative independent claim 7, regarding the additional limitations of the system, computing device, user interface, one or more processors, memory, application integrated with an electronic health record (EHR) system and non-transitory, computer-readable medium storing instructions, the Examiner submits that these limitations amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)).
Thus, representative independent claim 7 and analogous independent claims 1 and 13 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
The dependent claims no not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reason discussed above with respect to determining that the dependent claims do not integrate the at least abstract idea into a practical application.
Therefore, claims 1-18 are ineligible under 35 USC §101.
Claim Rejections - 35 USC § 103
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.
Claims 1-3, 5-9, 11-15 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Moturu 2017/0235912 A1) in view of Bostic (US 2020/0303047 A1).
Claim 1:
Moturu discloses A method for assisting a medical provider during a clinical visit (See Figs. 6A-6B, P0016 care providers (CP), patient visits with the care provider and user-provider interactions in P0019, P0029, P0038.), the method comprising:
accessing, by a computing device, historical medical data associated with a plurality of patients, the historical medical data comprising at least one of medical histories, laboratory results, diagnostic tests, medication histories, or treatment histories (See care provider device in Abstract, Fig. 1C, see treatment evaluation previous diagnoses, previous treatments, current medical status, current medications, current symptoms, and current conditions from populations of patients in P0019-P0020, P0033-P0034, P0055-P0056, shown in Figs. 2-3, and 14A-14C.);
accessing, by the computing device, current medical data associated with a specific patient (See exemplary smartphone and smartwatch in P0028 collecting patient digital behavior data and medical device data in [P0031] device sensor information can include recorded biosignals (e.g., heart rate, blood pressure, EEG signals, blood sugar levels, etc.).);
generating a suspected diagnosis for the specific patient by applying a first machine learning model to the current medical data (See Fig. 4, diagnosing by applying machine learning models in P0047-P0048.);
determining, based at least in part on the suspected diagnosis, whether a clinical assessment for the specific patient is to be performed during the clinical visit, using at least one of the first machine learning model and a second machine learning model (See Fig. 4 severity of user condition over time, P0037, models and approaches to generate analysis and recommendations, and generating the medical status analysis including the providers scheduling patient assessment in P0019 and P0052.);
generating, by the computing device, a user interface for presentation during the clinical visit, the user interface comprising:
an indication of the suspected diagnosis (See medical status analysis display diagnosis risk levels, signs and symptoms of depression in Figs. 11, 14A-C and P0040, P0055.), and
at least one of:
a medication associated with the specific patient (See exemplary recommended medications such as Zoloft, Celexa and Remeron shown in Figs. 14A-C and P0064.), and
a clinical recommendation associated with the specific patient (See recommended medications in Figs. 11, 14A-C and P0057.); and
updating, based on the provider input, a structured medical record associated with the specific patient (See Fig. 15A-C and [P0064] updated versions of a medical status analysis (e.g., an updated patient medical report based on up-to-date patient data collected from patient smartphone usage.).
Although Moturu discloses a method, system and software for assisting a medical provider generating a user interface for presentation a medication and a clinical recommendation associated with the specific patient during the clinical visit as mentioned above, Moturu does not explicitly teach a gap in care associated with the specific patient and receiving provider input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation. Bostic teaches:
a gap in care associated with the specific patient (See P0189 exemplary healthcare professionals fail to prescribe drugs and P0200 treatment plans as gaps in care.),
receiving, via the user interface, provider input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation (See pharmacological tracking platform 100 in Fig. 1, [P0200-P0201] The platform 100 may analyze the one or more potential treatment plans and compare the one or more potential treatment plans to best clinical practices, identify gaps in care according to the one or more potential treatment plans, and present one or both of the best clinical practices and gaps in care to the oncologist. The platform 100 may evaluate efficacy of the one or more potential treatment plans and present one or more efficacy metrics to the oncologist based on each of the one or more potential treatment plans.);
Therefore, it would have been obvious to one of ordinary skill in the art of pharmacological management before the effective filing date of the claimed invention to modify the method, system and software of Moturu to include a gap in care associated with the specific patient and receiving provided input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation as taught by Bostic when averting side effects when the patient is prescribed appropriate tests prior to being prescribed a treatment mentioned in Bostic’s P0003.
Claim 7:
Moturu discloses A computing system comprising:
one or more processors; and
a memory storing instructions that, when executed by the one or more processors, cause the computing system (See user interface configuration system with processor and computer-readable medium in P0069.) to:
access historical medical data associated with a plurality of patients, the historical medical data comprising at least one of medical histories, laboratory results, diagnostic tests, medication histories, or treatment histories (See care provider device in Abstract, Fig. 1C, see treatment evaluation previous diagnoses, previous treatments, current medical status, current medications, current symptoms, and current conditions from populations of patients in P0019-P0020, P0033-P0034, P0055-P0056, shown in Figs. 2-3, and 14A-14C.);
access current medical data associated with a specific patient (See exemplary smartphone and smartwatch in P0028 collecting patient digital behavior data and medical device data in [P0031] device sensor information can include recorded biosignals (e.g., heart rate, blood pressure, EEG signals, blood sugar levels, etc.).);
generate a suspected diagnosis for the specific patient by applying a first machine learning model to the current medical data (See Fig. 4, diagnosing by applying machine learning models in P0047-P0048.);
determine, based at least in part on the suspected diagnosis, whether a clinical assessment for the specific patient is to be performed during a clinical visit, using at least one of the first machine learning model and a second machine learning model (See Fig. 4 severity of user condition over time, P0037, models and approaches to generate analysis and recommendations, and generating the medical status analysis including the providers scheduling patient assessment in P0019 and P0052.);
generate a user interface for presentation during the clinical visit, the user interface comprising:
an indication of the suspected diagnosis (See medical status analysis display diagnosis risk levels, signs and symptoms of depression in Figs. 11, 14A-C and P0040, P0055.), and
at least one of:
a medication associated with the specific patient (See exemplary recommended medications such as Zoloft, Celexa and Remeron shown in Figs. 14A-C and P0064.), and
a clinical recommendation associated with the specific patient (See recommended medications in Figs. 11, 14A-C and P0057.); and
update, based on the provider input, a structured medical record associated with the specific patient (See Fig. 15A-C and [P0064] updated versions of a medical status analysis (e.g., an updated patient medical report based on up-to-date patient data collected from patient smartphone usage.).
Although Moturu discloses a method, system and software for assisting a medical provider generating a user interface for presentation a medication and a clinical recommendation associated with the specific patient during the clinical visit as mentioned above, Moturu does not explicitly teach a gap in care associated with the specific patient and receiving provided input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation. Bostic teaches:
a gap in care associated with the specific patient (See P0189 exemplary healthcare professionals fail to prescribe drugs and P0200 treatment plans as gaps in care.),
receiving, via the user interface, provider input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation (See pharmacological tracking platform 100 in Fig. 1, [P0200-P0201] The platform 100 may analyze the one or more potential treatment plans and compare the one or more potential treatment plans to best clinical practices, identify gaps in care according to the one or more potential treatment plans, and present one or both of the best clinical practices and gaps in care to the oncologist. The platform 100 may evaluate efficacy of the one or more potential treatment plans and present one or more efficacy metrics to the oncologist based on each of the one or more potential treatment plans.);
Therefore, it would have been obvious to one of ordinary skill in the art of pharmacological management before the effective filing date of the claimed invention to modify the method, system and software of Moturu to include a gap in care associated with the specific patient and receiving provided input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation as taught by Bostic when averting side effects when the patient is prescribed appropriate tests prior to being prescribed a treatment mentioned in Bostic’s P0003.
Claim 13:
Moturu discloses A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the processors (See user interface configuration system with processor and computer-readable medium in P0069.) to:
access historical medical data associated with a plurality of patients, the historical medical data comprising at least one of medical histories, laboratory results, diagnostic tests, medication histories, or treatment histories (See care provider device in Abstract, Fig. 1C, see treatment evaluation previous diagnoses, previous treatments, current medical status, current medications, current symptoms, and current conditions from populations of patients in P0019-P0020, P0033-P0034, P0055-P0056, shown in Figs. 2-3, and 14A-14C.);
access current medical data associated with a specific patient (See exemplary smartphone and smartwatch in P0028 collecting patient digital behavior data and medical device data in [P0031] device sensor information can include recorded biosignals (e.g., heart rate, blood pressure, EEG signals, blood sugar levels, etc.).);
generate a suspected diagnosis for the specific patient by applying a first machine learning model to the current medical data (See Fig. 4, diagnosing by applying machine learning models in P0047-P0048.);
determine, based at least in part on the suspected diagnosis, whether a clinical assessment for the specific patient is to be performed during a clinical visit, using at least one of the first machine learning model and a second machine learning model (See Fig. 4 severity of user condition over time, P0037, models and approaches to generate analysis and recommendations, and generating the medical status analysis including the providers scheduling patient assessment in P0019 and P0052.);
generate a user interface for presentation during the clinical visit, the user interface comprising:
an indication of the suspected diagnosis (See medical status analysis display diagnosis risk levels, signs and symptoms of depression in Figs. 11, 14A-C and P0040, P0055.), and
at least one of:
a medication associated with the specific patient (See exemplary recommended medications such as Zoloft, Celexa and Remeron shown in Figs. 14A-C and P0064.), and
a clinical recommendation associated with the specific patient (See recommended medications in Figs. 11, 14A-C and P0057.); and
update, based on the provider input, a structured medical record associated with the specific patient (See Fig. 15A-C and [P0064] updated versions of a medical status analysis (e.g., an updated patient medical report based on up-to-date patient data collected from patient smartphone usage.).
Although Moturu discloses a method, system and software for assisting a medical provider generating a user interface for presentation a medication and a clinical recommendation associated with the specific patient during the clinical visit as mentioned above, Moturu does not explicitly teach a gap in care associated with the specific patient and receiving provided input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation. Bostic teaches:
a gap in care associated with the specific patient (See P0189 exemplary healthcare professionals fail to prescribe drugs and P0200 treatment plans as gaps in care.),
receive, via the user interface, provider input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation (See pharmacological tracking platform 100 in Fig. 1, [P0200-P0201] The platform 100 may analyze the one or more potential treatment plans and compare the one or more potential treatment plans to best clinical practices, identify gaps in care according to the one or more potential treatment plans, and present one or both of the best clinical practices and gaps in care to the oncologist. The platform 100 may evaluate efficacy of the one or more potential treatment plans and present one or more efficacy metrics to the oncologist based on each of the one or more potential treatment plans.);
Therefore, it would have been obvious to one of ordinary skill in the art of pharmacological management before the effective filing date of the claimed invention to modify the method, system and software of Moturu to include a gap in care associated with the specific patient and receiving provided input indicating confirmation, rejection, or deferral of the suspected diagnosis, the medication, the gap in care, or the clinical recommendation as taught by Bostic when averting side effects when the patient is prescribed appropriate tests prior to being prescribed a treatment mentioned in Bostic’s P0003.
Regarding claim 2, Moturu and Bostic teach the method of claim 1 mentioned above, Bostic teaches further comprising: receiving provider input confirming the suspected diagnosis; and associating the confirmed suspected diagnosis with a coded diagnosis entry in the structured medical record (With the a coded diagnosis entry as auto-encoder/neural network encoder reducing input data into a small code, see machine learning models such as neural network, deep neural network, recurrent neural network, and Hidden Markov Model in P0049, P0058-P0059, P0101-P0102 where lab test entries for diagnosis are applied to machine learning.).
Therefore, it would have been obvious to one of ordinary skill in the art of pharmacological management before the effective filing date of the claimed invention to modify the method, system and software of Moturu to include receiving provider input confirming the suspected diagnosis and associating the confirmed suspected diagnosis with a coded diagnosis entry as taught by Bostic to integrate statical analysis to assess the quality of a lab testing organization mentioned in Bostic’s P0107, P0112.
Regarding claim 3, Moturu discloses the method of claim 1, wherein the user interface is presented through an application integrated with an electronic health record (EHR) system (See electronic health records in P0028 and P0037).).
Regarding claim 5, Moturu and Bostic teach the method of claim 1 mentioned above, Moturu teaches further comprising surfacing evidence supporting the suspected diagnosis within the user interface based on extracted elements from clinical notes, imaging reports, laboratory results, or medication histories (With surfacing evidence as a request for input from the medical provider, see request for decision support in order facilitate the provision of time-sensitive, relevant patient medical information in P0060 and up-to-date data for the patient in P0064.).
Regarding claim 6, Moturu and Bostic teach the method of claim 1 mentioned above, Moturu teaches wherein determining whether a clinical assessment is to be performed further comprises identifying a clinical visit type or provider specialty associated with the specific patient and adjusting the determination based thereon (See [P0040] identifying a subset of users associated with conditions suitable for treatment through a subset of therapeutic interventions (e.g., therapy, psychiatry, specialized care provider visits, etc.). Also, see P0054 specialist determined for user’s condition.).
Regarding claim 8, Moturu and Bostic teach computing system of claim 7 mentioned above, Bostic teaches wherein the instructions further cause the computing system to: receive provider input confirming the suspected diagnosis; and associate the confirmed suspected diagnosis with a coded diagnosis entry in the structured medical record (With the a coded diagnosis entry as auto-encoder/neural network encoder reducing input data into a small code, see machine learning models such as neural network, deep neural network, recurrent neural network, and Hidden Markov Model in P0049, P0058-P0059, P0101-P0102 where lab test entries for diagnosis are applied to machine learning.).
Therefore, it would have been obvious to one of ordinary skill in the art of pharmacological management before the effective filing date of the claimed invention to modify the method, system and software of Moturu to include receiving provider input confirming the suspected diagnosis and associating the confirmed suspected diagnosis with a coded diagnosis entry as taught by Bostic to integrate statical analysis to assess the quality of a lab testing organization mentioned in Bostic’s P0107, P0112.
Regarding claim 9, Moturu discloses the computing system of claim 7, wherein the user interface is presented through an application integrated with an electronic health record (EHR) system (See electronic health records in P0028 and P0037).).
Regarding claim 11, Moturu and Bostic teach the computing system of claim 7 mentioned above, Moturu teaches wherein the user interface further comprises evidence supporting the suspected diagnosis, the evidence extracted from at least one of clinical notes, imaging reports, laboratory results, or medication histories (With surfacing evidence as a request for input from the medical provider, see request for decision support in order facilitate the provision of time-sensitive, relevant patient medical information in P0060 and up-to-date data for the patient in P0064.).
Regarding claim 12, Moturu and Bostic teach the computing system of claim 7 mentioned above, Moturu teaches wherein determining whether a clinical assessment is to be performed further comprises: identifying a clinical visit type or provider specialty associated with the specific patient; and adjusting the determination based at least in part on the identified clinical visit type or provider specialty (See [P0040] identifying a subset of users associated with conditions suitable for treatment through a subset of therapeutic interventions (e.g., therapy, psychiatry, specialized care provider visits, etc.). Also, see P0054 specialist determined for user’s condition.).
Regarding claim 14, Moturu and Bostic teach non-transitory computer-readable medium of claim 13 mentioned above, Bostic teaches wherein the instructions further cause the processors to: receive provider input confirming the suspected diagnosis; and associate the confirmed suspected diagnosis with a coded diagnosis entry in the structured medical record (With the a coded diagnosis entry as auto-encoder/neural network encoder reducing input data into a small code, see machine learning models such as neural network, deep neural network, recurrent neural network, and Hidden Markov Model in P0049, P0058-P0059, P0101-P0102 where lab test entries for diagnosis are applied to machine learning.).
Therefore, it would have been obvious to one of ordinary skill in the art of pharmacological management before the effective filing date of the claimed invention to modify the method, system and software of Moturu to include receiving provider input confirming the suspected diagnosis and associating the confirmed suspected diagnosis with a coded diagnosis entry as taught by Bostic to integrate statical analysis to assess the quality of a lab testing organization mentioned in Bostic’s P0107, P0112.
Regarding claim 15, Moturu discloses the non-transitory computer-readable medium of claim 13, wherein the user interface is presented through an application integrated with an electronic health record (EHR) system (See electronic health records in P0028 and P0037).).
Regarding claim 17, Moturu and Bostic teach the non-transitory computer-readable medium of claim 13 mentioned above, Moturu teaches wherein the user interface further comprises evidence supporting the suspected diagnosis, the evidence extracted from at least one of clinical notes, imaging reports, laboratory results, or medication histories (With surfacing evidence as a request for input from the medical provider, see request for decision support in order facilitate the provision of time-sensitive, relevant patient medical information in P0060 and up-to-date data for the patient in P0064.).
Regarding claim 18, Moturu and Bostic teach the non-transitory computer-readable medium of claim 13 mentioned above, Moturu teaches wherein determining whether a clinical assessment is to be performed further comprises: identifying a clinical visit type or provider specialty associated with the specific patient; and adjusting the determination based at least in part on the identified clinical visit type or provider specialty (See [P0040] identifying a subset of users associated with conditions suitable for treatment through a subset of therapeutic interventions (e.g., therapy, psychiatry, specialized care provider visits, etc.). Also, see P0054 specialist determined for user’s condition.).
Claims 4, 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Moturu 2017/0235912 A1) in view of Bostic (US 2020/0303047 A1) further in view of Ensey (US 2018/0181720 A1).
Regarding claim 4, although Moturu and Bostic teach the method of claim 1 mentioned above, Moturu and Bostic do not explicitly teach determining the suspected diagnosis based on both structured and unstructured portions of the current medical data. Ensey teaches wherein the suspected diagnosis is determined based at least in part on both structured and unstructured portions of the current medical data (See data mining structured and unstructured in P0094 and Fig. 14 structured query language (SQL) in P0080, P0132.).
Therefore, it would have been obvious to one of ordinary skill in the art of assisting the medical provider in care plans and pathways before the effective filing date of the claimed invention to modify the method, system and software of Moturu and Bostic to include determining the suspected diagnosis based on both structured and unstructured portions of the current medical data as taught by Ensey to support Electronic Medical Record (EMR) systems with managing robust, big data mentioned in Ensey’s P0003.
Regarding claim 10, although Moturu and Bostic teach the computing system of claim 7 mentioned above, Moturu and Bostic do not explicitly teach determining the suspected diagnosis based on both structured and unstructured portions of the current medical data. Ensey teaches wherein generating the suspected diagnosis comprises applying the first machine learning model to both structured and unstructured portions of the current medical data associated with the specific patient (See data mining structured and unstructured in P0094 and Fig. 14 structured query language (SQL) in P0080, P0132.).
Therefore, it would have been obvious to one of ordinary skill in the art of assisting the medical provider in care plans and pathways before the effective filing date of the claimed invention to modify the method, system and software of Moturu and Bostic to include determining the suspected diagnosis based on both structured and unstructured portions of the current medical data as taught by Ensey to support Electronic Medical Record (EMR) systems with managing robust, big data mentioned in Ensey’s P0003.
Regarding claim 16, although Moturu and Bostic teach the non-transitory computer-readable medium of claim 13 mentioned above, Moturu and Bostic do not explicitly teach determining the suspected diagnosis based on both structured and unstructured portions of the current medical data. Ensey teaches wherein generating the suspected diagnosis comprises applying the first machine learning model to both structured and unstructured portions of the current medical data associated with the specific patient (See data mining structured and unstructured in P0094 and Fig. 14 structured query language (SQL) in P0080, P0132.).
Therefore, it would have been obvious to one of ordinary skill in the art of assisting the medical provider in care plans and pathways before the effective filing date of the claimed invention to modify the method, system and software of Moturu and Bostic to include determining the suspected diagnosis based on both structured and unstructured portions of the current medical data as taught by Ensey to support Electronic Medical Record (EMR) systems with managing robust, big data mentioned in Ensey’s P0003.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Crossen (US 2021/0407682 A1), Sipula (WO 2020/053759 A2) and Allen (US 10,971,254 B2).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERESA S WILLIAMS whose telephone number is (571)270-5509. The examiner can normally be reached Mon-Fri, 8:30 am -6:30 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.
/T.S.W./ Examiner, Art Unit 3687
08/18/2026
/Anita Y Coupe/ Supervisory Patent Examiner, Art Unit 3619
Prosecution Insights