DETAILED ACTION
This office action is based on the claim(s) filed on 09/04/2026.
Claims 1-10, 12-14, and 16-22 have been amended.
Claims 1-10, 12-14, and 16-22 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/04/2026 has been entered.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “unit” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a module of a risk evaluator” in Claim(s) 1, 3-6, 8-11 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and “evaluator” and functional language, for example, “determine an output of the risk”, without reciting sufficient structure to achieve the function.
“data aggregator module” in Claim(s) 1-2 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language, for example, “determining if the safety event caused harm...”, without reciting sufficient structure to achieve the function.
“a root-cause determiner module” in Claim(s) 5 and 17 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “determining if the safety event caused harm to the patient”, without reciting sufficient structure to achieve the function.
“a recommender module” in Claim(s) 6, and 18 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “determining if the safety event caused harm to the patient”, without reciting sufficient structure to achieve the function.
“AI predictor module/predictor module” in Claim(s) 8, 10, 19 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “to predict a second safety event...”, without reciting sufficient structure to achieve the function.
“an investigation trigger module” in Claim(s) 9 and 20 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “training an AI system to learn about data elements...”, without reciting sufficient structure to achieve the function.
“classifier module” in Claim(s) 4, 16 has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “configured to access data about the patient...”, without reciting sufficient structure to achieve the function.
“partial data flow module” in Claim(s) 3, has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “configured to perform operations comprising the steps of determining if the safety event...”, without reciting sufficient structure to achieve the function.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL-The specification shall contain a written description of the invention, and
of the manner and process of making and using it, in such full, clear, concise, and exact terms as to
enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to
make and use the same, and shall set forth the best mode contemplated by the inventor or joint
inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-10, 12-14, and 16-22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ). first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Specifically, the following limitations of claims 1, 4, 5, 12, 16, fail to comply with the written description requirement, since they do not adequately link or associate adequately described particular structure, material, or acts to perform the function recited in the claims identified to invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
Claim 1-6, 8-11, 16-20, recite the limitations for “module of a risk evaluator ... to determine...”, “data aggregator module ... determine...”, “root-cause determiner module... determining...”, “recommender module... determine”, “AI predictor module/predictor module ... to predict...”, “investigation trigger module... training an AI system to learn about data elements...”, “classifier module... configured to access...”, “partial data flow module ... configured to perform...”, which have been interpreted to invoke 35 U.S.C. 112(f). However, the instant specification does not disclose an algorithm for a computer-implemented means-plus-function limitation that performs the function of the module. Rather, the specification and drawings, for example, PGPUB [Fig. 1], [0037-0039], [0044-0047], [0049-0051], [0053] describes “a "module" however in [0037] it describes “A controller 44 can execute one or more modules 52, 54, 56, 58, 60, 62, 64, which are subsystems of the risk evaluator 38”, merely restates the function of the module(s). Therefore, in accordance with MPEP § 2181.IV, the instant specification does not provide written description support for this limitation as there is no corresponding structure disclosed in the specification.
Claim Rejections - 35 USC § 112(b)
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.
Claim(s) 1-10, 12-14, and 16-22 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 pre-AIA the applicant regards as the invention.
Claims 1-6, 8-11, 16-20 limitations, “a module of a risk evaluator..., a data aggregator module..., a root-cause determiner module..., a recommender module..., an investigation trigger module..., AI predictor module..., partial data flow module...”, has been interpreted under 112(f) as a means plus function limitation because of the combination of a non-structural term “module” and functional language “configured to perform operations comprising the steps of determining if the safety event...”, invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
The specification discloses a hardware structure of a generic PC/processor/server, which is not considered an adequate structure to perform the claimed functions. To perform the claimed functions, a computer comprising of hardware (processor, memory, etc.,) and software/algorithm to be programed to perform the functions may be considered an adequate structure yet there is no disclosure of any particular structure, either explicitly or inherently, to perform the functions. Moreover, the Applicant specifications disclose the mentioned modules/means however no description structure associated with the module(s) and/or the module(s) programmed to perform the steps. The use of the term “module” in the claim language is not sufficient system structure for performing the claim steps. As would be recognized by those of ordinary skill in the art, the term “Module” can be performed by any type of software and hardware combination which can be any generic computer. The specification does not provide sufficient details such that one of ordinary skill in the art would understand which “Module” structures perform(s) the claimed function.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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.
Claim 1-10, 12-14, and 16-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1-10, 12, and 21-22 are drawn to a method and Claims 13-14 and 16-20 are drawn to a system, which are within the four statutory categories (i.e., a machine and a process). Claims 1-10, 12-14, and 16-22 are further directed to an abstract idea on the grounds set out in detail below.
Under Step 2A, Prong 1, the steps of the claim for the invention represents an abstract idea of a series of steps that recite a process for patient safety surveillance and management. Receiving monitoring data for identifying safety event and risk associated with the event and present it to a user are steps that is/are an abstract idea that could have been performed by a human actor interacting with a system/interface to implement the abstract idea performing the steps detecting, acquiring, receiving, evaluating, transmitting, which both the instant claims and the abstract idea are defined as Certain Methods of Organizing Human Activity (managing personal behavior or interactions between people, including following rules or instructions).
Independent Claim 1 recite the steps of:
“detecting, using a sensor interfaced with a patient monitoring network, a safety event involving the patient,
acquiring, using a plurality of sensors and assessing devices, a plurality of patient health data for identifying and investigating the safety event,
receiving and processing the patient health data to evaluate the risk associated with patient care,
operating, by a controller executing program instructions stored in a non-transitory memory storing a training dataset comprising a root cause analysis (RCA) library, a module of a risk evaluator to use the data acquired and the RCA library to determine an output of the risk associated with the patient in real-time,
wherein the controller automatically correlates the patient health data received from the plurality of sensors and assessing devices over the patient monitoring network with the RCA library to identify causal factors contributing to the safety event without requiring manual data retrieval from each of the plurality of sensors and assessing devices
transmitting the output to a user device and managing patient care based on the output, and operating, by the controller, a data aggregator module configured to perform operations comprising the steps of
determining if the safety event caused harm to the patient by automatically accessing and aggregating patient data from the plurality of sensors and assessing devices over the patient monitoring network, and
prompting a user to log a time of occurrence of the safety event if the safety event caused harm to the patient
at least partially auto-filling an incident investigation report based on the patient health data received from the plurality of sensors and assessing devices, thereby reducing the time required to complete an incident investigation by eliminating manual data harvesting from each of the plurality of sensors and assessing devices”
Independent Claim 10 recite the steps of:
Detecting, using a sensor interfaced with a patient monitoring network, a first safety event involving the patient,
acquiring, using a plurality of sensors and assessing devices, patient health data for identifying and investigating the first safety event,
utilizing by a controller executing program instructions stored in a non-transitory memory, an AI-based operation trained using a root cause analysis (RCA) training dataset to automatically correlate the patient health data with the RCA training dataset and determine a root-cause of the first safety event and level of patient harm without requiring manual data retrieval from each of the plurality of sensors and assessing devices,
managing patient care based on the root-cause; and
using the patient health data acquired to determine risk associated with the patient in real-time by operating, by the controller, a predictor module configured to perform operations comprising the steps of
installing and connecting an Al system to the plurality of sensors and assessing devices,
training and verifying the Al system's ability to predict a second safety event,
utilizing the Al system to predict the second safety event, and
transmitting an alert to the user to prevent the second safety event
and at least partially auto-filling an incident investigation report based on the patient health data received from the plurality of sensors and assessing devices, thereby reducing the time required to complete an incident investigation by eliminating manual data harvesting from each of the plurality of sensors and assessing devices.”
Independent Claim 13 recites similar steps as in Claim 1:
“a plurality of assessing device, the plurality of assessing devices interfaced with a patient monitoring network to capture data for identifying and investigating a safety event,
a risk evaluator including a controller comprising one or more processors, and a non-transitory memory device storing program instructions and a training dataset comprising a root cause analysis (RCA) library, the controller operable to execute the program instructions to receive and process data from the assessing devices over the patient monitoring network, the controller further operable to automatically correlate the data received with the RCA library to identify causal factors contributing to the safety event without requiring manual data retrieval,
the controller further operable to evaluate the risk associated with patient care in real-time by operating a module based on the data and the training dataset in the memory device, the controller further operable to produce an output for monument of patient care and to at least partially auto-fill an incident investigation report based on the data, thereby reducing the time required to complete an incident investigation by eliminating manual data harvesting, and
a user device including a display, the display illustrating risk associated with patient-care wherein the controller is further operable to prompt a user to log a time of occurrence of the safety event if the safety event caused harm to the patient.”
These limitations, as drafted, given the broadest reasonable interpretation, cover performance of the limitations by a human user/actor interaction with computing device(s) that constitute Certain Methods of Organizing Human Activity along with Mental process. For example, the limitations encompass a user the ability to collect a monitoring device data associated with a patient to identify a safety event involving the patient and evaluate and determine the event risk on the patient and present the risk analysis to a user, which are steps that that could have been performed by a human actor using generic computing components/units to implement the abstract idea. These limitations encompass activity of a single person or multiple people and a computer, interacting with other users and with computing system(s) to perform the steps of the claimed invention for evaluating patient safety risk event, which constitutes Certain Methods of Organizing Human Activity. Accordingly, the claim limitations (in BOLD) recite an abstract idea. Any limitations not identified above as part of the process are deemed "additional elements," and will be discussed in further detail below.
Under Step 2A, Prong 2, this judicial exception is not integrated into a practical application because the remaining elements amount to no more than general purpose computer components programmed to perform the abstract ideas, linking the abstract idea to a particular technological environment. In particular, the claims recite the additional elements such as “user device, sensor, assessing device, controller, memory, display, module/aggregator module/predictor module, AI system” are computing components that iteratively takes input data and analyzes said data to determine an output while performing generic computer functions, e.g., “operating a module...”, “prompt[ing] a user...”, and are recited at a high level of generality and is/are a mere instruction(s) that may be performed by human that it amounts no more than adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f), generally linking the use of the judicial exception to a particular technological environment or field of use, see MPEP 2106.05(h), adding insignificant extra-solution activity to the judicial exception, (i.e. “transmitting …”), and mere data gathering that does not add a meaningful limitation to the above abstract idea, see MPEP 2106.05(d)-(g). As set forth in the 2019 Eligibility Guidance, 84 Fed. Reg. at 55 "merely include[ing] instructions to implement an abstract idea on a computer" is an example of when an abstract idea has not been integrated into a practical application. Accordingly, looking at the claim as a whole, individually and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Under step 2B, the claims do not include additional elements that are sufficient to amount to "significantly more" than the judicial exception because as mentioned above, the additional elements amount to no more than generic computing components, recited at a high level of generality, do not present improvements to another technology or technical field, nor do they affect an improvement to the functioning of the computer itself, that amount to no more than mere instruction to perform the abstract idea such that it amounts no more than adding the words "apply it" (or an equivalent) to apply the exception using generic computer component, see MPEP 2106.05(f), adding insignificant extra-solution activity to the judicial exception, (i.e., “transmitting …”), and mere data gathering that does not add a meaningful limitation to the above abstract idea, see MPEP 2106.05(d)-(g) and Symantec, and OIP Techs. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation and mere instructions to apply an exception using a generic computer component cannot provide an inventive concept, See Alice, 573 U.S. at 223 ("mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention."). The claims are not patent eligible.
Dependent Claims 2-9, 12, 14, and 16-22 include all of the limitations of claim(s) 1, 10, and 13, and therefore likewise incorporate the above-described abstract idea. While the depending claims add additional limitations, such as
As for claims 2-9, 12, 14, and 16-22, the claim(s) recite limitations that are under the broadest reasonable interpretation, further define the abstract idea noted in the independent claim(s) that covers performance by a human interaction constituting Certain methods of organizing human activity but for, the recitation of the generic computer components which are similarly rejected because, neither of the claims, further, defined the abstract idea and do not further limit the claim to a practical application or provide an inventive concept such that the claims are subject matter eligible. The claims recite additional elements “controller, a module of a risk evaluator, a data aggregator module, a root-cause determiner module, a recommender module, an investigation trigger module, a partial data flow module, a classifier module, AI predictor module, patient-controlled analgesia (PCA) pump, a respiratory equipment, a surveillance device, a fluid management device, a bring your own device (BYOD), a patient support apparatus, or a real-time locating system (RTLS), AI system”. In particular, the claims recite the additional elements that implement the identified abstract idea. These computing components are recited at a high level of generality, for example, the AI system is recited in the claims in a high level of generality and is in described in the specification in an arbitrary form without disclosing a specific process how these elements are implemented to perform a task as such is a mere in instruction(s) that may be performed by human that it amounts no more than adding the words "apply it" (or an equivalent), e.g., “prompting a user”, “auto-filling an incident” . Similarly, as mentioned above Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element to perform the noted steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept ("significantly more").
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 8-9, 13, 16-22 are rejected under 35 U.S.C. 103 as being unpatentable over Anthapur (US 2022/0230746 A1) in view of Dotan et al. (US 2016/0070864 A1- “Dotan”) in view of Grantcharov et al. (US 2021/0076966 Al “Grantcharov”)
Regarding Claim 1 (Currently Amended), Anthapur teaches a method for evaluating risk associated with a patient in a healthcare facility comprising the steps of:
detecting, using a sensor interfaced with a patient monitoring network, a safety event involving the patient Anthapur discloses a monitoring system that includes multiple sensors provided access over the network to medical events data and are located to sense health status and activity of an at-risk subject and detecting the subject activity (Anthapur: [Fig. 1], [0041-0042], [0060], [0094])
acquiring using a plurality of sensors and assessing devices, a plurality of patient health data for identifying and investigating the safety event, Anthapur discloses receiving sensors and devices such as vital signs sensors, blood pressure measuring device, temperature measuring device, weight measuring device, camera, location component, accelerometer, motion detection component etc., and include client device (e.g., mobile device) where data is evaluated to determine safety status of the subject where a decision operation evaluates or inspects information obtained from the sensors multiple time intervals to determine whether the sensor data indicates no detection of subject activity or indicates sensing the subject activity and determine if the activity has been completed by the subject or not and examine the activity context for whether the activity detected indicates an actual emergency or safety event (Anthapur: [Fig. 13A-B, 16, 17], [0042-0043], [0060-0062], [0098], [0122])
receiving and processing the patient health data to evaluate the risk associated with patient care, Anthapur discloses the decision operation evaluates information and context of the subject activity and determines if the activity indicates an actual emergency for a possible occurrence of a risk event or safety event (Anthapur: [0062-0063])
operating by a controller executing program instructions stored in a non-transitory memory storing a training dataset comprising a root cause analysis (RCA) library a module of a risk evaluator to use the patient health data acquired and the RCA library to determine an output of the risk associated with the patient in real-time, Anthapur discloses executing instruction stored in a non-transitory memory to use the data collected by the plurality of sensors and devices for monitoring to and evaluating in a real-time the subject and outputting an alert message reporting the detected risk event (Anthapur: [Fig. 14, 15A-B, 18], [0045], [0063], [0105])
wherein the controller automatically correlates the patient health data received from the plurality of sensors and assessing devices over the patient monitoring network with the RCA library to identify causal factors contributing to the safety event without requiring manual data retrieval from each of the plurality of sensors and assessing devices
transmitting the output to a user device and managing patient care based on the output, Anthapur discloses sends information over the network to one or more of the user devices based upon the sensor information such as sending the emergency alert event messages to user devices and escalate to care members according to protocol list (Anthapur: [Fig. 17], [0043], [0045], [0061], [0063], [0103]).
Operating, by the controller, a data aggregator module configured to perform operations Anthapur discloses a monitoring and control module performing data aggregation [data aggregator module] (Anthapur: [Fig. 1B], [0044], [0047]), comprising the steps of
determining if the safety event caused harm to the patient by automatically accessing and aggregating patient data from the plurality of sensors and assessing devices over the patient monitoring network, Anthapur discloses process automatically obtaining sensors and devices data to determine if the emergency risk event indicating a harm for the subject, e.g., fall or injury incident (Anthapur: [Fig. 15A-B, 18], [0041-0042], [0062-0063], [0107]), and
prompting a user to log a time of occurrence of the safety event if the safety event caused harm to the patient Anthapur discloses an alert report associated with the subject risk event prompted to a user to provide input (Anthapur: [Fig. 15B], [0062-0063])
and at least partially auto-filling an incident investigation report based on the patient health data received from the plurality of sensors and assessing devices, thereby reducing the time required to complete an incident investigation by eliminating manual data harvesting from each of the plurality of sensors and assessing devices Anthapur discloses a consolidated report of the health status and activity of a resident and prompting an alert report filled with the incident details and section for a user/member input (Anthapur [Fig. 15B], [0045], [0060], [0065-0066]).
Anthapur discloses associating risk with sensors and devices data [0054], [0060], and prompting a report with a recording a timeframe of the subject risk incident (Anthapur: [Fig. 15B]). However, Anthapur does not expressly disclose root cause analysis (RCA) and association of sensors and devices biometric data with the RCA in addition does not expressly disclose that the time of incident to be logged by a user and as underlined.
Dotan teaches
prompting a user to log a time of occurrence of the safety event, Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064])
at least partially auto-filling an incident investigation report based on the patient health data received from the plurality of sensors and assessing devices, thereby reducing the time required to complete an incident investigation by eliminating manual data harvesting from each of the plurality of sensors and assessing devices Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have Anthapur time of incident report to incorporate allowing a user to log the time of occurrence, as taught by Dotan, in which contributing, intervening, and prevention factors supports analysis for review to improve care quality and patient safety (Dotan: [0008], [0080]).
Grantcharov teaches
storing a training dataset comprising a root cause analysis (RCA) library Grantcharov discloses process the session container files to identify root causes of adverse patient outcomes and generate a training interface to communicate training data using the identified root causes and the session container files (Grantcharov: [0060], [0549])
wherein the controller automatically correlates the patient health data received from the plurality of sensors and assessing devices over the patient monitoring network with the RCA library to identify causal factors contributing to the safety event without requiring manual data retrieval from each of the plurality of sensors and assessing devices Grantcharov discloses patient data received from sensors and/or devices capturing biometric data captured in a real time to identify safety hazard event and correlating the event to container files comprising root cause analysis (Grantcharov: [Fig. 16] [0007-0008], [0059], [0412]).
Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have Anthapur association of sensors and devices data with an event to incorporate root cause analysis (RCA) library training data for correlating safety event with sensors and devices data, as taught by Grantcharov, for improving patient safety and
enabling analytical capabilities relating to the obtained data (Grantcharov: [0112]).
Regarding Claim 2 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, the data aggregator module further comprises the steps of identifying event-related data acquired from the plurality of sensors and the assessing devices about the patient during a given time period based on the time of occurrence of the safety event, Anthapur discloses monitoring activity associated with the subject risk event and identifying context information from the sensors associated with the event indicating activity of the subject to infer risk event (Anthapur: [Fig. 15B], [0041-0042], [0060], [0062-0063]), and
prompting the user to complete an investigation into the safety event Anthapur discloses an alert report associated with the subject risk event prompted to a user to provide input (Anthapur: [Fig. 15B], [0062-0063]).
Regarding Claim 3 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, the module of the risk evaluator comprises:
Operating, by the controller, a partial data flow module configured to perform operations comprising the steps of determining if the safety event caused harm to the patient, Anthapur discloses process to determine if the emergency risk event indicating a harm for the subject, e.g., fall or injury incident (Anthapur: [Fig. 15A-B, 18], [0062-0063], [0107])
prompting a user to log a time of occurrence of the safety event, partially auto-filling an incident investigation report based on the data received from the plurality of sensors and the assessing devices, Anthapur discloses a consolidated report of the health status and activity of a resident and prompting an alert report filled with the incident details and section for a user/member input [partially auto-filling] (Anthapur [Fig. 15B], [0045], [0060], [0065-0066])
identifying event-related data about the patient during a given time period based on the time of occurrence of the safety event, Anthapur discloses monitoring activity associated with the subject risk event and identifying context information from the sensors associated with the event indicating activity of the subject to infer risk event (Anthapur: [Fig. 15B], [0060], [0062-0063])
prompting the user to complete an investigation into the safety event by providing the partially auto-filled incident investigation report Anthapur discloses a consolidated report of the health status and activity of a resident and prompting an alert report filled with the incident details and section for a user input [partially auto-filling] (Anthapur [Fig. 15B], [0045], [0066]
Anthapur does not expressly disclose the features as underlined.
Dotan teaches
prompting a user to log a time of occurrence of the safety event, Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064])
partially auto-filling an incident investigation report based on the data received from the plurality of sensors and the assessing devices, Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1 and incorporated herein.
Regarding Claim 4 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, a module of the risk evaluator comprises:
Operating, by the controller, a classifier module configured to perform operations comprising the steps of determining if the safety event caused harm to the patient, Anthapur discloses classifying events such as fall or injury event and associated with different activity (Anthapur: [Fig. 19], [0113])
prompting a user to log a time of occurrence of the safety event, Anthapur discloses a sending a message comprising alert event of the subject to a user (e.g. caregiver) comprising time of the event (Anthapur: [Fig. 15B], [0113])
utilizing an AI-based operation to determine a classification of the safety event, Anthapur discloses a trained AI for classifying events (Anthapur: [Fig. 19], [0062-0063], [0079], [0113])
partially auto-filling an incident investigation report with the data received from the plurality of sensors and the assessing devices, Anthapur discloses an incident report partially filled with sensor data (Anthapur: [Fig. 15A-B])
prompting the user to complete an investigation into the safety event by providing the partially-filled incident investigation report Anthapur discloses the incident report partially filled with sensor data and a section for a user (e.g., caregiver) input (Anthapur: [Fig. 15A-B], [0108]).
Anthapur does not expressly disclose the features as underlined.
Dotan teaches
prompting a user to log a time of occurrence of the safety event, Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064])
partially auto-filling an incident investigation report with the data received from the plurality of sensors and the assessing devices, Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1 and incorporated herein.
Regarding Claim 5 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, the module of the risk evaluator comprises:
Operating, by the controller, a root-cause determiner module configured to perform operations comprising the steps of determining if the safety event caused harm to the patient, Anthapur discloses evaluating the steps for determining the risk event of the subject such as if the subject is harmed, e.g., fail/fallen or injured, such that determine if the subject change behavior [root cause] (Anthapur: [Fig. 5A-C, 19], [0062-0065], [0089], [0107])
prompting a user to log a time of occurrence of the safety event, Anthapur discloses a sending a message comprising alert event of the subject to a user (e.g. caregiver) comprising time of the event (Anthapur: [Fig. 15B],)
utilizing an AI-based operation trained using a root cause analysis (RCA) training dataset to determine a root-cause of the safety event, Anthapur discloses a trained AI to process steps of the evaluation of the subject risk event such that determine if the subject change behavior [root cause] (Anthapur: [Fig. 5A-C, 19], [0062-0063], [0065], [0113])
partially auto-filling an incident investigation report based on the data received from the plurality of sensors and the assessing devices, Anthapur discloses an incident report partially filled with sensor data (Anthapur: [Fig. 15A-B])
prompting the user to complete an investigation into the safety event by providing the partially auto-filled incident investigation report Anthapur discloses the incident report partially filled with sensor data and a section for a user (e.g., caregiver) input (Anthapur: [Fig. 15A-B], [0108]).
Anthapur does not expressly disclose the features as underlined.
Dotan teaches
prompting a user to log a time of occurrence of the safety event, Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064])
partially auto-filling an incident investigation report with the data received from the plurality of sensors and the assessing devices, Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1 and incorporated herein.
Regarding Claim 6 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, the module of the risk evaluator comprises:
Operating, by the controller, a recommender module configured to perform operations comprising the steps of determining if the safety event caused harm to the patient, Anthapur discloses recommending modifying the subject care plan when the evaluation determined a risk event alert associated with the subject (Anthapur: [Fig. 8], [0046], [0090])
prompting a user to log a time of occurrence of the safety event, Anthapur discloses a sending a message comprising alert event of the subject to a user (e.g. caregiver) comprising time of the event (Anthapur: [Fig. 15B],)
utilizing an AI-based operation trained using a root cause analysis (RCA) training dataset to determine a root-cause of the safety event, Anthapur discloses a trained AI to process steps of the evaluation of the subject risk event such that determine if the subject change behavior [root cause] (Anthapur: [Fig. 5A-C, 19], [0062-0063], [0065], [0113])
utilizing the AI-based operation to write a description about the root-cause of the safety event, (Anthapur: [Fig. 15A-B])
partially auto-filling an incident investigation report with the data received from the plurality of sensors and the assessing devices, Anthapur discloses an incident report partially filled with sensor data (Anthapur: [Fig. 15A-B])
recommending an action plan to the user based on the root-cause determination made by the AI-based operation Anthapur discloses recommending modifying the subject care plan when the evaluation determined a risk event alert associated with the subject (Anthapur: [Fig. 8], [0046], [0090]).
Anthapur does not expressly disclose the features as underlined.
Grantcharov teaches
operation trained using a root cause analysis (RCA) training dataset Grantcharov discloses process the session container files to identify root causes of adverse patient outcomes and generate a training interface to communicate training data using the identified root causes and the session container files (Grantcharov: [0060], [0549]).
Dotan teaches
prompting a user to log a time of occurrence of the safety event, , Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064])
partially auto-filling an incident investigation report with the data received from the plurality of sensors and the assessing devices, Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1 and incorporated herein.
Regarding Claim 8 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, the module of the risk evaluator comprises:
operating, by the controller, an AI predictor module configured to perform operations comprising the steps of installing and connecting an AI system to the plurality of sensors and assessing devices, Anthapur discloses an AI ATP builder operation receives activity data which can include a sensor data stream collected using installed sensors and devices (Anthapur: [Fig. 8, 11, 12], [0082], [0087], [0115])
training and verifying the AI system's ability to predict a second safety event Anthapur discloses machine learning is used to implement training AI system for predicting and identifying different incidents such that the machine learning involved studying existing data, learning from existing data and making predictions about new data (Anthapur: [0060], [0063], [0088], [0113-0115])
utilizing the AI system to predict the second safety event, (Anthapur: [0113-0115])
transmitting an alert to the user to prevent an occurrence of the second safety event (Anthapur: [0113-0115]).
Regarding Claim 9 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 1, wherein operating, by the controller, the module of the risk evaluator comprises:
operating, by the controller, an investigation trigger module configured to perform operations comprising the steps of training an AI system to learn about data elements that contribute to the safety event, Anthapur discloses a decision operation evaluating information obtained from different devices used to train an AI implemented on a machine learning to learn from data input and pattern indicating a risk event, (Anthapur: [0060], [0087], [0090], [0096])
identifying a data abnormality from the data received from the plurality of sensors and assessing devices, Anthapur discloses the decision operation evaluating information and determine data deviation determines deviant and anomalous behaviors and activates indicating occurrence of a risk event (Anthapur: [0063], [0090], [0104])
completing an incident investigation process (Anthapur: [0060-0065], [0105-0106])
generating a safety event report, (Anthapur: [0063], [0107])
transmitting the safety event report to the user device (Anthapur: [0063], [0108]).
Regarding Claim 10 (Currently Amended), Anthapur teaches a method for evaluating risk associated with a patient in a healthcare facility comprising the steps of:
the claim limitations recite substantially similar limitations to claim 1, as such, are rejected for similar reasons as given above and the additional claim limitation are rejected as the following:
using the patient health data acquired to determine risk associated with the patient in real-time by operating, by the controller, a predictor module configured to perform operations real-time monitoring of the subject and outputting an alert message reporting the detected risk event (Anthapur: [Fig. 14], [0105]) comprising the steps of
installing and connecting an Al system to the plurality of sensors and assessing devices Anthapur discloses using a master AI system connected to receive activity data from the installed and connected devices/sensors (Anthapur: [Fig. 9, 10], [0041-0042], [0087], [0101-0102]),
Examiner takes a note that unless a description of the AI system indicting a special and specific way of installation, a system to communicate with other components indicating the system is already installed and connected.
training and verifying the Al system's ability to predict a second safety event Anthapur discloses machine learning is used to implement training AI system for predicting and identifying different incidents such that the machine learning involved studying existing data, learning from existing data and making predictions about new data (Anthapur: [0060], [0063], [0088], [0113-0115]),
utilizing the Al system to predict the second safety event Anthapur discloses using AI operation to determine a risk event of the subject and level of risk such that the AI deduction of the adverse scenario for which the alert was generated is accurate or a false positive (Anthapur: [Fig. 4, 11], [0062-0063], [0107], [0113-0115])),
transmitting an alert to the user to prevent the second safety event (Anthapur: [0113-0115])
Regarding Claim 13 (Currently Amended), Anthapur teaches a system for evaluating risk associated with a patient comprising:
other than a controller and a memory device, training data set and display, the display illustrating risk associated with patient-care (Anthapur: [Fig. 5A-C], [0059-0063]).
the other claim limitations recite substantially similar limitations to claim 1, as such, are rejected for similar reasons as given above.
Regarding Claim 16 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the system of claim 13, wherein the risk evaluator is operable to implement, by the controller executing the program instructions, a classifier module configured to access data about the patient from the assessing devices over the patient monitoring network during a given time period based on a time of occurrence of the safety event, Anthapur discloses a trained AI for classifying events accessed and obtained from plurality of devices during periodic time intervals such as fall or injury event and associated with different activity (Anthapur: [Fig. 19], [0060], [0062-0063], [0079], [0113])
utilize an AI-based operation trained using the root cause analysis (RCA) library to determine a classification of the safety event, Anthapur discloses a trained AI for classifying events (Anthapur: [Fig. 19], [0062-0063], [0079], [0113])
partially auto-fill the incident investigation report with the data Anthapur discloses the incident report partially filled with sensor data and a section for a user (e.g., caregiver) input (Anthapur: [Fig. 15A-B], [0108]).
Grantcharov teaches
trained using the root cause analysis (RCA) library Grantcharov discloses process the session container files to identify root causes of adverse patient outcomes and generate a training interface to communicate training data using the identified root causes and the session container files (Grantcharov: [0060], [0549]).
Dotan teaches
partially auto-fill the incident investigation report with the data Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 13 and incorporated herein.
Regarding Claim 17 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the system of claim 13, wherein the risk evaluator is operable to implement, by the controller executing the program instructions, a root-cause determiner module configured to access data about the patient from the assessing devices over the patient monitoring network during a given time period based on a time of occurrence of the safety event, Anthapur discloses evaluating data accessed and obtained from plurality of devices during periodic time intervals for determining the risk event of the subject such as if the subject is harmed, e.g., fail/fallen or injured, such that determine if the subject change behavior (Anthapur: [Fig. 5A-C, 19], [0060], [0062-0065], [0089], [0107])
utilize an AI-based operation trained using the root cause analysis (RCA) library to determine a root-cause of the safety event, Anthapur discloses a trained AI to process steps of the evaluation of the subject risk event such that determine if the subject change behavior [root cause] (Anthapur: [Fig. 5A-C, 19], [0062-0063], [0065], [0113]).
partially auto-fill the incident investigation report with the data Anthapur discloses an incident report partially filled with sensor data (Anthapur: [Fig. 15A-B]).
However, Anthapur does not disclose the features as underlined.
Grantcharov teaches
a root-cause determiner and operation trained using the root cause analysis (RCA) library Grantcharov discloses process the session container files to identify root causes of adverse patient outcomes and generate a training interface to communicate training data using the identified root causes and the session container files (Grantcharov: [0060], [0227], [0549]).
Dotan teaches
partially auto-fill the incident investigation report with the data Dotan discloses after the patient safety data for the safety event reported, the data recorded may automatically populated in the patient safety event fields (Dotan: [Fig. 2], [0062], [0068], [0070]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 13 and incorporated herein.
Regarding Claim 18 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the system of claim 13, wherein the risk evaluator is operable to implement, by the controller executing the program instructions, a recommender module configured to access data about the patient from the assessing devices over the patient monitoring network during a given time period based on a time of occurrence of the safety event, Anthapur discloses recommending modifying the subject care plan when the evaluation determined a risk event alert associated with the subject based on data accessed and obtained from plurality of devices during periodic time intervals (Anthapur: [Fig. 8], [0046], [0060], [0090])
utilize an AI-based operation trained using the root cause analysis (RCA) library to determine a root-cause of the safety event, partially auto-fill the incident investigation report with the data, Anthapur discloses a trained AI to process steps of the evaluation of the subject risk event such that determine if the subject change behavior [root cause] (Anthapur: [Fig. 5A-C, 19], [0062-0063], [0065], [0113])
transmit a recommended action plan to the user device Anthapur discloses recommending modifying the subject care plan when the evaluation determined a risk event alert associated with the subject (Anthapur: [Fig. 8], [0046], [0090], [0100]).
However, Anthapur does not disclose the features as underlined.
Grantcharov teaches
trained using the root cause analysis (RCA) library to determine a root-cause of the safety event Grantcharov discloses process the session container files to identify root causes of adverse patient outcomes and generate a training interface to communicate training data using the identified root causes and the session container files (Grantcharov: [0060], [0549]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 13 and incorporated herein.
Regarding Claim 19-20, the claims recite substantially similar limitations to claims 8-9 as such, are rejected for similar reasons as given above.
Regarding Claim 21 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 10, further comprising:
determining if the first safety event caused harm to the patient Anthapur discloses process to determine if the emergency risk event indicating a harm for the subject, e.g., fall or injury incident (Anthapur: [Fig. 15A-B, 18], [0062-0063], [0107])
prompting a user to log a time of occurrence of the first safety event if the first safety event caused harm to the patient Anthapur discloses a consolidated report of the health status and activity of a resident and prompting an alert report filled with the incident details and section for a user/member input (Anthapur [Fig. 15B], [0045], [0060], [0065-0066]),
identifying event-related data acquired from the plurality of sensors and the assessing devices about the patient during a given time period based on the time of occurrence of the first safety event Anthapur discloses monitoring activity associated with the subject risk event and identifying context information from the sensors associated with the event indicating activity of the subject to infer risk event (Anthapur: [Fig. 15B], [0060], [0062-0063])
prompting the user to complete an investigation into the first safety event Anthapur discloses an alert report associated with the subject risk event prompted to a user to provide input (Anthapur: [Fig. 15B], [0062-0063])
Anthapur discloses recording a timeframe of the subject risk incident (Anthapur: [Fig. 15B]), however does not expressly disclose the time of incident to be logged by a user as underlined.
Dotan teaches
prompting a user to log a time of occurrence of the safety event, Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 10 and incorporated herein.
Regarding Claim 22 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 10, further comprising:
determining if the first safety event caused harm to the patient Anthapur discloses process to determine if the emergency risk event indicating a harm for the subject, e.g., fall or injury incident (Anthapur: [Fig. 15A-B, 18], [0062-0063], [0107])
prompting a user to log a time of occurrence of the first safety event, partially auto-filling an incident investigation report based on the data received from the plurality of sensors and the assessing devices, Anthapur discloses a consolidated report of the health status and activity of a resident and prompting an alert report filled with the incident details and section for a user/member input the incident report partially filled with sensor data and a section for a user (e.g., caregiver) input (Anthapur: [Fig. 15A-B], [0045], [0060], [0065-0066], [0108]),
identifying event-related data about the patient during a given time period based on the time of occurrence of the first safety event, Anthapur discloses events obtained from plurality of devices during periodic time intervals such as fall or injury event and associated with different activity and the monitoring activity associated with the subject risk event and identifying context information from the sensors associated with the event indicating activity of the subject to infer risk event (Anthapur: [Fig. 15B], [0060], [0062-0063])
prompting the user to complete an investigation into the first safety event by providing the partially auto-filled incident investigation report Anthapur discloses an alert report associated with the subject risk event prompted to a user to provide input (Anthapur: [Fig. 15B], [0062-0063])
Dotan discloses Dotan discloses after patient safety event occurs, user may document the patient safety event as such the patient safety application prompted on the user mobile device to login or/and provide information associated with safety event such as safety event category and severity where the application registers the date and time associated with the entered event information by the user as prat of the Agency for Healthcare Quality and Research (AHRQ) report (Dotan: [Fig. 2, 6, 20], [0060-0064]).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 10 and incorporated herein.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Anthapur (US 2022/0230746 A1) in view of Dotan et al. (US 2016/0070864 A1- “Dotan”) in view of Grantcharov et al. (US 2021/0076966 Al “Grantcharov”) in view of Bollish et al. (US 2005/0177096 Al- “Bollish”)
Regarding Claim 7 (Currently Amended), the combination of Anthapur, Dotan, and Grantcharov teaches the method of claim 6, wherein the AI-based operation is configured to access data from the plurality of sensors and assessing devices comprising at least one of a patient-controlled analgesia (PCA) pump, a respiratory equipment, a surveillance device, a fluid management device, a bring your own device (BYOD), a patient support apparatus, or a real-time locating system (RTLS) Anthapur discloses an AI and machine learning techniques to evaluate information form input devices such as vital signs sensors, camera, location component, accelerometer, motion detection component etc., and include client device (e.g., mobile device) [bring your own device (BYOD)] (Anthapur: [Fig. 13A-B], [0042-0043], [0098], [0122]).
However, Anthapur does not expressly discloses PCA pump, respiratory or fluid management device.
Bollish discloses monitoring physiological parameter of a patient using input from a patient-controlled analgesia (PCA) pump, a respiratory device, a fluid management device (Bollish: [Fig. 12, 17], [0017], [0025], [0061]).
Therefore, it would be obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have Anthapur surveillance devices for monitoring the subject to incorporate other devices such as patient-controlled analgesia (PCA) pump, a respiratory device, a fluid management device, as taught by Bollish, to ensure greater safety and decreased risk of injuries from respiratory depression (Bollish: [0081]).
Regarding Claim 12 and 14, the claims recite substantially similar limitations to claim 7 as such, is/are rejected for similar reasons as given above.
Response to Amendment
Applicant's arguments filed 09/04/2026 have been fully considered by the Examiner and addressed as the following:
In the remarks, Applicant argues in substance that:
Applicant's arguments with respect to the 35 U.S.C. § 112(b) rejection on page 9-10.
On page 9-10 of the remarks, Applicant argues “The Examiner asserts that the claims contain limitations that are not described in the written description. Applicant respectfully disagrees ... Therefore, the disclosure teaches the above modules as being configured to operate so as to perform the specific functions. Accordingly, one of ordinary skill in the art would understand the module structures as recited in the claims...”, Examiner respectfully disagree. As described above and similarly in the response of the prior OA mailed 06/04/2026, the Applicant specification describes a function of the modules however the claim(s) is/are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph for the written description fails to disclose the corresponding structure and the use of the term “module” in the claim language is not sufficient system structure for performing the claim steps/function and the specification does not provide sufficient details such that one of ordinary skill in the art would understand which “Module” structures perform(s) the claimed function. Therefore, the claim(s) rejection is maintained.
Applicant's arguments with respect to the 35 U.S.C. § 101 rejection on page 10-14.
On page 11-12 of the remarks, Applicant argues “Claim 1 has been amended to recite, among other things, "managing patient care based on the output [ determined by the risk evaluator," and claim 10 has been amended to recite, "managing patient care based on the [determined] root-cause." Claim 13 has been amended similarly to claim 1... As such, amended claims 1-10, 12-14, and 16-20 enhance patient care and improve patient treatment ... This is just such a case. The application of the present claims, which are recited to occur in real-time by accessing data from multiple devices, cannot practically be performed in the human mind.”, Examiner respectfully disagree. Examiner asserts that the claims are given their broadest reasonable interpretation for the purpose of determining whether they encompass a judicial exception. The amended claims, given their broadest reasonable interpretation, recite an abstract idea which have been analyzed under Step 2A, Prong One reciting a process for monitoring and surveillance of a patient and collect to analyze and assess the data for safety events and identify risk associated with the patient and a user logs in the safety event information and verify a generated report to be submitted and provide an action which define a judicial exception steps while using computing devices to perform the abstract steps, for managing patient care, as described by the Applicant, which are steps can be performed by a user interacting with a device(s) for performing the abstract idea which are concepts that falls within the Certain Methods of Organizing Human Activity grouping and sub grouping sub-grouping "managing personal behavior or interactions between people".
On page 12 of the remarks, Applicant argues “The claims, as amended, recite a practical application... To the extent that claims 1, 10, and 13 continue to be considered directed to recite a judicial exception, the judicial exception is integrated into a practical application in the form of providing more efficient patient care and prevent health complications (see, [0042]), As such, the claims recite a practical application. Since the additional element(s) in the claim integrate any applicable judicial exception into a practical application of the exception, the claim is not "directed to" the judicial exception, and therefore the claim is eligible”, Examiner respectfully disagree. As discussed in response to the same argument in the prior OA mailed 06/04/2026, The Applicant specification [0042] “incident investigation report can further include patient complaints, falls, violent events, patient deterioration, and other information. Similarly, a fall compliance report can be used to track bed settings for fall-risk patients, highlight bed settings that may put patients at risk, and strengthen fall prevention strategies by uncovering areas of improvement” which does not describe a management is performed and implemented other than presenting recommendation steps for patient care which is defined under judicial exception as an abstract step.
Moreover, as described in the rejection above, the claim does not describe a particular improvement of computer’s functionality or a technical field, rather using additional elements, “e.g., user device, sensor, assessing device, controller, memory, display, module/aggregator module/predictor module, AI system”, to perform the steps abstract idea such as detecting, collecting/obtaining, analyzing, assessing, determining, and displaying through leveraging computing technology in a well understood manner however improving upon an abstract idea does not make the abstract idea any less abstract. In light of the Alice decision and the guidance provided in the 2019 PEG, the features listed in the claims, are not considered an improvement to another technology or technical field, or an improvement to the functioning of the computer itself rather describes an improvement patient care via monitoring and surveillance, which is solving a health facility and patient administrative problem, using computers, for assessing the patient safety events and risk. In addition, relying on computing devices to perform routine tasks more quickly or more accurately is insufficient to render a claim patent eligible (See Alice, 134 S. Ct. at 2359 "use of a computer to create electronic records, track multiple transactions, and issue simultaneous instructions" is not an inventive concept). Even when considering the claims additional elements, the claims as a whole, individually and in combination, provide no integration of the abstract ideas into a practical application that no meaningful limits on practicing the abstract idea are introduced, see MPEP 2106. As set forth in the 2019 Eligibility Guidance, 84 Fed. Reg. at 55 "merely include[ing] instructions to implement an abstract idea on a computer" is an example of when an abstract idea has not been integrated into a practical application. The claims as a whole are therefore directed to an abstract idea.
On page 13-14 of the remarks, Applicant argues “Claims 1, 10, and 13 recite additional elements that amount to significantly more than the recited judicial exception ... the Examiner must look at the claims as a whole ... when considered as a whole, are directed to methods and systems for assessing patient risk by evaluating disparate signals in real-time, identifying an output, prompting a user or alerting a caregiver to improve patient care... Such complex assessment cannot be made by the human mind. Such an application enhances patient treatment and provides efficient care.”, Examiner respectfully disagree. As mentioned above, the steps recited in independent claims, when viewed as a whole, recite a judicial exception for the steps, under BRI, recites an abstract idea for patient monitoring and surveillance for safety event while citing addition element described at high level and as tool(s) to perform the abstract idea as such the thrust of Applicant's invention is to improve the abstract idea for evaluating a patient safety through leveraging computing technology, e.g., user device, sensor, assessing device, controller, memory, display, module/aggregator module/predictor module, AI system, in an understood manner. The fact that the judicial exception, identified in the rejection above, relies upon detecting safety event, collecting patient data, analyzing, assessing the risk, does not impart an improvement to any existing computer, or any other technology or technical field. At best, this gathering of data to be used for improving patient care may improve the abstract idea. However, improving upon an abstract idea does not make the abstract idea any less abstract. In addition, as discussed above, the additional elements are disclosed at a high level of generality that invoke computers or other machinery merely as a tool to perform an existing process will generally not amount to significantly more than a judicial exception. “Use of a machine that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not integrate a judicial exception or provide significantly more, see 2106.05(b), and Bilski.
Therefore, the Applicant argument is found to be unpersuasive and Examiner remains the 101 rejections of claims which have been updated to address Applicant's argument.
Applicant's arguments with respect to the 35 U.S.C. § 102 rejection on page 14-16.
In response to the applicant amendment for the Applicant argument for claim 10 that “Anthapur does not describe the limitations recited in claim 1... Anthapur does not describe ... to determine an output of the risk associated with the patient in real-time”, Examiner respectfully disagree. Anthapur in [Fig. 14 and [0045] describes a real-time process and outputting risk associated with the patient. Further Applicant argued “...and prompting a user to log a time of occurrence of the safety event if the safety event caused harm to the patient," previously recited in claim 2. The Examiner asserts that this limitation is taught by Henwood. However, Henwood does not teach amended claim 1”, Examiner respectfully disagree. Although the Applicant arguing a newly amended feature, Examiner withdraws the 102 rejections. Therefore, Applicant argument is moot.
Applicant's arguments with respect to the 35 U.S.C. § 103 rejection on page 16-17.
On page 16 of the remarks, Applicant argues “Anthapur is silent to prompting a user to logging any time of occurrence of the safety event... Henwood does not describe any prompting based on the condition "if the safety event caused harm to the patient," as recited in amended claim 1”, Examiner respectfully disagree. As described in the OA rejection, Anthapur discloses the feature argued by the Applicant “prompting based on the condition "if the safety event caused harm to the patient” and Henwood discloses the feature argued by the Applicant “prompting a user to logging any time of occurrence of the safety event”. While the claims as amended recite prompting if safety event caused a harm, Henwood discloses a prompt for a user to enter the status of event which is the safety event caused a harm. Therefore. It is clear that the combination of references teaches the claim limitations and as argued above. Moreover, Examiner has introduced new references disclosing the amended and argued limitations
Therefore, Examiner finds the Applicant argument is moot.
Prior Art Cited but not Applied
The following document(s) were found relevant to the disclosure but not applied:
“Creating a Defined Process to Improve the Timeliness of Serious Safety Event Determination and Root Cause Analysis”- “Donnelly”.
The references are relevant since it discloses monitoring and analyzing patient physiological parameters to indicate safety of patient care.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAAELDIN ELSHAER whose telephone number is (571)272-8284. The examiner can normally be reached M-Th 8:30-5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, MAMON OBEID can be reached at Mamon.Obeid@USPTO.GOV. 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.
/ALAAELDIN M. ELSHAER/Primary Examiner, Art Unit 3687
