DETAILED ACTION
The present office action represents a final action on the merits.
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 .
Priority
This application claims the priority date of a provisional application 63/562,990 dated March 8, 2024.
Status of Claims
Claims 1-14 are amended, claims 16-20 are new, and claims 1-20 are pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-12 are drawn to a method for managing alarm events associated with each of one or more patients, which is within the four statutory categories (i.e., process). Claim 13 is drawn to a computer program product comprising computer program code, which is not within the four statutory categories (i.e., software per se); the claims may fall within a statutory category once amended by Applicant. Claims 14-20 are drawn to a processing device for managing alarm events associated with each of one or more patients, which is within the four statutory categories (i.e., machine).
Claim 1 recites a method for managing alarm events associated with each of one or more patients, wherein each of the one or more of patients is assigned to at least one clinical staff member, comprising:
detecting occurrence of an alarm event associated with a clinical status of a patient using a patient information system;
identifying at least one clinical staff member assigned to the patient;
detecting a current location of the identified at least one clinical staff member using data from a position tracking system, the position tracking system configured to track a location of the at least one clinical staff member;
determining an availability status of the identified at least one clinical staff member based at least in part on the location of the identified clinical staff member; and
communicating information relating to the detected alarm event to the identified at least one clinical staff member using a user output subsystem, wherein the user output subsystem includes:
a first output channel permitting communication of information related to an alarm event in real time with occurrence of the alarm event; and
a second output channel permitting communication of information related to an alarm event at a time subsequent to occurrence of the alarm event;
wherein the communicating the information relating to the detected alarm event comprises:
selectively outputting the information to the identified at least one clinical staff member by means of the first output channel responsive to the availability status indicating that the identified at least one clinical staff member is available to attend to the alarm event; and
outputting the information to the identified at least one clinical staff member by means of the second output channel responsive to the availability status indicating that the identified at least one clinical staff member is unavailable to attend to the alarm event.
Claim 13 recites a non-transitory storage medium comprising a computer program product comprising computer program code configured, when executed by a processor, to cause the processor to perform a method in accordance with claims 1.
Claims 14-20 recite a processing device for managing alarm events associated with each of one or more patients, wherein each of the one or more patients is assigned to at least one clinical staff member, the processing device comprising:
one or more processors; and
a communication module;
wherein the communication module is communicatively coupled with:
a position tracking system configured to track a location of the at least one clinical staff member; and
a patient information system configured to detect alarm events associated with a clinical status of each of the one or more patients;
wherein the one or more processors are configured to:
detect occurrence of an alarm event associated with a patient using the patient information system;
identify at least one clinical staff member assigned to the patient;
determine an availability status of the identified at least one clinical staff member based at least in part on the location of the identified at least one clinical staff member; and
communicate information relating to the detected alarm event to the identified at least one clinical staff member using a user output subsystem, wherein the user output subsystem includes:
a first output channel permitting communication of information related to an alarm event in real time with occurrence of the alarm event; and
a second output channel permitting communication of information related to an alarm event at a time subsequent to occurrence of the alarm event;
wherein the communicating the information relating to the detected alarm event comprises selectively outputting the information to the identified at least one clinical staff member by means of the first output channel responsive to the availability status indicating that the identified at least one clinical staff member is available to attend to the alarm event, and outputting the information to the identified at least one clinical staff member by means of the second output channel responsive to the availability status indicating that the identified at least one clinical staff member is unavailable to attend to the alarm event.
The bolded limitations, given the broadest reasonable interpretation, cover a certain method of organizing human activity (e.g., gathering patient information; managing patient information, in this case clinical event management.). The underlined limitations are not part of the identified abstract idea (the method of organizing human activity) and are deemed “additional elements,” and will be discussed in further detail below.
Dependent claims 2-12 and 15-20 are similarly rejected because they either further define/narrow the abstract idea and/or do not further limit the claim to a practical application or provide an inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination.
The dependent claims include additional limitations but these only serve to further limit the abstract idea, and hence are nonetheless directed towards fundamentally the same abstract idea as independent claims 1, 13, and 14.
The additional elements from claims 1 and 14 include:
a patient information system (apply it, MPEP 2106.05(f)).
a position tracking system (apply it, MPEP 2106.05(f)).
a user output subsystem (apply it, MPEP 2106.05(f)).
The additional elements from claim 13 include:
a computer program product comprising computer program code configured, when executed by a processor (apply it, MPEP 2106.05(f)).
The additional elements from claim 14 include:
a processing device (apply it, MPEP 2106.05(f)).
one or more processor (apply it, MPEP 2106.05(f)).
a communication module (apply it, MPEP 2106.05(f)).
The dependent claims contain additional elements including:
a user input channel (apply it, MPEP 2106.05(f)).
at least one mobile device (apply it, MPEP 2106.05(f)).
Claims 1-15 are not integrated into a practical application because the additional elements (i.e., the limitations not identified as part of the abstract idea) amount to no more than limitations which:
amount to mere instructions to apply an exception – for example, the recitation of “a patient information system”, “a position tracking system”, “a user output subsystem”, “a computer program product comprising computer program code configured, when executed by a processor”, “a processing device”, “one or more processor”, “a communication module”, “a user input channel”, “at least one mobile device”, which amounts to merely invoking a computer as a tool to perform the abstract idea e.g. see Specification Pages 15-17, 19, and 21 (see MPEP 2106.05(f));
Furthermore, the claims do not include additional elements that are sufficient to amount to “significantly more” than the judicial exception because, the additional elements (i.e., the elements other than the abstract idea) amount to no more than limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrated by:
The Specification discloses that the additional elements are well-understood, routine, and conventional in nature (i.e., Pages 15-17, 19, and 21 of the Specification discloses that the additional elements (i.e., a patient information system, a position tracking system, a user output subsystem, a computer program product comprising computer program code configured, when executed by a processor, a processing device, one or more processor, a communication module, a user input channel, at least one mobile device) comprise a plurality of different types of generic computing systems that are configured to perform generic computer functions that are well understood routine, and conventional activities previously known to the pertinent industry (i.e., healthcare);
Relevant court decisions: The following are examples of court decisions demonstrating well-understood, routine and conventional activities, e.g. MPEP 2106.05(d)(II):
Receiving or transmitting data over a network, e.g. see Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); – similarly, the current invention acquires patient and clinical staff member data.
Dependent claims 2-12 and 15-20 include other limitations, but none of these functions are deemed significantly more than the abstract idea because the additional elements recited in the aforementioned dependent claims similarly represent no more than those found in the independent claims.
Thus, taken alone, the additional elements do not amount to “significantly more” than the above identified abstract idea. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves a medication information management system, management control device, terminal device, management method, and program storage medium for medication information or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, claims 1-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mazar (U.S. Pub. No. 2015/0302539 A1).
Regarding claim 1, Mazar discloses a method for managing alarm events associated with each of one or more patients, wherein each of the one or more of patients is assigned to at least one clinical staff member, comprising (Paragraphs [0009], [0012], and [0145] discuss a management system for patients that allow healthcare professionals to view the most important data for a number of patients in varying locations, to provide alerts regarding a current status of a patient assigned to one or more caregivers.):
detecting occurrence of an alarm event associated with a clinical status of a patient using a patient information system (Paragraph [0012] discusses provide alerts regarding a current status of a patient to one or more caregivers, for example, a patient worn sensor can monitor ECG readings and heart rate for a patient and analyze this information to determine if the ECG readings and heart rate are within a specified acceptable range, the monitor can send an alert to one or more caregivers to inform the caregivers that an emergency situation associated with the patient (such as, for example, cardiac arrest) is occurring.);
identifying at least one clinical staff member assigned to the patient system (Paragraphs [0012] and [0145] discuss provide alerts regarding a current status of a patient assigned to one or more caregivers.);
detecting a current location of the identified at least one clinical staff member using data from a position tracking system, the position tracking system configured to track a location of the at least one clinical staff member (Paragraphs [0052], [0063]-[0065], [0068], [0162]-[0164], and [0179] discuss caregiver can monitor a patient from a remote location, an urgent alert to a nurse located within a close proximity to the patient, for example, the user can be an attending physician that makes rounds and carries the mobile device and as the physician moves from room to room, location identification functionality of the mobile device (e.g., a GPS unit, RF triangulation unit, or other location detection unit) continually identifies the changing location of the mobile device.));
determining an availability status of the identified at least one clinical staff member based at least in part on the location of the identified clinical staff member (Paragraphs [0068] and [0229] discuss identify doctors and caregivers are available, for example, if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.); and
communicating information relating to the detected alarm event to the identified at least one clinical staff member using a user output subsystem, wherein the user output subsystem includes (Paragraph [0039] discusses communicating through a network, for example, a chest sensor can transmit a distress signal to a computer located at a nursing station. The nursing station can then indicate to a caregiver that the patient has initiated a distress call.):
a first output channel (Examiner notes that the prior art does not expressly state “first output channel” or “second output channel” however, the prior art includes communications through various methods and networks.) permitting communication of information related to an alarm event in real time with occurrence of the alarm event (Paragraph [0039] discuss communicate a distress signal to a bedside monitor, or to another computing device using wireless communications and/or by communicating through a network. For example, when the patient presses the button, the chest sensor can transmit a distress signal to a computer located at a nursing station.); and
a second output channel permitting communication of information related to an alarm event at a time subsequent to occurrence of the alarm event (Paragraphs [0039]–[0040] discuss information related to the distress call can be recorded and stored along with an indication of a time when the distress call was made, and vital sign and other information for the patient at the time of the distress call and audio recording (e.g., that includes the patient reciting symptoms) can be recorded along with a time stamp of when the recording was made and stored in computer memory of the chest sensor and/or another computing device in communication with the chest sensor, can be used by one or more caregivers in diagnosing the patient.);
wherein the communicating the information relating to the detected alarm event comprises:
selectively outputting the information to the identified at least one clinical staff member by means of the first output channel responsive to the availability status indicating that the identified at least one clinical staff member is available to attend to the alarm event (Paragraphs [0068] and [0229] discuss the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.); and
outputting the information to the identified at least one clinical staff member by means of the second output channel responsive to the availability status indicating that the identified at least one clinical staff member is unavailable to attend to the alarm event (Paragraphs [0068] and [0229] discuss if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.).
Regarding claim 2, Mazar discloses wherein the method comprises determining an availability status indicating that the identified at least one clinical staff member is available to attend to the alarm event when the identified at least one clinical staff member is located in at least one predetermined area associated with clinical availability (Paragraphs [0048] and [0068] discuss alerts regarding particular patient alarm states can be routed based on a number of factors, including proximity of caregivers to the patient, or current status of caregivers, for example, if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.).
Regarding claims 3, Mazar discloses wherein the method comprises determining an availability status indicating that the identified at least one clinical staff member is unavailable to attend to the alarm event when the identified at least one clinical staff member is located in at least one predetermined area associated with clinical unavailability (Paragraphs [0048] and [0068] discuss alerts regarding particular patient alarm states can be routed based on a number of factors, including proximity of caregivers to the patient, or current status of caregivers, for example, if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.).
Regarding claim 4, Mazar discloses wherein the user output subsystem further comprises a user input channel permitting a user to input a response to an alarm event (Paragraphs [0011], [0035], [0067], and [0113] discuss alerts can be sent to elicit a caregiver response, a note or message can be addressed to the attention of one or more other caregivers, for example, a nurse can use the bedside monitor to indicate that the alarm state has been addressed and resolved.);
wherein the method comprises detecting non-response of the identified at least one clinical staff member to an alarm event (Paragraph [0066] discusses if the central server determines that no one has responded to the alarm state within a specified period of time, it can identify a second set of caregivers to inform about the alarm state and transmit alerts to the second set of caregivers.); and
responsive to detecting non-response to the alarm event, outputting the information relating to the detected alarm event by means of the second output channel (Paragraph [0066] discusses if a particular alarm state for the patient is not addressed within a specified period of time, the system can escalate alerts that are issued by the system, the central server can identify a first set of caregivers to alert to the alarm situation, sending alerts to mobile devices of each of the first set of caregivers, or by sending alerts to bedside monitors or stations at which caregivers are located.).
Regarding claim 5, Mazar discloses wherein the user output subsystem further comprises a user input channel permitting a user to input a response to an alarm event (Paragraphs [0115], [0149]-[0150], and [0158]-[0159] discuss input device used by the user, if an alarm state for a particular patient is detected, the user interface can alert a user of the display by causing a panel associated with a patient experiencing the alarm state to start flashing, change color, become enlarged, or otherwise visually indicate an alarm state, the nurse can then select the control to view information for the alert that can allow the nurse to respond to the alert.);
wherein the method comprises:
detecting an input by the identified at least one clinical staff member at the user input channel indicating current unavailability to attend to the alarm event (Paragraphs [0133] and [0158]-[0159] discuss on a display, the nurse can select the control to view information for the alert that can allow the nurse to respond to the alert, if the caregiver is unable to properly address the alarm state, the caregiver can use the alert control to un-pause the alert, which can lead the system to escalate alerts for the alarm state and notify one or more additional caregivers of the alarm state.), and
responsive to detecting said input, outputting the information relating to the detected alarm event by means of the second output channel (Paragraph [0159] discusses the user interface includes a control for accessing alerts, for example, the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week) or alerts associated with multiple patients, allow the user to access information on patient alarm states that prompted each alert, information that allowed the system to identify the alarm state, how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Regarding claim 6, Mazar discloses wherein the user output subsystem further comprises a user input channel permitting a user to input a response to an alarm event (Paragraphs [0067] and [0158]-[0159] discuss on a display, the nurse can select the control to view information for the alert that can allow the nurse to respond to the alert.);
wherein the method comprises:
detecting an input by the identified at least one clinical staff member at the user input channel indicative of a delegation instruction (Paragraphs [0011] and [0064] discuss the system can send an alert to a nurse within close proximity to the patient indicating that the patient is vomiting, potential reasons why the patient is vomiting, and recommended steps to deal with the situation, a nurse can make a note that a patient had a particular reaction after taking medication and set the note to the attention of a pharmacist responsible for care of the patient and receive an alert that a new note has been addressed to his attention, review the note, and review other information associated with the patient to best determine if a change to the patient's medication schedule needs to be made.), and
responsive to detecting said input, outputting the information relating to the detected alarm event by means of the second output channel (Paragraph [0159] discusses the user interface includes a control for accessing alerts, for example, the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week) or alerts associated with multiple patients, allow the user to access information on patient alarm states that prompted each alert, information that allowed the system to identify the alarm state, how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Regarding claim 7, Mazar discloses wherein the output of information relating to the detected alarm event by means of the second output channel comprises (Paragraph [0053] discusses alerts can be sent to caregivers through mobile devices carried or worn by the caregivers.):
generating an alarm event summary associated with the detected alarm event, the alarm event summary comprising information relating to the detected alarm event (Paragraphs [0053] and [0171]-[0172] discuss patient events and alerts and the caregiver can access the patient newsfeed of events using caregiving network functionality of the system that is accessible using the mobile device.); and
communicating the alarm event summary to the identified at least one clinical staff member (Paragraphs [0053], [0102]-[0103], [0140], and [0171]-[0172] discuss patient events and alerts and the caregiver can access the patient newsfeed of events using caregiving network functionality of the system that is accessible using the mobile device, nurse/doctor can obtain patient history of alarms, user interface can also include a listing of past alarm states for the patient and information related to each alarm state.).
Regarding claim 8, Mazar discloses wherein the alarm event summary includes information relating to clinical actions taken to resolve the alarm event, and optionally includes information relating to one or more required clinical actions (Paragraph [0159] discusses the user interface includes a control for accessing alerts, for example, an alert screen whereby the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week) or alerts associated with multiple patients, allow the user to access information on patient alarm states that prompted each alert, information that allowed the system to identify the alarm state, how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Regarding claim 9, Mazar discloses wherein the alarm event summary includes information relating to a clinical status of the patient at a time of generating the alarm event summary and/or information relating to a clinical status of the patient at a time of communicating the alarm event summary to the identified at least one clinical staff member (Paragraph [0159] discusses the user interface includes a control for accessing alerts, for example, an alert screen whereby the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week) or alerts associated with multiple patients, allow the user to access information on patient alarm states that prompted each alert, information that allowed the system to identify the alarm state, how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Regarding claim 10, Mazar discloses wherein the method comprises detecting multiple alarm events for a same patient during a period when the availability status of the identified at least one clinical staff member assigned to the patient indicates that the identified at least one clinical staff member is unavailable (Paragraphs [0133] and [0159] discuss the user interface includes a control for accessing alerts, for example, an alert screen whereby the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week), if the caregiver is unable to properly address the alarm state, the caregiver can use the alert control to un-pause the alert, which can lead the system to escalate alerts for the alarm state and notify one or more additional caregivers of the alarm state.); and
generating a consolidated alarm event summary for the multiple alarm events (Paragraphs [0096] and [0159] discuss the patient news feed can be displayed, for example, as part of a visual representation of the patient profile and the user interface includes a control for accessing alerts, for example, an alert screen whereby the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week).
Regarding claim 11, Mazar discloses further comprising:
detecting that the identified at least one clinical staff member has entered a predetermined area using data from the position tracking system (Paragraphs [0018], [0048], [0053], [0179] discuss an alert can be sent to one or more caregivers within a predetermined proximity of the patient; the physician carries the mobile device, location identification functionality of the mobile device (e.g., a GPS unit, RF triangulation unit, or other location detection unit) continually identifies the changing location of the mobile device, and update the patient newsfeed to bring information for one or more patients located in or associated with the room in which the physician is currently located.); and
communicating the alarm event summary to the identified at least one clinical staff member in response to detecting that the clinical staff member has entered the predetermined area (Paragraph [0179] discusses the physician carries the mobile device, location identification functionality of the mobile device (e.g., a GPS unit, RF triangulation unit, or other location detection unit) continually identifies the changing location of the mobile device, and update the patient newsfeed to bring information for one or more patients located in or associated with the room in which the physician is currently located.).
Regarding claim 12, Mazar discloses wherein the method comprises determining, using data from the position tracking system, when the identified at least one clinical staff member is engaged in the care of a patient, and determining the availability status of the identified at least one clinical staff member as being indicative of unavailability to attend to the alarm event when the identified at least one clinical staff member is engaged in the care of another patient (Paragraphs [0068] and [0179] discuss the physician carries the mobile device, location identification functionality of the mobile device (e.g., a GPS unit, RF triangulation unit, or other location detection unit) continually identifies the changing location of the mobile device, and update the patient newsfeed to bring information for one or more patients located in or associated with the room in which the physician is currently located; if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other.).
Regarding claim 13, Mazar discloses a non-transitory storage medium comprising a computer program product comprising computer program code configured, when executed by a processor, to cause the processor to perform a method in accordance with claims 1 (Claim 11 discusses a non-transitory computer readable storage medium encoded with a computer program, the program comprising instructions that when executed by one or more data processing apparatus cause the one or more data processing apparatus to perform operations comprising.).
Regarding claim 14, Mazar discloses a processing device for managing alarm events associated with each of one or more patients, wherein each of the one or more patients is assigned to at least one clinical staff member, the processing device comprising (Paragraphs [0009], [0012], and [0033] discuss a management system and electronics for processing for patients that allow healthcare professionals to view the most important data for a number of patients in varying locations, to provide alerts regarding a current status of a patient to one or more caregivers.):
one or more processors (Paragraph [0253] discusses one or more processors.); and
a communication module (Paragraph [0253] discusses a computer coupled to communicate with devices.);
wherein the communication module is communicatively coupled with module (Paragraph [0253] discusses a computer coupled to communicate with devices.):
a position tracking system configured to track a location of the at least one clinical staff member (Paragraph [0179] discusses the physician carries the mobile device, location identification functionality of the mobile device (e.g., a GPS unit, RF triangulation unit, or other location detection unit) continually identifies the changing location of the mobile device.); and
a patient information system configured to detect alarm events associated with a clinical status of each of the one or more patients (Paragraph [0012] discusses the system can provide alerts regarding a current status of a patient to one or more caregivers.);
wherein the one or more processors are configured to (Paragraphs [0252]-[0253] discuss processors for executing instructions.):
detect occurrence of an alarm event associated with a patient using the patient information system (Paragraph [0012] discusses provide alerts regarding a current status of a patient to one or more caregivers, for example, a patient worn sensor can monitor ECG readings and heart rate for a patient and analyze this information to determine if the ECG readings and heart rate are within a specified acceptable range, the monitor can send an alert to one or more caregivers to inform the caregivers that an emergency situation associated with the patient (such as, for example, cardiac arrest) is occurring.);
identify at least one clinical staff member assigned to the patient (Paragraphs [0012] and [0145] discuss provide alerts regarding a current status of a patient assigned to one or more caregivers.);
determine an availability status of the identified at least one clinical staff member based at least in part on the location of the identified at least one clinical staff member (Paragraphs [0068] and [0229] discuss identify doctors and caregivers are available, for example, if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.); and
communicate information relating to the detected alarm event to the identified at least one clinical staff member using a user output subsystem, wherein the user output subsystem includes (Paragraph [0039] discusses communicating through a network, for example, a chest sensor can transmit a distress signal to a computer located at a nursing station. The nursing station can then indicate to a caregiver that the patient has initiated a distress call.):
a first output channel permitting communication of information related to an alarm event in real time with occurrence of the alarm event (Paragraph [0039] discuss communicate a distress signal to a bedside monitor, or to another computing device using wireless communications and/or by communicating through a network. For example, when the patient presses the button, the chest sensor can transmit a distress signal to a computer located at a nursing station.); and
a second output channel permitting communication of information related to an alarm event at a time subsequent to occurrence of the alarm event (Paragraphs [0039]–[0040] discuss information related to the distress call can be recorded and stored along with an indication of a time when the distress call was made, and vital sign and other information for the patient at the time of the distress call and audio recording (e.g., that includes the patient reciting symptoms) can be recorded along with a time stamp of when the recording was made and stored in computer memory of the chest sensor and/or another computing device in communication with the chest sensor, can be used by one or more caregivers in diagnosing the patient.);
wherein the communicating the information relating to the detected alarm event comprises selectively outputting the information to the identified at least one clinical staff member by means of the first output channel responsive to the availability status indicating that the identified at least one clinical staff member is available to attend to the alarm event (Paragraphs [0068] and [0229] discuss the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.), and
outputting the information to the identified at least one clinical staff member by means of the second output channel responsive to the availability status indicating that the identified at least one clinical staff member is unavailable to attend to the alarm event (Paragraphs [0068] and [0229] discuss if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore unavailable to respond to the alarm state associated with the second patient and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.).
Regarding claim 15, Mazar discloses a system for managing alarm events associated with each of one or more patients, wherein each of the one or more patients is assigned to at least one clinical staff member, comprising (Paragraphs [0009], [0012], and [0145] discuss a management system for patients that allow healthcare professionals to view the most important data for a number of patients in varying locations, to provide alerts regarding a current status of a patient assigned to one or more caregivers.):
a position tracking system configured to track a location of the at least one clinical staff member (Paragraph [0179] discusses the physician carries the mobile device, location identification functionality of the mobile device (e.g., a GPS unit, RF triangulation unit, or other location detection unit) continually identifies the changing location of the mobile device.);
a patient information system configured to detect alarm events associated with a clinical status of each of the one or more patients (Paragraph [0012] discusses provide alerts regarding a current status of a patient to one or more caregivers, for example, a patient worn sensor can monitor ECG readings and heart rate for a patient and analyze this information to determine if the ECG readings and heart rate are within a specified acceptable range, the monitor can send an alert to one or more caregivers to inform the caregivers that an emergency situation associated with the patient (such as, for example, cardiac arrest) is occurring.); and
a processing device as claimed in claim 14 (Paragraph [0033] discusses electronics for processing.).
Regarding claim 16, Mazar discloses wherein determining an availability status by the one or more processors comprises determining an availability status indicating that the identified at least one clinical staff member is available to attend to the alarm event when the identified at least one clinical staff member is located in at least one predetermined area associated with clinical availability (Paragraphs [0048] and [0068] discuss alerts regarding particular patient alarm states can be routed based on a number of factors, including proximity of caregivers to the patient, or current status of caregivers, for example, if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.).
Regarding claim 17, Mazar discloses wherein determining an availability status by the one or more processors comprises determining an availability status indicating that the identified at least one clinical staff member is unavailable to attend to the alarm event when the identified at least one clinical staff member is located in at least one predetermined area associated with clinical unavailability (Paragraphs [0048], [0068], and [0252]-[0253] discuss the steps are performed by a processor and the alerts regarding particular patient alarm states can be routed based on a number of factors, including proximity of caregivers to the patient, or current status of caregivers, for example, if a first doctor is currently involved in responding to an emergency situation for a first patient, if an alarm state occurs for a second patient near the first doctor, the system can determine that the first doctor is already engaged and therefore and identify one or more other caregivers that can potentially respond to the alarm state for the second patient and send alerts to these other caregivers.).
Regarding claim 18, Mazar discloses wherein the user output subsystem further comprises a user input channel permitting a user to input a response to an alarm event, and wherein the one or more processors is further configured to (Paragraphs [0011], [0035], [0067], [0113], and [0252]-[0253] discuss the steps are performed by a processor and alerts can be sent to elicit a caregiver response, a note or message can be addressed to the attention of one or more other caregivers, for example, a nurse can use the bedside monitor to indicate that the alarm state has been addressed and resolved.):
detect non-response of the identified at least one clinical staff member to an alarm event (Paragraph [0066] discusses if the central server determines that no one has responded to the alarm state within a specified period of time, it can identify a second set of caregivers to inform about the alarm state and transmit alerts to the second set of caregivers.); and
output, responsive to detecting non-response to the alarm event, the information relating to the detected alarm event by means of the second output channel (Paragraph [0066] discusses if a particular alarm state for the patient is not addressed within a specified period of time, the system can escalate alerts that are issued by the system, the central server can identify a first set of caregivers to alert to the alarm situation, sending alerts to mobile devices of each of the first set of caregivers, or by sending alerts to bedside monitors or stations at which caregivers are located.).
Regarding claim 19, Mazar discloses wherein the user output subsystem further comprises a user input channel permitting a user to input a response to an alarm event, and wherein the one or more processors is further configured to (Paragraphs [0115], [0149]-[0150], [0158]-[0159], and [0252]-[0253] discuss the steps are performed by a processor and an input device used by the user, if an alarm state for a particular patient is detected, the user interface can alert a user of the display by causing a panel associated with a patient experiencing the alarm state to start flashing, change color, become enlarged, or otherwise visually indicate an alarm state, the nurse can then select the control to view information for the alert that can allow the nurse to respond to the alert.):
detect an input by the identified at least one clinical staff member at the user input channel indicating current unavailability to attend to the alarm event (Paragraphs [0133] and [0158]-[0159] discuss on a display, the nurse can select the control to view information for the alert that can allow the nurse to respond to the alert, if the caregiver is unable to properly address the alarm state, the caregiver can use the alert control to un-pause the alert, which can lead the system to escalate alerts for the alarm state and notify one or more additional caregivers of the alarm state.); and
output, responsive to detecting said input, the information relating to the detected alarm event by means of the second output channel (Paragraph [0159] discusses the user interface includes a control for accessing alerts, for example, the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week) or alerts associated with multiple patients, allow the user to access information on patient alarm states that prompted each alert, information that allowed the system to identify the alarm state, how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Regarding claim 20, Mazar discloses wherein the user output subsystem further comprises a user input channel permitting a user to input a response to an alarm event, and wherein the one or more processors is further configured to (Paragraphs [0067] and [0158]-[0159] discuss on a display, the nurse can select the control to view information for the alert that can allow the nurse to respond to the alert.):
detect an input by the identified at least one clinical staff member at the user input channel indicative of a delegation instruction (Paragraphs [0011] and [0064] discuss the system can send an alert to a nurse within close proximity to the patient indicating that the patient is vomiting, potential reasons why the patient is vomiting, and recommended steps to deal with the situation, a nurse can make a note that a patient had a particular reaction after taking medication and set the note to the attention of a pharmacist responsible for care of the patient and receive an alert that a new note has been addressed to his attention, review the note, and review other information associated with the patient to best determine if a change to the patient's medication schedule needs to be made.); and
output, responsive to detecting said input, the information relating to the detected alarm event by means of the second output channel (Paragraph [0159] discusses the user interface includes a control for accessing alerts, for example, the user can select the control to cause the mobile device to display current alerts for the patient, past alerts for the patient, alerts that occurred within a specified time frame (e.g., the past week) or alerts associated with multiple patients, allow the user to access information on patient alarm states that prompted each alert, information that allowed the system to identify the alarm state, how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Response to Arguments
Applicant’s arguments filed July 15, 2026 have been fully considered.
Rejections under 35 U.S.C. 101:
Examiner withdraws the 35 U.S.C. 101 rejection, with respect to claim 13 for failure to claim the necessary hardware in light of Applicant’s amendment.
Rejections under 35 U.S.C. 101:
Prong 1 Step 2A
With respect to claim 1 and the Prong 1 35 U.S.C. 101 rejection, Applicant’s amendment fails to overcome the previous rejection. Claim 1 as amended recites an abstract idea, a method of organizing human activity. See MPEP 2106.04(a)(2)(II)(C) Managing Personal Behavior or Relationships or Interactions Between People. Applicant states, “the present claims recite steps that are not instructions to a human being to follow when managing and communicating alarm events associated with each of one or more patients. For example, among other things, a human being does not "follow[] rules or instructions" in order to "detect a current location of the identified at least one clinical staff member using data from a position tracking system, the position tracking system configured to track a location of the at least one clinical staff member." Indeed, a human being cannot detect a current location of the identified at least one clinical staff member using data from a position tracking system. Further, a human being does not "follow[] rules or instructions" in order to selectively "communicat[e] information relating to the detected alarm event to the identified at least one clinical staff member using a user output subsystem" using "a first output channel permitting communication of information related to an alarm event in real time with occurrence of the alarm event" or "a second output channel permitting communication of information related to an alarm event at a time subsequent to occurrence of the alarm event.".” (Remarks, page 12). Examiner respectfully disagrees. Here, the application is managing alarm events for patients, communicating information relating to the detected alarm. Applicant further states, “Applicant has compared the present claims to the only provided examples (i.e., In re Marco Guldenaar Holding B. V., In re Brown, and Bilski v. Kappos identified by the Patent Office), to show how the present claims are unlike these examples of "following rules or instructions" by a human being.” (Remarks, page 13). Examiner respectfully disagrees. The examples cited by Applicant are distinguishable from the present Application. A human being could manage and report an alarm event and the improvement is to the abstract idea. Applicant states, “Applicant respectfully notes that it cannot be reasonably debated that were claim 15 written as follows, under no logical interpretation could the claim be rejected under 35 U.S.C. § 101... That this physical system is configured to do something does not make that device any less physical; it does not transform a physical device into a non-physical device, nor into an abstract idea. It is indisputable that the claimed system is a physical system comprising all of the components enumerated above, regardless of the functionality of that system.” (Remarks, pages 14-15). Examiner respectfully disagrees. Here, there is no improvement to the functioning of any of the additional elements or any physical device. Applicant recites several Examples from the PTO, however, these examples are all distinguishable from the present Application. In Example 20, the sensor data is used to adjust the velocity of the end effector – here, the Application provides for a method for managing alarm events associated with each of one or more, wherein each of the one or more patients is assigned to at least one clinical staff member and nothing is being adjusted as a result of managing the alarm. The improvement is to the abstract idea.
Step 2A, Prong 2
While practical application is a way to overcome the Prong 2 35 U.S.C. 101 rejection, claim 1 as written fails to result in a practical application. Applicant states, “The specification explains that inpatient healthcare units such as ICUs may generate frequent alarms, leading to alarm fatigue, missed notifications, unnecessary interruptions, and the need for a healthcare worker to manually check symptoms, clinical records, or colleagues to understand what occurred while the worker was unavailable. The claimed solution addresses that technical alarm-delivery problem by using patient-monitoring information, staff-location information, and a user output subsystem having two different output channels. In particular, the system provides a first channel for real-time alarm-event information when the assigned staff member is available and a second channel for communicating alarm-event information at a later time when the assigned staff member is unavailable.” (Remarks, page 17). Examiner respectfully disagrees. Here, the application is organizing human activity, directed to the abstract idea of alarm management and prioritizing and responding to multiple simultaneous or closely timed alerts, The additional elements in claim 1 include a patient information system, a position tracking system, a processing device, one or more processors, a communication module, a user output subsystem, etc., however, they do not result in a practical application as they are recited at an apply it level, as stated above. Here, managing alarms is not a technical problem.
Applicant states, “the claimed combination applies patient-monitoring data, staff-location data, and a two-channel output subsystem to adapt how alarm-event information is technically delivered in a clinical alarm system. The specification explains that the disclosed methods and systems provide more efficient output of patient alarm-related information, including by contextually adapting the mode or method of output based at least in part on the current location of the relevant healthcare worker.” (Remarks, page 19). Examiner respectfully disagrees. Here, it is unclear how the limitations improve an existing technological process. All components in the claims are being used for their intended purpose and as written do not result in a practical application or significantly more than the abstract idea. For the reasons stated above, claim similarly fails to overcome the 35 U.S.C. 101 rejection.
Rejections under 35 U.S.C. 102
With respect to claim 1 and the 35 U.S.C. 102 rejection, Applicant’s amendment overcomes the previous 35 U.S.C. 102 rejection. Applicant states, “Mazar fails to describe or suggest this selective availability-based channel-selection feature.” (Remarks, page 21). Examiner notes that the prior art does not expressly state “channel”, however, the prior art includes communications through various methods and networks, Paragraph [0039] discusses communicate a distress signal to a bedside monitor, or to another computing device using wireless communications and/or by communicating through a network. Applicant’s arguments with respect to claim 1 have been considered and the Examiner’s rejection has been updated to address Applicant’s claim amendments. Similarly, Examiner’s rejection related to claim 14 has been amended.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAWN TRINAH HAYNES whose telephone number is (571)270-5994. The examiner can normally be reached M-F 7:30-5:15PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jason Dunham can be reached on (571)272-8109. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DAWN T. HAYNES/
Art Unit 3686
/RACHELLE L REICHERT/Primary Examiner, Art Unit 3686
Prosecution Insights