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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-19 in the reply filed on January 19, 2026 is acknowledged.
Status of Claims
This office action for the 18/963451 application is in response to the communications filed January 19, 2026.
Claims 1-20 were initially submitted November 27, 2024.
Claims 1-20 were subject to restriction requirement January 15, 2026.
Claims 1-19 were elected without traverse January 19, 2026.
Claim 20 was withdrawn from consideration January 19, 2026.
Claims 1-19 are currently pending and considered below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claim 10,
This claim recites the limitation of “wherein the local assistant hub”. This limitation lacks antecedent basis and is therefore considered to be indefinite. For the purposes of examination, the Examiner will interpret this limitation as “further comprising a local assistant hub, wherein the local assistant hub”.
As per claims 11-16,
These claims are dependent from a base claim that was determined to be indefinite. Accordingly, these claims are also indefinite.
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-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
As per claim 1,
Step 1: The claim recites subject matter within a statutory category as a machine.
Step 2A is a two-prong inquiry, in which Prong 1 determines whether a claim recites a judicial exception. Prong 2 determines if the additional limitations of the claim integrates the recited judicial exception into a practical application. If the additional elements of the claim fail to integrate the judicial exception into a practical application, claim is directed to the recited judicial exception, see MPEP 2106.04(II)(A).
Step 2A Prong 1: The claim contains subject matter that recites an abstract idea, with the steps of generating a continuous and adaptive patient risk profile through multi-source data integration, retrieve and integrate patient data from structured data, semi-structured data, and unstructured data, wherein each category of patient data is subjected to a source-specific normalization and validation process prior to integration; generate a patient risk profile by executing a real-time risk scoring algorithm, wherein the patient risk profile is derived from the aggregated and pre-processed patient data; apply a dynamic weighting to each type of patient data, said weighting being determined by predefined contextual rules, wherein said contextual rules incorporate reliability factor of the data source and relevance of the data to the patient's current health context in determining the weighting; adjust the applied weighting in real-time based on detected deviations from baseline values within the patient data; and monitor and recalibrate the patient risk profile continuously at predefined time intervals, wherein the frequency and timing of recalibration are dynamically adjusted based on a duration and magnitude of deviations in the patient data from baseline values. These steps, as drafted, under the broadest reasonable interpretation recite:
certain methods of organizing human activity (e.g., fundamental economic principles or practices including: hedging; insurance; mitigating risk; etc., commercial or legal interactions including: agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations; etc., managing personal behavior or relationships or interactions between people including: social activities; teaching; following rules or instructions; etc.) but for recitation of generic computer components. That is, other than reciting steps as performed by the generic computer components, nothing in the claim element precludes the step from being directed to certain methods of organizing human activity. The identified abstract idea, law of nature, or natural phenomenon identified above, in the context of this claim, encompasses a certain method of organizing human activity, namely managing personal behavior or relationships or interactions between people. This is because each of the limitations of the abstract idea are able to be performed by a human person in the course of their personal behavior. If a claim limitation, under its broadest reasonable interpretation, covers at least the recited methods of organizing human activity above, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. See MPEP 2106.04(a).
Step 2A Prong 2: The claim does not recite additional elements that integrate the judicial exception into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements amount to no more than limitations which:
amount to mere instructions to apply an exception, see MPEP 2106.05(f), such as:
“A computer-implemented system for” and “the system comprising: a processor; and a memory operatively connected to the processor, the memory storing instructions that, when executed by the processor, cause the system to:” which corresponds to merely using a computer as a tool to perform an abstract idea. Paragraph [00163] of the as-filed specification describes that the hardware that implements the steps of the abstract idea are at a level of a generic computer. Implementing an abstract idea on a generic computer, does not integrate the abstract idea into a practical application in Step 2A Prong Two or add significantly more in Step 2B, similar to how the recitation of the computer in the claim in Alice amounted to mere instructions to apply the abstract idea of intermediated settlement on a generic computer.
add insignificant extra-solution activity to the abstract idea, see MPEP 2106.05(g), such as:
“from Electronic Health Records (EHRs)”, “from monitoring devices” and “from external sources” which corresponds to mere data gathering and/or output.
Accordingly, this claim is directed to an abstract idea.
Step 2B: The claim does not recite additional elements that amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and/or generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, identified as insignificant extra-solution activity to the abstract idea, amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields such as:
computer functions that have been identified by the courts as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity, see MPEP 2106.05(d)(II), such as:
“from Electronic Health Records (EHRs)”, “from monitoring devices” and “from external sources” which corresponds to receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 2,
Claim 2 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 2 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the source-specific normalization and validation process for unstructured and semi-structured data incorporates … environmental, social, and behavioral data, to perform adaptive validation of data based on contextual relevance to the patient's current health status,” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“a machine learning model trained specifically on diverse data patterns, including” and “the model executed by a hardware-based AI processing unit” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 3,
Claim 3 depends from claim 2 and inherits all the limitations of the claim from which it depends. Claim 3 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the source-specific normalization and validation process for integrating the patient data from the unstructured sources further comprises: a source-specific pre-processing module configured to retrieve and validate Social Determinants of Health (SDoH) data …and social media platforms…, wherein … normalizes the unstructured data comprising the SDoH by converting the unstructured data into structured formats compatible with the real-time risk scoring algorithm” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“using a machine-learning-based natural language processing (NLP) engine” and “using a machine-learning-based natural language processing (NLP) engine” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“from the external databases” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 4,
Claim 4 depends from claim 3 and inherits all the limitations of the claim from which it depends. Claim 4 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“assigns a reliability factor to the unstructured data based on an accuracy and timeliness of the retrieved SDoH data, the reliability factor being dynamically adjusted based on real-time evaluations of data integrity and relevance to the patient's current health context.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“wherein the machine-learning-based NLP engine” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 5,
Claim 5 depends from claim 4 and inherits all the limitations of the claim from which it depends. Claim 5 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“assign the reliability factor to the unstructured data by: parsing and extracting key entities from the unstructured data using named entity recognition (NER) and; …evaluate the accuracy of the extracted data by comparing it against known, validated sources; determining the timeliness of the unstructured data by analyzing timestamps and comparing it to current patient health events; and calculating the reliability factor based on a weighted combination of accuracy and timeliness, the reliability factor being used to adjust the weighting of the unstructured data when calculating the patient's risk profile.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“wherein the machine-learning-based NLP engine is further configured to”, “other NLP techniques” and “applying a machine learning model trained on labeled datasets to” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 6,
Claim 6 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 6 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“comprising a real-time data monitoring … to continuously track and collect the patient data…, the real-time data monitoring …dynamically adjust the patient's risk profile in response to the detected deviations in the patient data from the baseline values, …for generating a continuous comprehensive risk profile.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“module configured”, “module being integrated with the processor and using a hardware-based processing unit to” and “wherein the recalibration occurs without human intervention” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“from one or more of the monitoring devices, the external sources, and the EHRs” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 7,
Claim 7 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 7 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“comprising a predictive health event detection…, wherein the predictive health event detection …continuously analyze patient data trends and generate an alert when the risk profile predicts an upcoming adverse health event, the predictive health event detection …to detect early warning signs of critical health deviations.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“engine implemented on the processor”, “engine is configured to” and “engine using one or more machine learning model trained on historical patient data” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 8,
Claim 8 depends from claim 7 and inherits all the limitations of the claim from which it depends. Claim 8 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“generate one or more hypothetical patient risk profiles by simulating future health scenarios through predictive modeling, the predictive modeling based on the patient data trends, historical deviations, and stochastic analysis of evolving health patterns across the structured data, the semi-structured data, and the unstructured data.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“comprising a generative AI engine operatively connected to the processor, wherein the generative AI engine is configured to” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 9,
Claim 9 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 9 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the patient data retrieved …comprises …the structured data, semi-structured data, and the unstructured data of various types,…: patient health data…; Social Determinants of Health (SDoH) data…; wearable devices data monitoring patient health metrics; patient-reported information…; social media data analyzed for behavioral and lifestyle insights; and hereditary health data…, …normalize, validate, and integrate the patient data for real-time risk profile generation.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“by the system”, “one or more computer-executable files containing” and “the computer-executable files including one or more of” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“from the Electronic Health Records (EHRs)”, “from the external databases”, “entered through a user interface”, “retrieved from family health records” and “wherein each computer-executable file is retrieved by a secure data retrieval device and processed by the processor to” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 10,
Claim 10 depends from claim 1 and inherits all the limitations of the claim from which it depends. Claim 10 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“configured to enable integration of the Electronic Health Records (EHRs), the monitoring devices, and the external sources using one or more communication standards without requiring a hardware upgrade.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“further comprising a local assistant hub, wherein the local assistant hub comprises a modular hardware architecture that includes one or more interchangeable communication modules for supporting multiple wireless protocols, including one or more of Wi-Fi, Bluetooth, ZigBee, and Thread” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 11,
Claim 11 depends from claim 10 and inherits all the limitations of the claim from which it depends. Claim 11 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the local assistant hub includes a data encryption module for ensuring secure local storage and transmission of the patient data, wherein the encryption module is configured to operate without requiring continuous connection to an external server, ensuring patient data privacy.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 12,
Claim 12 depends from claim 11 and inherits all the limitations of the claim from which it depends. Claim 12 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“performing … data analytics and real-time risk calculations” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“wherein the local assistant hub further comprises a local processing unit for”, “on-device” and “thereby reducing latency and minimizing reliance on cloud-based processing for continuous monitoring of the risk.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 13,
Claim 13 depends from claim 12 and inherits all the limitations of the claim from which it depends. Claim 13 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the local assistant hub is configured to support data integration from the monitoring devices, wherein the monitoring devices comprises one or more of a heart rate monitor, a continuous glucose monitor, a sleep tracking device,” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
“wherein each of the monitoring devices is configured to communicate with the local assistant hub using a device-specific protocol and transmit the patient data in real-time.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 14,
Claim 14 depends from claim 13 and inherits all the limitations of the claim from which it depends. Claim 14 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the semi structured data comprises a patient-generated information, …receiving the patient-generated information via one or more through voice, touch, or text input, allowing a user to manually input computer executable details into the system for integration into the patient risk profile.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“further wherein the local assistant hub includes an adaptive interface for” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 15,
Claim 15 depends from claim 14 and inherits all the limitations of the claim from which it depends. Claim 15 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“interpret the patient-generated information, including voice commands, and translate these into actionable data points that are integrated into the patient risk profile.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“wherein the local assistant hub is equipped with natural language processing (NLP) capabilities to” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 16,
Claim 16 depends from claim 10 and inherits all the limitations of the claim from which it depends. Claim 16 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“wherein the local assistant hub includes a housing containing a display interface for providing real-time feedback on the patient risk profile, wherein the interface displays aggregated patient data including the structured data from the Electronic Health Records (EHRs), the semi-structured data from the monitoring devices, and the unstructured data from the external sources in a consolidated view for interpretation by a user.” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to mere data gathering and/or output and receiving or transmitting data over a network.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 17,
Claim 17 is substantially similar to claim 1. Accordingly, claim 17 is rejected for the same reasons as claim 1.
As per claim 18,
Claim 18 depends from claim 17 and inherits all the limitations of the claim from which it depends. Claim 18 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“analyzing patient data trends continuously using a predictive health event detection…, wherein …detect early warning signs of critical health deviations; generating an alert when the predictive health event detection …determines, based on the patient risk profile, that an adverse health event is likely to occur; and adjusting the patient risk profile in real time in response to the alert, said adjustment being performed by recalculating the patient's risk profile based on the detected trends and predicted health event.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“engine”, “the engine uses at least one machine learning model trained on historical patient data to” and “engine” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
As per claim 19,
Claim 19 depends from claim 17 and inherits all the limitations of the claim from which it depends. Claim 19 merely further defines the abstract idea and/or introduces additional elements that are insufficient to provide a practical application or something significantly more:
“assigning a reliability factor to the unstructured data retrieved from Social Determinants of Health (SDoH) data sources…, wherein the reliability factor is determined based on the accuracy and timeliness of the retrieved data; dynamically adjusting the reliability factor in real time based on one or more predefined parameters; and using the dynamically adjusted reliability factor to modify the weighting applied to the unstructured data when calculating the patient risk profile.” further describes the abstract idea. This claim limitation is still directed to “Certain Methods of Organizing Human Activity” and therefore continues to recite an abstract idea.
“using a machine-learning-based Natural Language Processing (NLP) engine” further defines an additional element that was insufficient to provide a practical application and/or significantly more. The claim with this further defining limitation still corresponds to merely using a computer as a tool to perform an abstract idea.
Looking at the limitations of the claim as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely recite an abstract idea and/or provide conventional computer implementation which does not impose a meaningful limit to integrate the abstract idea into a practical application and/or amount to no more than limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (US 2023/0307115; herein referred to as Kumar) in view of Sayiner et al. (US 2024/0274256; herein referred to as Sayiner).
As per claim 1,
Kumar teaches a computer-implemented system for generating a continuous and adaptive patient risk profile through multi-source data integration, the system comprising: a processor; and a memory operatively connected to the processor, the memory storing instructions that, when executed by the processor, cause the system to: retrieve and integrate patient data from structured data from Electronic Health Records (EHRs), semi-structured data, and unstructured data from external sources, wherein each category of patient data is subjected to a source-specific normalization and validation process prior to integration:
(Paragraphs [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form).)
Kumar further teaches generate a patient risk profile by executing a real-time risk scoring algorithm, wherein the patient risk profile is derived from the aggregated and pre-processed patient data:
(Paragraphs [0035]-[0042] of Kumar. The teaching describes that historical data 105 may be collectively stored in a single data structure. For example, the diagnoses 110, medications 115, clinical assessments 120, demographics 125, and natural language notes 130 may each be represented in a user profile (with indications of any changes over time), or as a sequence of structures (e.g., a set of profiles or forms, each corresponding to a particular point or window in time and containing attributes for that time). The machine learning system 135 may receive a broader set of data (e.g., all diagnoses of the residents). The machine learning system 130 may then select which subset of the data to consider (e.g., using feature selection techniques, as discussed above, or based on the defined set of features to be used), or may assign weights to each feature (e.g., using machine learning) to generate accurate depression risk scores.)
Kumar further teaches apply a dynamic weighting to each type of patient data:
(Paragraphs [0036] and [0105] of Kumar. The teaching describes that the diagnoses 110 generally correspond to a set of one or more specified diagnoses or disorders. In such an embodiment, the historical data 105 can indicate, for each specified disorder or diagnosis, whether the corresponding user has been diagnosed with the specified disorder (at the relevant time). In some embodiments, the diagnoses 110 are curated or selected based on their impact on potential depression. For example, in one aspect, a user (e.g., a clinician) may manually specify disorders that have a high impact on future depression. In some embodiments, some or all of the diagnoses may be inferred or learned (e.g., using one or more feature selection techniques). For example, one or more machine learning models or feature selection algorithms may be used to identify specific disorders (or to determine dynamic weights for each disorder) based on their impact on the risk of depression. The machine learning system processes the identified/extracted attributes using a trained machine learning model. As discussed above, the machine learning model may generally specify a set of parameters (e.g., weights) for input features and/or intermediate features (within internal portions of the model) learned during training. In some embodiments, as discussed above, the model may specify weights for individual features, for groups of features, or for both individual features and groups of features. For example, a “diagnosis” category may be assigned a first weight. To generate a score for the diagnosis category, the individual diagnoses specified within may each be associated with respective weights. That is, a diagnosis of one disorder may have a higher weight than a second disorder.)
Kumar further teaches adjust the applied weighting in real-time based on detected deviations from baseline values within the patient data; and monitor and recalibrate the patient risk profile continuously at predefined time intervals, wherein the frequency and timing of recalibration are dynamically adjusted based on a duration and magnitude of deviations in the patient data from baseline values:
(Paragraphs [0027], [0030] and [0059] of Kumar. The teaching describes that the machine learning model (also referred to in some aspects as a risk model or a depression model) can be trained and used as an assessment tool for clinicians (e.g., nurses, caregivers, doctors, and the like) to assist in identifying users at risk of depression (e.g., patients, residents of a long-term care facility, and the like), thereby improving care, and preventing potentially significant negative outcomes. In some embodiments, by monitoring for changes in the conditions for each user, the system is able to identify those in need of additional care, and can assist with reallocating resources and driving targeted interventions to help mitigate, prevent, or reduce the effect of the risk or depression. In some embodiments, the machine learning model enables real-time insights, including alerts that notify the clinician or caretaker when there has been a change in condition with any user (e.g., within the past 24 hours) that affects potential depression, and provides the clinician with an actionable assessment and intervention details. These features and weights can then be used to automatically and efficiently process new user data in order to identify potential concerns for depression. In some aspects, the model may be trained during a training phase, and then be deployed as a static model that, once deployed, remains fixed. In other embodiments, the model may be refined or updated (either periodically or upon specified criteria). That is, during use in detecting and intervening in potential depressions, the model may be refined based on feedback from users, caregivers, and the like. For example, if a clinician indicates that a user has depression (regardless of whether the model predicted the diagnosis), the model may be refined based on this indication. Similarly, if a clinician indicates that the user does not have depression, the model may be refined to reflect this new data. For example, when a new resident enters a residential care facility, the machine learning system 135 may use their current attributes to generate an initial risk score. As another example, whenever a resident's attributes change (e.g., due to a newly-received diagnosis and/or a removed diagnosis), the machine learning system 135 may automatically detect the change and generate an updated risk score 235.)
Kumar does not explicitly teach semi-structured data coming from a monitoring device or said weighting being determined by predefined contextual rules, wherein said contextual rules incorporate reliability factor of the data source and relevance of the data to the patient's current health context in determining the weighting.
However, Sayiner teaches the collection of monitoring device data:
(Paragraph [0094] of Sayiner. The teaching describes that the passive capture module 322 may include data interfaces specific to data collection from other devices. This may include additional passive collection of patient metrics through hardware such as Fitness trackers (activity metrics, such as steps walked, elevation, heart rate). Pulse Oximeters (PO2, respiratory rate, Oxygen saturation), and night time monitoring (respiratory rate, awakeness/night time symptoms through devices such as fitness trackers or smart watches))
Sayiner further teaches determining patient data context based on context rules wherein said contextual rules incorporate reliability factor of the data source and relevance of the data to the patient's current health context:
(Paragraphs [0012] and [0017] of Sayiner. The teaching describes a method of determining a recommendation to change a treatment regimen of a respiratory ailment. The treatment regimen includes a plurality of steps. Use data of a respiration medicament device to deliver controller or rescue respiration medicament to the patient is collected via a communication interface. The use data is transmitted to a storage device. The use data is stored in the storage device, which is accessible to a data analysis engine. Based on the collected use data and patient context data, a patient value associated with the treatment regimen is determined by the data analysis engine. A comparison of the patient value is made to a threshold level. A recommendation to change the step of the treatment regimen is made based on the comparison to the threshold level. A notification of the recommendation of the change of the step of the treatment regimen is provided. Contextual data from each of the population of patients is collected. Outcomes from the population of patients for the treatment regimen are collected. Initial recommendation thresholds for each of the steps of the multiple step treatment regimen are determined. The initial recommendation thresholds are adjusted based on the collected use data, contextual data, and outcomes until a predetermined level of confidence is reached.)
It would have been obvious to one of ordinary skill in the art before the time of filing to add to the weighting rules of Kumar, the contextual rules of Sayiner. Paragraph [0082] of Sayiner teaches that the disclosed methods of data analysis lead to improved clinical outcomes because of the leveraged data analysis engine. One of ordinary skill in the art in possession of Kumar would have looked to Sayiner to gain this advantage. One of ordinary skill in the art would have added to Kumar, the teaching of Sayiner based on this incentive without yielding unexpected results.
As per claim 2,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 1.
Kumar further teaches wherein the source-specific normalization and validation process for unstructured and semi-structured data incorporates a machine learning model trained specifically on diverse data patterns, including environmental, social, and behavioral data, to perform adaptive validation of data based on contextual relevance to the patient's current health status, the model executed by a hardware-based AI processing unit:
(Paragraph [0117] of Kumar. The teaching describes that the machine learning system extracts one or more clinical assessments for the user. As discussed above, the clinical assessments can generally correspond to assessments or evaluations of the user's functional state (e.g., prepared by a clinician). For example, the extracting the assessments may include determining whether the user has recently been assessed for weight loss, weight gain, pain, increased or decreased food intake, isolation (either social, such as due to limited family, or physical, such as due to illness), one or more mood or behavioral issues, and the like. In embodiments, the particular assessments that are extracted may be determined based on the features used by the machine learning model, which may be defined manually and/or using machine learning or feature selection techniques. In some embodiments, in addition to evaluating which assessments are present, the machine learning system can also consider the recency of the assessments. For example, in addition to or instead of simply determining whether the user has been assessed with weight loss, the machine learning system may determine how recently the weight loss occurred, and use this recency as input to the model. For example, more recent assessments may be treated with increased weight.)
As per claim 3,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 2.
The combined teaching of Kumar and Sayiner further teaches wherein the source-specific normalization and validation process for integrating the patient data from the unstructured sources further comprises: a source-specific pre-processing module configured to retrieve and validate Social Determinants of Health (SDoH) data from the external databases and social media platforms using a machine-learning-based natural language processing (NLP) engine, wherein the machine-learning-based NLP engine normalizes the unstructured data comprising the SDoH by converting the unstructured data into structured formats compatible with the real-time risk scoring algorithm:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0102] and [0116] of Sayiner. The teaching describes that the data capture module 322 may include an evaluation of social determinants of health (SDoH) summary. According to the World Health Organization, SDoH are the conditions in which people are born, grow, live, work and age. These circumstances are shaped by the distribution of money, power, and resources at global, national, and local levels. The data may include social media account linking and assessment of usage of the media account, as well as the depth and breadth of the social network.)
As per claim 4,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 3.
The combined teaching of Kumar and Sayiner further teaches wherein the machine-learning-based NLP engine assigns a reliability factor to the unstructured data based on an accuracy and timeliness of the retrieved SDoH data, the reliability factor being dynamically adjusted based on real-time evaluations of data integrity and relevance to the patient's current health context:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0102] and [0116] of Sayiner. The teaching describes that the data capture module 322 may include an evaluation of social determinants of health (SDoH) summary. According to the World Health Organization, SDoH are the conditions in which people are born, grow, live, work and age. These circumstances are shaped by the distribution of money, power, and resources at global, national, and local levels. The data may include social media account linking and assessment of usage of the media account, as well as the depth and breadth of the social network.)
(Paragraphs [0012] and [0017] of Sayiner. The teaching describes a method of determining a recommendation to change a treatment regimen of a respiratory ailment. The treatment regimen includes a plurality of steps. Use data of a respiration medicament device to deliver controller or rescue respiration medicament to the patient is collected via a communication interface. The use data is transmitted to a storage device. The use data is stored in the storage device, which is accessible to a data analysis engine. Based on the collected use data and patient context data, a patient value associated with the treatment regimen is determined by the data analysis engine. A comparison of the patient value is made to a threshold level. A recommendation to change the step of the treatment regimen is made based on the comparison to the threshold level. A notification of the recommendation of the change of the step of the treatment regimen is provided. Contextual data from each of the population of patients is collected. Outcomes from the population of patients for the treatment regimen are collected. Initial recommendation thresholds for each of the steps of the multiple step treatment regimen are determined. The initial recommendation thresholds are adjusted based on the collected use data, contextual data, and outcomes until a predetermined level of confidence is reached.)
As per claim 5,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 4.
The combined teaching of Kumar and Sayiner further teaches wherein the machine-learning-based NLP engine is further configured to assign the reliability factor to the unstructured data by: parsing and extracting key entities from the unstructured data using named entity recognition (NER) and other NLP techniques; applying a machine learning model trained on labeled datasets to evaluate the accuracy of the extracted data by comparing it against known, validated sources; determining the timeliness of the unstructured data by analyzing timestamps and comparing it to current patient health events; and calculating the reliability factor based on a weighted combination of accuracy and timeliness, the reliability factor being used to adjust the weighting of the unstructured data when calculating the patient's risk profile:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0102] and [0116] of Sayiner. The teaching describes that the data capture module 322 may include an evaluation of social determinants of health (SDoH) summary. According to the World Health Organization, SDoH are the conditions in which people are born, grow, live, work and age. These circumstances are shaped by the distribution of money, power, and resources at global, national, and local levels. The data may include social media account linking and assessment of usage of the media account, as well as the depth and breadth of the social network.)
(Paragraphs [0012] and [0017] of Sayiner. The teaching describes a method of determining a recommendation to change a treatment regimen of a respiratory ailment. The treatment regimen includes a plurality of steps. Use data of a respiration medicament device to deliver controller or rescue respiration medicament to the patient is collected via a communication interface. The use data is transmitted to a storage device. The use data is stored in the storage device, which is accessible to a data analysis engine. Based on the collected use data and patient context data, a patient value associated with the treatment regimen is determined by the data analysis engine. A comparison of the patient value is made to a threshold level. A recommendation to change the step of the treatment regimen is made based on the comparison to the threshold level. A notification of the recommendation of the change of the step of the treatment regimen is provided. Contextual data from each of the population of patients is collected. Outcomes from the population of patients for the treatment regimen are collected. Initial recommendation thresholds for each of the steps of the multiple step treatment regimen are determined. The initial recommendation thresholds are adjusted based on the collected use data, contextual data, and outcomes until a predetermined level of confidence is reached.)
(Paragraphs [0027], [0030] and [0059] of Kumar. The teaching describes that the machine learning model (also referred to in some aspects as a risk model or a depression model) can be trained and used as an assessment tool for clinicians (e.g., nurses, caregivers, doctors, and the like) to assist in identifying users at risk of depression (e.g., patients, residents of a long-term care facility, and the like), thereby improving care, and preventing potentially significant negative outcomes. In some embodiments, by monitoring for changes in the conditions for each user, the system is able to identify those in need of additional care, and can assist with reallocating resources and driving targeted interventions to help mitigate, prevent, or reduce the effect of the risk or depression. In some embodiments, the machine learning model enables real-time insights, including alerts that notify the clinician or caretaker when there has been a change in condition with any user (e.g., within the past 24 hours) that affects potential depression, and provides the clinician with an actionable assessment and intervention details. These features and weights can then be used to automatically and efficiently process new user data in order to identify potential concerns for depression. In some aspects, the model may be trained during a training phase, and then be deployed as a static model that, once deployed, remains fixed. In other embodiments, the model may be refined or updated (either periodically or upon specified criteria). That is, during use in detecting and intervening in potential depressions, the model may be refined based on feedback from users, caregivers, and the like. For example, if a clinician indicates that a user has depression (regardless of whether the model predicted the diagnosis), the model may be refined based on this indication. Similarly, if a clinician indicates that the user does not have depression, the model may be refined to reflect this new data. For example, when a new resident enters a residential care facility, the machine learning system 135 may use their current attributes to generate an initial risk score. As another example, whenever a resident's attributes change (e.g., due to a newly-received diagnosis and/or a removed diagnosis), the machine learning system 135 may automatically detect the change and generate an updated risk score 235.)
As per claim 6,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 1.
Kumar further teaches comprising a real-time data monitoring module configured to continuously track and collect the patient data from one or more of the monitoring devices, the external sources, and the EHRs, the real-time data monitoring module being integrated with the processor and using a hardware-based processing unit to dynamically adjust the patient's risk profile in response to the detected deviations in the patient data from the baseline values, wherein the recalibration occurs without human intervention for generating a continuous comprehensive risk profile:
(Paragraphs [0027], [0030] and [0059] of Kumar. The teaching describes that the machine learning model (also referred to in some aspects as a risk model or a depression model) can be trained and used as an assessment tool for clinicians (e.g., nurses, caregivers, doctors, and the like) to assist in identifying users at risk of depression (e.g., patients, residents of a long-term care facility, and the like), thereby improving care, and preventing potentially significant negative outcomes. In some embodiments, by monitoring for changes in the conditions for each user, the system is able to identify those in need of additional care, and can assist with reallocating resources and driving targeted interventions to help mitigate, prevent, or reduce the effect of the risk or depression. In some embodiments, the machine learning model enables real-time insights, including alerts that notify the clinician or caretaker when there has been a change in condition with any user (e.g., within the past 24 hours) that affects potential depression, and provides the clinician with an actionable assessment and intervention details. These features and weights can then be used to automatically and efficiently process new user data in order to identify potential concerns for depression. In some aspects, the model may be trained during a training phase, and then be deployed as a static model that, once deployed, remains fixed. In other embodiments, the model may be refined or updated (either periodically or upon specified criteria). That is, during use in detecting and intervening in potential depressions, the model may be refined based on feedback from users, caregivers, and the like. For example, if a clinician indicates that a user has depression (regardless of whether the model predicted the diagnosis), the model may be refined based on this indication. Similarly, if a clinician indicates that the user does not have depression, the model may be refined to reflect this new data. For example, when a new resident enters a residential care facility, the machine learning system 135 may use their current attributes to generate an initial risk score. As another example, whenever a resident's attributes change (e.g., due to a newly-received diagnosis and/or a removed diagnosis), the machine learning system 135 may automatically detect the change and generate an updated risk score 235.)
As per claim 7,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 1.
Kumar further teaches comprising a predictive health event detection engine implemented on the processor, wherein the predictive health event detection engine is configured to continuously analyze patient data trends and generate an alert when the risk profile predicts an upcoming adverse health event, the predictive health event detection engine using one or more machine learning model trained on historical patient data to detect early warning signs of critical health deviations:
(Paragraphs [0027], [0030] and [0059] of Kumar. The teaching describes that the machine learning model (also referred to in some aspects as a risk model or a depression model) can be trained and used as an assessment tool for clinicians (e.g., nurses, caregivers, doctors, and the like) to assist in identifying users at risk of depression (e.g., patients, residents of a long-term care facility, and the like), thereby improving care, and preventing potentially significant negative outcomes. In some embodiments, by monitoring for changes in the conditions for each user, the system is able to identify those in need of additional care, and can assist with reallocating resources and driving targeted interventions to help mitigate, prevent, or reduce the effect of the risk or depression. In some embodiments, the machine learning model enables real-time insights, including alerts that notify the clinician or caretaker when there has been a change in condition with any user (e.g., within the past 24 hours) that affects potential depression, and provides the clinician with an actionable assessment and intervention details. These features and weights can then be used to automatically and efficiently process new user data in order to identify potential concerns for depression. In some aspects, the model may be trained during a training phase, and then be deployed as a static model that, once deployed, remains fixed. In other embodiments, the model may be refined or updated (either periodically or upon specified criteria). That is, during use in detecting and intervening in potential depressions, the model may be refined based on feedback from users, caregivers, and the like. For example, if a clinician indicates that a user has depression (regardless of whether the model predicted the diagnosis), the model may be refined based on this indication. Similarly, if a clinician indicates that the user does not have depression, the model may be refined to reflect this new data. For example, when a new resident enters a residential care facility, the machine learning system 135 may use their current attributes to generate an initial risk score. As another example, whenever a resident's attributes change (e.g., due to a newly-received diagnosis and/or a removed diagnosis), the machine learning system 135 may automatically detect the change and generate an updated risk score 235.)
As per claim 8,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 7.
Kumar further teaches comprising a generative AI engine operatively connected to the processor, wherein the generative AI engine is configured to generate one or more hypothetical patient risk profiles by simulating future health scenarios through predictive modeling, the predictive modeling based on the patient data trends, historical deviations, and stochastic analysis of evolving health patterns across the structured data, the semi-structured data, and the unstructured data:
(Paragraph [0119] of Kumar. The teaching describes that the machine learning system can therefore extract relevant user attributes to train machine learning model(s) to predict depression risk, or to be used as input to trained models in order to generate predicted risks during runtime. Since this is a future forecast, this is considered to be a hypothetical reality for a patient risk profile that has been simulated though predictive modeling by a machine learning model construed as a generative AI model.)
As per claim 9,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 1.
The combined teaching of Kumar and Sayiner further teaches wherein the patient data retrieved by the system comprises one or more computer-executable files containing the structured data, semi-structured data, and the unstructured data of various types, the computer-executable files including one or more of: patient health data from the Electronic Health Records (EHRs); Social Determinants of Health (SDoH) data from the external databases; wearable devices data monitoring patient health metrics; patient-reported information entered through a user interface; social media data analyzed for behavioral and lifestyle insights; and hereditary health data retrieved from family health records, wherein each computer-executable file is retrieved by a secure data retrieval device and processed by the processor to normalize, validate, and integrate the patient data for real-time risk profile generation:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0102] and [0116] of Sayiner. The teaching describes that the data capture module 322 may include an evaluation of social determinants of health (SDoH) summary. According to the World Health Organization, SDoH are the conditions in which people are born, grow, live, work and age. These circumstances are shaped by the distribution of money, power, and resources at global, national, and local levels. The data may include social media account linking and assessment of usage of the media account, as well as the depth and breadth of the social network.)
As per claim 10,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 1.
Sayiner further teaches further comprising a local assistant hub, wherein the local assistant hub comprises a modular hardware architecture that includes one or more interchangeable communication modules for supporting multiple wireless protocols, including one or more of Wi-Fi, Bluetooth, ZigBee, and Thread, configured to enable integration of the Electronic Health Records (EHRs), the monitoring devices, and the external sources using one or more communication standards without requiring a hardware upgrade:
(Paragraphs [0039], [0046] and [0094] and Figure 1 of Sayiner. The teaching describes that the client devices 110, at the behest of their users, interact with the respiratory ailment analytics system 100 via the network 150. The client device for the patient is seen as a local assistant hub. This device has a modular hardware architecture that includes sensor 120 and communicates with a network adapter and either a wired or wireless communication protocol, an example of which is the Bluetooth Low Energy (BTLE) protocol. The passive capture module 322 may also include additional passive collection of metrics through data aggregator software such as the Apple Health Kit, Google Fit and/or EHR based applications.)
As per claim 11,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 10.
Sayiner further teaches wherein the local assistant hub includes a data encryption module for ensuring secure local storage and transmission of the patient data, wherein the encryption module is configured to operate without requiring continuous connection to an external server, ensuring patient data privacy:
(Paragraph [0068] of Sayiner. The teaching describes that patient and provider data are encrypted for security and is at least password protected and otherwise secured to meet all Health Insurance Portability and Accountability Act (HIPAA) requirements.)
As per claim 12,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 11.
wherein the local assistant hub further comprises a local processing unit for performing on-device data analytics and real-time risk calculations, thereby reducing latency and minimizing reliance on cloud-based processing for continuous monitoring of the risk.
As per claim 13,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 12.
Sayiner further teaches wherein the local assistant hub is configured to support data integration from the monitoring devices, wherein the monitoring devices comprises one or more of a heart rate monitor, a continuous glucose monitor, a sleep tracking device, wherein each of the monitoring devices is configured to communicate with the local assistant hub using a device-specific protocol and transmit the patient data in real-time:
(Paragraphs [0039], [0046] and [0094] and Figure 1 of Sayiner. The teaching describes that the client devices 110, at the behest of their users, interact with the respiratory ailment analytics system 100 via the network 150. The client device for the patient is seen as a local assistant hub. This device has a modular hardware architecture that includes sensor 120 and communicates with a network adapter and either a wired or wireless communication protocol, an example of which is the Bluetooth Low Energy (BTLE) protocol. The passive capture module 322 may also include additional passive collection of metrics through data aggregator software such as the Apple Health Kit, Google Fit and/or EHR based applications. The passive capture module 322 may include data interfaces specific to data collection from other devices. This may include additional passive collection of patient metrics through hardware such as Fitness trackers (activity metrics, such as steps walked, elevation, heart rate). Pulse Oximeters (PO2, respiratory rate, Oxygen saturation), and night time monitoring (respiratory rate, awakeness/night time symptoms through devices such as fitness trackers or smart watches))
As per claim 14,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 13.
Sayiner further teaches wherein the semi structured data comprises a patient-generated information, further wherein the local assistant hub includes an adaptive interface for receiving the patient-generated information via one or more through voice, touch, or text input, allowing a user to manually input computer executable details into the system for integration into the patient risk profile:
(Paragraph [0044] of Sayiner. The teaching describes the dashboard allows patients 111, caregivers and providers 112 to interact with each other, receive asthma rescue event risk notifications, exchange messages about treatment, provide and receive additional event and non-event data, and so on.)
As per claim 15,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 14.
The combined teaching of Kumar and Sayiner further teaches wherein the local assistant hub is equipped with natural language processing (NLP) capabilities to interpret the patient-generated information, including voice commands, and translate these into actionable data points that are integrated into the patient risk profile:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0039], [0046] and [0094] and Figure 1 of Sayiner. The teaching describes that the client devices 110, at the behest of their users, interact with the respiratory ailment analytics system 100 via the network 150. The client device for the patient is seen as a local assistant hub. This device has a modular hardware architecture that includes sensor 120 and communicates with a network adapter and either a wired or wireless communication protocol, an example of which is the Bluetooth Low Energy (BTLE) protocol. The passive capture module 322 may also include additional passive collection of metrics through data aggregator software such as the Apple Health Kit, Google Fit and/or EHR based applications. The passive capture module 322 may include data interfaces specific to data collection from other devices. This may include additional passive collection of patient metrics through hardware such as Fitness trackers (activity metrics, such as steps walked, elevation, heart rate). Pulse Oximeters (PO2, respiratory rate, Oxygen saturation), and night time monitoring (respiratory rate, awakeness/night time symptoms through devices such as fitness trackers or smart watches))
As per claim 16,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 10.
The combined teaching of Kumar and Sayiner wherein the local assistant hub includes a housing containing a display interface for providing real-time feedback on the patient risk profile, wherein the interface displays aggregated patient data including the structured data from the Electronic Health Records (EHRs), the semi-structured data from the monitoring devices, and the unstructured data from the external sources in a consolidated view for interpretation by a user:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0039], [0046] and [0094] and Figure 1 of Sayiner. The teaching describes that the client devices 110, at the behest of their users, interact with the respiratory ailment analytics system 100 via the network 150. The client device for the patient is seen as a local assistant hub. This device has a modular hardware architecture that includes sensor 120 and communicates with a network adapter and either a wired or wireless communication protocol, an example of which is the Bluetooth Low Energy (BTLE) protocol. The passive capture module 322 may also include additional passive collection of metrics through data aggregator software such as the Apple Health Kit, Google Fit and/or EHR based applications. The passive capture module 322 may include data interfaces specific to data collection from other devices. This may include additional passive collection of patient metrics through hardware such as Fitness trackers (activity metrics, such as steps walked, elevation, heart rate). Pulse Oximeters (PO2, respiratory rate, Oxygen saturation), and night time monitoring (respiratory rate, awakeness/night time symptoms through devices such as fitness trackers or smart watches))
As per claim 17,
Claim 17 is substantially similar to claim 1. Accordingly, claim 17 is rejected for the same reasons as claim 1.
As per claim 18,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 17.
analyzing patient data trends continuously using a predictive health event detection engine, wherein the engine uses at least one machine learning model trained on historical patient data to detect early warning signs of critical health deviations; generating an alert when the predictive health event detection engine determines, based on the patient risk profile, that an adverse health event is likely to occur; and adjusting the patient risk profile in real time in response to the alert, said adjustment being performed by recalculating the patient's risk profile based on the detected trends and predicted health event:
(Paragraphs [0027], [0030] and [0059] of Kumar. The teaching describes that the machine learning model (also referred to in some aspects as a risk model or a depression model) can be trained and used as an assessment tool for clinicians (e.g., nurses, caregivers, doctors, and the like) to assist in identifying users at risk of depression (e.g., patients, residents of a long-term care facility, and the like), thereby improving care, and preventing potentially significant negative outcomes. In some embodiments, by monitoring for changes in the conditions for each user, the system is able to identify those in need of additional care, and can assist with reallocating resources and driving targeted interventions to help mitigate, prevent, or reduce the effect of the risk or depression. In some embodiments, the machine learning model enables real-time insights, including alerts that notify the clinician or caretaker when there has been a change in condition with any user (e.g., within the past 24 hours) that affects potential depression, and provides the clinician with an actionable assessment and intervention details. These features and weights can then be used to automatically and efficiently process new user data in order to identify potential concerns for depression. In some aspects, the model may be trained during a training phase, and then be deployed as a static model that, once deployed, remains fixed. In other embodiments, the model may be refined or updated (either periodically or upon specified criteria). That is, during use in detecting and intervening in potential depressions, the model may be refined based on feedback from users, caregivers, and the like. For example, if a clinician indicates that a user has depression (regardless of whether the model predicted the diagnosis), the model may be refined based on this indication. Similarly, if a clinician indicates that the user does not have depression, the model may be refined to reflect this new data. For example, when a new resident enters a residential care facility, the machine learning system 135 may use their current attributes to generate an initial risk score. As another example, whenever a resident's attributes change (e.g., due to a newly-received diagnosis and/or a removed diagnosis), the machine learning system 135 may automatically detect the change and generate an updated risk score 235.)
As per claim 19,
The combined teaching of Kumar and Sayiner teaches the limitations of claim 17.
The combined teaching of Kumar and Sayiner further teaches assigning a reliability factor to the unstructured data retrieved from Social Determinants of Health (SDoH) data sources using a machine-learning-based Natural Language Processing (NLP) engine, wherein the reliability factor is determined based on the accuracy and timeliness of the retrieved data; dynamically adjusting the reliability factor in real time based on one or more predefined parameters; and using the dynamically adjusted reliability factor to modify the weighting applied to the unstructured data when calculating the patient risk profile:
(Paragraphs [0040], [0065]-[0075] and [0199] of Kumar. The teaching describes a system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method. FIG. 3 depicts an example workflow 300 for preprocessing unstructured data for improved machine learning. In some embodiments, the workflow 300 may be performed to process natural language data 305 for input to one or more machine learning models. In some embodiments, the workflow 300 is performed by one or more remote systems (e.g., by a cloud-based service). In the illustrated example, the natural language data 305 can first undergo text extraction 310. The text extraction 310 generally corresponds to extracting natural language text from an unstructured portion of the natural language data 305. For example, if the natural language data 305 includes a set of clinical notes (e.g., notes written by a clinician describing an encounter with a user or patient), the text extraction 310 can include identifying and extracting these notes for evaluation. In some aspects, the notes may further include structured or semi-structured data that can undergo more traditional processing as needed, such as a timestamp indicating when the note was written or revised, an indication of the specific user about whom the note was written, the author of the note, and the like. The normalization 315 can generally a wide variety of text normalization processes, such as converting all characters in the extracted text to lowercase, converting accented or foreign language characters to ASCII characters, expanding contractions, converting words to numeric form where applicable, converting dates to a standard date format, and the like. Vectorization [integration of patient data] 345 may generally include converting the text into one or more objects that can be represented numerically (e.g., into a vector or tensor form). In some embodiments, as discussed in more detail below, these natural language notes 130 can be evaluated (e.g., using natural language processing techniques or machine learning models) to help quantify the potential risk of depression for the user.)
(Paragraphs [0102] and [0116] of Sayiner. The teaching describes that the data capture module 322 may include an evaluation of social determinants of health (SDoH) summary. According to the World Health Organization, SDoH are the conditions in which people are born, grow, live, work and age. These circumstances are shaped by the distribution of money, power, and resources at global, national, and local levels. The data may include social media account linking and assessment of usage of the media account, as well as the depth and breadth of the social network.)
(Paragraphs [0012] and [0017] of Sayiner. The teaching describes a method of determining a recommendation to change a treatment regimen of a respiratory ailment. The treatment regimen includes a plurality of steps. Use data of a respiration medicament device to deliver controller or rescue respiration medicament to the patient is collected via a communication interface. The use data is transmitted to a storage device. The use data is stored in the storage device, which is accessible to a data analysis engine. Based on the collected use data and patient context data, a patient value associated with the treatment regimen is determined by the data analysis engine. A comparison of the patient value is made to a threshold level. A recommendation to change the step of the treatment regimen is made based on the comparison to the threshold level. A notification of the recommendation of the change of the step of the treatment regimen is provided. Contextual data from each of the population of patients is collected. Outcomes from the population of patients for the treatment regimen are collected. Initial recommendation thresholds for each of the steps of the multiple step treatment regimen are determined. The initial recommendation thresholds are adjusted based on the collected use data, contextual data, and outcomes until a predetermined level of confidence is reached.)
(Paragraphs [0027], [0030] and [0059] of Kumar. The teaching describes that the machine learning model (also referred to in some aspects as a risk model or a depression model) can be trained and used as an assessment tool for clinicians (e.g., nurses, caregivers, doctors, and the like) to assist in identifying users at risk of depression (e.g., patients, residents of a long-term care facility, and the like), thereby improving care, and preventing potentially significant negative outcomes. In some embodiments, by monitoring for changes in the conditions for each user, the system is able to identify those in need of additional care, and can assist with reallocating resources and driving targeted interventions to help mitigate, prevent, or reduce the effect of the risk or depression. In some embodiments, the machine learning model enables real-time insights, including alerts that notify the clinician or caretaker when there has been a change in condition with any user (e.g., within the past 24 hours) that affects potential depression, and provides the clinician with an actionable assessment and intervention details. These features and weights can then be used to automatically and efficiently process new user data in order to identify potential concerns for depression. In some aspects, the model may be trained during a training phase, and then be deployed as a static model that, once deployed, remains fixed. In other embodiments, the model may be refined or updated (either periodically or upon specified criteria). That is, during use in detecting and intervening in potential depressions, the model may be refined based on feedback from users, caregivers, and the like. For example, if a clinician indicates that a user has depression (regardless of whether the model predicted the diagnosis), the model may be refined based on this indication. Similarly, if a clinician indicates that the user does not have depression, the model may be refined to reflect this new data. For example, when a new resident enters a residential care facility, the machine learning system 135 may use their current attributes to generate an initial risk score. As another example, whenever a resident's attributes change (e.g., due to a newly-received diagnosis and/or a removed diagnosis), the machine learning system 135 may automatically detect the change and generate an updated risk score 235.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD A NEWTON whose telephone number is (313)446-6604. The examiner can normally be reached M-F 8:00AM-4:00PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PETER H. CHOI can be reached at (469) 295-9171. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAD A NEWTON/Primary Examiner, Art Unit 3681
Prosecution Insights