DETAILED ACTION
The present office action represents a nonfinal 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-15 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.
Claim 13 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because there are no structural elements in the claims.
Claim 13 claims computer program code (software), however, fails to claim the necessary hardware. Pursuant to MPEP 2106.03, a machine is a "concrete thing, consisting of parts, or of certain devices and combination of devices." Digitech, 758 F.3d at 1348-49, 111 USPQ2d at 1719 (quoting Burr v. Duryee, 68 U.S. 531, 570, 17 L. Ed. 650, 657 (1863)). This category "includes every mechanical device or combination of mechanical powers and devices to perform some function and produce a certain effect or result." Nuijten, 500 F.3d at 1355, 84 USPQ2d at 1501 (quoting Corning v. Burden, 56 U.S. 252, 267, 14 L. Ed. 683, 690 (1854)). Here, the claims recite “computer program code” but fail to disclose any structural element, no computer or device is claimed, and therefore, can be construed as software per se, which is non-statutory.
Claims 1-15 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-15 is 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;
responsive to the availability status indicating that the identified clinical staff member is unavailable to attend to the alarm event:
generating an alarm event summary comprising information relating to the detected alarm event; and
communicating the alarm event summary to the identified clinical staff member using a user output subsystem.
Claim 13 recites 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-15 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 clinical staff member;
responsive to the availability status indicating that the identified clinical staff member is unavailable to attend to the alarm event:
generate an alarm event summary comprising information relating to the detected alarm event; and
communicate the alarm event summary to the identified clinical staff member using a user output subsystem.
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 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 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-15 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-15 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.);
responsive to the availability status indicating that the identified 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.):
generating an alarm event summary comprising information relating to the detected alarm event (Paragraphs [0069] and [0076] discuss alerts can be generated and details related to the alert generated in an alert message.); and
communicating the alarm event summary to the identified clinical staff member using a user output subsystem (Paragraphs [0012] and [0031] discuss detection of an alarm state or other issue associated with the patient can result in one or more components of the system issuing an alert to one or more caregivers regarding a current status of a patient, for example, a patient worn sensor can monitor ECG readings and if the readings are outside of an acceptable range for the patient, 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.).
Regarding claim 2, Mazar discloses wherein the method comprises determining an availability status indicating that the clinical staff member is available to attend to the alarm event when the 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 clinical staff member is unavailable to attend to the alarm event when the 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 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
wherein, responsive to detecting non-response to the alarm event, the method further comprises generating an alarm event summary for the alarm event and communicating the alarm event summary to the identified clinical staff member using a user output subsystem (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 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, generating an alarm event summary for the alarm event (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 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, generating an alarm event summary for the alarm event (Paragraphs [0011] and [0159] discuss the user interface can include user input and information on how the alarm states were resolved, and status of the patient after the alarm states were resolved.).
Regarding claim 7, Mazar discloses wherein the user output subsystem includes at least one mobile device associated with the identified clinical staff member assigned to the patient (Paragraph [0053] discusses alerts can be sent to caregivers through mobile devices carried or worn by the caregivers.); and
wherein communicating the alarm event summary to the identified clinical staff member comprises communicating the alarm event summary to the at least one mobile device by means of a mobile communication interface (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.).
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 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 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 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 clinical staff member is engaged in the care of a patient, and determining the availability status of the clinical staff member as being indicative of unavailability to attend to the alarm event when the 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 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 (Paragraphs [0019] and [0252] discuss a method and a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor.).
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 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.);
responsive to the availability status indicating that the identified 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.):
generate an alarm event summary comprising information relating to the detected alarm event (Paragraphs [0069] and [0076] discuss alerts can be generated and details related to the alert generated in an alert message.); and
communicate the alarm event summary to the identified clinical staff member using a user output subsystem (Paragraphs [0012] and [0031] discuss detection of an alarm state or other issue associated with the patient can result in one or more components of the system issuing an alert to one or more caregivers regarding a current status of a patient, for example, a patient worn sensor can monitor ECG readings and if the readings are outside of an acceptable range for the patient, 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.).
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.).
Conclusion
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