DETAILED ACTION
This is responsive to RCE filed on 10/28/2025 in which claims 1-4, 6 and 21-22 are presented for examination; Claim 1 has been amended. Claims 5 , 7-20 and 23-27 have been cancelled.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/28/2025 has been entered.
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-4, 6 and 21-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 1:
Step 1: Is the claim to a process, machine, manufacture or composition of matter?” Yes, it’s a machine(device).
Step 2a Prong 1 (judicial exception)
Step 2A (1): “Does the claim recite an abstract idea, law of nature, or natural phenomenon? Yes , the claim comes under mental processes.
Claim 1 recites:
“A monitoring device, comprising: a temperature measurement module configured to interface with a temperature probe to receive body temperature readings of a patient an SpO2 module configured to interface with a clip that attaches to an appendage of the patient to receive blood oxygen content and pulse rate measurements of the patient; a non-invasive blood pressure module configured to interface with an inflatable cuff to receive blood pressure measurements of the patient an alarm light bar at least one processor communicatively coupled to the temperature measurement module, the SpO2 module, the non-invasive blood pressure module, and the alarm light bar; and at least one system memory encoding instructions which, when executed by the at least one processor, cause the monitoring device to: receive an identifier for a caregiver; obtain an access level for the monitoring device based upon the identifier of the caregiver; generate a dynamic interface, the dynamic interface being configured based upon the access level of the caregiver, wherein a lower access level allows the caregiver to capture and save physiological parameters using at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module, and wherein a higher access level provides additional functionality over the lower access level ; access historical physiological information based upon the access level; the historical physiological information acquired from monitoring a patient over a period of time using the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module, the historical physiological information including at least one of the body temperature readings, the blood oxygen content and pulse rate measurements, and the blood pressure measurements; the historical physiological information is accessed from a server device, and access to at least one of a type of the historical physiological information and an amount of the historical physiological information is limited based on the access level; display on the dynamic interface a recommendation for one or more alarm limits based upon the historical physiological information, the one or more alarm limits including upper and lower alarm limits for the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module based upon the historical physiological information; adjust the one or more alarm limits based on the access level; and mute an alarm triggered by a physiological parameter exceeding the one or more alarm limits based on the access level, the alarm generated on the alarm light bar.”
All the limitations above are abstract idea related to the mental process (concepts performed in the human mind (including an observation, evaluation, judgment, opinion)) with the exception of bold and underlined limitations. Claim language pertains to access level granted to a caregiver based on credentials(i.e. lower level access to nurse assistant and high level access to registered nurse or clinician. ) to access or modify patient’s physiological information or alert/alarm notifications. It can be done on paper as for example specifying the roles of a nurse or clinician according to credentials. Recommending an alarm setting based on patient’s physiological information can be done mentally or on paper. Access to mute an alarm can also be given based on credentials. A patient’s historical physiological information can be retrieved/accessed from hospital records and the access to the information is also limited based on the access level(credentials).
Step 2A(2): Prong Two: evaluate whether the claim recites additional elements that integrate the exception into a practical application of the exception. NO
The claim does recite additional elements; however they don’t integrate the exception into a practical application of the exception.
Monitoring device (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
temperature measurement module( Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
temperature probe( Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
SPO2 module( Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
temperature measurement module( Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
non-invasive blood pressure module( Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
alarm light bar( Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
processor (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
system memory (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
monitoring device (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
receive an identifier (Adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) )
dynamic interface (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
display (Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
server device(Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f))
Step 2B: evaluate whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception? NO
As discussed previously with respect to Step 2A Prong Two, the additional elements in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
Regarding the claim limitation,“ receive an identifier” the courts have recognized the computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (“i. 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”); See, MPEP 2106.05 (d)(II)
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Dependent claims 2-4 , 6 and 21-22 further narrow the abstract idea recited above with regard to claim 1; In addition, claims contain the additional elements of “the monitoring device” “processor”, “server device ” , “display”.
Under step 2A, prong two, the above recited elements don’t integrate the exception into a practical application of the exception as merely adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
As discussed previously with respect to Step 2A Prong Two, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Setzer et al. ( US 20080072896 A1) in view of Al-Ali et al. (US 20140135588 A1), in view of DE WAELE et al (US 20160051206 A1) and further in view of Gondek et al (US 20160350504 A1)
Regarding claim 1, Setzer teaches a monitoring device, comprising:
an alarm light bar (para, “[0055] One or more LEDs on the ventilator's housing 78 may work in conjunction with one or more audible indicators, hardware buttons, and/or on-screen information on display 52 to provide redundant feedback regarding the state of ventilator 24 and/or the power source(s). One or more power source LEDs may indicate the source from which ventilator 24 is currently drawing power. For example, if ventilator 24 is plugged into an AC power source (e.g., a wall outlet or a cigarette lighter), an external power LED 94 may light up. If ventilator 24 is running on batteries, a battery power LED 96 may light up.” Also, see Fig. 2);
at least one processor communicatively coupled to [the temperature measurement module, the SpO2 module, the non-invasive blood pressure module, and] the alarm light bar(para, “[0039] In some embodiments, the ventilator or GUI may include a housing that includes one or more of the following: a control device for silencing an alarm for a predetermined period of time or for resetting an alarm; a control device for deactivating user interaction with the touch screen display; a control device for causing the ventilator to initiate a breath according to current breath settings of the programmable ventilator controller; a control device for initiating delivery of 100% oxygen to the patient for a predetermined period of time; an indicator of a source of power of the ventilator; and/or an indicator for indicating a malfunction of the ventilator or related hardware or software.”)
and at least one system memory encoding instructions which,( para, 0043)
when executed by the at least one processor, cause the monitoring device to: receive an identifier for a caregiver (“[0037] In some embodiments, any user may access any view displayed by the GUI, e.g., by selecting any view from a view menu. In other embodiments, the GUI may manage user access to particular views, thereby managing user access to access particular values, modify particular settings, or access other data. For example, the GUI may restrict user access to particular views using any suitable restriction technique, e.g., using passwords or access keys, or requiring particular buttons or icons to be pressed simultaneously or in sequence.” Note: here password or access keys can be identifier for the caregiver (user));
obtain an access level for the monitoring device based upon the identifier of the caregiver (“[0037] In some embodiments, any user may access any view displayed by the GUI, e.g., by selecting any view from a view menu. In other embodiments, the GUI may manage user access to particular views, thereby managing user access to access particular values, modify particular settings, or access other data. For example, the GUI may restrict user access to particular views using any suitable restriction technique, e.g., using passwords or access keys, or requiring particular buttons or icons to be pressed simultaneously or in sequence.”
“[0057] As discussed above, multi-level GUI module 22 may generate and display multiple different views on a touch screen display 52. The different views may have different levels of complexity and/or provide different levels of access to ventilation parameters. For example, different views may display values for different sets of ventilation parameters and/or allow users to adjust settings for different sets of ventilation parameters. The different views may be appropriate for, or correspond to, users having various levels of sophistication regarding ventilatory care, such as, for example, doctors, nurses, respiratory therapists, home care providers, medical equipment representatives, and/or ventilation patients (i.e., persons receiving the ventilatory care). The different views may allow the user to pick the view that includes particular information that the user wants or needs to view or monitor, e.g., based on the sophistication of the user, the particular patient being treated, the type of care being provided, and/or the personal preferences of the user.”);
generate a dynamic interface, the dynamic interface being configured based upon the access level of the caregiver (“[0037] In some embodiments, any user may access any view displayed by the GUI, e.g., by selecting any view from a view menu. In other embodiments, the GUI may manage user access to particular views, thereby managing user access to access particular values, modify particular settings, or access other data. For example, the GUI may restrict user access to particular views using any suitable restriction technique, e.g., using passwords or access keys, or requiring particular buttons or icons to be pressed simultaneously or in sequence.”
“[0057] As discussed above, multi-level GUI module 22 may generate and display multiple different views on a touch screen display 52. The different views may have different levels of complexity and/or provide different levels of access to ventilation parameters. For example, different views may display values for different sets of ventilation parameters and/or allow users to adjust settings for different sets of ventilation parameters. The different views may be appropriate for, or correspond to, users having various levels of sophistication regarding ventilatory care, such as, for example, doctors, nurses, respiratory therapists, home care providers, medical equipment representatives, and/or ventilation patients (i.e., persons receiving the ventilatory care). The different views may allow the user to pick the view that includes particular information that the user wants or needs to view or monitor, e.g., based on the sophistication of the user, the particular patient being treated, the type of care being provided, and/or the personal preferences of the user.”);
access historical physiological information based upon the access level (“[0065] Menu region 142 may provide various menu items that may be selected by a user, for example, to access the different views; access various settings; set up a new patient for ventilatory care; view history and/or alarm logs; setup, edit and/or view multiple preset breath delivery therapies; and/or adjust the current breath mode, breath type, and/or breath trigger options. In some embodiments, a user may touch display 52 to make selections from menu region 142. Various aspects of menu region 142 may be better understood in view of FIGS. 12-22, discussed below.”);
and access to at least one of a type of the historical physiological information and an amount of the historical physiological information is limited based on the access level (para, “[0059] 1. A Simple View (Level 1 access) (see, e.g., FIG. 5)--this view may display monitored ventilation data (e.g., an airway graphic indicating monitored pressure and/or flow data) and/or one or more ventilation parameter settings, but may suppress a significant amount of monitored patient data (e.g., data typically understood or used by relatively sophisticated users) and may provide no access for adjusting ventilation parameter settings.”);
the alarm generated on the alarm light bar (para, “[0055] One or more LEDs on the ventilator's housing 78 may work in conjunction with one or more audible indicators, hardware buttons, and/or on-screen information on display 52 to provide redundant feedback regarding the state of ventilator 24 and/or the power source(s). One or more power source LEDs may indicate the source from which ventilator 24 is currently drawing power. For example, if ventilator 24 is plugged into an AC power source (e.g., a wall outlet or a cigarette lighter), an external power LED 94 may light up. If ventilator 24 is running on batteries, a battery power LED 96 may light up.” Also, see Fig. 2)
Setzer doesn’t explicitly teach:
a temperature measurement module configured to interface with a temperature probe to receive body temperature readings of a patient;
an SpO2 module configured to interface with a clip that attaches to an appendage of the patient to receive blood oxygen content and pulse rate measurements of the patient;
a non-invasive blood pressure module configured to interface with an inflatable cuff to receive blood pressure measurements of the patient
at least one processor communicatively coupled to the temperature measurement module, the SpO2 module, the non-invasive blood pressure module, [and the alarm light bar];
wherein a lower access level allows the caregiver to capture and save physiological parameters, using at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module,
and wherein a higher access level provides additional functionality over the lower access level;
the historical physiological information acquired from monitoring a patient over a period of time using the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module,
the historical physiological information including at least one of the body temperature readings, the blood oxygen content and pulse rate measurements, and the blood pressure measurements.
the historical physiological information is accessed from a server device,
display on the dynamic interface a recommendation for one or more alarm limits for the at least one of the temperature measurement module, the SPO2 module and the non-invasive blood pressure module based upon the historical physiological information
the one or more alarm limits including upper and lower alarm limits based upon the historical physiological information;
adjust the one or more alarm limits based on the access level;
and mute an alarm triggered by a physiological parameter exceeding the one or more alarm limits based on the access level
Al-Ali teaches:
wherein a lower access level allows the caregiver to capture and save physiological parameters, using at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module,(Para, “[0249] In some embodiments, the patient monitoring device enables or disables a particular feature based upon detection of the clinician token 1410. For example, the patient monitoring device may enable/disable menus and buttons (e.g., alarm limit menu, alarm silence, all mute, etc.) based upon the credentials of the detected clinician. In some embodiments, the patient monitoring device 1400 begins transmission of patient monitoring information to a remote device upon detecting the presence of a clinician. For example, a bedside patient monitor capable of capturing breathing sounds from a patient could automatically begin transmission of those breathing sounds to the clinician's Bluetooth headset, which, incidentally, can serve as the clinician token 1410 as well. In other embodiments, the patient monitoring device 1400 could begin transmission of any type of monitoring information to a remote device via, for example, the Internet upon detecting the presence of a particular clinician. For example, the patient monitoring device 1400 can transmit the patient's oxygen saturation trend data to the clinician's computer for later analysis and diagnosis. The patient monitoring device 1400 can also transmit any other type of patient information (e.g., medical parameter values and/or trend data, video and/or audio from the patient's room, etc.) to, for example, the clinician's computer, or some other device, in response to detection of the presence of some particular clinician in proximity to the patient monitoring device 1400.” Note: here the data based on the clinician’s token can be transmitted for later analysis, thus saved; also see Fig. 11 for “Save” option, and para 0207; also see para 0008 for blood pressure and SpO2.),
and wherein a higher access level provides additional functionality over the lower access level ( Para, “[0249] In some embodiments, the patient monitoring device enables or disables a particular feature based upon detection of the clinician token 1410. For example, the patient monitoring device may enable/disable menus and buttons (e.g., alarm limit menu, alarm silence, all mute, etc.) based upon the credentials of the detected clinician….”);
the historical physiological information is accessed from a server device(para, “[0085] The network interface module 106 receives context information, for example, by a nurse entering the information in the network interface module 106 or from a server 136. In one embodiment, by receiving this information (including, e.g., patient identification number and location), the network interface module 106 becomes exclusively assigned to the medical patient. The network interface module 106 transmits or communicates the contextual data package to clinicians during an alarm or alert, upon clinician request, or on a scheduled basis. In addition, the network interface module 106 may transmit a continuous stream of physiological information to clinicians.”
Also, para “[0088] In some implementations, a server 136 may optionally be included in the physiological monitoring system 100. The server 136 in these implementations is generally a computing device such as a blade server or the like. In certain embodiments, the server 136 is an appliance server housed in a data closet. In other embodiments, the server 136 is a server located at a central nurses' station, such as a workstation server.”
Also, para “[0091] In one embodiment, the journaling function of the server 136 constitutes a transaction-based architecture. Certain transactions of the physiological monitoring system 100 are journaled such that a timeline of recorded events may later be re-constructed to evaluate the quality of healthcare given. These transactions include state changes relating to physiological information from the patient monitoring devices 100, to the patient monitoring devices 110, to the hospital WLAN 126 connection, to user operation, and to system behavior. Journaling related to the physiological information received from a physiological monitor in one embodiment includes recording the physiological information itself, recording changes in the physiological information, or both.”)
and mute an alarm triggered by a physiological parameter exceeding the one or more alarm limits based on the access level (para, “0249] In some embodiments, the patient monitoring device enables or disables a particular feature based upon detection of the clinician token 1410. For example, the patient monitoring device may enable/disable menus and buttons (e.g., alarm limit menu, alarm silence, all mute, etc.) based upon the credentials of the detected clinician. In some embodiments, the patient monitoring device 1400 begins transmission of patient monitoring information to a remote device upon detecting the presence of a clinician. For example, a bedside patient monitor capable of capturing breathing sounds from a patient could automatically begin transmission of those breathing sounds to the clinician's Bluetooth headset, which, incidentally, can serve as the clinician token 1410 as well. In other embodiments, the patient monitoring device 1400 could begin transmission of any type of monitoring information to a remote device via, for example, the Internet upon detecting the presence of a particular clinician. For example, the patient monitoring device 1400 can transmit the patient's oxygen saturation trend data to the clinician's computer for later analysis and diagnosis. The patient monitoring device 1400 can also transmit any other type of patient information (e.g., medical parameter values and/or trend data, video and/or audio from the patient's room, etc.) to, for example, the clinician's computer, or some other device, in response to detection of the presence of some particular clinician in proximity to the patient monitoring device 1400.”
Also, para “[0078] In certain embodiments, the sensor processing module 104 generates waveforms from signals received from the sensors 102. The sensor processing module 104 may also analyze single or multiparameter trends to provide early warning alerts to clinicians prior to an alarm event. In addition, the sensor processing module 104 in certain embodiments generates alarms in response to physiological parameters exceeding certain safe thresholds.”)
It would have been obvious for a person of ordinary skill in the art to incorporate enabling/disabling menu features based on user token teaching of Al-Ali into the teachings of Setzer at the time the application was filed in order to provide different menu options based on the user’s credentials. (Para, “[0249] In some embodiments, the patient monitoring device enables or disables a particular feature based upon detection of the clinician token 1410. For example, the patient monitoring device may enable/disable menus and buttons (e.g., alarm limit menu, alarm silence, all mute, etc.) based upon the credentials of the detected clinician…”)
Setzer as modified by Al-Ali doesn’t explicitly teach:
display on the dynamic interface a recommendation for one or more alarm limits for the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module based upon the historical physiological information,
the one or more alarm limits including upper and lower alarm limits based upon the historical physiological information;
adjust the one or more alarm limits based on the access level;
De Waele teaches:
display on the dynamic interface a recommendation for one or more alarm limits for at least one of the temperature measurement module, the SPO2 module, and the non-invasive blood pressure module based upon the historical physiological information (para, “[0027] An observational analyzer or means 48 generates one or more suggested setting changes and/or further refines based on an observational analysis of the vital sign signals and/or patient data. In one embodiment, a healthcare practitioner selects a patient or patient population for recommended changed alarm settings and the observational analyzer 48 recommends one or more alarm setting changes. For example, a healthcare practitioner communicatively connects to a medical monitor 12 using an alerting device 30 and/or other computing device 50, and selects the patient and/or vital sign for review, and the observational analyzer generates a setting change in response. In another embodiment, the observational analyzer 48 recommends changes to alarm settings for the patient based on current vital sign signals and/or patient data 44, and sends the recommended changes to the alerting device 30 or other computing device 50. Over time, based on recent medical history, vital sign signals and/or alarm data, the patient can be reassigned or recommended to be reassigned to a different alarm profile or changed settings.” Para 0023 teaches the alerting device can be a medical monitor, display, or mobile device.
Also, para “[0043] A recommendation 136 for a changed alarm setting 22 is generated in a step or with a module 128 based on an observational analysis. The observational analysis, such as described in reference to FIG. 5, includes changes in alarm settings 22 of medical monitors 12 modeled as deviations from policy. The recommendation 136, which includes one or more changed or different settings, is generated from the modeled changes. For example, a modeled observational analysis identifies a set of settings, A, for SpO.sub.2 and HR, which deviates from general use in organizational units of type R. In another example, a modeled observational analysis identifies a set of settings, B, for BP of a target patient population with a condition X, which deviates from general use in an organization. The recommendation 136 can be separately provided or incorporated into one or more suggested profiles 26. Also, observed deviations from the policy can lead to initiation of additional training in alarm management for the clinical staff.”)
the one or more alarm limits including upper and lower alarm limits based upon the historical physiological information (para, “[0007] In accordance with another aspect, a system to monitor patient vital signs includes a medical monitor and an observational analyzer. The medical monitor is configured to receive monitored vital signs for at least one patient and includes a plurality of sets of alarm settings defined according to a constructed normative model of data from selected medical monitors. Each set of alarm setting includes at least one of an upper and a lower limit for at least one monitored vital sign. The observational analyzer is configured to receive the at least one monitored vital sign in an alarm condition according to a first set of alarm settings and return a recommended second set of alarm settings which places the at least one monitored vital sign in a non-alarm condition.”);
adjust the one or more alarm limits based on the access level (claim 5, “5. The system to generate medical monitor alarm settings (10) according any one of claims 1-4, wherein the observational analyzer (44) is configured to: send the recommended change to at least one alerting device (30) receiving the alarm condition; and receive acceptance of the recommended change and change the alarm settings in a medical monitor (12) for the patient to the accepted alarm settings.” Note: please see 112(a) rejection for new matter; also Setzer already teaches that user can have access to different settings based on user access level (see, para 0004)).
It would have been obvious for a person of ordinary skill in the art to incorporate alarm recommendation teaching of De Waele into the teachings of Setzer as modified by Al-Ali at the time the application was filed in order to adopt alarm setting to individual patient. (Para 0032, “….The observational analyzer 48 recommends new alarm settings, which are adaptive to the individual patient. The recommended alarm settings can be constrained or subject to sets of the settings, e.g. change from a first set of alarm settings X to second set of alarm settings Y subject to healthcare practitioner approval…”)
Setzer as modified by Al-Ali and DE WAELE does not explicitly teach
a temperature measurement module configured to interface with a temperature probe to receive body temperature readings of a patient;
an SpO2 module configured to interface with a clip that attaches to an appendage of the patient to receive blood oxygen content and pulse rate measurements of the patient;
a non-invasive blood pressure module configured to interface with an inflatable cuff to receive blood pressure measurements of the patient
at least one processor communicatively coupled to the temperature measurement module, the SpO2 module, the non-invasive blood pressure module, [and the alarm light bar];
the historical physiological information acquired from monitoring a patient over a period of time using the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module,
the historical physiological information including at least one of the body temperature readings, the blood oxygen content and pulse rate measurements, and the blood pressure measurements.
Gondek teaches:
a temperature measurement module configured to interface with a temperature probe to receive body temperature readings of a patient(para, “[0049] Another example physiological measurement device is a temperature measurement device. The temperature measurement device is designed to measure the body temperature of a patient. In some embodiments, the temperature measurement device includes a handle and a temperature probe. The probe is designed to make physical contact with a patient in order to sense a body temperature of the patient. In some embodiments, the temperature probe is removable.);
an SpO2 module configured to interface with a clip that attaches to an appendage of the patient to receive blood oxygen content and pulse rate measurements of the patient(para, “[0047] An example physiological measurement device is an SpO2 measurement device. The SpO2 measurement device is designed to measure oxygen content within the blood of a patient. In some embodiments, the SpO2 measurement device includes a clip that attaches to an appendage of a patient, such as a finger. The clip is designed to detect and measure a pulse and an oxygen content of blood flowing within the patient.”);
a non-invasive blood pressure module configured to interface with an inflatable cuff to receive blood pressure measurements of the patient( para, “[0048] Another example physiological measurement device is a non-invasive blood pressure (NIBP) measurement device. The NIBP measurement device is designed to measure blood pressure of a patient. In some embodiments, the NIBP device includes an inflatable cuff that attaches to an appendage of a patient, such as an upper arm of the patient. The inflatable cuff is designed to measure the systolic and diastolic blood pressure of the patient, the mean arterial pressure (MAP) of the patient, and the pulse rate of blood flowing within the patient.”)
at least one processor communicatively coupled to the temperature measurement module, the SpO2 module, the non-invasive blood pressure module, [and the alarm light bar](see para, 0049, 0047 and 0048)
the historical physiological information acquired from monitoring a patient over a period of time using the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module(para, “[0036] When the medical device 104 is operating within the interval profile, the medical device 104 obtains a series of measurements of one or more physiological parameters of a single monitored patient over a period of time. In addition, the medical device 104 displays, on the display screen 200, an interval profile home screen. The interval profile home screen contains a representation of a physiological parameter of the monitored patient. The representation is based on at least one measurement in the series of measurements. A representation of a physiological parameter is a visible image conveying information about the physiological parameter.” Note: Also, see para 0020 and 0047.)
the historical physiological information including at least one of the body temperature readings, the blood oxygen content and pulse rate measurements, and the blood pressure measurements(para, “[0036] When the medical device 104 is operating within the interval profile, the medical device 104 obtains a series of measurements of one or more physiological parameters of a single monitored patient over a period of time…”
Also, para “[0047] An example physiological measurement device is an SpO2 measurement device. The SpO2 measurement device is designed to measure oxygen content within the blood of a patient. In some embodiments, the SpO2 measurement device includes a clip that attaches to an appendage of a patient, such as a finger. The clip is designed to detect and measure a pulse and an oxygen content of blood flowing within the patient.” Note: Also, see para 0020)
It would have been obvious for a person of ordinary skill in the art to include monitoring devices of Gondek into the teachings of Setzer as modified by Al-Ali and DE WAELE at the time the application was filed in order to measure one or more physiological parameters of a patient. (para, “[0046] The physiological measurement device 400 operates to measure one or more physiological parameters of a patient. Some embodiments include multiple physiological measurement devices.”)
Regarding claim 2, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the monitoring device of claim 1.
Setzer teaches wherein the identifier includes one or more caregiver roles (“[0057] As discussed above, multi-level GUI module 22 may generate and display multiple different views on a touch screen display 52. The different views may have different levels of complexity and/or provide different levels of access to ventilation parameters. For example, different views may display values for different sets of ventilation parameters and/or allow users to adjust settings for different sets of ventilation parameters. The different views may be appropriate for, or correspond to, users having various levels of sophistication regarding ventilatory care, such as, for example, doctors, nurses, respiratory therapists, home care providers, medical equipment representatives, and/or ventilation patients (i.e., persons receiving the ventilatory care). The different views may allow the user to pick the view that includes particular information that the user wants or needs to view or monitor, e.g., based on the sophistication of the user, the particular patient being treated, the type of care being provided, and/or the personal preferences of the user.” Note: here based on different role (doctor, nurse, etc.…) different view corresponds.)
Regarding claim 3, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the monitoring device of claim 1.
Setzer teaches wherein an increase in the access level provides an increased amount of information that is displayed by the monitoring device (“0057] As discussed above, multi-level GUI module 22 may generate and display multiple different views on a touch screen display 52. The different views may have different levels of complexity and/or provide different levels of access to ventilation parameters.”)
Regarding claim 4, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the monitoring device of claim 1.
Setzer teaches wherein an increase in the access level provides an increased amount of control over the monitoring device (“0057] As discussed above, multi-level GUI module 22 may generate and display multiple different views on a touch screen display 52. The different views may have different levels of complexity and/or provide different levels of access to ventilation parameters.”)
Regarding claim 21, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the monitoring device of claim 1.
Al-Ali further teaches wherein the historical physiological information includes information captured at earlier points in time by other devices (para, “[0138] In certain embodiments, systems and methods are provided for rapidly storing and acquiring physiological trend data. For instance, physiological information obtained from a medical patient can be stored in a round-robin database. The round-robin database can store the physiological information in a series of records equally spaced in time. Parameter descriptors may be used to identify parameter values in the records. The parameter values can be dynamically updated by changing the parameter descriptors to provide for a flexible database. In addition, the size of files used in the database can be dynamically adjusted to account for patient condition.”
Also, para “[0151] Advantageously, in certain embodiments, the MMS 620 can store physiological information obtained from the patient monitors 640 in a round-robin database (RRDB) 624. The RRDB 622 of various embodiments includes a streamlined database structure that facilitates rapidly storing and retrieving patient data. The RRDB 622 can therefore be used in certain embodiments to rapidly provide physiological trend data to the nurses' stations 630 and to the clinician devices 650. Thus, for example, if a clinician desires to see a patient's physiological trends over a certain time period, such as the past hour, the clinician can use a nurses' station computer 630 or clinical device 650 to query the MMS 620. The MMS 620 may then obtain physiological information corresponding to the desired time period from the RRDB 622. Advantageously, the RRDB 622 can enable faster acquisition of trend data then is possible with relational databases currently used by hospital monitoring systems. Additional uses and optimizations of the RRDB 622 are described below.”
It would have been obvious for a person of ordinary skill in the art to capture historical physiological information teachings of AI-Ali into the teachings of Setzer as modified by Al-Ali and DE WAELE at the time the application was filed in order to enable faster acquisition of trend data. (AI-Ali , para, “[0151] Advantageously, in certain embodiments, the MMS 620 can store physiological information obtained from the patient monitors 640 in a round-robin database (RRDB) 624. The RRDB 622 of various embodiments includes a streamlined database structure that facilitates rapidly storing and retrieving patient data. The RRDB 622 can therefore be used in certain embodiments to rapidly provide physiological trend data to the nurses' stations 630 and to the clinician devices 650. Thus, for example, if a clinician desires to see a patient's physiological trends over a certain time period, such as the past hour, the clinician can use a nurses' station computer 630 or clinical device 650 to query the MMS 620. The MMS 620 may then obtain physiological information corresponding to the desired time period from the RRDB 622. Advantageously, the RRDB 622 can enable faster acquisition of trend data then is possible with relational databases currently used by hospital monitoring systems. Additional uses and optimizations of the RRDB 622 are described below.”)
Regarding claim 22, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the monitoring device of claim 1.
Al-Ali further teaches comprising further instructions which, when executed by the at least one processor, cause the monitoring device to: display the historical physiological information as a trend (para , “[0445] FIGS. 40A-B, 41, 42, 43A-B illustrate additional display embodiments having various advantageous features. FIGS. 40A-B illustrate trend displays 4000 having colored alarm zones 4010 so that a user can readily identify the historical severity of a patient condition that triggers an alarm. FIG. 41 illustrate displays that invert arrow keys to match the cursor. FIGS. 43A-B illustrate trend displays and corresponding set-up screens.”
Also, para “[0191] A history view area 930 in certain implementations can show medical event data corresponding to a selected patient monitor status module 912. This medical event data can be obtained from a journal database for inclusion in the GUI 900. The historical view 930 can show, for example, when a sensor was connected or disconnected from a patient, when alarms were active, and when a patient was admitted to the hospital or department. Although not shown, the history view area 930 can also be configured to show trend data obtained from an RRDB instead of, or in addition to, the journaled data.”
It would have been obvious for a person of ordinary skill in the art to display the historical physiological trend teachings of AI-Ali into the teachings of Setzer as modified by Al-Ali and DE WAELE at the time the application was filed in order to identify the historical severity of a patient condition. (AI-Ali , para , “[0445] FIGS. 40A-B, 41, 42, 43A-B illustrate additional display embodiments having various advantageous features. FIGS. 40A-B illustrate trend displays 4000 having colored alarm zones 4010 so that a user can readily identify the historical severity of a patient condition that triggers an alarm. FIG. 41 illustrate displays that invert arrow keys to match the cursor. FIGS. 43A-B illustrate trend displays and corresponding set-up screens.”)
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Setzer as modified by Al-Ali , DE WAELE , Gondek and in view of Curchoe (US 20220051788 A1)
Regarding claim 6, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the monitoring device of claim 1.
Setzer as modified by Al-Ali , DE WAELE and Gondek does not explicitly teach further instructions which, when executed by the at least one processor, cause the monitoring device to:
send the identifier to the server device;
and receive the access level from the server device.
Curchoe teaches further instructions which, when executed by the at least one
processor, cause the monitoring device to:
sending the identifier to a server device (“[0047] As can be appreciated, the system 100 can be configured to deploy role-based access management for the IVF application—where each user of a client computing device 102a-102d that accesses the server computing device 106 can be assigned one or more user roles (e.g., Technologist, Patient, Director, Administrator, Physician, etc.) that define the permissions and level of access afforded to that user by the server computing device 106 with respect to the functionality of the IVF software application. For example, a Technologist may have access to different modules (and sub-functions within those modules) within the IVF software application (e.g., testing, inventory, etc.) than a Patient would, and vice versa. These user roles can be data structures that are stored in database 110 and associated with one or more user- or client device-based credentials, so that when a particular user logs in to use the IVF software application with a set of user credentials (e.g., username, password), the server computing device 106 and/or the client computing device 102a-102d can authenticate the user credentials and select the appropriate role associated with the user credentials in order to initialize and configure the IVF software application for use.”);
and receiving the access level from the server device (“[0047] As can be appreciated, the system 100 can be configured to deploy role-based access management for the IVF application—where each user of a client computing device 102a-102d that accesses the server computing device 106 can be assigned one or more user roles (e.g., Technologist, Patient, Director, Administrator, Physician, etc.) that define the permissions and level of access afforded to that user by the server computing device 106 with respect to the functionality of the IVF software application. For example, a Technologist may have access to different modules (and sub-functions within those modules) within the IVF software application (e.g., testing, inventory, etc.) than a Patient would, and vice versa. These user roles can be data structures that are stored in database 110 and associated with one or more user- or client device-based credentials, so that when a particular user logs in to use the IVF software application with a set of user credentials (e.g., username, password), the server computing device 106 and/or the client computing device 102a-102d can authenticate the user credentials and select the appropriate role associated with the user credentials in order to initialize and configure the IVF software application for use.”)
It would have been obvious for a person of ordinary skill in the art to use server authenticating teaching of Curchoe into the teachings of Setzer as modified by Al-Ali , DE WAELE and Gondek at the time the application was filed in order to provide role based access to the system. (“0048] In one embodiment, there can be at least five different types of user roles: Director, Technologist, Administrator, Physician, and Patient. Each of these roles can have certain permissions and functionality associated with it, such as:”)
Response to Arguments
Applicant's arguments filed on 15 have been fully considered but they are not persuasive.
Remarks - 35 USC § 101
In remarks, Pg. 6, applicant contends: “the hardware elements incorporated into claim 1 transform the claimed subject matter into a spot monitor.”
The examiner agrees that the hardware elements incorporated are not abstract elements, rather as recited these elements are additional elements. Each of these elements have been addressed in the 35 U.S.C. 101 section above. These elements are being merely applied to capture the physiological data (as can be seen in majority of medical settings); furthermore the claims or specification don’t provide any improvement to these elements that would integrate the abstract idea into a practical application.
In remarks, Pg. 7, applicant contends: “amended claim 1 recites specific hardware elements that cannot be practically performed in the human mind because the "temperature measurement module configured to interface with a temperature probe,"SpO2 module configured to interface with a clip," and "non-invasive blood pressure module configured to interface with an inflatable cuff' are not limitations that cannot practically be performed in the human mind.”
The examiner agrees that hardware modules are not an abstract idea, rather they recite additional elements that have been addressed above.
In remarks, Pg. 8, applicant contends: “amended claim 1 improves spot monitor technology by creating dynamic interfaces specifically tailored to the hardware measurement capabilities available. Rather than generic access control, the claims implement "a dynamic interface being configured based upon the access level of the caregiver, wherein a lower access level allows the caregiver to capture and save physiological parameters using at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module." This represents a technological improvement to how spot monitors present their measurement capabilities to users based on both access credentials and the specific hardware modules present.”
The improvement to technology is disclosed by reciting technical improvements to the additional elements; the use of access level to grant permission to certain features is not a technical improvement rather an abstract idea itself. This is nothing more than rule based accessed. The technical aspect are already present, by disabling/allowing certain features using the access level, one is merely controlling permissions; rather than providing an improvement to technology.
In remarks, Pg. 8, applicant contends: “further, amended claim 1 provides a technological solution for alarm management in spot monitors by connecting historical data analysis to hardware-specific alarm generation by reciting "display on the dynamic interface a recommendation for one or more alarm limits for the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module based upon the historical physiological information."
Similar to above limitation, the data is merely being displayed on display device according to rules, and claims/specification don’t provide any details as to how the display technology is being improved.
The applicant also makes remarks with regard to oversimplifying the claim, however the applicant doesn’t elaborate or point to any claims or specification as to how the technical improvement is being made. The claim is amended to include hardware sensors/modules to capture the data, which is merely applying these generic devices to capture data (such as in any medical facility); furthermore, there is no discussion with regard to display technology as to how the display of device is being improved; rather access level is being used to restrict/grant permission to certain features.
Remarks - 35 USC § 103
In remarks, Pg. 12, applicant contends: “the Office Action cites paragraph 27 of De Waele for allegedly disclosing display on the dynamic interface a recommendation for one or more alarm limits based upon the historical physiological information. While De Waele discloses alarm recommendations, De Waele does not disclose or suggest use of historical data captured by temperature measurement, SpO2, and NIBP hardware modules for tailoring alarm recommendations for these modules.
Para, “[0007] In accordance with another aspect, a system to monitor patient vital signs includes a medical monitor and an observational analyzer. The medical monitor is configured to receive monitored vital signs for at least one patient and includes a plurality of sets of alarm settings defined according to a constructed normative model of data from selected medical monitors. Each set of alarm setting includes at least one of an upper and a lower limit for at least one monitored vital sign. The observational analyzer is configured to receive the at least one monitored vital sign in an alarm condition according to a first set of alarm settings and return a recommended second set of alarm settings which places the at least one monitored vital sign in a non-alarm condition.”
As can be seen, the reference explicitly teaches that alarm setting are presented based on vital sign of patient. The reference further teaches:
“[0020] With reference to FIG. 1, an embodiment of a system 10 for usage of observed alarm settings for alarm management is diagrammatically illustrated. The system 10 includes one or more medical monitors 12, which receive vital sign signal values from monitored patients 14. The vital sign signals are sensed by one or more vital sign monitoring devices 16, such as a non-invasive or invasive blood pressure (BP) monitor, SpO.sub.2 or blood oximetry device, respiratory rate (RR) monitor, electrocardiogram (ECG) monitor, Heart Rate (HR) monitor and the like affixed, attached, or otherwise connected to each monitored patient shown with a partial exploded view. The vital sign monitoring devices 16 sense the corresponding vital sign signal and transmit the vital sign signal to the medical monitor 12 as the vital sign signal, e.g. as a waveform and/or as a value. In one embodiment, the system 10 includes a central monitor 18 via a network 20, which receives vital signs from a communication unit 21 of each medical monitor 12, representing a group of centrally monitored patients. The network 20 can include public and/or private networks, wired or wireless networks, cellular and/or data networks, hard-wired or virtual (Cloud-based systems) and combinations. Patients can be ambulatory or non-ambulatory, centralized or distributed geographically, clinic based, home based or hospital based, intensive care unit (ICU) based, and the like.”
Thus, reference explicitly teaches use of such modules/devices to capture the data. Also, see claim rejection above that addresses each amended claim limitation. Also, note, the claim states “display on the dynamic interface a recommendation for one or more alarm limits for the at least one of the temperature measurement module, the SpO2 module, and the non-invasive blood pressure module.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUMA WASEEM whose telephone number is (571)272-1316. The examiner can normally be reached Monday-Friday(9:00am - 5:00 pm) EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jason B. 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.
/HUMA WASEEM/Examiner, Art Unit 3686
/JASON B DUNHAM/Supervisory Patent Examiner, Art Unit 3686