DETAILED ACTION
This office action is based on the claim set filed on 04/13/2026.
Claims 1-2, 10, 12-13, and 19-20 have been amended.
Claims 11 and 15 have been canceled.
Claims 21-22 are new.
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 .
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) 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.
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(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-6, 8-10, 13, and 16-20 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.
Claim 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...”, in Claim(s) 1-11, 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 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 a module of a risk evaluator to use the data acquired to determine an output of the risk associated with the patient in real-time,
transmitting the output to a user device and managing patient care based on the output, operating a data aggregator module comprising the steps of
determining if the safety event caused harm to the patient by accessing patient data from the sensor or the assessing device, and
prompting a user to log a time of occurrence of the safety event if the safety event caused harm to the patient.”
Independent Claim 10 recite the steps of:
detecting 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 an AI-based operation to determine a root-cause of the first safety event and level of patient harm,
managing patient care based on the root-cause;
using the patient health data acquired to determine risk associated with the patient in real-time by operating a predictor module comprising the steps of
installing and connecting an Al system to the accessing device,
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.
Independent Claim 13 recites similar steps as in Claim 1:
“an assessing device to capture data for identifying and investigating a safety event,
a risk evaluator including a controller and a memory device, the controller operable to receive and process data from the assessing device,
the controller further operable to evaluate the risk associated with patient care in real-time by operating a module based on the data and a training dataset in the memory device, the controller further operable to produce an output for monument of patient care, 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 “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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 10 is rejected under 35 U.S.C. 102(a)(2) as being anticipated by Anthapur (US 2022/0230746 A1)
Regarding Claim 10 (Currently Amended), Anthapur teaches a method for evaluating risk associated with a patient comprising the steps of:
detecting a first safety event involving the patient Anthapur discloses a monitoring system that includes multiple sensors that are located to sense health status and activity of an at-risk subject and detecting the subject activity (Anthapur: [Fig. 1], [0041-0042], [0060]),
acquiring, using a plurality of sensors and assessing devices, patient health data for identifying and investigating the first safety event, Anthapur discloses a system comprising plurality of modules that operate to perform one or more operations or functions and providing access to different information, (Anthapur: [Fig. 1B], [0044], [0047]).
utilizing an AI-based operation to determine a root-cause of the first safety event and level of patient harm Anthapur discloses the system comprising a master AI system connected to plurality of components that collects data to identify a safety event and the cause of the event such as when a user is not moving [root cause], it is determined that the user hay have fallen [safety event] (Anthapur: [Fig. 17-19], [0045], [0062])
managing patient care based on the root-cause escalate to care members according to protocol list and type of safety event such as schedule a visit or call emergency (Anthapur: [Fig. 17-19], [0045], [0062], [0103];
using the patient health data acquired to determine risk associated with the patient in real-time by operating a predictor module 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 accessing device Anthapur discloses using a master AI system connected to receive activity data from the installed and connected devices/sensors (Anthapur: [Fig. 9, 10], [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]).
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 Henwood (CA 02781251 A1)
Regarding Claim 1 (Currently Amended), Anthapur teaches a method for evaluating risk associated with a patient comprising the steps of:
detecting, using a sensor or an assessing device, a safety event involving the patient Anthapur discloses a monitoring system that includes multiple sensors that are located to sense health status and activity of an at-risk subject and detecting the subject activity (Anthapur: [Fig. 1], [0041-0042], [0060])
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 sensor and devices such as vital signs sensors, 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 determine if the activity indicates an actual emergency for a possible occurrence of a risk event or safety event (Anthapur: [0062-0063])
operating a module of a risk evaluator to use the patient health data acquired to determine an output of the risk associated with the patient in real-time, Anthapur discloses a real-time monitoring of the subject and outputting an alert message reporting the detected risk event (Anthapur: [Fig. 14, 15A-B, 18], [0045], [0063], [0105])
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 a data aggregator module 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 accessing patient data from the sensor or the assessing device 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]), 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])
Anthapur discloses prompting a report with a 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.
Henwood teaches
prompting a user to log a time of occurrence of the safety event, Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating the subject good condition (Henwood: [p. 26, line 11-12]).
Regarding Claim 2 (Currently Amended), the combination of Anthapur and Henwood teaches the method of claim 1, wherein operating the data aggregator module further comprises the steps of identifying event-related data acquired from the sensor or the assessing device 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]), 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 (Original), the combination of Anthapur and Henwood teaches the method of claim 1, wherein operating the module of the risk evaluator comprises:
operating a partial data flow 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 sensor and the assessing device, 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 discloses prompting partially auto-filled report with a 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.
Henwood teaches
prompting a user to log a time of occurrence of the safety event, Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating the subject good condition (Henwood: [p. 26, line 11-12]).
Regarding Claim 4 (Original), Anthapur teaches the method of claim 1, wherein operating the module of the risk evaluator comprises:
operating a classifier 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 sensor and the assessing device, 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 discloses prompting partially auto-filled report with a 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.
Henwood teaches
prompting a user to log a time of occurrence of the safety event, Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating the subject good condition (Henwood: [p. 26, line 11-12]).
Regarding Claim 5 (Original), Anthapur teaches the method of claim 1, wherein operating the module of the risk evaluator comprises:
operating a root-cause determiner module 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 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 sensor and the assessing device, 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 discloses prompting partially auto-filled report with a 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.
Henwood teaches
prompting a user to log a time of occurrence of the safety event, Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating the subject good condition (Henwood: [p. 26, line 11-12]).
Regarding Claim 6 (Original), Anthapur teaches the method of claim 1, wherein operating the module of the risk evaluator comprises:
operating a recommender module 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 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 sensor and the assessing device, 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 discloses prompting partially auto-filled report with a 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.
Henwood teaches
prompting a user to log a time of occurrence of the safety event, Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating the subject good condition (Henwood: [p. 26, line 11-12]).
Regarding Claim 8 (Original), the combination of Anthapur and Henwood teaches the method of claim 1, wherein operating the module of the risk evaluator comprises:
operating an AI predictor module comprising the steps of installing and connecting an AI system to the accessing device, 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 (Original), the combination of Anthapur and Henwood teaches the method of claim 1, wherein operating the module of the risk evaluator comprises:
operating an investigation trigger module 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 sensor and assessing device, 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 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 (Original), the combination of Anthapur and Henwood teaches the system of claim 13, wherein the risk evaluator further comprises a AI system, and wherein the risk evaluator is operable to implement a classifier module configured to access data about the patient from the assessing device 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 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 an 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]).
Regarding Claim 17 (Original), the combination of Anthapur and Henwood teaches the system of claim 13, wherein the risk evaluator further comprises a AI system, and wherein the risk evaluator is operable to implement a root-cause determiner module configured to access data about the patient from the assessing device 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 [root cause] (Anthapur: [Fig. 5A-C, 19], [0060], [0062-0065], [0089], [0107])
utilize an AI-based operation 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 an incident investigation report with the data Anthapur discloses an incident report partially filled with sensor data (Anthapur: [Fig. 15A-B]).
Regarding Claim 18 (Original), the combination of Anthapur and Henwood teaches the system of claim 13, wherein the risk evaluator further comprises an AI system, and wherein the risk evaluator is operable to implement a recommender module configured to access data about the patient from the assessing device 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 to determine a root-cause of the safety event, partially auto-fill an 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]).
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 (New), Anthapur 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 sensor or the assessing device 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 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.
Henwood teaches
prompting a user to log a time of occurrence of the safety event, Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating
the subject good condition (Henwood: [p. 26, line 11-12]).
Regarding Claim 22 (New), Anthapur 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 sensor and the assessing device, 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])
Henwood discloses prompting a user for safety response to log or provide information associated with safety response where the user response is to be entered within a predetermined time period and when entered it indicates the time of occurrence (Henwood: [p. 10, line 17-21], [p. 26, line 6-23], [p. 27, line 6-19], [p. 38, line 12-14]).
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 Henwood, which helps indicating the subject good condition (Henwood: [p. 26, line 11-12]).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Anthapur (US 2022/0230746 A1) in view of Henwood (CA 2781251 A1) in view of Bollish et al. (US 2005/0177096 Al- “Bollish”)
Regarding Claim 7 (Original), the combination of Anthapur and Henwood teaches the method of claim 6, wherein the AI-based operation is configured to access data from 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 14, the claim recites substantially similar limitations to claim 7 as such, is rejected for similar reasons as given above.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Anthapur (US 2022/0230746 A1) in view of Bollish et al. (US 2005/0177096 Al- “Bollish”)
Regarding Claim 12 (Currently Amended), Anthapur teaches the method of claim 10, wherein the accessing device comprises 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]).
Response to Amendment
Applicant's arguments filed 04/13/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. 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 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.
On page 10 of the remarks, Applicant argues “The Examiner has rejected claims 15-20 under 35 U.S.C. § 112(b), asserting that the claims are indefinite. The Examiner asserts that the claims contain limitations that are not described in the written description. Applicant respectfully disagrees”, Examiner disagrees to the Applicant remarks. Claims 15-20 were rejected for indefiniteness however in light of the claim’s amendment, claim 15 canceled, Examiner withdraws the 112(b)-indefiniteness rejection for claim 15-120.
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 “Claims 1, 10, and 13 do not recite a judicial exception ... Applicant asserts that the determination that the claims recite a judicial exception is flawed... 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, 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 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, 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 “Claims 1, 10, and 13 integrate any potential judicial exception into a practical application ... As amended, claims 1 and 13 integrate any potential judicial exception into a practical application because claim 1 recites the steps of "managing patient care based on the output ... the judicial exception is integrated into a practical application in the form of providing more efficient patient care and prevent health complications (see [0042]) ... 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. 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, by 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).
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 ... Such complex assessment cannot be made by the human mind. Such an application enhances patient treatment and provides efficient car”, 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.
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, Examiner withdraws the 102 rejections for claims 1, 8-9, 11, 13, and 15-20. As for the Applicant argument for claim 10 that “Anthapur does not describe the limitations recited in claim 10 ... Anthapur is silent to determining the root-cause of the safety event ... Anthapur does not teach using AI-based operation to determine both the root-cause of this change in activity and the level of patient harm...”, Examiner respectfully disagree. Anthapur in [0062] as an example, describes the factor or reason of alert for a fall incident and when then the incident is investigated, it determined the cause of the triggering the alert report which is associated with the resident change in behavior. This is one example for identifying factor(s) or root-cause of the safety event. Claim 10 rejection has been updated and the 102 rejection is maintained. Therefore. Applicant argument(s) is/are unpersuasive.
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”. It is clear that the combination of the references teaches the claim limitations and as argued above.
As such, Examiner finds that the applicant is addressing each reference individually to teach all the claim elements ignoring the fact that the Examiner rejection is based on nonobviousness 35 USC 103. Therefore, in response to applicant's arguments against the references individually, one cannot show nonobviousness by arguing references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413,208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Therefore, Examiner finds the Applicant argument unpersuasive.
Prior Art Cited but not Applied
The following document(s) were found relevant to the disclosure but not applied:
US 2015/0120311- “Mayer”- discloses patient safety event reporting including the identification, mitigation, and prevention of risks, hazards, and harms through a data-entry platform for preparing a report regarding a patient safety event.
US 2023/0370548 “KUCHARSKI” discloses capturing sensor data to detect an occurrence of a potential public-safety incident and further monitors whether a user operating the device has not reported the safety incident to an identified public-safety agency.
The references are relevant since it discloses monitoring and analyzing patient physiological parameters to indicate safety of patient care.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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
Prosecution Insights