DETAILED ACTION
This is responsive to RCE filed on 01/20/2026 in which claims 1-20 are presented for examination; Claims 1, 5, 10, 14, and 20 have been amended.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/20/2026 has been entered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 1:
Step 1: Is the claim to a process, machine, manufacture or composition of matter?” Yes, it’s a system(machine).
Step 2a Prong 1 (judicial exception)
Step 2A (1): “Does the claim recite an abstract idea, law of nature, or natural phenomenon? Yes , the claim comes under mental processes.
Claim 1 recites:
“A system, comprising: a memory that stores instructions; and a processor configured to execute the instructions to: register, via an interface of the system, an individual with the system; interact, by utilizing a triage artificial intelligence engine, with the individual to obtain information comprising sensor data from the individual , wherein the interacting comprises capturing, by utilizing a sensor device, the sensor data associated with the individual; identify, by utilizing the triage artificial intelligence engine and based on the information comprising the sensor data , a medical complaint associated with the individual, wherein the medical complaint is identified based on the information having a correlation with medical complaint information utilized to train the triage artificial intelligence engine; generate, by utilizing the triage artificial intelligence engine and based on the medical complaint, a digital record associated with the individual, wherein the digital record includes a plan associated with addressing the medical complaint; finalize the digital record if a standing order protocol exists that matches criteria associated with the plan in the digital record , wherein the standing order protocol comprises executable rules that, when matched, cause the system to perform predefined actions; in response to the finalizing and in accordance with at least one of the executable rules, automatically generate one or more orders associated with the plan and transmit at least one of the orders or the digital record to at least one of the individual, a third party, or a medical billing system; provide, if the standing order protocol does not exist, the digital record for further review by a provider via provider worklist; and modifying, based on an input received that is associated with the further review, the digital record.”
All the limitations above are abstract idea related to the mental process (concepts performed in the human mind (including an observation, evaluation, judgment, opinion)) with the exception of bold and underlined limitations. Claim language pertains to recording a complaint from a patient , the record also includes treatment plan during patient’s past visit. Analyzing if already exiting clinical guidelines matches with the treatment plan of the record and finalizing it(recommending treatment), otherwise reviewing the record for further changes. A patient’s data can be obtained easily by examining the patient in a clinical setting. Similarly , clinical data can easily be transmitted to the individual , billing system or third party, in any hospital. All of this can be done mentally or on the paper.
Step 2A(2): Prong Two: evaluate whether the claim recites additional elements that integrate the exception into a practical application of the exception. NO
The claim does recite additional elements; however they don’t integrate the exception into a practical application of the exception.
system(Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
memory (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
processor (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
interface (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
artificial intelligence engine (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
digital record (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
sensor data (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
sensor device (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
executable rules(Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
automatically generate (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
transmit at least one of the orders( Adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) )
Step 2B: evaluate whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception? NO
As discussed previously with respect to Step 2A Prong Two, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
Regarding claim limitation “transmit at least one of the orders” the courts have recognized the computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (“i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information”); See, MPEP 2106.05 (d)(II)
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Dependent claims 2-13 further narrows the abstract idea and add the additional elements of “teleconference”, “transmit the digital record to a medical billing system”, “derivative digital record”,
Under step 2A, prong two, the additional elements don’t integrate the exception into a practical application of the exception as merely adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
As discussed previously with respect to Step 2A Prong Two, the additional elements in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Regarding claim 14, it is a method claim ,and rejected under the same rationale as claim 1.
Dependent claims 15-19 further narrows the abstract idea and add the additional elements of “interface”, “transmit the digital record to a medical billing system”, “derivative digital record”,
Under step 2A, prong two, the additional elements don’t integrate the exception into a practical application of the exception as merely adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
As discussed previously with respect to Step 2A Prong Two, the additional elements in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
Regarding claim 20, it is rejected under the same rationale as claim 14, and adds the additional elements of “non-transitory computer-readable device”, “processor”.
Under step 2A, prong two, the additional elements don’t integrate the exception into a practical application of the exception as merely adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
As discussed previously with respect to Step 2A Prong Two, the additional elements in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
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.
Claims 1- 6, 9, 11, 14-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over KANNAN et al. ( US 20190311807 A1) in view of Trajkovic et al. (US 20230274820 A1)
Regarding claim 1, KANNAN teaches a system, comprising:
a memory that stores instructions(see para 0010);
and a processor configured to execute the instructions to(see para 0010):
register, via an interface of the system, an individual with the system (para, “[0045] The user information module 108 may include two submodules—a user profile/modeling submodule 110 and a personalization submodule 112. The user profile/modeling submodule 110 may create and/or update a user's profile with all relevant information available about the user from the user input interface 104. The user profile/modeling submodule 110 may be built on the notion of creating a personalized health record. The personalization submodule 112 may use the user's profile from the user profile/modeling submodule 110 in order to optimize the relevance of the recommendations and information that the system 100 is to present to the user.” Note: here, creating user’s profile and personalized health records using interface is registering.);
interact, by utilizing a triage artificial intelligence engine, with the individual to obtain information comprising sensor data from the individual (para, “[0105] As described before, the goal to the system 100 is to answer patient questions by giving a set of actionable recommendations that may include not only a diagnostic and triaging, but also referral or treatment. One important actionable recommendation that a patient that is looking for information about her health situation can get is whether she needs to visit a doctor and what is the relative urgency of the medical attention. This is accomplished by the ability of the system 100 to triage patients. In most situations, the triaging decision may be accomplished by formulating a diagnosis and classifying the diagnosis into the required attention and urgency. However, in many other situations, the simple existence of a symptom can trigger a triage recommendation. For example, chest pain on an elderly patient or high fever in an infant will trigger an automatic recommendation to visit the emergency room regardless of the confidence on the diagnosis. Also, see Fig. 11 for obtaining information from the individual. Also, Fig. 15, step 1506.
Also, para “[0103] Referring back to FIG. 1, one important aspect of the system 100 is that it allows for multimodal input as part of the dialog/conversation. The system 100 allows a user/patient to input voice, images, and video as part of the dialog flow. For example, if the patient mentions having a skin rash, the system 100 may invite the patient to upload a picture. The system 100 may then perform automatic image classification and will use the output as another symptom in the diagnosis. Beyond typical multimedia documents, the system 100 may be designed to accept information coming from any medical sensor or monitoring device (e.g., heart rate monitor, blood pressure monitor, etc.).”);
identify, by utilizing the triage artificial intelligence engine and based on the information comprising the sensor data , a medical complaint associated with the individual (para, “[0046] The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc.….” Also, see Fig. 13 where potential conditions are found based on user input of symptoms.
Also, para “[0103] Referring back to FIG. 1, one important aspect of the system 100 is that it allows for multimodal input as part of the dialog/conversation. The system 100 allows a user/patient to input voice, images, and video as part of the dialog flow. For example, if the patient mentions having a skin rash, the system 100 may invite the patient to upload a picture. The system 100 may then perform automatic image classification and will use the output as another symptom in the diagnosis. Beyond typical multimedia documents, the system 100 may be designed to accept information coming from any medical sensor or monitoring device (e.g., heart rate monitor, blood pressure monitor, etc.).”),
wherein the medical complaint is identified based on the information having a correlation with medical complaint information utilized to train the triage artificial intelligence engine (para, “[0046] The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc. In an embodiment, the DDx 116 may be based on rules in a knowledge based codifying probabilistic relationships between symptoms/findings and diseases. In another embodiment, the DDx 116 may be based on machine-learned models deriving relations between symptoms/findings and diseases from historical medical records. In yet another embodiment, the DDx 116 may be based on machine-learned models deriving both probabilities and relationships from historic medical records. In another embodiment, the DDx 116 may be based on machine-learned models learned from mixed data that includes at least one of synthetic data generated by a pre-existing expert system, electronic medical records, manual cases, labeled cases from the diagnosis engine, as will be described below. Alternatively, the DDx 116 may comprise all these embodiments working in ensemble such that each embodiment may operate based on a current state of knowledge independently, and offer possible responses along with a confidence and a value estimate. Additionally, there may be an ensemble arbitrator to choose a response out of the possible responses or a collection of responses from the different embodiments, that is best for the user or circumstance given a match or a mismatch between the possible responses, and the value and the confidence estimate each embodiment expresses in its corresponding response. The ensemble arbitrator may learn a weight to use for each possible response from each of embodiment of the DDx 116 based upon history.”);
generate, by utilizing the triage artificial intelligence engine and based on the medical complaint, a digital record associated with the individual, wherein the digital record includes a plan associated with addressing the medical complaint (para , “[0068] FIG. 6 is a flowchart illustrating a method 600 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 600 begins at step 610 with the user making a healthcare inquiry. At step 620, the method 600 determines and classifies the intent of user's inquiry as one of a plurality of intent classifications (as described below), using a conversational engine (e.g., conversational engine 114). The method 600 proceeds to step 630, where a decision is made as to whether the user's intent is understood. If the user's intent is not understood (in which case, no trustworthy actionable recommendation may be provided with some degree of confidence), the user's inquiry is escalated to a doctor, at step 640. However, if the user's intent is understood at step 630, the method 600 moves to step 650 and instantiates one of a plurality of specialized conversational engines for the intent, based on the intent classification. Then, at step 660, based on interfacing with a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118), the method 600 elicits more information from the user (if needed). Once all needed information is obtained from the user, the method 600 decides, at step 680, whether a confident recommendation may be made. If a confident recommendation may not be made at step 680, the user's inquiry is escalated to a doctor, at step 640. Otherwise, a recommendation (e.g., diagnosis, referral, treatment, etc.) is made to the user at step 690. The goal of the method 600, therefore, is to provide at least one of a plurality of actionable recommendations to the user.”)
finalize the digital record if a standing order protocol exists that matches criteria associated with the plan in the digital record (para, “[0134] FIG. 14 is a flowchart illustrating a method 1400 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 1400 begins at step 1410 with the user making a healthcare inquiry. At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment. If the user's intent is not related to either a diagnosis or a treatment, the method 1400 invokes a converse at step 1440. The converse generates a reasonable response based on what the medical decision support system knows about its past few interactions with the user. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”);
wherein the standing order protocol comprises executable rules that, when matched, cause the system to perform predefined actions (para, “[0134] FIG. 14 is a flowchart illustrating a method 1400 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 1400 begins at step 1410 with the user making a healthcare inquiry. At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment....”
Also, para, “[0082] ..... The intent classification module 710 may classify a user's intent into a finite set of “intents.” Those intents include, but are not limited to, diagnosis, doctor referral, prescription or treatment recommendation, and information on a given disease....”) ;
in response to the finalizing and in accordance with at least one of the executable rules, automatically generate one or more orders associated with the plan and transmit at least one of the orders or the digital record to at least one of the individual, a third party, or a medical billing system (Para, “[0121] Similarly, some situations may require the patient to undergo some form of laboratory testing. In some cases, the kind of testing might be available through some form of at-home procedure (e.g., blood pressure), but in many other cases the patient may need to visit a physician or pharmacist. For the former, the system 100 may refer the patient to existing third-party applications and solutions. For the latter, the system 100 may refer the patient to nearby facilities considering all the information about the patient and the current situation (e.g., how urgent the test is). In any of these cases, the system 100 may facilitate the paperwork. The system 100 may include a database of pharmacies and doctors that may provide a given test procedure.”);
provide, if the standing order protocol does not exist, the digital record for further review by a provider via a provider worklist (para, “[0134] …….At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment. If the user's intent is not related to either a diagnosis or a treatment, the method 1400 invokes a converse at step 1440. The converse generates a reasonable response based on what the medical decision support system knows about its past few interactions with the user. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”);
and modifying, based on an input received that is associated with the further review, the digital record (para, “[0134]….. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”).
KANNAN does not explicitly teach:
wherein the interacting comprises capturing by utilizing a sensor device, the sensor data associated with the individual,
Trajkovic teaches (Note: Kannan implicitly teaches this limitation, however to explicitly teach the limitation, Trajkovic reference is being introduced):
wherein the interacting comprises capturing by utilizing a sensor device, the sensor data associated with the individual(para, “[0013] The data acquisition subsystem may be deployed in a triage or assessment area of the facility 102 and includes one or more sensors 116. The sensors 116 are generally configured to detect current status attributes for a patient 120. For example, the sensors 116 may include direct sensors, such as a blood pressure sensor 116-1. The direct sensors are generally configured to directly detect a measurable attribute of the patient 120, such as the patient’s heart rate, blood pressure, temperature, or the like. The sensors 116 may further include indirect sensors configured to capture data from which attributes of the patient 120 may be derived….”
Also, para “[0032] At block 305, the data acquisition subsystem obtains current status attributes for the patient 120. The data acquisition subsystem may obtain directly measured attributes, as well as derived attributes. For example, the data acquisition subsystem may obtain various vital signs (e.g., blood pressure, heart rate, temperature, and the like) and other measurable attributes of the patient 120 via the direct sensors. The data acquisition subsystem may further obtain raw image data from the camera 116-2 and apply image processing and/or computer vision analysis at the processor 124 to derive visually perceptible attributes of the patient 120.”)
It would have been obvious for a person of ordinary skill in the art to apply capturing data using sensor teachings of Trajkovic into the teachings of Kannan at the time the application was filed in order to detect current status attributes for a patient. (para “[0013] The data acquisition subsystem may be deployed in a triage or assessment area of the facility 102 and includes one or more sensors 116. The sensors 116 are generally configured to detect current status attributes for a patient 120. For example, the sensors 116 may include direct sensors, such as a blood pressure sensor 116-1. The direct sensors are generally configured to directly detect a measurable attribute of the patient 120, such as the patient’s heart rate, blood pressure, temperature, or the like. ....…”)
Regarding claim 2, KANNAN as modified by Trajkovic teaches the system of claim 1.
KANNAN further teaches wherein the processor is further configured to generate the plan based on the information, the medical complaint, or a combination thereof, correlating with at least one plan utilized to train the triage artificial intelligence engine (para, “[0057] …. At step 1220, the rule-based expert system is used as a generative model to create sample medical cases. At step 1240, the sample medical cases created at step 1220 are used to train a machine-learned model. The machine-learned model may then be applied to a medical decision support system at step 1250. This becomes a novel and effective way to extend and generalize expert systems that can then be combined at the data level. At step 1230, the medical cases generated by the expert system may be combined with other medical cases such as manually generated medical cases 1260, medical cases 1270 gathered from sources such as EMRs, and/or labeled medical cases 1280 from the system usage itself.”)
Regarding claim 3, KANNAN as modified by Trajkovic teaches the system of claim 1.
KANNAN further teaches wherein the processor is further configured to register the individual with the system based on receiving registration information associated with the individual via an interface of the system (para, “[0045] The user information module 108 may include two submodules—a user profile/modeling submodule 110 and a personalization submodule 112. The user profile/modeling submodule 110 may create and/or update a user's profile with all relevant information available about the user from the user input interface 104. The user profile/modeling submodule 110 may be built on the notion of creating a personalized health record. The personalization submodule 112 may use the user's profile from the user profile/modeling submodule 110 in order to optimize the relevance of the recommendations and information that the system 100 is to present to the user.”)
Regarding claim 4, KANNAN as modified by Trajkovic teaches the system of claim 1.
KANNAN further teaches wherein the processor is further configured to determine whether the individual requires a consultation with the provider (para, “[0107] While the system 100 may be designed to give up-to-date and accurate medical information, in many situations, the interaction with the patient will determine that the best path forward is for her to visit a doctor. Exemplary cases when the system 100 may decide to refer the patient to a doctor may include, but is not limited, to the following: [0108] Probability of complications are above a certain threshold [0109] Patient requires physical examination or lab tests [0110] The internal algorithms are not certain of what is the issue with the patient [0111] The patient has described a critical symptom (e.g., “chest pain”).”)
Regarding claim 5, KANNAN as modified by Trajkovic , teaches the system of claim 4.
KANNAN further teaches wherein the processor is further configured to provide the digital record including the plan to the provider via the provider worklist for the provider if the consultation with the provider is not required (“[0114] In follow-ups, the system 100 may collect data on treatment paths chosen by the patient, and outcomes, and use these data to learn models for which treatments to propose to other patients in the future. Some of those treatments may involve prescriptions or recommendations for over-the-counter medications. For the former, the system 100 may include referral to a healthcare professional, who can safely prescribe medications. This could be an offline prescription based on data collected, a real-time or scheduled chat or message interaction, a real-time or scheduled video consultation, or a scheduled visit for physical examination. In any of these cases, the system 100 may facilitate the paperwork of prescribing and forwarding the prescription onto a pharmacy.”)
Regarding claim 6, KANNAN as modified by Trajkovic , teaches the system of claim 4.
KANNAN further teaches wherein the processor is further configured to facilitate a teleconference for the consultation between the individual and the provider if the individual is determined to require the consultation with the provider (para, “[0112] In all these cases, the system 100 may determine the best doctor to whom to refer the patient considering different variables that include everything that is known about the patient (e.g., location, healthcare provider) and their current situation (e.g., vitals, symptoms). The system 100 may present a ranked list of recommendations. The system 100 may include a database of doctors and facilities that can provide a given medical procedure or service. On the other hand, the system 100 may also provide the possibility to refer directly to in-house physicians through text or video consultation.”)
Regarding claim 9, KANNAN as modified by Trajkovic , teaches the system of claim 1.
KANNAN further teaches wherein the processor is further configured to train an artificial intelligence model using training information utilized to facilitate identification of medical complaints, generation of plans, identification of diagnoses associated with the medical complaint, or a combination thereof (Para, “[0102] Additionally, engines that are based on models learned from data may be included. Such models quantify the relation between symptoms and diseases observed in real-world data. The models are trained using various medical data such as anonymized EMRs from research databases or university hospitals, and from introspecting on the data collected in feedback and follow-up from the engine's own interaction with patients. Sources of bias in the samples that drive the models may be quantified, and the models may be corrected for known and estimated bias. The models may incorporate disease and symptom prevalence in the general population, and may include how those statistics vary in specific subpopulations by demographic, geography, calendar, social connections, etc. In one embodiment, the models are constrained to quantify relationships identified by the rule-based engines….”)
Regarding claim 11, KANNAN as modified by Trajkovic , teaches the system of claim 1.
KANNAN further teaches wherein the processor is further configured to facilitate initiation of a treatment, a procedure, dispensing of a medication, a medical test, or a combination thereof, in accordance with the plan of the digital record (para “[0121] Similarly, some situations may require the patient to undergo some form of laboratory testing. In some cases, the kind of testing might be available through some form of at-home procedure (e.g., blood pressure), but in many other cases the patient may need to visit a physician or pharmacist. For the former, the system 100 may refer the patient to existing third-party applications and solutions. For the latter, the system 100 may refer the patient to nearby facilities considering all the information about the patient and the current situation (e.g., how urgent the test is). In any of these cases, the system 100 may facilitate the paperwork. The system 100 may include a database of pharmacies and doctors that may provide a given test procedure.”)
Regarding claim 14, KANNAN teaches a method, comprising:
interacting, by utilizing a triage artificial intelligence engine of a system, with an individual to obtain information comprising sensor data from the individual during a first encounter with the individual (para, “[0105] As described before, the goal to the system 100 is to answer patient questions by giving a set of actionable recommendations that may include not only a diagnostic and triaging, but also referral or treatment. One important actionable recommendation that a patient that is looking for information about her health situation can get is whether she needs to visit a doctor and what is the relative urgency of the medical attention. This is accomplished by the ability of the system 100 to triage patients. In most situations, the triaging decision may be accomplished by formulating a diagnosis and classifying the diagnosis into the required attention and urgency. However, in many other situations, the simple existence of a symptom can trigger a triage recommendation. For example, chest pain on an elderly patient or high fever in an infant will trigger an automatic recommendation to visit the emergency room regardless of the confidence on the diagnosis. Also, see Fig. 11 for obtaining information from the individual. Also, Fig. 15, step 1506; para 0104 teaches previous sessions of patient, thus there are multiple encounters.
Also, para “[0103] Referring back to FIG. 1, one important aspect of the system 100 is that it allows for multimodal input as part of the dialog/conversation. The system 100 allows a user/patient to input voice, images, and video as part of the dialog flow. For example, if the patient mentions having a skin rash, the system 100 may invite the patient to upload a picture. The system 100 may then perform automatic image classification and will use the output as another symptom in the diagnosis. Beyond typical multimedia documents, the system 100 may be designed to accept information coming from any medical sensor or monitoring device (e.g., heart rate monitor, blood pressure monitor, etc.).”);
identifying, by utilizing the triage artificial intelligence engine and based on the information comprising the sensor data, a medical complaint associated with the individual (para, “[0046] The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc.….” Also, see Fig. 13 where potential conditions are found based on user input of symptoms.
Also, para “[0103] Referring back to FIG. 1, one important aspect of the system 100 is that it allows for multimodal input as part of the dialog/conversation. The system 100 allows a user/patient to input voice, images, and video as part of the dialog flow. For example, if the patient mentions having a skin rash, the system 100 may invite the patient to upload a picture. The system 100 may then perform automatic image classification and will use the output as another symptom in the diagnosis. Beyond typical multimedia documents, the system 100 may be designed to accept information coming from any medical sensor or monitoring device (e.g., heart rate monitor, blood pressure monitor, etc.).”),
wherein the medical complaint is identified based on the information having a correlation with medical complaint information utilized to train the triage artificial intelligence engine (para, “[0046] The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc. In an embodiment, the DDx 116 may be based on rules in a knowledge based codifying probabilistic relationships between symptoms/findings and diseases. In another embodiment, the DDx 116 may be based on machine-learned models deriving relations between symptoms/findings and diseases from historical medical records. In yet another embodiment, the DDx 116 may be based on machine-learned models deriving both probabilities and relationships from historic medical records. In another embodiment, the DDx 116 may be based on machine-learned models learned from mixed data that includes at least one of synthetic data generated by a pre-existing expert system, electronic medical records, manual cases, labeled cases from the diagnosis engine, as will be described below. Alternatively, the DDx 116 may comprise all these embodiments working in ensemble such that each embodiment may operate based on a current state of knowledge independently, and offer possible responses along with a confidence and a value estimate. Additionally, there may be an ensemble arbitrator to choose a response out of the possible responses or a collection of responses from the different embodiments, that is best for the user or circumstance given a match or a mismatch between the possible responses, and the value and the confidence estimate each embodiment expresses in its corresponding response. The ensemble arbitrator may learn a weight to use for each possible response from each of embodiment of the DDx 116 based upon history.”);
generating, by utilizing the triage artificial intelligence engine and based on the medical complaint, a digital record associated with the individual, wherein the digital record includes a plan associated with addressing the medical complaint (para , “[0068] FIG. 6 is a flowchart illustrating a method 600 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 600 begins at step 610 with the user making a healthcare inquiry. At step 620, the method 600 determines and classifies the intent of user's inquiry as one of a plurality of intent classifications (as described below), using a conversational engine (e.g., conversational engine 114). The method 600 proceeds to step 630, where a decision is made as to whether the user's intent is understood. If the user's intent is not understood (in which case, no trustworthy actionable recommendation may be provided with some degree of confidence), the user's inquiry is escalated to a doctor, at step 640. However, if the user's intent is understood at step 630, the method 600 moves to step 650 and instantiates one of a plurality of specialized conversational engines for the intent, based on the intent classification. Then, at step 660, based on interfacing with a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118), the method 600 elicits more information from the user (if needed). Once all needed information is obtained from the user, the method 600 decides, at step 680, whether a confident recommendation may be made. If a confident recommendation may not be made at step 680, the user's inquiry is escalated to a doctor, at step 640. Otherwise, a recommendation (e.g., diagnosis, referral, treatment, etc.) is made to the user at step 690. The goal of the method 600, therefore, is to provide at least one of a plurality of actionable recommendations to the user.”);
finalizing the digital record if a standing order protocol exists that matches criteria associated with the plan in the digital record (para, “[0134] FIG. 14 is a flowchart illustrating a method 1400 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 1400 begins at step 1410 with the user making a healthcare inquiry. At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment. If the user's intent is not related to either a diagnosis or a treatment, the method 1400 invokes a converse at step 1440. The converse generates a reasonable response based on what the medical decision support system knows about its past few interactions with the user. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”);
wherein the standing order protocol comprises executable rules that, when matched, cause the system to perform predefined actions including specifying one or more orders associated with the plan(para, “[0134] FIG. 14 is a flowchart illustrating a method 1400 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 1400 begins at step 1410 with the user making a healthcare inquiry. At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment....”
Para, “[0082] ..... The intent classification module 710 may classify a user's intent into a finite set of “intents.” Those intents include, but are not limited to, diagnosis, doctor referral, prescription or treatment recommendation, and information on a given disease....”);
in response to the finalizing and in accordance with the executable rules of the standing order protocol, automatically generating the specified one or more orders and transmitting at least one of the orders or the digital record to at least one of the individual, a third party, or a medical billing system((Para, “[0121] Similarly, some situations may require the patient to undergo some form of laboratory testing. In some cases, the kind of testing might be available through some form of at-home procedure (e.g., blood pressure), but in many other cases the patient may need to visit a physician or pharmacist. For the former, the system 100 may refer the patient to existing third-party applications and solutions. For the latter, the system 100 may refer the patient to nearby facilities considering all the information about the patient and the current situation (e.g., how urgent the test is). In any of these cases, the system 100 may facilitate the paperwork. The system 100 may include a database of pharmacies and doctors that may provide a given test procedure.”);
providing, if the standing order protocol does not exist, the digital record for further review by a provider via a provider worklist (para, “[0134] …….At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment. If the user's intent is not related to either a diagnosis or a treatment, the method 1400 invokes a converse at step 1440. The converse generates a reasonable response based on what the medical decision support system knows about its past few interactions with the user. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”);
and modifying, based on an input received that is associated with the further review, the digital record (para, “[0134]….. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”).
KANNAN does not explicitly teach:
wherein the interacting comprises capturing. by utilizing a sensor device, the sensor data associated with the individual,
Trajkovic teaches:
wherein the interacting comprises capturing. by utilizing a sensor device, the sensor data associated with the individual, (para, “[0013] The data acquisition subsystem may be deployed in a triage or assessment area of the facility 102 and includes one or more sensors 116. The sensors 116 are generally configured to detect current status attributes for a patient 120. For example, the sensors 116 may include direct sensors, such as a blood pressure sensor 116-1. The direct sensors are generally configured to directly detect a measurable attribute of the patient 120, such as the patient’s heart rate, blood pressure, temperature, or the like. The sensors 116 may further include indirect sensors configured to capture data from which attributes of the patient 120 may be derived….”
Also, para “[0032] At block 305, the data acquisition subsystem obtains current status attributes for the patient 120. The data acquisition subsystem may obtain directly measured attributes, as well as derived attributes. For example, the data acquisition subsystem may obtain various vital signs (e.g., blood pressure, heart rate, temperature, and the like) and other measurable attributes of the patient 120 via the direct sensors. The data acquisition subsystem may further obtain raw image data from the camera 116-2 and apply image processing and/or computer vision analysis at the processor 124 to derive visually perceptible attributes of the patient 120.”)
It would have been obvious for a person of ordinary skill in the art to apply capturing data using sensor teachings of Trajkovic into the teachings of Kannan at the time the application was filed in order to detect current status attributes for a patient. (para “[0013] The data acquisition subsystem may be deployed in a triage or assessment area of the facility 102 and includes one or more sensors 116. The sensors 116 are generally configured to detect current status attributes for a patient 120. For example, the sensors 116 may include direct sensors, such as a blood pressure sensor 116-1. The direct sensors are generally configured to directly detect a measurable attribute of the patient 120, such as the patient’s heart rate, blood pressure, temperature, or the like. The sensors 116 may further include indirect sensors configured to capture data from which attributes of the patient 120 may be derived. For example, the indirect sensors may include a camera 116-2 or other image sensor, to capture image data representing the patient 120. The image data may then be analyzed to derive visually perceptible attributes of the patient 120, such as a rash or discoloration on the patient’s skin, sweating or shivering of the patient, or the like…”)
Regarding claim 15, KANNAN as modified by Trajkovic teaches the method of claim 14,
KANNAN further teaches further comprising registering, via an interface of the system, the individual with the system (para, “[0045] The user information module 108 may include two submodules—a user profile/modeling submodule 110 and a personalization submodule 112. The user profile/modeling submodule 110 may create and/or update a user's profile with all relevant information available about the user from the user input interface 104. The user profile/modeling submodule 110 may be built on the notion of creating a personalized health record. The personalization submodule 112 may use the user's profile from the user profile/modeling submodule 110 in order to optimize the relevance of the recommendations and information that the system 100 is to present to the user.” Note: here, creating user’s profile and personalized health records using interface is registering.)
Regarding claim 19, KANNAN as modified by Trajkovic teaches the method of claim 14,
KANNAN teaches further comprising generating the plan for the digital record based on an assessment of the individual, subjective data associated with the individual, objective data associated with the individual, or a combination thereof (para, “[0105] As described before, the goal to the system 100 is to answer patient questions by giving a set of actionable recommendations that may include not only a diagnostic and triaging, but also referral or treatment. One important actionable recommendation that a patient that is looking for information about her health situation can get is whether she needs to visit a doctor and what is the relative urgency of the medical attention. This is accomplished by the ability of the system 100 to triage patients. In most situations, the triaging decision may be accomplished by formulating a diagnosis and classifying the diagnosis into the required attention and urgency. However, in many other situations, the simple existence of a symptom can trigger a triage recommendation. For example, chest pain on an elderly patient or high fever in an infant will trigger an automatic recommendation to visit the emergency room regardless of the confidence on the diagnosis.”)
Regarding claim 20, KANNAN teaches a non-transitory computer-readable device comprising instructions, which, when loaded and executed by a processor, cause the processor to perform operations (para 0142), the operations comprising:
interacting, by utilizing a triage artificial intelligence engine of a system, with an individual to obtain information comprising sensor data from the individual during a first encounter with the individual (para, “[0105] As described before, the goal to the system 100 is to answer patient questions by giving a set of actionable recommendations that may include not only a diagnostic and triaging, but also referral or treatment. One important actionable recommendation that a patient that is looking for information about her health situation can get is whether she needs to visit a doctor and what is the relative urgency of the medical attention. This is accomplished by the ability of the system 100 to triage patients. In most situations, the triaging decision may be accomplished by formulating a diagnosis and classifying the diagnosis into the required attention and urgency. However, in many other situations, the simple existence of a symptom can trigger a triage recommendation. For example, chest pain on an elderly patient or high fever in an infant will trigger an automatic recommendation to visit the emergency room regardless of the confidence on the diagnosis. Also, see Fig. 11 for obtaining information from the individual. Also, Fig. 15, step 1506; para 0104 teaches previous sessions of patient, thus there are multiple encounters.
Also, para “[0103] Referring back to FIG. 1, one important aspect of the system 100 is that it allows for multimodal input as part of the dialog/conversation. The system 100 allows a user/patient to input voice, images, and video as part of the dialog flow. For example, if the patient mentions having a skin rash, the system 100 may invite the patient to upload a picture. The system 100 may then perform automatic image classification and will use the output as another symptom in the diagnosis. Beyond typical multimedia documents, the system 100 may be designed to accept information coming from any medical sensor or monitoring device (e.g., heart rate monitor, blood pressure monitor, etc.).”);
identifying, by utilizing the triage artificial intelligence engine and based on the information comprising the sensor data , a medical complaint associated with the individual (para, “[0046] The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc.….” Also, see Fig. 13 where potential conditions are found based on user input of symptoms.
Also, para “[0103] Referring back to FIG. 1, one important aspect of the system 100 is that it allows for multimodal input as part of the dialog/conversation. The system 100 allows a user/patient to input voice, images, and video as part of the dialog flow. For example, if the patient mentions having a skin rash, the system 100 may invite the patient to upload a picture. The system 100 may then perform automatic image classification and will use the output as another symptom in the diagnosis. Beyond typical multimedia documents, the system 100 may be designed to accept information coming from any medical sensor or monitoring device (e.g., heart rate monitor, blood pressure monitor, etc.).”),
wherein the medical complaint is identified based on the information having a correlation with medical complaint information utilized to train the triage artificial intelligence engine (para, “[0046] The conversational engine 114 may be in charge of understanding user's input(s), reasoning about the user's input(s), and deciding what is the most appropriate output(s) after consulting with the DDx 116 and the KB 118. The DDx 116 may produce a ranked list of possible diagnoses given any number of findings, which may be symptoms expressed by the patient as well as their history, demographics, etc. In an embodiment, the DDx 116 may be based on rules in a knowledge based codifying probabilistic relationships between symptoms/findings and diseases. In another embodiment, the DDx 116 may be based on machine-learned models deriving relations between symptoms/findings and diseases from historical medical records. In yet another embodiment, the DDx 116 may be based on machine-learned models deriving both probabilities and relationships from historic medical records. In another embodiment, the DDx 116 may be based on machine-learned models learned from mixed data that includes at least one of synthetic data generated by a pre-existing expert system, electronic medical records, manual cases, labeled cases from the diagnosis engine, as will be described below. Alternatively, the DDx 116 may comprise all these embodiments working in ensemble such that each embodiment may operate based on a current state of knowledge independently, and offer possible responses along with a confidence and a value estimate. Additionally, there may be an ensemble arbitrator to choose a response out of the possible responses or a collection of responses from the different embodiments, that is best for the user or circumstance given a match or a mismatch between the possible responses, and the value and the confidence estimate each embodiment expresses in its corresponding response. The ensemble arbitrator may learn a weight to use for each possible response from each of embodiment of the DDx 116 based upon history.”);
generating, by utilizing the triage artificial intelligence engine and based on the medical complaint, a digital record associated with the individual, wherein the digital record includes a plan associated with addressing the medical complaint (para , “[0068] FIG. 6 is a flowchart illustrating a method 600 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 600 begins at step 610 with the user making a healthcare inquiry. At step 620, the method 600 determines and classifies the intent of user's inquiry as one of a plurality of intent classifications (as described below), using a conversational engine (e.g., conversational engine 114). The method 600 proceeds to step 630, where a decision is made as to whether the user's intent is understood. If the user's intent is not understood (in which case, no trustworthy actionable recommendation may be provided with some degree of confidence), the user's inquiry is escalated to a doctor, at step 640. However, if the user's intent is understood at step 630, the method 600 moves to step 650 and instantiates one of a plurality of specialized conversational engines for the intent, based on the intent classification. Then, at step 660, based on interfacing with a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118), the method 600 elicits more information from the user (if needed). Once all needed information is obtained from the user, the method 600 decides, at step 680, whether a confident recommendation may be made. If a confident recommendation may not be made at step 680, the user's inquiry is escalated to a doctor, at step 640. Otherwise, a recommendation (e.g., diagnosis, referral, treatment, etc.) is made to the user at step 690. The goal of the method 600, therefore, is to provide at least one of a plurality of actionable recommendations to the user.”);
finalizing the digital record if a standing order protocol exists that matches criteria associated with the plan in the digital record (para, “[0134] FIG. 14 is a flowchart illustrating a method 1400 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 1400 begins at step 1410 with the user making a healthcare inquiry. At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment. If the user's intent is not related to either a diagnosis or a treatment, the method 1400 invokes a converse at step 1440. The converse generates a reasonable response based on what the medical decision support system knows about its past few interactions with the user. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”);
the standing order protocol comprising executable rules that, when matched, cause the system to perform predefined actions including specifying one or more orders associated with the plan((para, “[0134] FIG. 14 is a flowchart illustrating a method 1400 for responding to a healthcare inquiry from a user (e.g., a patient) using a medical decision support system (e.g., the system 100, 200, or 300) in accordance with an embodiment of the present disclosure. The method 1400 begins at step 1410 with the user making a healthcare inquiry. At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment....”
Para, “[0082] ..... The intent classification module 710 may classify a user's intent into a finite set of “intents.” Those intents include, but are not limited to, diagnosis, doctor referral, prescription or treatment recommendation, and information on a given disease....”) ;
in response to the finalizing and in accordance with the executable rules of the standing order protocol, automatically generating the specified one or more orders and transmitting at least one of the orders or the digital record to at least one of the individual, a third party, or a medical billing system((Para, “[0121] Similarly, some situations may require the patient to undergo some form of laboratory testing. In some cases, the kind of testing might be available through some form of at-home procedure (e.g., blood pressure), but in many other cases the patient may need to visit a physician or pharmacist. For the former, the system 100 may refer the patient to existing third-party applications and solutions. For the latter, the system 100 may refer the patient to nearby facilities considering all the information about the patient and the current situation (e.g., how urgent the test is). In any of these cases, the system 100 may facilitate the paperwork. The system 100 may include a database of pharmacies and doctors that may provide a given test procedure.”);
providing, if the standing order protocol does not exist, the digital record for further review by a provider via a provider worklist(para, “[0134] …….At step 1420, the method 1400 classifies the intent of user's inquiry (e.g., using intent classification module 710). The method 1400 proceeds to step 1430, where a decision is made as to whether the user's intent is related to either a diagnosis or a treatment. If the user's intent is not related to either a diagnosis or a treatment, the method 1400 invokes a converse at step 1440. The converse generates a reasonable response based on what the medical decision support system knows about its past few interactions with the user. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”);
and modifying, based on an input received that is associated with the further review, the digital record (para, “[0134]….. However, if the user's intent is related to either a diagnosis or a treatment at step 1430, the method 1400 moves to step 1450 and determines whether the confidence on a given diagnosis or treatment is above a predetermined threshold. If the confidence is below or at the predetermined threshold, the method 1400 moves to step 1460 to generate a next question, as described above, to elicit more information from the user. If the confidence is above the predetermined threshold, the method 1400 moves to step 1470 to communicate either a diagnosis or a treatment (informed by a diagnosis engine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) to the user. Any of the response from step 1440, the next question from step 1460, and the diagnosis or treatment from step 1470 may require an optional approval/edit by a medical expert at step 1480 before being presented to the user. For example, the method 1400 may trigger step 1480 based on predefined settings (e.g., a physician may need to approve diagnosis recommendations that include diagnosis above a certain severity).”).
KANNAN does not explicitly teach:
wherein the interacting comprises capturing. by utilizing a sensor device, the sensor data associated with the individual,
Trajkovic teaches:
wherein the interacting comprises capturing. by utilizing a sensor device, the sensor data associated with the individual(para, “[0013] The data acquisition subsystem may be deployed in a triage or assessment area of the facility 102 and includes one or more sensors 116. The sensors 116 are generally configured to detect current status attributes for a patient 120. For example, the sensors 116 may include direct sensors, such as a blood pressure sensor 116-1. The direct sensors are generally configured to directly detect a measurable attribute of the patient 120, such as the patient’s heart rate, blood pressure, temperature, or the like. The sensors 116 may further include indirect sensors configured to capture data from which attributes of the patient 120 may be derived….”
Also, para “[0032] At block 305, the data acquisition subsystem obtains current status attributes for the patient 120. The data acquisition subsystem may obtain directly measured attributes, as well as derived attributes. For example, the data acquisition subsystem may obtain various vital signs (e.g., blood pressure, heart rate, temperature, and the like) and other measurable attributes of the patient 120 via the direct sensors. The data acquisition subsystem may further obtain raw image data from the camera 116-2 and apply image processing and/or computer vision analysis at the processor 124 to derive visually perceptible attributes of the patient 120.”)
It would have been obvious for a person of ordinary skill in the art to apply capturing data using sensor teachings of Trajkovic into the teachings of Kannan at the time the application was filed in order to detect current status attributes for a patient. (para “[0013] The data acquisition subsystem may be deployed in a triage or assessment area of the facility 102 and includes one or more sensors 116. The sensors 116 are generally configured to detect current status attributes for a patient 120. For example, the sensors 116 may include direct sensors, such as a blood pressure sensor 116-1. The direct sensors are generally configured to directly detect a measurable attribute of the patient 120, such as the patient’s heart rate, blood pressure, temperature, or the like. The sensors 116 may further include indirect sensors configured to capture data from which attributes of the patient 120 may be derived. For example, the indirect sensors may include a camera 116-2 or other image sensor, to capture image data representing the patient 120. The image data may then be analyzed to derive visually perceptible attributes of the patient 120, such as a rash or discoloration on the patient’s skin, sweating or shivering of the patient, or the like…”)
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan as modified by Trajkovic in view of Beale et al. (US 20170169177 A1)
Regarding claim 7, KANNAN as modified by Trajkovic teaches the system of claim 6.
KANNAN as modified by Trajkovic doesn’t explicitly teach wherein the input associated with the further review is generated based on the teleconference for the consultation between the individual and the provider.
Beale teaches wherein the input associated with the further review is generated based on the teleconference for the consultation between the individual and the provider (para, “[0050] After some period of time, the AI system 603 will analyze feedback from patient devices 607, patient adherence to prescribed homework 608, and any changes in symptoms 609 and use this information to suggest advantageous revisions to the initial plan of service 605, in the form of a revised treatment plan 610. The professional, in consultation with the patient, is free to accept or reject any of these proposed changes or to make other non-proposed changes. In any event, the next iteration of the treatment plan begins 610 and the new interventions 611 are pursued in much the same manner as the original ones. This process could possibly have numerous iterations, but for the sake of brevity, a single iteration will be described here.”
Para, “[0033] In this system 100, a healthcare professional 105 will contribute data to the system through a range of means. Through both the in-session screen 106 and the not-in-session screen 107, the professional 105 will be able to select and identify in-session interventions as well as homework assignments. The professional 105 will also enter assessments, diagnoses, and prognoses into the system. They will also be able to meet with a patient 101 via encrypted real-time image and audio presence to provide professional consultation, education, assessment, diagnosis, intervention, or treatment. The professional 105 will also receive feedback about the patient's adherence to prescribed treatments, receive suggestions about optimized treatment interventions, and receive additional data about the patient's psychological state and recent behaviors.” Note: patient can receive consultation via teleconferencing (real time image and audio), and furthermore the professional in consultation with patient can accept/reject plan changes, or make other non-propose changes. Kannan already teaches teleconferencing and editing the treatment, but it doesn’t explicitly state that edit to treatment is done while teleconferencing, which is being explicitly addressed by Beale reference.)
It would have been obvious for a person of ordinary skill in the art to apply plan modification during consultation teachings of Beale into the teachings of Kannan as modified by Trajkovic at the time the application was filed in order to accept/reject proposed changes to the initial plan of service via consultation. (Para, “[0050] … The professional, in consultation with the patient, is free to accept or reject any of these proposed changes or to make other non-proposed changes.….”)
Regarding claim 8, KANNAN as modified by Trajkovic and Beale teaches the system of claim 7.
Beale further teaches wherein the processor is further configured to finalize the digital record based on the input by updating the plan based on additional information obtained via the teleconference for the consultation (para, “[0050] After some period of time, the AI system 603 will analyze feedback from patient devices 607, patient adherence to prescribed homework 608, and any changes in symptoms 609 and use this information to suggest advantageous revisions to the initial plan of service 605, in the form of a revised treatment plan 610. The professional, in consultation with the patient, is free to accept or reject any of these proposed changes or to make other non-proposed changes. In any event, the next iteration of the treatment plan begins 610 and the new interventions 611 are pursued in much the same manner as the original ones. This process could possibly have numerous iterations, but for the sake of brevity, a single iteration will be described here.”
Para, “[0033] In this system 100, a healthcare professional 105 will contribute data to the system through a range of means. Through both the in-session screen 106 and the not-in-session screen 107, the professional 105 will be able to select and identify in-session interventions as well as homework assignments. The professional 105 will also enter assessments, diagnoses, and prognoses into the system. They will also be able to meet with a patient 101 via encrypted real-time image and audio presence to provide professional consultation, education, assessment, diagnosis, intervention, or treatment. The professional 105 will also receive feedback about the patient's adherence to prescribed treatments, receive suggestions about optimized treatment interventions, and receive additional data about the patient's psychological state and recent behaviors.”)
It would have been obvious for a person of ordinary skill in the art to apply plan modification during consultation teachings of Beale into the teachings of Kannan as modified by Trajkovic and Beale at the time the application was filed in order to accept/reject proposed changes to the initial plan of service via consultation. (Para, “[0050] … The professional, in consultation with the patient, is free to accept or reject any of these proposed changes or to make other non-proposed changes.….”)
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kannan as modified by Trajkovic in view of Bates (US 20170323064 A1)
Regarding claim 10, KANNAN as modified by Trajkovic teaches the system of claim 1.
KANNAN as modified by Trajkovic does not explicitly teach wherein the processor is further configured to transmit the digital record to the medical billing system for further processing after the digital record is finalized.
Bates teaches wherein the processor is further configured to transmit the digital record to a medical billing system for further processing after the digital record is finalized (para, “[0079] Returning to FIG. 1, automated diagnostic system 102, in embodiments, comprises a payment feature that uses patient identification information to access a database to determine if a patient 109 has previously arranged a method of payment. If the patient database does not indicate a previously arranged method of payment, automated diagnostic system 102 may prompt the patient to enter payment information, such as insurance, bank, or credit card information. Automated diagnostic system 102 may determine whether the payment information is valid and automatically obtain an authorization from the insurance, EHR system and/or the card issuer for payment for a certain amount for services rendered by the doctor. An invoice may be electronically presented to the patient 109, e.g., upon completion of a consultation, such that the patient 109 can authorize payment of the invoice, e.g., via an electronic signature.” Note: here the system is automated, and it is automatically processing the billing, thus record is received by the billing system.)
It would have been obvious for a person of ordinary skill in the art to apply automatic billing teachings of Bates into the teachings of Kannan as modified by Trajkovic at the time the application was filed in order to automatically charge for services provided. (Para, “[0079] ….. Automated diagnostic system 102 may determine whether the payment information is valid and automatically obtain an authorization from the insurance, EHR system and/or the card issuer for payment for a certain amount for services rendered by the doctor….”)
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan as modified by Trajkovic in view of Riker et al. (US 20050111621 A1)
Regarding claim 12, KANNAN as modified by Trajkovic teaches the system of claim 1.
KANNAN as modified by Trajkovic does not explicitly teach wherein the processor is further configured to generate a derivative digital record based on updates to the information that occur over time.
Riker teaches wherein the processor is further configured to generate a derivative digital record based on updates to the information that occur over time (para, “[0129] In the preferred embodiment of the present invention, the computer planning system 35 provides ability to interpolate between "checkpoints". Some treatment planning systems provide a means for saving or temporarily storing a plurality of iterations of a treatment plan in the form of an updated version, for subsequent comparison and to permit backtracking. The user is provided a real-time control permitting the user to establish any two plans ("checkpoints") as the end points on a single continuum, thus providing the user an enhanced speed and freedom in exploring various contingent possibilities. Referring to FIG. 3, the GUI display 150 can include a button 158, drop-down menu (not shown), or a similar device which permits access to the list of plans, and a button 158', drop-down menu (not shown), or a similar device which permits adding the current plan to the list. The interpolate between checkpoints function can allow the user to make some changes, save the modified plan as another version, and then later recall any of the prior versions in order to basically slide back and forth within the continuum between those versions, or prior versions, or with the current display plan, to further develop even more contingent versions.”)
It would have been obvious for a person of ordinary skill in the art to apply creating plan derivates teachings of Riker into the teachings of Kannan as modified by Trajkovic at the time the application was filed in order to develop contingent plans. (Para 0129, “….The interpolate between checkpoints function can allow the user to make some changes, save the modified plan as another version, and then later recall any of the prior versions in order to basically slide back and forth within the continuum between those versions, or prior versions, or with the current display plan, to further develop even more contingent versions.”)
Regarding claim 13, KANNAN as modified by Trajkovic and Riker teaches the system of claim 12.
Riker further teaches wherein the processor is further configured to conduct a variance analysis of the digital record with the derivative digital record to detect a discrepancy between the digital record and the derivative record, a change in the plan of the digital record and a derivative plan in the derivative digital record, occurrence of an error, or a combination thereof (para, “[0129] In the preferred embodiment of the present invention, the computer planning system 35 provides ability to interpolate between "checkpoints". Some treatment planning systems provide a means for saving or temporarily storing a plurality of iterations of a treatment plan in the form of an updated version, for subsequent comparison and to permit backtracking. The user is provided a real-time control permitting the user to establish any two plans ("checkpoints") as the end points on a single continuum, thus providing the user an enhanced speed and freedom in exploring various contingent possibilities. Referring to FIG. 3, the GUI display 150 can include a button 158, drop-down menu (not shown), or a similar device which permits access to the list of plans, and a button 158', drop-down menu (not shown), or a similar device which permits adding the current plan to the list. The interpolate between checkpoints function can allow the user to make some changes, save the modified plan as another version, and then later recall any of the prior versions in order to basically slide back and forth within the continuum between those versions, or prior versions, or with the current display plan, to further develop even more contingent versions.”
Also, para “[0028] To some extent, radiation therapy treatment planning is still an art of balance and compromise. It would be advantageous to provide a partial "undo of changes function" to aid a user, wanting to make a plan variation, in the discovery of what sacrifices that a particular change requires. It would correspondingly be advantageous to provide the user with a real-time control permitting the user to dynamically undo a change, completely or partially, and to explore trade-offs, in order to quickly select an optimum balance.”)
It would have been obvious for a person of ordinary skill in the art to apply creating plan derivates teachings of Riker into the teachings of Kannan as modified by Trajkovic and Riker at the time the application was filed in order to develop contingent plans. (Para 0129, “….The interpolate between checkpoints function can allow the user to make some changes, save the modified plan as another version, and then later recall any of the prior versions in order to basically slide back and forth within the continuum between those versions, or prior versions, or with the current display plan, to further develop even more contingent versions.”)
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kannan as modified by Trajkovic and in view of Hanov et al. (US 20100179825 A1)
Regarding claim 16, KANNAN as modified by Trajkovic teaches the method of claim 14.
Kannan as modified by Trajkovic does not explicitly teach further comprising determining whether a second encounter with the individual is associated with the medical complaint.
Hanov teaches further comprising determining whether a second encounter with the individual is associated with the medical complaint (para, “[0031] As previously mentioned, in one embodiment, the present invention relates to a computerized method and system for use in, e.g., a healthcare computing environment, for copying a healthcare plan, order, phase, or portion thereof, that is associated with a first encounter for a patient and includes at least one patient-specific customization, upon the patient presenting on a second encounter having the same condition/diagnosis. With reference to FIGS. 2A-2E, a flow chart representative of such a method in accordance with an embodiment of the present invention is illustrated and depicted generally as reference numeral 200. Method 200 may be implemented on the above-described exemplary computing system environment (FIG. 1) and, by way of example only, may be utilized to present to a clinician, at least one previously ordered and patient-customized healthcare plan, order, phase, or portion thereof, upon the patient presenting in association with a subsequent encounter. (The terms "individual", "person", and "patient" are used interchangeably herein and are not meant to limit the nature of the referenced individual in any way. Rather, the methods and systems described herein are equally applicable in, for instance, a veterinary setting. Further, use herein of the term "patient" is not meant to imply any particular relationship between the individual and those modifying component(s) of a clinical order.)”)
It would have been obvious for a person of ordinary skill in the art to apply checking previous encounter teachings of Hanov into the teachings of Kannan as modified by Trajkovic at the time the application was filed in order to save time. (Para 0005, “….In this way, the clinician can save time in ordering plans of care as they do not have to make the same customizations every time they want to order the same plan of care/order/phase for a particular patient.”)
Regarding claim 17, KANNAN as modified by Trajkovic and Hanov teaches the method of claim 16.
Hanov further teaches further comprising presenting the digital record associated with the individual to the individual to confirm whether a change is to be made to the digital record if the second encounter is associated with the medical complaint (para, “[0031] As previously mentioned, in one embodiment, the present invention relates to a computerized method and system for use in, e.g., a healthcare computing environment, for copying a healthcare plan, order, phase, or portion thereof, that is associated with a first encounter for a patient and includes at least one patient-specific customization, upon the patient presenting on a second encounter having the same condition/diagnosis. With reference to FIGS. 2A-2E, a flow chart representative of such a method in accordance with an embodiment of the present invention is illustrated and depicted generally as reference numeral 200. Method 200 may be implemented on the above-described exemplary computing system environment (FIG. 1) and, by way of example only, may be utilized to present to a clinician, at least one previously ordered and patient-customized healthcare plan, order, phase, or portion thereof, upon the patient presenting in association with a subsequent encounter. (The terms "individual", "person", and "patient" are used interchangeably herein and are not meant to limit the nature of the referenced individual in any way. Rather, the methods and systems described herein are equally applicable in, for instance, a veterinary setting. Further, use herein of the term "patient" is not meant to imply any particular relationship between the individual and those modifying component(s) of a clinical order.)”)
It would have been obvious for a person of ordinary skill in the art to apply checking previous encounter teachings of Hanov into the teachings of Kannan as modified by Trajkovic and Hanov at the time the application was filed in order to save time. (Para 0005, “….In this way, the clinician can save time in ordering plans of care as they do not have to make the same customizations every time they want to order the same plan of care/order/phase for a particular patient.”)
Regarding claim 18, KANNAN as modified by Trajkovic and Hanov teaches the method of claim 16.
Hanov further teaches further comprising generating a new digital record if the second encounter is not associated with the medical complaint (para, “[0019] ….. If the patient has not previously presented with the same condition/diagnosis, a clinician searches for and selects an appropriate healthcare plan, order and/or phase from a plurality of reference plans/orders/phases; customizes the selected healthcare plan, order and/or phase (that is, adds an order, removes an order, changes an order detail, calculates a medication dose, or the like); and orders the customized plan/order/phase for the patient. If, however, it is determined that the patient has previously presented with the same condition/diagnosis, the clinician is presented with a list of healthcare plans, orders and/or phases that have been previously ordered and customized for the patient. The clinician may select an appropriate plan/order/phase from the presented listing and the selected plan/order/phase will include the customizations previously made for the patient. In this way, the clinician can save time in ordering plans of care as they do not have to make the same customizations every time they want to order the same plan of care/order/phase for a particular patient.” Note: here new record/plan is created using the reference plan.)
It would have been obvious for a person of ordinary skill in the art to apply checking previous encounter teachings of Hanov into the teachings of Kannan as modified by Trajkovic and Hanov at the time the application was filed in order to save time. (Para 0005, “….In this way, the clinician can save time in ordering plans of care as they do not have to make the same customizations every time they want to order the same plan of care/order/phase for a particular patient.” Note: in instance case it is obvious that if there is no previous plan, one need to create new plan.
Response to Arguments
Applicant's arguments filed on 06 have been fully considered but they are not persuasive.
Remarks - 35 USC § 101
In remarks, Pg. 10, applicant contends: “Under Step 2A, Prong 1, the claims are not "directed to" an abstract idea (e.g., mental process). For example, at least the following claim elements cannot be performed "in the human mind" or merely with pen and paper: (1) Capturing sensor data "by utilizing a sensor device" (e.g., claims 1, 14, 20). Humans do not and cannot "capture" objective sensor signals without instrumentation; this step requires a particular class of hardware and produces non-mental data streams. (2) Identifying a medical complaint "based on correlation" to "medical complaint information utilized to train the triage artificial intelligence engine" (e.g., claims 1, 14, 20). This entails the use of a trained AI model operating on acquired sensor data and other information; the correlation computation and model inference cannot be performed in the human mind as claimed, particularly at the scale/format of sensor/device data. (3) Finalizing conditioned on "a standing order protocol comprising executable rules that specify one or more orders" and "automatically generate the specified one or more orders and transmit" them, including "to a medical billing system" (e.g., claims 1, 14, 20). These steps expressly provide a machine to evaluate rule matches, specify orders, generate those orders, and perform electronic transmission to named endpoints (individual, third party, medical billing). The foregoing is technological workflow orchestration, not a mental step. Additionally, the claimed sequence is a specific technological workflow. The Office Action's abstraction of "recording a complaint and finalizing it" omits the required technological components and machine actions. Under the broadest reasonable interpretation, each independent claim, as amended, recites concrete operations that depend on sensors, trained models, executable-rule protocols, and electronic transmissions to external systems (including billing). Those are not mental processes.”
As argued above , capturing sensor data is non-mental step. One could gather patient data in a clinical setting using pen and paper, thus capturing the data, and if it needs to be captured by sensor, this is just on apply level. A tool can be used to gather/capture data but its only done on generic level. The training of AI model on acquired data is how any machine learning model being trained works. There is no detail of how this particular AI training is different from a normal training of a model. The correlation computation is simply using mathematical concept (comes under abstract idea) . Executing rules and automatically generating orders are simply using computer as a tool , when conditions are met. Transmitting data over the network is insignificant extra-solution activity , see MPEP 2106.05(g) , (“i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information”); See, MPEP 2106.05 (d)(II).
A patient ‘s data can be matched with specified rules/conditions , and based on them any order can be generated in a clinical setting. The data can be transferred between different departments for review/update etc. As for as performing all these task are concerned using machine/computer, this is merely on apply level . On contrary to be defined by applicant, sensors, trained models, executable -rule protocols and electronic transmissions can be done using computer as a tool. As far as meeting conditions to generate orders, its simply reaching a threshold/value and followed by order generation, which is analyzing and judging, thus falling under abstract idea of mental process. The examiner agrees the entire claim is not an abstract idea, and it contains many additional limitations; however, the additional limitations alone, or in combination as whole don’t integrate the abstract idea into practical application. The claims, or the specification don’t provide any technical details that show improvement into the technology.
In remarks, Pg. 11, applicant contends : Under Step 2A, Prong 2, even if an abstract concept were implicated, the claims integrate it into a practical application. For example, the claims provide meaningful application of technology to achieve a real-world result: (1) Required data acquisition via "sensor device" transforms the interaction into machine-enabled data capture beyond mere information reception. (2) Use of a trained "triage artificial intelligence engine" to identify complaints "based on correlation" integrates AI model inference into the workflow, applying a specific technology to analyze multi-modal inputs (including sensor data). (3) Conditional finalization based on a protocol "comprising executable rules that specify orders associated with the plan" imposes a concrete decision structure that drives downstream actions. This is more than a "field of use": it is a particular control mechanism within clinical case management. (4) "Automatically generate the specified orders and transmit" them "to a medical billing system" (and/or individual/third party) ties finalization to machine-executed operational consequences-creating orders and pushing them into billing and external recipients. That is a tangible, practical application with immediate real-world effect on care delivery and revenue- cycle processing. (5) If the protocol does not exist, the record is routed "via a provider worklist," and the record is then "modified based on input associated with the further review." This establishes a gating mechanism tied to the existence/non-existence of executable protocols, integrating expert review via a defined workflow-not a generic post-processing step. Furthermore, the ordered combination meaningfully limits any alleged abstract idea to a specific clinical triage and order-generation/billing process. It is not simply "apply it on a
computer"; the claims require particular components and rule-based controls that cause real- world actions (order generation, transmission to billing) when conditions are met.”
The applicant provides conclusory statement about the limitations discussed in the argument.(1) Capturing data using sensor does make it machine-enabled captured data, but machine is being used merely as a tool . One could acquire data simply using pen and paper , and it can be collected using sensor/machine as well. Here is no detail of how sensor is being used to collect the data. (2) Using a trained “triage artificial intelligence engine” in to the workflow is merely using it. In a clinical setting one could acquire symptoms/complaints or any sort of data and triage based on the need. Here the trained AI is only being used, which already has data feed in to it.(3) Conditional finalization for concrete decision is simply following rules/protocols in a clinical case management. A case goes through a hierarchy of management , and follow certain protocols /instructions before a final decision is made. (4) Generating specified orders and transmitting them to medical billing system/ third party is insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) ) “the courts have recognized the computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (“i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information”); See, MPEP 2106.05 (d)(II)
Here, transmitting over the network is extra-solution activity; however, the application of rules, analyzing, and judging is part of abstract idea itself.
In remarks, Pg. 12, applicant contends: “With regard to Step 2B, the claims recite "significantly more" than well-understood, routine, and conventional (WURC) computer functions. For example, specific, non- conventional features and ordered combination include: (1) A triage AI model that identifies medical complaints based on correlation to training data and sensor-device inputs is not a generic computer function; it is a specifically trained inference engine integrated into the claimed workflow. (2) A "standing order protocol comprising executable rules" that, upon matching criteria associated with the plan, "specif[ies] one or more orders," is a specialized rule-based control mechanism, not a routine computer operation. It dictates the content and issuance of clinical orders tied to plan criteria. (3) "Automatically generate orders and transmit" them "to a medical billing system" evidences a concrete, automated post-decision pathway into revenue-cycle operations. This is not mere data display; it is actionable electronic order generation and delivery to external endpoints (including billing). (4) The negative- condition routing "via a provider worklist" and subsequent "modifying based on input" reflects a non-trivial clinical governance loop contingent on the presence/absence of standing protocols. The ordered combination of AI triage, protocol-based finalization, automatic order/billing transmission, and governed provider review is far from a routine, generic computer sequence. Moreover, the Office Action does not provide factual evidence that the above ordered combination was well-understood, routine, and conventional at the relevant time. Absent such evidence, and given the claim's specificity, Step 2B is satisfied.”
The above argument substantially recites, the previous argument under step 2B, and is addressed in same manner as argument above. Simply put, the claims, or the specification discusses use of technology such as sensor, and intelligence engine, however, it doesn’t provide any improvement to these technologies, neither is I listing any technical issue, and providing the solution to technical problem.
Remarks - 35 USC § 103
In remarks, Pg. 16, applicant contends :
“Kannan, relied upon as the primary reference, fails to disclose or suggest the claimed "standing order protocol" framework or the downstream, rule-governed actions that follow finalization. The Office Action's mapping consistently cites Kannan's intent classification and confidence-threshold flow (see Kannan paragraph [0134]), in which the system classifies a user's intent, determines whether confidence exceeds a threshold, and either elicits more information or "communicate[s] either a diagnosis or a treatment" to the user, optionally seeking expert approval/edit before presentation. A confidence threshold with optional approval/edit is not a "standing order protocol comprising executable rules" that, upon matching criteria associated with the plan in the digital record, "specif[ies] one or more orders associated with the plan," nor does Kannan condition "finaliz[ation]" of a digital record on such a protocol match. Furthermore, Kannan does not disclose "in response to the finalizing and in accordance with the executable rules of the standing order protocol, automatically generat[ing] the specified one or more orders and transmit[ting] at least one of the orders or the digital record" to the individual, third parties, or a medical billing system. The passages cited for Kannan's follow-up, referral, or facilitation of paperwork (e.g., Kannan paragraphs [0112], [0114]) do not teach protocol-based order specification, conditional record finalization, or the claimed automatic generation/transmission to named endpoints (including billing). The Office Action';s attempt to equate a "confidence threshold" with a "standing order protocol comprising executable rules" is a hindsight reconstruction that lacks support in Kannan and does not satisfy the requirement to show a teaching or a reasoned motivation to modify the primary reference into the claimed protocol-governed workflow.”
The summary of above arguments is that applicant believes that examiner is equating “A confidence threshold with optional approval/edit is not a " to be standing order protocol. The applicant’s amendments further clarify that “wherein the standing order protocol comprises executable rules that, when matched, cause the system to perform predefined actions.”
The examiner have elaborated on this point in detail, in the office action mailed on 09/19/2025, Pg. 59-62. The examiner doesn’t equate threshold to be standing order protocol, rather determining the intent is being equated to determining the standing order protocol. Note, as explained previously, intent in the reference is not defined as plain meaning, rather para 0082 states:
“[0082] In order to offer the above functionalities, the system may implement a dialog engine (e.g., the conversational engine 114) that may include an intent classification module. FIG. 7 illustrates the operation of an intent classification module 710 within a conversational engine 700, in accordance with an embodiment of the present disclosure. The conversational engine 700 may be an example of the conversational engine 114. The intent classification module 710 may classify a user's intent into a finite set of “intents.” Those intents include, but are not limited to, diagnosis, doctor referral, prescription or treatment recommendation, and information on a given disease. The intent classification module 710 may be built by using a combination of encoded rules and machine-learned classifier models....”
As can be seen intent can be classified as diagnosis, doctor referral, treatment recommendation etc... Here, intent is classified into any of the above category, and each of the category such as doctor referral or treatment recommendation are standing order protocols. In step 620 (Fig. 6), the intent is determined, but in order for the intent to be properly determined, it have to be above the threshold (step 630), if it is not above the threshold, then there is no standing order protocol, thus the inquiry is escalated to doctor. As can be seen, if the classification is determined, then in step 650, specialized conversation engine for the intent is initialized, in other words corresponding standing order protocol is initialized.
In remarks, Pg. 17, applicant contends :
The amended claims also provide for a negative-condition routing: "provide, if the standing order protocol does not exist, the digital record for further review by a provider via a provider worklist," and "modify based on an input received that is associated with the further review." Kannan's flow (See paragraph [0134]) does not disclose routing via a "provider worklist" tied specifically to the nonexistence of a standing order protocol. Rather, Kannan discusses escalation to a doctor when intent is not understood or confidence is insufficient and optional approval/edit prior to user presentation. That governance is not conditional routing based on standing-order existence, nor is it routing through a provider "worklist" as claimed. The Office Action does not identify any passage in Kannan teaching a provider worklist mechanism anchored to the presence/absence of standing orders.”
As explained, with regard to above argument, the escalation to doctor is based on, if the intent (protocol) related to patient inquiry can’t be determined with confidence. Para 0068, teaches this conditional aspect very clearly:
“....The method 600 proceeds to step 630, where a decision is made as to whether the user's intent is understood. If the user's intent is not understood (in which case, no trustworthy actionable recommendation may be provided with some degree of confidence), the user's inquiry is escalated to a doctor, at step 640. However, if the user's intent is understood at step 630, the method 600 moves to step 650 and instantiates one of a plurality of specialized conversational engines for the intent, based on the intent classification...”.
Here intent being not understood is equated to standing protocol not existing; note, as stated above, the reference uses intent as classification, not persons intention. Para 0082, “...Those intents include, but are not limited to, diagnosis, doctor referral, prescription or treatment recommendation, and information on a given disease. ...”)
For example, here, if one can tell with confidence, the treatment recommendations for users inquiry, it means the protocol existed, that could be recommended; however, if one could not determine the treatment with confidence (no protocol), then it will be escalated to doctor. Regarding “via provider worklist”, para 0067 teaches:
“A Celery 518, which may be included in the engine 408, is an asynchronous task queue/job queue based on distributed message passing. The Celery 518 may be focused on real-time operation, and may also supports scheduling...”
The escalation message is being passed via the job queue, thus provider worklist. Also, it is given, that if the system is not understanding, how to direct user’s inquiry with confidence, and escalating to a doctor, then it is via provider worklist. Also , Note, regarding claims 14-19 , these are process/method claims, and conditional /contingent language is not given a patentable weight.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUMA WASEEM whose telephone number is (571)272-1316. The examiner can normally be reached Monday-Friday(9:00am - 5:00 pm) 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, Jason B. Dunham can be reached on (571) 272-8109. 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.
/HUMA WASEEM/Examiner, Art Unit 3686
/JASON B DUNHAM/Supervisory Patent Examiner, Art Unit 3686
Prosecution Insights