SYSTEM, METHODS, AND APPARATUSES FOR MANAGING DATA FOR ARTIFICIAL INTELLIGENCE SOFTWARE AND MOBILE APPLICATIONS IN DIGITAL HEALTH THERAPEUTICS

Application No. 17/833,625

• Filed: Jun 06, 2022
• Examiner: WILLIAMS, TERESA S
• Art Unit: 3687
• Tech Center: 3600 — Transportation & Electronic Commerce
• Assignee: Click Therapeutics Inc.
• OA Round: 3 (Non-Final)

Office Action

DETAILED ACTION
Status of Claims
This action is in reply to the Request for Continued Examination filed on 10/29/2025.
Claims 43-46, 54-57, 86, 89-90, 92, 96, 99-102, 114, 119-121, 126, 129-130, 132, 136, 141-143, 148, 151-152 and 154 have been amended.
Claims 1-42, 51-52, 62-63 and 65-85 have been cancelled.
Claims 43-50, 53-61, 64 and 86-157 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 10/29/2025 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 43-50, 53-61, 64 and 86-157 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 43-50, 86-95, 106-109 and 114-135 are directed to a method (i.e., a process) and claims 54-61, 64, 86-113, and 136-157 are directed to a system (i.e., a machine). Accordingly, claims 43-50, 53-61, 64 and 86-157 are all within at least one of the four statutory categories.
Step 2A - Prong One:
An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Representative independent claims 54 and 136 include limitations that recite an abstract idea.
Specifically, the abstract idea in independent claim 54 recites:
An apparatus, the apparatus to treat a cardiometabolic condition of a user comprising:
a processor configured to:
receive, from one or more devices associated with a user, a plurality of initial inputs and an indicator of a cardiometabolic condition of the user, wherein each initial input of the plurality of initial inputs contains a value;
store each value of the plurality of initial inputs into a database that is configured to store one or more database records of the user;
provide a therapy regimen to treat a cardiometabolic condition of the user, the therapy regimen comprising one or more machine- readable computer files containing machine-executed instructions, the one or more machine- readable computer files configured to generate a plurality of graphical user interfaces (GUIs) to provide content to a software application on the one or more devices associated with the user;
monitor interactions between the user and the software application;
applying, by the one or more processors, the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample users labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome;
update the therapy regimen in accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition; and
transmit content to present via the plurality of GUIs based on the updated therapy regimen.
Specifically, the abstract idea in independent claim 136 recites:
An apparatus to treat a cardiometabolic condition of a user, the apparatus comprising:
a processor configured to:
receive, from one or more devices associated with a user, a request to generate a therapy regimen to treat a cardiometabolic condition of a user, said request comprising a plurality of initial inputs and an indicator of the cardiometabolic condition of the user, wherein each initial input of the plurality of initial inputs contains a value;
store each value of the plurality of initial inputs into a database that is configured to store one or more database records of the user;
generate the therapy regimen to treat the cardiometabolic condition of the user, the therapy regimen based upon data of the request, wherein the therapy regimen comprises one or more machine-readable computer files containing one or more machine executable instructions, the one or more machine-readable computer files configured to generate a graphical user interfaces (GUIs) to provide content;
transmit the therapy regimen to a software application on one or more user devices;
monitor interactions between the user and the software application;
apply the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample users labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome;
update the therapy regimen accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition; and
transmit content to present via the plurality of GUIs based on the updated therapy regimen.
The Examiner submits that the foregoing underlined limitations constitute: (a) “certain methods of organizing human activity” because providing a therapy regimen associated with a user who has a cardiometabolic condition and causing an improvement in a likelihood of success corresponding to the cardiometabolic condition are treating patient or providing healthcare services, which relate to managing human behavior/interactions between people. For example, an individual with a medical condition may use a medical app on the individual’s mobile phone for tracking amounts of physiological activities and providing feedback, as status to determine that the individual is achieving goals in following a therapy regimen. Also, these limitations constitute (b) “a mental process” because monitoring a therapy regimen associated with a user who has a condition by tracking a frequency of interactions is an observation/evaluation/analysis that can be performed in the human mind or with a pen and paper. Furthermore, these limitations constitute (c) “mathematical concepts” because weighing to generate a health score and indicating parameters and relative weights for the parameters are mathematical concepts. Accordingly, the claim describes at least one abstract idea.
Dependent claims 44-50, 53, 55-61, 64, 86-113, 115-135 and 137-157 inherit the limitations that recite an abstract idea from their dependence on claims 43, 54, 114 or 136, and thus these claims also recite an abstract idea under the Step 2A - Prong 1 analysis. In addition, claims 49-53, 64, 87-88, 96, 98, 100-101, 103, 105, 109, 113, 126, 128, 130-131, 135, 140, 148, 150 and 152-153 recite further limitations that: 1) merely recite specific kinds of data and 2) under their broadest reasonable interpretations, amount to additional steps/functions in the method of organizing human activity.
Specifically, claims 44, 55, 119 and 141 recite inputting determining the health score associated with the cardiometabolic condition of the user using the interactions between the user and the machine learning and one or more types of data corresponding to a set of the one or more values for the one or more data inputs stored in the database record of the user. Claims 45, 56, 120 and 142 retraining, by the machine learning software within the one or more processors, the health score model associated with the condition in response to the database storing a predetermined number of additional database records. Claims 46-47, 57-58, 106-108, 110-112, 115-117, 121-122, 138 and 143-144 recite updating, by the computer, the machine model associated with the condition at predetermined time, a chatbot queue of the user to include the chatbot identifier, updating, by the one or more processors, the therapy regimen of the user based upon the updated health score that is updated using the one or more data inputs and the frequency of interactions, updating, by the one or more processors, the health score of the user using the one or more data inputs and a frequency of interactions between the user and the software application to provide an updated health score and updating the therapy regimen of the user further comprises transmitting, by the one or more processors, the updated therapy regimen to the software application of the user. Claims 50, 61, 125 and 147 recite storing, by the one or more processors, each value of the plurality of data inputs into the one or more database records of the user. Claims 53 and 64 recites wherein the device configured to generate the body metric measurement is selected from the group comprising: a smart home device, a wearable device, and a fitness tracker. Claims 86, 93, 126 and 148 recite wherein the condition of the user is a diabetes health condition. Claims 90, 130 and 152 recite wherein the condition of the user is type II diabetes. Claims 91, 101, 131 and 153 recite wherein the machine learning software executes machine learning algorithms and processes selected from the group consisting of generalized linear models, random forests, support vector machines, unsupervised and/or supervised clustering, and deep learning, wherein deep learning includes neural networks. Claims 92, 102, 132 and 154 recite comparing, by the computer or processor, one or more data fields relevant to the user’s condition against pre-stored milestone parameters or data values at predetermined milestone intervals, wherein the prestored milestone values may operate as threshold values. Claims 93, 103, 133 and 155 recite wherein there are multiple pre-stored updated threshold value for multiple data fields, to compare multiple different user values of different fields against multiple different pre-stored values. Claims 94, 104, 134 and 156 recite automatically adjusting, by the computer, features and/or resources provided to the user based upon one or more of the updated health score and the updated threshold value.
Step 2A - Prong Two:
Regarding Prong Two of Step 2A, it must be determined whether the claim as a whole integrates the abstract idea into a practical application. As noted, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
The limitations of claims 43, 54, 114 and 33, as drafted is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting a computer, one or mor processors, one or more devices, one or more machine executable instructions, graphical user interface (GUIs), one or more machine-readable computer files containing machine-executed instructions and a software application to perform the limitations, nothing in the claim elements precludes the steps from practically being performed in the mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation within a health care environment in the mind but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” and “Mental Process” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
The judicial exception is not integrated into a practical application. In particular, the computer, one or mor processors, one or more devices, one or more machine executable instructions, graphical user interface (GUIs), one or more machine-readable computer files containing machine-executed instructions and a software application are recited at high levels of generality (i.e., as generic computer components performing generic computer functions of receiving data/inputs, determining and providing data) such that it amounts no more than mere instructions to apply the exception using the generic computer components.
Regarding the additional limitations “machine learning model”, the Examiner submits that this additional limitation amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)). Regarding the additional limitation “receiving, by one or mor processors, from one or more devices associated with a user, a plurality of initial inputs and an indicator of a condition of the user, wherein each initial input of the plurality of initial inputs contain a value……”, the Examiner submits that this additional limitation merely adds insignificant pre-solution activity (data gathering; selecting data to be manipulated) to the at least one abstract idea (see MPEP § 2106.05(g)).
Thus, taken alone, the additional elements do not amount to significantly more than the above identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvements in the functioning of a computer or an improvement to another technology or technical field, apply or us the above-noted implement/use to above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (see 2019 PEG and MPEP §2106.05). Their collective functions merely provide conventional computer implementation.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer component provide an inventive concept. The claims are not patent eligible.
Step 2B:
Regarding Step 2B, in representative independent claims 43, 54, 114 and 136, regarding the additional limitations of the computer, one or mor processors, one or more devices, one or more machine executable instructions, graphical user interface (GUIs), one or more machine-readable computer files containing machine-executed instructions and a software application, the Examiner submits that these limitations amount to merely using a computer to perform the at least one abstract idea (see MPEP § 2106.05(f)).
Thus, representative independent claims 43 and 54 and analogous independent claims 114 and 136 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
Claims 43, 45, 54-56, 114, 119-120, 136 and 141-142 introduce elements of the machine learning software for performing the generating and retraining steps of the invention amount to no more than mere instructions to apply the exception using generic computer components. Also, claims 91 and 131 introduce elements of the machine learning algorithms and processes selected from the group consisting of generalized linear models, random forests, support vector machines, unsupervised and/or supervised clustering, and deep learning, wherein deep learning includes neural networks. As evidence of the generic nature of the above recited additional elements the machine learning software that carries out generating a health score of the user based on interactions between the user and aspects of the software application, one or more values stored in a database record of the user, and the condition associated with the user merely digitize interactions that could occur between human actors such that they amount to the words “apply it” with a computer. Such processing thus utilizes computer components recited at a high level of generality that could otherwise occur between healthcare provider and a patient, and thus this element amounts to the words “apply it” with a computer.
The dependent claims no not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reason discussed above with respect to determining that the dependent claims do not integrate the at least abstract idea into a practical application.
Therefore, claims 43-50, 53-61, 64 and 86-157 are ineligible under 35 USC §101.

Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.

Claims 43-44, 46, 49-50, 53-55, 60-61, 64, 86-88, 92-98, 102-119, 124-128, 131-141, 143, 146-150 and 151-157 are rejected under 35 U.S.C. 103 as being unpatentable over McClure (US 2014/0278474 A1) in view of Brust (US 2017/0329933 A1).
Claim 43:
McClure discloses a computer-implemented method to treat a cardiometabolic condition of a user (See Fig. 1, P0032, P0041 planning intervention messages, P0078-P0079 communicate coaching conversations. With hypertension and diabetes as a cardiometabolic conditions, see P0084 and [P0099] if the condition is diabetes, an outcome could be a change in HbA1c level, when key measurable outcomes for interventions are based on the participant's health goals (P0071). Also, see Fig. 15B, P0100 medication management, Fig. 16. Taking Prescribed Meds.) comprising:
receiving, by one or more processors, from one or more devices associated with a user, a plurality of initial inputs and an indicator of a cardiometabolic condition of the user, wherein each initial input of the plurality of initial inputs contains a value (See measured data 110 as input containing a value, blood pressure cuff and glucose monitor in P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.);
storing, by the one or more processors, each value of the plurality of initial inputs into a database that is configured to store one or more database records of the user (Besides the store of data in P0042, see [P0052] collect information from multiple devices and publish it to a database, and data archive in P0055.); and
providing, by the one or more processors, a therapy regimen to treat the cardiometabolic condition of the user, the therapy regimen comprising one or more machine-readable computer files containing machine-executed instructions, the one or more machine-readable computer files configured to generate a plurality of graphical user interfaces (GUIs) to provide content to a software application on the one or more devices associated with the user (See [P0007] a computer readable storage device storing a computer program product including machine-readable instructions that, when executed by a computer system, carry out operations including providing, on a user interface of an electronic device, elements of conversations chosen based on an identity of a user of the electronic device, the user being associated with a health goal system that chooses interventions, [P0113] a client computer having a graphical user interface or a Web browser and challenge user interface in P0107, Fig. 20. Also, see communicating intervention messages to helping people with their health goals (P0027-P0028), related to any aspect of the individual's condition such as diabetes mentioned in P0032 and P0099.);
applying, by the one or more processors, the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample users labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome (With relative weights as the parameters when calculating a corresponding health score, see predicted likelihoods, reached outcomes and health goals in P0076. Also, see measurable parameters such as blood pressure (P0024) glucose monitor, sleep monitor (P0032) and in [P0044-P0045] One approach to model generation uses data (e.g., historic data) from participants (e.g., past participants) to train decision models 124 that then attempt to predict which interaction options (our reference to interaction options includes, for example interventions and intervention communications). With labelled data as learned historical trends from training data, see [P0076] The score is continually updated and can reflect multiple years of health risk data and trends of the individual and P0101. See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0103.).
Although McClure discloses a method and system for generating and monitoring a therapy regimen, applying machine learning from a weighed health score as mentioned above, McClure does not explicitly teach monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs. Brust teaches:
monitoring, by the one or more processors, interactions between the user and the software application (See a wearable device 360 worn by the patient 340 processed by the electronic computing device 350 in Fig. 3, [P0047-P0048] the patient interface 330 may be presented on a patient-operated electronic computing device 350 (e.g., a smartphone computing device). The patient interface 330 may be implemented through a graphical user interface 355 (e.g., software app) that displays suggestion and guidance information to encourage, instruct, or control treatment activities by the patient 340. For example, the graphical user interface 355 may present audiovisual content generated or selected from the physical therapist interface 310 which relates to physical therapy exercise activities to be performed by the patient 340, such as a series of movements 365.);
updating, by the one or more processors, the therapy regimen in accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition (See P0078 diabetes and hypertension as cardiometabolic conditions, scoring in P0092 based on the wearable device input and adaptive patient input and caregiver therapy. Also, see modify recommendations and suggested content for the therapy activities in P0045, delivery therapy content in Fig. 9A-9B, GUI mentioned in P0094-P0099 with adaptive therapy.); and
transmitting, by the one or more processors, content to present via the plurality of GUIs based on the updated therapy regimen (See P0049 virtual agent communicating adaptive to learning over the therapy content.).
Therefore, it would have been obvious to one of ordinary skill in the art of adaptive therapy using electronic devices before the effective filing date of the claimed invention to modify the method and system of McClure to include monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs as taught by Brust to closely monitor and provide feedback on the therapy activity techniques directly given to the patient as mentioned in Brust’s P0003.
Claim 54:
McClure discloses an apparatus, the apparatus to treat a cardiometabolic condition of a user (See Fig. 1, P0032, P0041 planning intervention messages, P0078-P0079 communicate coaching conversations. With hypertension and diabetes as a cardiometabolic conditions, see P0084 and [P0099] if the condition is diabetes, an outcome could be a change in HbA1c level, when key measurable outcomes for interventions are based on the participant's health goals (P0071). Also, see Fig. 15B, P0100 medication management, Fig. 16. Taking Prescribed Meds.) comprising:
a processor (See Fig. 1, P0110 where all apparatus, devices, and machines for processing data, include processors.) configured to:
receive, from one or more devices associated with a user, a plurality of initial inputs and an indicator of a cardiometabolic condition of the user, wherein each initial input of the plurality of initial inputs contains a value (See measured data 110 as input containing a value in P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.);
store each value of the plurality of initial inputs into a database that is configured to store one or more database records of the user (Besides the store of data in P0042, see [P0052] collect information from multiple devices and publish it to a database, and data archive in P0055.); and
provide a therapy regimen to treat the cardiometabolic condition of the user, the therapy regimen comprising one or more machine-readable computer files containing machine-executed instructions, the one or more machine-readable computer files configured to generate a plurality of graphical user interfaces (GUIs) to provide content to a software application on the one or more devices associated with the user See [P0007] a computer readable storage device storing a computer program product including machine-readable instructions that, when executed by a computer system, carry out operations including providing, on a user interface of an electronic device, elements of conversations chosen based on an identity of a user of the electronic device, the user being associated with a health goal system that chooses interventions, [P0113] a client computer having a graphical user interface or a Web browser and challenge user interface in P0107, Fig. 20. Also, see communicating intervention messages to helping people with their health goals (P0027-P0028), related to any aspect of the individual's condition such as diabetes mentioned in P0032 and P0099.);
apply the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample users labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome (With relative weights as the parameters when calculating a corresponding health score, see predicted likelihoods, reached outcomes and health goals in P0076. Also, see measurable parameters such as blood pressure (P0024) glucose monitor, sleep monitor (P0032) and in [P0044-P0045] One approach to model generation uses data (e.g., historic data) from participants (e.g., past participants) to train decision models 124 that then attempt to predict which interaction options (our reference to interaction options includes, for example interventions and intervention communications). With labelled data as learned historical trends from training data, see [P0076] The score is continually updated and can reflect multiple years of health risk data and trends of the individual and P0101. See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0103.).
Although McClure discloses a method and system for generating and monitoring a therapy regimen, applying machine learning from a weighed health score as mentioned above, McClure does not explicitly teach monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs. Brust teaches:
monitor interactions between the user and the software application (See a wearable device 360 worn by the patient 340 processed by the electronic computing device 350 in Fig. 3, [P0047-P0048] the patient interface 330 may be presented on a patient-operated electronic computing device 350 (e.g., a smartphone computing device). The patient interface 330 may be implemented through a graphical user interface 355 (e.g., software app) that displays suggestion and guidance information to encourage, instruct, or control treatment activities by the patient 340. For example, the graphical user interface 355 may present audiovisual content generated or selected from the physical therapist interface 310 which relates to physical therapy exercise activities to be performed by the patient 340, such as a series of movements 365.);
update the therapy regimen in accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition (See P0078 diabetes and hypertension as cardiometabolic conditions, scoring in P0092 based on the wearable device input and adaptive patient input and caregiver therapy. Also, see modify recommendations and suggested content for the therapy activities in P0045, delivery therapy content in Fig. 9A-9B, GUI mentioned in P0094-P0099 with adaptive therapy.); and
transmit content to present via the plurality of GUIs based on the updated therapy regimen (See P0049 virtual agent communicating adaptive to learning over the therapy content.).
Therefore, it would have been obvious to one of ordinary skill in the art of adaptive therapy using electronic devices before the effective filing date of the claimed invention to modify the method and system of McClure to include monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs as taught by Brust to closely monitor and provide feedback on the therapy activity techniques directly given to the patient as mentioned in Brust’s P0003.
Claim 114:
McClure discloses a computer-implemented method to treat a cardiometabolic condition of a user (See Fig. 1, P0032, P0041 planning intervention messages, P0078-P0079 communicate coaching conversations. With hypertension and diabetes as a cardiometabolic conditions, see P0084 and [P0099] if the condition is diabetes, an outcome could be a change in HbA1c level, when key measurable outcomes for interventions are based on the participant's health goals (P0071). Also, see Fig. 15B, P0100 medication management, Fig. 16. Taking Prescribed Meds.) comprising:
receiving, by one or more processors, from one or more devices associated with a user, a request to generate a therapy regimen to treat a cardiometabolic condition of a user, said request comprising a plurality of initial inputs and an indicator of the cardiometabolic condition of the user, wherein each initial input of the plurality of initial inputs contains a value (Asking questions in coaching conversation about chronic disease or lifestyle, the adjusting previous health suggestion in P0079-P00809 construe requesting to generate a therapy regimen to treat a condition. Also, see coach messaging question in P0088 and [P0103] conversations related to nutrition, eye care, foot care, and other topics that are known to relate to diabetes. See measured data 110 as input containing a value in P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.);
storing, by the one or more processors, each value of the plurality of initial inputs into a database that is configured to store one or more database records of the user (Besides the store of data in P0042, see [P0052] collect information from multiple devices and publish it to a database, and data archive in P0055.);
generating, by the one or more processors, the therapy regimen to treat the cardiometabolic condition of the user, the therapy regimen based upon data of the request, wherein the therapy regimen comprises one or more machine-readable computer files containing one or more machine executable instructions, the one or more machine-readable computer files configured to generate a plurality of graphical user interfaces (GUIs) to provide content See [P0007] a computer readable storage device storing a computer program product including machine-readable instructions that, when executed by a computer system, carry out operations including providing, on a user interface of an electronic device, elements of conversations chosen based on an identity of a user of the electronic device, the user being associated with a health goal system that chooses interventions, [P0113] a client computer having a graphical user interface or a Web browser and challenge user interface in P0107, Fig. 20. Also, see communicating intervention messages to helping people with their health goals (P0027-P0028), related to any aspect of the individual's condition such as diabetes mentioned in P0032 and P0099.);
transmitting, by the one or more processors, the therapy regimen to a software application on one or more user devices (See a wearable device 360 worn by the patient 340 processed by the electronic computing device 350 in Fig. 3, [P0047-P0048] the patient interface 330 may be presented on a patient-operated electronic computing device 350 (e.g., a smartphone computing device). The patient interface 330 may be implemented through a graphical user interface 355 (e.g., software app) that displays suggestion and guidance information to encourage, instruct, or control treatment activities by the patient 340. For example, the graphical user interface 355 may present audiovisual content generated or selected from the physical therapist interface 310 which relates to physical therapy exercise activities to be performed by the patient 340, such as a series of movements 365.); and
applying, by the one or more processors, the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample user labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome (With relative weights as the parameters when calculating a corresponding health score, see predicted likelihoods, reached outcomes and health goals in P0076. Also, see measurable parameters such as blood pressure (P0024) glucose monitor, sleep monitor (P0032) and in [P0044-P0045] One approach to model generation uses data (e.g., historic data) from participants (e.g., past participants) to train decision models 124 that then attempt to predict which interaction options (our reference to interaction options includes, for example interventions and intervention communications). With labelled data as learned historical trends from training data, see [P0076] The score is continually updated and can reflect multiple years of health risk data and trends of the individual and P0101. See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0103.).
Although McClure discloses a method and system for generating and monitoring a therapy regimen, applying machine learning from a weighed health score as mentioned above, McClure does not explicitly teach monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs. Brust teaches:
monitoring, by the one or more processors, interactions between the user and the software application (See a wearable device 360 worn by the patient 340 processed by the electronic computing device 350 in Fig. 3, [P0047-P0048] the patient interface 330 may be presented on a patient-operated electronic computing device 350 (e.g., a smartphone computing device). The patient interface 330 may be implemented through a graphical user interface 355 (e.g., software app) that displays suggestion and guidance information to encourage, instruct, or control treatment activities by the patient 340. For example, the graphical user interface 355 may present audiovisual content generated or selected from the physical therapist interface 310 which relates to physical therapy exercise activities to be performed by the patient 340, such as a series of movements 365.);
updating, by the one or more processors, the therapy regimen in accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition (See P0078 diabetes and hypertension as cardiometabolic conditions, scoring in P0092 based on the wearable device input and adaptive patient input and caregiver therapy. Also, see modify recommendations and suggested content for the therapy activities in P0045, delivery therapy content in Fig. 9A-9B, GUI mentioned in P0094-P0099 with adaptive therapy.); and
transmitting, by the one or more processors, content to present via the plurality of GUIs based on the updated therapy regimen (See P0049 virtual agent communicating adaptive to learning over the therapy content.).
Therefore, it would have been obvious to one of ordinary skill in the art of adaptive therapy using electronic devices before the effective filing date of the claimed invention to modify the method and system of McClure to include monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs as taught by Brust to closely monitor and provide feedback on the therapy activity techniques directly given to the patient as mentioned in Brust’s P0003.
Claim 136:
McClure discloses an apparatus, the apparatus to treat a cardiometabolic condition of a user (See Fig. 1, P0032, P0041 planning intervention messages, P0078-P0079 communicate coaching conversations. With hypertension and diabetes as a cardiometabolic conditions, see P0084 and [P0099] if the condition is diabetes, an outcome could be a change in HbA1c level, when key measurable outcomes for interventions are based on the participant's health goals (P0071). Also, see Fig. 15B, P0100 medication management, Fig. 16. Taking Prescribed Meds.) comprising:
a processor (See Fig. 1, P0110 where all apparatus, devices, and machines for processing data, include processors.) configured to:
receive, from one or more devices associated with a user, a request to generate a therapy regimen to treat a cardiometabolic condition of a user, said request comprising a plurality of initial inputs and an indicator of the cardiometabolic condition of the user, wherein each initial input of the plurality of initial inputs contains a value (Asking questions in coaching conversation about chronic disease or lifestyle, the adjusting previous health suggestion in P0079-P00809 construe requesting to generate a therapy regimen to treat a condition. Also, see coach messaging question in P0088 and [P0103] conversations related to nutrition, eye care, foot care, and other topics that are known to relate to diabetes. See measured data 110 as input containing a value in P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.);
store each value of the plurality of initial inputs into a database that is configured to store one or more database records of the user (Besides the store of data in P0042, see [P0052] collect information from multiple devices and publish it to a database, and data archive in P0055.);
generate the therapy regimen to treat the cardiometabolic condition of the user, the therapy regimen based upon data of the request, wherein the therapy regimen comprises one or more machine-readable computer files containing one or more machine executable instructions, the one or more machine-readable computer files configured to generate a graphical user interfaces (GUIs) to provide content (See [P0007] a computer readable storage device storing a computer program product including machine-readable instructions that, when executed by a computer system, carry out operations including providing, on a user interface of an electronic device, elements of conversations chosen based on an identity of a user of the electronic device, the user being associated with a health goal system that chooses interventions, [P0113] a client computer having a graphical user interface or a Web browser and challenge user interface in P0107, Fig. 20. Also, see communicating intervention messages to helping people with their health goals (P0027-P0028), related to any aspect of the individual's condition such as diabetes mentioned in P0032 and P0099.);
transmit the therapy regimen to a software application on one or more user devices (See a wearable device 360 worn by the patient 340 processed by the electronic computing device 350 in Fig. 3, [P0047-P0048] the patient interface 330 may be presented on a patient-operated electronic computing device 350 (e.g., a smartphone computing device). The patient interface 330 may be implemented through a graphical user interface 355 (e.g., software app) that displays suggestion and guidance information to encourage, instruct, or control treatment activities by the patient 340. For example, the graphical user interface 355 may present audiovisual content generated or selected from the physical therapist interface 310 which relates to physical therapy exercise activities to be performed by the patient 340, such as a series of movements 365.); and
apply the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample users labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome (With relative weights as the parameters when calculating a corresponding health score, see predicted likelihoods, reached outcomes and health goals in P0076. Also, see measurable parameters such as blood pressure (P0024) glucose monitor, sleep monitor (P0032) and in [P0044-P0045] One approach to model generation uses data (e.g., historic data) from participants (e.g., past participants) to train decision models 124 that then attempt to predict which interaction options (our reference to interaction options includes, for example interventions and intervention communications). With labelled data as learned historical trends from training data, see [P0076] The score is continually updated and can reflect multiple years of health risk data and trends of the individual and P0101. See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0103.).
Although McClure discloses a method and system for generating and monitoring a therapy regimen, applying machine learning from a weighed health score as mentioned above, McClure does not explicitly teach monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs. Brust teaches:
monitor interactions between the user and the software application (See a wearable device 360 worn by the patient 340 processed by the electronic computing device 350 in Fig. 3, [P0047-P0048] the patient interface 330 may be presented on a patient-operated electronic computing device 350 (e.g., a smartphone computing device). The patient interface 330 may be implemented through a graphical user interface 355 (e.g., software app) that displays suggestion and guidance information to encourage, instruct, or control treatment activities by the patient 340. For example, the graphical user interface 355 may present audiovisual content generated or selected from the physical therapist interface 310 which relates to physical therapy exercise activities to be performed by the patient 340, such as a series of movements 365.);
update the therapy regimen accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition (See P0078 diabetes and hypertension as cardiometabolic conditions, scoring in P0092 based on the wearable device input and adaptive patient input and caregiver therapy. Also, see modify recommendations and suggested content for the therapy activities in P0045, delivery therapy content in Fig. 9A-9B, GUI mentioned in P0094-P0099 with adaptive therapy.); and
transmit content to present via the plurality of GUIs based on the updated therapy regimen (See P0049 virtual agent communicating adaptive to learning over the therapy content.).
Therefore, it would have been obvious to one of ordinary skill in the art of adaptive therapy using electronic devices before the effective filing date of the claimed invention to modify the method and system of McClure to include monitoring interactions between the user and the software application, updating the therapy regimen according to a health score and transmitting content to present the updated therapy regimen via GUIs as taught by Brust to closely monitor and provide feedback on the therapy activity techniques directly given to the patient as mentioned in Brust’s P0003.
Regarding claim 44, McClure teaches wherein generating the health score of the user further comprises generating, by the one or more processors, the machine learning model associated with the cardiometabolic condition according to a statistical analysis of one or more types of data stored in a plurality of database records of the database (See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0045-P0046, where statistical analysis of historical data is used to generate a model and collection data archived in database mentioned in P0052.), and wherein the machine learning model is configured to determine the health score of the user using: the interactions between the user and the software application and one or more types of data corresponding to a set one or more values for one or more data inputs stored in database record of the user (Besides Fig. 10, 1012, Fig. 14, 1410, P0076, P0098 health outcomes scores, see triggered events and threshold analysis for scoring using machine learning mentioned in P0103. See measurable parameter (P0024) and parameters of models (P0050). See predicted likelihoods, reached outcomes, health goals and health outcome scores in P0076).).
Regarding claim 46, McClure discloses further comprising updating, by the one or more processors, the machine learning model associated with the cardiometabolic condition at predetermined time intervals (Taught in P0097, as set of metrics that can be measured in routine, short time intervals, day and week periods in P0055.).
Regarding claims 49 and 60, McClure discloses wherein the health score is further based upon an amount of interactions between the user and the software application (See P0003-P0004, where the score representing characteristics of interactions between participants and the health goal system, conversations received from a device P0008, interactive web app P0051 and P0076.).
Regarding claims 50 and 61, McClure discloses wherein receiving the plurality of initial inputs further comprises storing, by the one or more processors, each value of the plurality of initial inputs into the one or more database records of the user (See measured data 110 as input containing a value in P0032. Besides the store of data in P0042, see [P0052] collect information from multiple devices and publish it to a database, and data archive in P0055.).
Regarding claims 53 and 64, McClure discloses wherein a device of the one or more devices is selected from a group comprising: a smart home device, a wearable device, and a fitness tracker (See pedometer in P0032 and self-report trackers in P0091.).
Regarding claim 55, McClure discloses wherein the processor is further configured to generate, the machine learning model associated with the cardiometabolic condition according to a statistical analysis of one or more types of data stored in a plurality of database records of the database (See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0045-P0046, where statistical analysis of historical data is used to generate a model and collection data archived in database mentioned in P0052.), and wherein the machine learning model is configured to determine the health score condition of the user using: the of interactions between the user and the software application and one or more types of data corresponding to a set of one or more values for one or more data inputs stored in the database record of the user (Besides Fig. 10, 1012, Fig. 14, 1410, P0076, P0098 health outcomes scores, see triggered events and threshold analysis for scoring using machine learning mentioned in P0103. See measurable parameter (P0024) and parameters of models (P0050). See predicted likelihoods, reached outcomes, health goals and health outcome scores in P0076).).
Regarding claims 57 and 143, McClure discloses wherein the processor is further configured to update the machine learning model associated with the cardiometabolic condition at predetermined time intervals (Taught in P0097, as set of metrics that can be measured in routine, short time intervals, day and week periods in P0055.).
Regarding claims 86, 96, 126 and 148, McClure disclose wherein the cardiometabolic condition of the user is a diabetes health condition (See P0078-P0079 communicate coaching conversations, exemplary if the condition is diabetes, an outcome could be a change in HbA1c level in [P0099].).
Regarding claims 93, 103, 133 and 155, McClure discloses wherein there are multiple pre-stored milestone values for multiple data fields, to compare multiple different user values of different fields against multiple different pre-stored values (Taught as comparing characteristics for a set of participants and populations in P0048, using biometric sensors in P0065.).
Regarding claims 94, 104, 134 and 156, McClure discloses further comprising automatically adjusting, by the one or more processors, at least one of features or resources provided to the user based upon one or more of the updated health score and the updated threshold value (See P0098-P0090, where the health outcome score are based on HbA1c level and lifestyle factors.).
Regarding claims 95, 105, 135 and 157, McClure discloses wherein said resources comprise meeting time with at least one of one or more coaches or specialist personnel (See messaging coach in Fig. 7 and exemplary coaching conversation in P0099.).
Regarding claims 92 and 132, McClure discloses comprising comparing, by the one or more processors, one or more data fields relevant to the user’s cardiometabolic condition against pre-stored milestone parameters or data values at predetermined milestone intervals, wherein the prestored milestone data values may operate as threshold values (See threshold level of validation in P0045-P0046, where statistical analysis of historical data is used to generate a model.).
Regarding claims 102 and 154, McClure discloses wherein the processor is further configured to compare one or more data fields relevant to the user’s cardiometabolic condition against pre-stored milestone parameters or data values at predetermined milestone intervals, wherein the prestored milestone data values may operate as threshold values (See threshold level of validation in P0045-P0046, where statistical analysis of historical data is used to generate a model.).
Regarding claims 106 and 115, McClure discloses receiving, by the one or more processors, a plurality of data inputs from the one or more devices, wherein at least one data input indicates an interaction between the user and the software application, and wherein each data input contains a value (See measured data 110 as input containing a value in P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.); and updating, by the one or more processors, the health score of the user using one or more data inputs and a frequency of interactions between the user and the software application to provide an updated health score (See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0103.).
Regarding claims 107, 111, 116 and 138, McClure discloses comprising updating, by the one or more processors, the therapy regimen of the user based upon the updated health score that is updated using the one or more data inputs and the frequency of interactions (Besides frequency levels of intervention messages in P0041, see interactive indicators Abstract, P0003, P0076 where multiple scores are determined based on health goals, risks and outcomes.).
Regarding claim 108, McClure discloses wherein updating the therapy regimen of the user further comprises transmitting, by the one or more processors, the updated therapy regimen to the software application of the user (Besides frequency levels of intervention messages in P0041, see interactive indicators Abstract, P0003, P0076 where multiple scores are determined based on health goals, risks and outcomes.).
Regarding claim 117, McClure discloses wherein updating the therapy regimen of the user further comprises transmitting, by the one or more processors, the updated therapy regimen to the software application (Besides frequency levels of intervention messages in P0041, see interactive indicators Abstract, P0003, P0076 where multiple scores are determined based on health goals, risks and outcomes.).
Regarding claims 109, 113, 118 and 140, McClure discloses wherein the software application is on a mobile device (See app server in P0051 and P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.).
Regarding claims 119 and 141, McClure teaches wherein generating the health score of the user further comprises generating, by the one or more processors, the machine learning model associated with the cardiometabolic condition according to a statistical analysis of one or more types of data stored in a plurality of database records of the database (See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0045-P0046, where statistical analysis of historical data is used to generate a model and collection data archived in database mentioned in P0052.), and wherein the machine learning model is configured to determine the health score associated with the cardiometabolic condition of the user using: the interactions between the user and the software application and the one or more types of data corresponding to a set of the one or more values for the one or more data inputs stored in a database record of the user (Besides Fig. 10, 1012, Fig. 14, 1410, P0076, P0098 health outcomes scores, see triggered events and threshold analysis for scoring using machine learning mentioned in P0103. See measurable parameter (P0024) and parameters of models (P0050). See predicted likelihoods, reached outcomes, health goals and health outcome scores in P0076).).
Regarding claims 121, McClure discloses further comprising updating, by the one or more processors, the machine learning model associated with the cardiometabolic condition at predetermined time intervals (Taught in P0097, as set of metrics that can be measured in routine, short time intervals, day and week periods in P0055.).
Regarding claims 124 and 146, McClure teaches wherein the health score is further based upon an amount of interactions between the user and the software application (See P0003-P0004, where the score representing characteristics of interactions between participants and the health goal system, conversations received from a device P0008, interactive web app P0051 and P0076.).
Regarding claims 125 and 147, McClure teaches wherein receiving the plurality of initial inputs further comprises storing, by the one or more processors, each value of the plurality of initial inputs into the one or more database records of the user (See measured data 110 as input containing a value in P0032. Besides the store of data in P0042, see [P0052] collect information from multiple devices and publish it to a database, and data archive in P0055.).
Regarding claims 126 and 96, McClure discloses wherein the cardiometabolic condition of the user is a diabetes health condition (See P0078-P0079 communicate coaching conversations, exemplary if the condition is diabetes, an outcome could be a change in HbA1c level in [P0099].).
Regarding claim 129, McClure discloses wherein the predetermined number of additional database records comprises records of a predetermined number of user having completed or participated for a predetermined time in the therapy regimens for the cardiometabolic condition associated with the user (Taught as comparing characteristics for a set of participants and populations in P0048, using biometric sensors in P0065.).
Regarding claims 110 and 137, McClure discloses receive a plurality of data inputs from the one or more devices, wherein at least one data input indicates an interaction between the user and the software application, and wherein each data input contains a value (See measured data 110 as input containing a value in P0032, where data is collected from electronic devices and entered into a mobile device 114 shown in Fig. 1.); update the health score of the user using one or more data inputs and the interactions between the user and the software application to provide an updated health score (See [P0003] calculating scores representing characteristics of interactions between participants and the health goal system, and based on the scores and the data determined by machine learning. Also, see P0103.).
Regarding claim 148, McClure discloses wherein the condition of the user is a diabetes health condition (See P0078-P0079 communicate coaching conversations, exemplary if the condition is diabetes, an outcome could be a change in HbA1c level in [P0099].).
Regarding claim 151, McClure discloses, wherein the predetermined number of additional database records comprises records of a predetermined number of user having completed or participated for a predetermined time in the therapy regimens for the cardiometabolic condition associated with the user (See measurable parameter (P0024) and parameters of models (P0050). With relative weights as the parameters when calculating a corresponding health score, see predicted likelihoods, reached outcomes and health goals in P0076. Also, see measurable parameters such as blood pressure (P0024) glucose monitor, sleep monitor (P0032) and in [P0044-P0045] One approach to model generation uses data (e.g., historic data) from participants (e.g., past participants) to train decision models 124 that then attempt to predict which interaction options (our reference to interaction options includes, for example interventions and intervention communications).).
Regarding claims 87, 97, 127 and 149, McClure disclose wherein the machine learning model is trained with and uses data fields relevant to monitoring diabetes (See P0078-P0079 communicate coaching conversations, exemplary if the condition is diabetes, an outcome could be a change in HbA1c level in [P0099].).
Regarding claims 88, 98, 128 and 150, McClure disclose wherein the data fields are selected from a group consisting of blood glucose, cholesterol, blood pressure, weight, and number of interactions with one or more of the one or more devices and a coach (See Fig. 7 coaching and tips in P0071 weight, blood pressure and blood glucose in P0094.).
Claims 45, 56, 89-90, 99-100, 120, 129-130 and 142 are rejected under 35 U.S.C. 103 as being unpatentable over McClure (US 2014/0278474 A1) in view of Brust (US 2017/0329933 A1) further in view of Abbas (WO 2017/106770 A1).
Regarding claims 45, 56 and 142, although McClure and Brust teach the health score model associated with the condition and using the machine learning software as mentioned above, McClure and Brust do not explicitly teach retraining the health score model associated with the condition in response to the database storing a predetermined number of additional database records. Abbas teaches:
wherein the processor is further configured to retrain, by the machine learning software within the processor, the health score model associated with the cardiometabolic condition in response to the database storing a predetermined number of additional database records (See [P0076-P0078] The data processing module may extract training data from a database or a user, apply a transformation to standardize the training data and Fig. 2, P0198-P0200, where exemplary therapy module scores result from sets of updated therapy assessments.).
Therefore, it would have been obvious to one of ordinary skill in the art of cognitive disorders before the effective filing date of the claimed invention to modify the method and system of McClure and Brust to include retraining the health score model associated with the condition in response to the database storing a predetermined number of additional database records as taught by Abbas to reduce the required time and resources for administering a method for identifying and treating attributes of cognitive function, such as behavioral, neurological or mental health disorders, and improve the accuracy and consistency of the identification outcomes of subjects as mentioned in Abbas’ P0005.
Regarding claim 89, McClure discloses wherein the predetermined number of additional database records comprises records of a predetermined number of customers having completed or participated for a predetermined time in the therapy regimens for the cardiometabolic condition associated with the user (Taught as comparing characteristics for a set of participants and populations in P0048, using biometric sensors in P0065.).
Regarding claims 90, 100, 130 and 152, McClure disclose wherein the cardiometabolic condition of the user is type II diabetes (See P0099 where having HbA1c outcomes construe having type II diabetes.).
Regarding claim 99, McClure discloses, wherein the predetermined number of additional database records comprises records of a predetermined number of customers having completed or participated for a predetermined time in the therapy regimens for the cardiometabolic condition associated with the user (See measurable parameter (P0024) and parameters of models (P0050). With relative weights as the parameters when calculating a corresponding health score, see predicted likelihoods, reached outcomes and health goals in P0076. Also, see measurable parameters such as blood pressure (P0024) glucose monitor, sleep monitor (P0032) and in [P0044-P0045] One approach to model generation uses data (e.g., historic data) from participants (e.g., past participants) to train decision models 124 that then attempt to predict which interaction options (our reference to interaction options includes, for example interventions and intervention communications).).
Regarding claim 120, although McClure and Brust teach the health score model associated with the condition and using the machine learning software as mentioned above, McClure and Brust do not explicitly teach retraining the health score model associated with the condition in response to the database storing a predetermined number of additional database records. Abbas teaches further comprising retraining, by the machine learning software within the computer, the health score model associated with the cardiometabolic condition in response to the database storing a predetermined number of additional database records (See [P0076-P0078] The data processing module may extract training data from a database or a user, apply a transformation to standardize the training data and Fig. 2, P0198-P0200, where exemplary therapy module scores result from sets of updated therapy assessments.).
Therefore, it would have been obvious to one of ordinary skill in the art of cognitive disorders before the effective filing date of the claimed invention to modify the method and system of McClure and Brust to include retraining the health score model associated with the condition in response to the database storing a predetermined number of additional database records as taught by Abbas to reduce the required time and resources for administering a method for identifying and treating attributes of cognitive function, such as behavioral, neurological or mental health disorders, and improve the accuracy and consistency of the identification outcomes of subjects as mentioned in Abbas’ P0005.
Regarding claim 130, McClure disclose wherein the cardiometabolic condition of the user is type II diabetes (See P0099 where having HbA1c outcomes construe having type II diabetes.).
Claims 47-48, 58-59, 122-123 and 144-145 are rejected under 35 U.S.C. 103 as being unpatentable over McClure (US 2014/0278474 A1) in view of Brust (US 2017/0329933 A1) further in view of Kidd (US 2017/0228520 A1).
Claims 47 and 122:
Kidd teaches: selecting, by the computer, a chatbot identifier for a corresponding chatbot for the software application to implement according to the therapy regimen (See Fig. 2, P0024-P0025, P0038 selected conversation components, animation components in achieving the goals and word choices selected by patient.); and updating, by the computer, a chatbot queue of the user to include the chatbot identifier (See updated interaction plan in P0034, P0037, when the interaction plan includes a medication regimen in P0059 with a patient-robot relationship in P0063, P0067.).
Therefore, it would have been obvious to one of ordinary skill in the art of patient engagement management before the filing date of the invention to modify the method, software and system of McClure and Brust to have selecting a chatbot identifier for a corresponding chatbot and updating a chatbot queue of the user to include the chatbot identifier, as taught by Kidd, to provide new and useful patient engagement in the healthcare field (See Kidd’s P0002, P0004).
Claims 48 and 123:
Kidd teaches: further comprising transmitting, by the computer, to the software application of the user a next chatbot identifier in the chatbot queue, wherein the chatbot queue of the user contains one or more chatbot identifiers corresponding respectively to one or more chatbots for the software application to implement (See Fig. 8, in [P0071] scheduling data requests for each companion robot in P0034 and video call request in P0072.).
Therefore, it would have been obvious to one of ordinary skill in the art of patient engagement management before the filing date of the invention to modify the method, software and system of McClure and Brust to have the chatbot queue of the user contains one or more chatbot identifiers, as taught by Kidd, to provide new and useful patient engagement in the healthcare field (See Kidd’s P0002, P0004).
Claims 58 and 144:
Kidd teaches: select a chatbot identifier for a corresponding chatbot for the software application to implement according to the therapy regimen (See Fig. 2, P0024-P0025, P0038 selected conversation components, animation components in achieving the goals and word choices selected by patient.); and update a chatbot queue of the customer to include the chatbot identifier (See updated interaction plan in P0034, P0037, when the interaction plan includes a medication regimen in P0059 with a patient-robot relationship in P0063, P0067.).
Therefore, it would have been obvious to one of ordinary skill in the art of patient engagement management before the filing date of the invention to modify the method, software and system of McClure and Brust to have selecting a chatbot identifier for a corresponding chatbot and updating a chatbot queue of the user to include the chatbot identifier, as taught by Kidd, to provide new and useful patient engagement in the healthcare field (See Kidd’s P0002, P0004).
Claims 59 and 145:
Kidd teaches: wherein the processor is further configured to transmit to the software application of the user a next chatbot identifier in the chatbot queue, wherein the chatbot queue of the user contains one or more chatbot identifiers corresponding respectively to one or more chatbots for the software application to implement (See Fig. 8, in [P0071] scheduling data requests for each companion robot in P0034 and video call request in P0072.).
Therefore, it would have been obvious to one of ordinary skill in the art of patient engagement management before the filing date of the invention to modify the method, software and system of McClure and Brust to have the chatbot queue of the user contains one or more chatbot identifiers, as taught by Kidd, to provide new and useful patient engagement in the healthcare field (See Kidd’s P0002, P0004).
Claims 91, 101, 131 and 153 are rejected under 35 U.S.C. 103 as being unpatentable over McClure (US 2014/0278474 A1) in view of Brust (US 2017/0329933 A1) further in view of Nevo (US 2015/0313529 A1).
Regarding claims 91, 101 and 131 and 153, Nevo teaches wherein the machine learning software executes machine learning algorithms and processes selected from the group consisting of generalized linear models, random forests, support vector machines, unsupervised and/or supervised clustering, and deep learning, wherein deep learning includes neural networks (See clustering, neural networks and support vector machine in P0027-P0028, P0067.).
Therefore, it would have been obvious to one of ordinary skill in the art of behavior monitoring before the effective filing date of the claimed invention to modify the method and system of McClure and Brust to include machine learning algorithms and selected processes as taught by Nevo to facilitate preventive medicine, where the type and extent of a treatment can be adjusted based on the monitored behavior as mentioned in Nevo’s P0044.

Response to Arguments
Regarding the double patent rejection, Applicant entered terminal disclaimer filed 10/29/2025 persuasive to withdraw the double patent rejection.
Applicant argues that amended claim 43 recites limitations that the human mind is not equipped to perform and does not recite any mathematical relationships, formulas, or calculations. see pgs. 20-21 of Remarks – Examiner disagrees.
Recited limitations, “providing, by the one or more processors, a therapy regimen to treat the cardiometabolic condition of the user, the therapy regimen comprising one or more machine-readable computer files containing machine-executed instructions, the one or more machine-readable computer files configured to generate a plurality of graphical user interfaces (GUIs) to provide content to a software application on the one or more devices associated with the user”, "monitoring, by the one or more processors, interactions between the user and the software application," "applying, by the one or more processors, the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user, wherein the machine learning model is trained using sample interactions by sample users labeled with a sample health score corresponding with a condition of sample users, wherein a first weight of the plurality of weights is set based on the condition of sample users and a second weight of the plurality of weights is set based on sample inputs or sample interactions, wherein the first weight and the second weight cause the model to generate the health score corresponding to at least one outcome”, "updating, by the one or more processors, the therapy regimen in accordance with the health score corresponding to at least one outcome, wherein the therapy regimen is updated to cause an improvement in a likelihood of success corresponding to the cardiometabolic condition," and "transmitting, by the one or more processors, content to present via the plurality of GUIs based on the updated therapy regimen”, are equivalent to: 1) a user with a cardiometabolic condition using a medical app to achieve therapeutic results, 2) monitoring the user’s usage of the medical app, 3) generating health scores based on labels, corresponding, interactive sample inputs and weighed outcomes, 4) updating the user’s therapy regimen based on the generated health score, and 5) transmitting updated user’s therapy regimen, which are interactive tasks of healthcare providers and patients, using mathematics and making observations in the human mind.
Applicant argues that claim 43 is directed to specific technical features, liken to Subject Matter Eligibility Example 39 see pgs. 21-22 of Remarks – Examiner disagrees.
Unlike Example 39, the instant case recites mathematical relationships, mental concepts and a method of organized human activity mentioned above in Step 2A – Prong 1, and the neural network has no training sets by applying mathematical transformations claimed in the instant case. In fact, it is unclear what interactions between the user and the software application is being monitored, weighed or labelled in order to generate a health score. For example, is there a frequency usage being monitored of how often the software application is activated or various severity types of interactions between the user and the software application? Also, sharing a specifically identified treatment regimen or transmitting an updated one is not using technology to do. Technology usage is neither described nor claimed when applying the interactions to a machine learning model comprising a plurality of weights to generate a health score of the user. Therefore, is a part of the abstract idea and can’t be used to integrate the abstract idea into a practical application.
Regarding the 103 rejection, Applicant's arguments filed 10/29/2025 have been fully considered but they are not persuasive. The amended claims have been considered and do not help to overcome the prior art rejection.

Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERESA S WILLIAMS whose telephone number is [phone]. The examiner can normally be reached Mon-Fri, 8:30 am -6:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached at [phone]. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.

/T.S.W./Examiner, Art Unit 3687 02/04/2026

/ALAAELDIN M. ELSHAER/Primary Examiner, Art Unit 3687

Prosecution Timeline

• Jun 06, 2022: Application Filed
• Sep 06, 2024: Non-Final Rejection — §101, §103
• Oct 23, 2024: Interview Requested
• Nov 05, 2024: Applicant Interview (Telephonic)
• Nov 05, 2024: Examiner Interview Summary
• Feb 12, 2025: Response Filed
• May 24, 2025: Final Rejection — §101, §103
• Jul 03, 2025: Interview Requested
• Jul 10, 2025: Applicant Interview (Telephonic)
• Jul 14, 2025: Examiner Interview Summary
• Jul 30, 2025: Response after Non-Final Action
• Sep 18, 2025: Interview Requested
• Sep 19, 2025: Interview Requested
• Sep 29, 2025: Applicant Interview (Telephonic)
• Sep 30, 2025: Examiner Interview Summary
• Oct 29, 2025: Request for Continued Examination
• Nov 07, 2025: Response after Non-Final Action
• Feb 04, 2026: Non-Final Rejection — §101, §103 (current)