DETAILED ACTION
This is responsive to amendments filed on 05/29/2026 in which claims 1-4, 6, 21-22, and 28-30 are presented for examination; Claim 1 have been amended. Claims 28-30 have been newly added.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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 vital signs 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 via login at the vital signs monitoring device; 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; generate for 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 that is accessed based on the higher access level. The one or more alarm limits including upper and lower alarm limits that are patient-specific. ; adjust the one or more alarm limits based on acceptance of the recommendation on the dynamic interface; and mute an alarm triggered by a physiological parameter exceeding the one or more alarm limits based on an input received on the dynamic interface , the input displayed on the dynamic interface based on the access level, the alarm generated on the alarm light bar ; and wherein the vital signs monitoring device operates within a monitoring workflow in which the vital signs monitoring device obtains a series of measurements of the physiological parameters of the patient over a period of time, and wherein the upper and lower alarm limits that are adjusted based on the historical physiological information of the patient are used to trigger an alarm when a measurement in the series of measurements of the physiological parameters exceeds the adjusted upper or lower alarm limit.
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). A patient’s vital signs can be obtained for over a period of time and track of alarm limit can be done by setting/specifying a value/limit and observing if the value reaches above the limit for and alarm rings,, which can be done mentally or on p[aper.
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.
Vital signs 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) )
login at the vital signs 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))
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))
vital signs 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))
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, 21-22 and 28-30 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, 21-22, and 28-29 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 vital signs monitoring device (Fig. 6), 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 via a login at the vital signs monitoring device (“[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)
[generate for 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 that is accessed based on the higher access level(para, “[0005] According to another embodiment of the present disclosure, a multi-level graphic user interface (GUI) for use with a ventilator system is provided. The multi-level GUI may include a touch screen display configured to display a view menu allowing a user to select from multiple different views providing different levels of user access to a plurality of ventilation parameters. The multiple different views may include a first view and a second view. The first view may display values for a first set of the ventilation parameters, each value comprising either a monitored value or a setting for a ventilation parameter. The first view may further provide user access for adjusting the setting for at least one of the first set of the ventilation parameters. The second view may display values for a second set of the ventilation parameters, each value comprising either a monitored value or a setting for a ventilation parameter....” Note: this para teaches user can have different level of access that allows them o see different set of parameters including monitored values (physiological information such as pressure value (see para 0027).
Also, para “[0085] In addition, in some embodiments, the menu of settings and/or other data that may be accessed via menu button 404 may depend on the particular view or the access level of the particular view. For example, selecting menu button 404 in a Level 1 access view (e.g., the Simple view) may provide the user access to a first menu of settings and/or other data, selecting the menu icon in a Level 2 access view (e.g., the Main view) may provide the user access to a second menu of settings and/or other data larger than the first menu of settings and/or other data, and selecting the menu icon in a Level 3 access view (e.g., the Advanced-Gauge or Advanced-Waveform view) may provide the user access to a third menu of settings and/or other data larger than the second menu of settings and/or other data. In some embodiments, buttons 432 corresponding to particular settings and/or other data that are not accessible in a particular view may be grayed out or hidden from the menu displayed when the menu button 404 is selected in that view.” Note: this para teaches that access level can determine the amount of access the user have to data, thus higher the level, more data aa user can access.”),
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,
generate for 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 [that is accessed based on the higher access level],
the one or more alarm limits including upper and lower alarm limits based upon the historical physiological information that are patient specific
adjust the one or more alarm limits based on acceptance of the recommendation on the dynamic interface; ;
and mute an alarm triggered by a physiological parameter exceeding the one or more alarm limits based on an input received on the dynamic interface , the input displayed on the dynamic interface based on the access level
and wherein the vital signs monitoring device operates within a monitoring workflow in which the vital signs monitoring device obtains a series of measurements of the physiological parameters of the patient over a period of time,
and wherein the upper and lower alarm limits that are adjusted based on the historical physiological information of the patient are used to trigger an alarm when a measurement in the series of measurements of the physiological parameters exceeds the adjusted upper or lower alarm limit.
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 an input received on the dynamic interface , the input displayed on the dynamic interface 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.”)
and the vital signs monitoring device operates within a monitoring workflow in which the vital signs monitoring device obtains a series of measurements of the physiological parameters of the patient over a period of time( Also, para “[0151] ........ 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 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:
generate for 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 [that is accessed based on the higher access level],
the one or more alarm limits including upper and lower alarm limits that are patient-specific;
adjust the one or more alarm limits based on acceptance of the recommendation on the dynamic interface;
and wherein the upper and lower alarm limits that are adjusted based on the historical physiological information of the patient are used to trigger an alarm when a measurement in the series of measurements of the physiological parameters exceeds the adjusted upper or lower alarm limit
De Waele teaches:
generate for 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 [that is accessed based on the higher access level] (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 that are patient specific (para, “[0041]..... The step can include conversion of continuous values to discrete intervals. The step can include identification of upper and/or lower alarm settings. The step can include different combinations of vital signs, e.g. alarm limits for one or more vital signs based on one or more of the vital signs as well as other factors, such as time of day, ambient temperature or barometer pressure, etc. The step can include identification of recommended target patient populations, e.g. according patient condition, diagnosis, demographic, etc., such as received in the medically related.”)
adjust the one or more alarm limits based on acceptance of the recommendation on the dynamic interface (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)).
and wherein the upper and lower alarm limits that are adjusted based on the historical physiological information of the patient are used to trigger an alarm when a measurement in the series of measurements of the physiological parameters exceeds the adjusted upper or lower alarm limit( para, “([0037] With reference to FIG. 5, an exemplary vital sign signal values and vital sign alarm setting graph is illustrated. Vital sign signals are represented by an average of the vital sign signal values over a selected time interval t.sub.1 to t.sub.2, such as 15 minutes or an hour, although it could be longer or shorter. The average of the vital sign values over the selected time interval T.sub.av 120 is represented by a variable X.sub.av. The values of the vital sign signals in FIGS. 2 and 4 can be represented by X.sub.av. In one embodiment, X.sub.av represents a variable which includes a time interval preceding a change in an alarm setting. Time is represented on the horizontal axis. The values of a vital sign signal X 122 are represented on the vertical axis. The graph plots the vital sign signal 124 over time. A first upper limit value L.sub.1 126 is represented as a line from a time t.sub.0 to t.sub.2, and a second upper limit value L.sub.2 128 beginning at t.sub.2. The second upper limit represents a changed alarm setting value. The values of the vital sign signal 124 are initially lower than the threshold limit value L.sub.1 at time t.sub.0 and greater than the threshold limit value L.sub.1 at time t.sub.1 indicative of the alarm condition. In one embodiment, after the vital sign has exceeded L.sub.1 for a time sufficiently long to infer that exceeding L.sub.1 is not a short term aberration, the data is collected over T.sub.av 120 and a new alarm limit is recommended. When the analysis produces the new recommended alarm limit at time t.sub.2, the alarm limit value is changed to a value greater than the vital sign signal value, e.g. L.sub.2>X. With this change, the patient is no longer in the state where the vital sign meets the alarm condition, e.g. non-alarm condition. The observed change from a normative alarm setting value, such as L.sub.1, to a different alarm setting value, such as L.sub.2, provides a value for observational modeling. The changed setting, an increase or a decrease, related or unrelated to an alarm condition, provide values for observational modeling or deviations from normative values....”
Para, “[0002] ..... Alarm monitors receive vital signs from patients and send alerts if one or more vital signs exceed one or more minimum or maximum threshold limit values.”)
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.”)
Regarding claim 28, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the vital signs monitoring device of claim 1.
Setzer as modified by Al-Ali , DE WAELE and Gondek does not explicitly teach the lower access level prevents the caregiver from requesting or accessing the historical physiological information, and wherein the higher access level permits the caregiver to request at least a portion of the historical physiological information.
Setzer further teaches wherein the lower access level prevents the caregiver from requesting or accessing the historical physiological information, and wherein the higher access level permits the caregiver to request at least a portion of the historical physiological information (para, “[0005] According to another embodiment of the present disclosure, a multi-level graphic user interface (GUI) for use with a ventilator system is provided. The multi-level GUI may include a touch screen display configured to display a view menu allowing a user to select from multiple different views providing different levels of user access to a plurality of ventilation parameters. The multiple different views may include a first view and a second view. The first view may display values for a first set of the ventilation parameters, each value comprising either a monitored value or a setting for a ventilation parameter. The first view may further provide user access for adjusting the setting for at least one of the first set of the ventilation parameters. The second view may display values for a second set of the ventilation parameters, each value comprising either a monitored value or a setting for a ventilation parameter....” Note: this para teaches user can have different level of access that allows them o see different set of parameters including monitored values (physiological information such as pressure value (see para 0027).
Also, para “[0085] In addition, in some embodiments, the menu of settings and/or other data that may be accessed via menu button 404 may depend on the particular view or the access level of the particular view. For example, selecting menu button 404 in a Level 1 access view (e.g., the Simple view) may provide the user access to a first menu of settings and/or other data, selecting the menu icon in a Level 2 access view (e.g., the Main view) may provide the user access to a second menu of settings and/or other data larger than the first menu of settings and/or other data, and selecting the menu icon in a Level 3 access view (e.g., the Advanced-Gauge or Advanced-Waveform view) may provide the user access to a third menu of settings and/or other data larger than the second menu of settings and/or other data. In some embodiments, buttons 432 corresponding to particular settings and/or other data that are not accessible in a particular view may be grayed out or hidden from the menu displayed when the menu button 404 is selected in that view.” Note: this para teaches that access level can determine the amount of access the user have to data, thus higher the level, more data aa user can access.)
Regarding claim 29, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the vital signs monitoring device of claim 1.
AI-Ali teaches wherein the higher access level provides, on the dynamic interface, functionality for both adjusting the one or more alarm limits and muting the alarm, and wherein the lower access level omits at least one of the functionality for adjusting the one or more alarm limits and the functionality for muting the alarm(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.....” Note: Setzer also teach alarm setting based on access level, Al-Ali is used to explicitly teach adjustment including muting.
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…”)
)
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, ”)
Claim 30 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 O'Connor et al. (US 20220072321 A1)
Regarding claim 30, Setzer as modified by Al-Ali , DE WAELE and Gondek teaches the vital signs monitoring device of claim 1.
Setzer as modified by Al-Ali , DE WAELE and Gondek does not explicitly teach
wherein receiving the identifier for the caregiver via the login at the vital signs monitoring device includes receiving credentials identifying the caregiver through scanning a badge at the vital signs monitoring device.
O'Connor teaches wherein receiving the identifier for the caregiver via the login at the vital signs monitoring device includes receiving credentials identifying the caregiver through scanning a badge at the vital signs monitoring device(para, “[0150] In certain embodiments, if a credentialed user has been authenticated at the companion device (312), then in some examples, the companion device 110, 111, 119, 204 may customize one or more companion device display views to user preferences or a treatment role of the user (316) based on stored role data 258a customization data 260a as discussed further below. In some examples, if less than a threshold amount of time has passed between uses of the companion device 110, 111, 119, 204, the companion device 110, 111, 119, 204 may automatically authenticate a previous user to use the companion device 110, 111, 119, 204. Otherwise, if more than the threshold period of time has passed and/or a new user is logging in to use the companion device, then in some implementations, the companion device 110, 111, 119, 204 may authenticate the user with received credentials, such as username/password inputs, at least one biometric input provided at a biometric input interface (e.g., fingerprint, iris recognition, facial recognition), and/or a badge scan via a scanning sensor on the companion device (e.g., RFID scan or a computer-readable code such as a QR code) (314). In some examples, upon authentication, the user may provide one or more inputs confirming or modifying a treatment role of the user in the associated medical event......”)
It would have been obvious for a person of ordinary skill in the art to incorporate scanning a badge for identification teaching of O'Connor into the teachings of Setzer as modified by Al-Ali , DE WAELE and Gondek at the time the application was filed in order to apply a well-known technique of scanning a badge for identity. ( para, [0150]...... if more than the threshold period of time has passed and/or a new user is logging in to use the companion device, then in some implementations, the companion device 110, 111, 119, 204 may authenticate the user with received credentials, such as username/password inputs, at least one biometric input provided at a biometric input interface (e.g., fingerprint, iris recognition, facial recognition), and/or a badge scan via a scanning sensor on the companion device (e.g., RFID scan or a computer-readable code such as a QR code) (314).
Response to Arguments
Applicant's arguments filed on 05/29/2026 have been fully considered but they are not persuasive.
Remarks - 35 USC § 101
Subject Matter Eligibility declaration:
The applicant states that technical problem of false alarm is being solved, and the applicant contends on pg. 4 of the declaration : “the subject matter covered in the pending claims improves the technology of vital signs monitoring devices. The improvement is not merely that information is analyzed, but rather changes the operational behavior of the physical hardware components of the monitoring device - specifically, the conditions under which the alarm light bar activates - during the continuous monitoring workflow.”
However, the false alarm issue is not related to physical hardware component of the device. Pg. 1 of the declaration states, “at the time the application was filed, the technical problem of false alarm generation by vital signs monitoring devices in patient monitoring environments was well-recognized. Prior art vital signs monitoring devices used fixed, generic alarm threshold settings that were not tailored to any individual patient's physiological baseline. This was and remains a significant technical cause of excessive false alarms in clinical monitoring.” Adjusting alarm threshold to any individual patient’s physiological baseline, is not an improvement to device’s hardware, instead , it is a setting; Also, the limitation of adjusting alarm threshold setting to patient’s baseline is abstract idea itself. This is no different than not being alarmed if patient’s blood pressure is 75, when the physician knows that patient blood pressure reading is always on low side. That’s why vital sign reports are presented in ranges , because every person will have different value of the same test , so range covers a lot of people. Using this information to set alarm, is rule based decision making, rather than an improvement to device’s hardware. Also, the claims mainly focus on role based access level, as it will be addressed in remarks.
Applicant on pg. 4 of declaration contends, “the claimed invention achieves a further technical improvement to the vital signs monitoring device through its integration of role-based access control with the alarm limit adjustment functionality via the dynamic interface. Claim 1 as amended implements this architecture by the dynamic interface being configured based upon the access level of the caregiver, where the lower access level allows the caregiver only to capture and save physiological parameters, and where the higher access level provides the additional functionality of accessing historical physiological information, receiving the patient-specific alarm limit recommendation, and accepting the adjusted alarm limits. The input to mute an alarm triggered by a physiological parameter exceeding the alarm limits is itself displayed on the dynamic interface based on the access level, meaning that the physical alarm output - the alarm light bar - cannot be silenced by a caregiver whose access level does not authorize that function.”
The applicant is stating that role-based access is being applied; this is not a technical improvement. The use of role-based access is well known, in almost all the fields. For example, a nurse can’t perform a surgery, and will not be allowed to perform the surgery; but a surgeon can perform the surgery. A visitor or patient can’t change the machine configuration in operation room(due to access restriction) , but the physician can. The same idea applies to accessing the information, it is well known that people with appropriate credentials can access the information. The access level that database administrative has, (e.g. to access data, modify, manipulate) , the end user can’t have that access. In this case, enabling/disabling certain feature from interface is also not an improvement to display device, rather it is access restriction. Also, role based access and privileges can be found in any walk of life; implementing these ideas by applying the computer/device is not a technical improvement.
Also regarding the state of art, though the 35 U.S.C 101 analysis are separate from prior art, the prior arts do reflect the state of art at the time before the filing of application.
Remarks:
In remarks, Pg. 8 , applicant contends: “These claimed operations are rooted in the functioning of a specialized physiological monitoring device and are not the type of concepts that can practically be performed in the human mind. The claims therefore do not recite a mental process under the USPTO's subject matter eligibility guidance. See MPEP § 2106.04(a)(2). “
Please see 35 U.S.C 101 analysis, the examiner have identified the hardware elements to be additional limitations, and addressed each of the elements. The examiner is not saying that one can use the module to capture the data using paper and pen, but the use of these modules to capture, configure, and display data is on apply it level. For example, all the clinics have the monitoring devices, that are used to collect patients physiological values, such as blood oxygen content, temperature etc. . there is no detail about the device , ow it is being improved. ; the use of dynamic configuration of device based on role, or access level is an additional limitation, but the claims or the specification don’t provide any detail discussion as how the dynamic configuration is being improved.
The applicant contends on pg. 14 : “Specifically, the SMED explains that, at the time of filing, prior art vital signs monitoring devices used fixed, generic alarm threshold settings that were not tailored to an individual patient's physiological baseline, and that this conventional approach was a technical cause of excessive false alarms in clinical monitoring environments. The prior art focused on post-hoc algorithmic filtering and context-based false alarm probability calculations rather than the claimed architecture for deriving and operationalizing patient-specific alarm thresholds.
The SMED further establishes that the declarant was not aware of prior systems that
combined the specific features recited in amended claim 1, namely systems that: derived patient- specific alarm limits from historical physiological data captured by the device's own sensor modules; restricted access to historical physiological data and alarm-adjustment functionality based on caregiver access level; and applied those adjusted alarm thresholds in a monitoring workflow to control alarm triggering on the device's physical alarm output.”
The argument has been addressed, under declaration section above.
Applicant contends on pg. 14 : “The inventive concept is also reflected in how the claimed architecture changes operation of the vital signs monitoring device itself. In amended claim 1, physiological data does not merely get collected, displayed, or analyzed for informational purposes. Instead, the claimed architecture uses patient-specific historical physiological information to reconfigure the operational thresholds that govern activation of the physical alarm light bar during the monitoring workflow. That is, the claimed system changes the device-control flow. The claimed subject matter provides a closed-loop monitoring-device architecture that links physical sensor inputs, patient-specific historical physiological data, access-level-gated configuration, and physical alarm output control. The claim therefore recites significantly more than merely presenting information or applying a generic rule.”
All the arguments have similar point; the applicant is stating, reconfiguring the operation of device as an improvement, that solves the technical problem; but, configuring a device is not an improvement, For any device to function, it has to be configured in medical setting, all the devices are configured to collect information, and display; changing the setting of the device is not a technical improvement. The device in this application is a medical device, which is a hardware device that is capable of being configured.
Applicant contends on pg. 15 : “the claimed subject matter is analogous to the eligible ordered combination in BASCOM, where the Federal Circuit held that an inventive concept may be found in the non-conventional and non-generic arrangement of known components. Here, amended claim 1 recites a specific ordered arrangement that was not conventional. In particular, the claim combines: (1) patient- specific alarm threshold generation; (2) historical physiological information acquired from physical sensor modules; (3) access-level-gated dynamic interface functionality; (4) access-level- based acceptance of alarm-limit recommendations; (5) access-level-based alarm muting; and (6) application of adjusted patient-specific thresholds to a series of physiological measurements to control activation of a physical alarm light bar.
This combination provides a specific technological arrangement for improving
monitoring-device alarm behavior.”
The above argument, and applicant’s own declaration makes it clear that technical problem solution lies in solving false positive problem, by the use of tailoring the operations to patient’s baseline. This concept, itself is an abstract idea. Access level-based alarming is an abstract idea; role based features is abstract idea. The applicant is applying device to execute these abstract ideas, by configuring the device. As it has been shown multiple times, configuring the device as claimed , don’t provide any improvement to the device’s hardware, or in the method of how the device is being configured. The majority of statement in the remarks are merely conclusory emphasizing , that it is a technical improvement, or solves a technical problem.
Regarding BASCOM, the case facts are not relevant. In BASCOM, the installation of a filtering tool at a specific location, remote from the end-users, with customizable filtering features specific to each end user, presented a non-conventional and non-generic arrangement of the additional elements. In instant case, all the hardware elements are present in monitoring medical device such as the one used when checking in; the examiner already have explained why configuring the device is not an improvement. The applicant’s solution to problem of applying the tailored configuration to patient’s baseline, is an abstract idea itself. The examiner have considered the additional elements in combination, as well as individually, when determining whether a claim as a whole amounts to significantly more, and deemed that claimed arrangement is conventional and generic arrangement of known, conventional elements at apply it level.
Remarks - 35 USC § 103
In remarks, Pg. 17, applicant contends:
“The claimed subject matter closes an operational loop of the device because (1) historical physiological information acquired from monitoring the patient over time is accessed based on caregiver access level; (2) that accessed historical information is used to generate patient-specific upper and lower alarm limit recommendations for the physiological measurement modules; (3) those recommendations are displayed on a dynamic interface configured based upon caregiver access level; (4) the alarm limits are adjusted based on access-level acceptance of the recommendation on that dynamic interface; and (5) the adjusted limits are then used in a monitoring workflow to trigger an alarm when a measurement in the series of physiological measurements exceeds the adjusted upper or lower limit. No cited reference teaches or suggests this particular combination.”
The applicant has not presented any argument here, by pointing out any specific detail, rather providing conclusory statement. The examiner have addressed each limitation including the amended claim limitations. The examiner agrees no single reference teaches the entire claimed invention; however, the claims are not rejected as being anticipated.
Applicant argues, on pg. 20 “The Office Action's proposed combination assembles disparate teachings from four references: Setzer's ventilator GUI access views, Al-Ali's credential-based monitoring interface controls, De Waele's medical-monitor alarm recommendation system, and Gondek's multi- parameter vital signs measurement device. The Office Action does not provide an articulated reason why a person of ordinary skill in the art would have modified these references to arrive at the specific claimed architecture..... That rear architecture is not taught or suggested by the cited art. Rather, it can be arrived at only by using Applicant's disclosure as a roadmap, which is improper hindsight.”
The primary reference Setzer teaches the claimed invention, including “a ventilator system includes a ventilator configured for ventilating a patient based on a plurality of ventilation parameters, and a multi-level graphic user interface (GUI) coupled to the ventilator. The multi-level GUI may be configured to display a view menu allowing a user to select from multiple different views providing different levels of user access to the ventilation parameters. The multiple different views may include a first view and a second view. The first view may display values for a first set of ventilation parameters, and user access for adjusting the setting for at least one of the first set of the ventilation parameters. The second view may display values for a second set of the ventilation parameters, and access for adjusting the settings for at least one of the second set of the ventilation parameters. The second set of ventilation parameters may be larger than the first set of ventilation parameters.”
What the reference is missing is the details of some of the claimed functionalities in claimed manner, as claimed over multiple rounds of prosecution. In order to address these limitations as merely obvious , the examiner have brought in the reference to explicitly teach each of the limitation. In addition, for each combination, the examiner not only have provided the rational/motivation for combination, but also have provided the citations where the motivation was found, thus ensuring there is no question of improper hindsight. Furthermore, the applicant is merely providing a conclusory statement.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights