DETAILED ACTION
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.
1. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Regarding claim 1:
Claim 1 is directed to idea of itself (abstract idea) without significantly more for the following reason(s):
Step 1: Claim 1 recites an apparatus comprising a replaceable component and a controller that determines that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus, and the controller is operable to prompt a user to enter an authorization code at the user interface before executing the functionality of the replaceable component. Thus, the claim is directed to process/apparatus, which is one of the statutory categories of the invention.
Step 2A — Prong One (Judicial Exception)
1. Claim 1 is directed to the abstract idea of analyzing observed data to determine a correspondence between devices (a patient support apparatus and a replaceable component) and then inferring a relationship (that the replaceable component is properly authorized for use with the patient support apparatus). The claim recites performing an authorization check for use of the replaceable component with the patient support apparatus is a mental process—i.e., collecting and analyzing information to detect misuse and notifying a user when misuse is detected (FairWarning); data analysis, pattern recognition, and making determinations/inferences based on a model of the device. SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161 (Fed. Cir. 2018) (statistical/analytical concepts); MPEP § 2106.04.
2. The claim limitations reflecting the judicial exception include, inter alia: “determining that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus”, and “prompting a user to enter an authorization code at the user interface before executing the functionality of the replaceable component”. These steps recite evaluation and correlation of data—activities that can be characterized as mental processes of data.
Step 2A — Prong Two (Integration into a Practical Application)
3. The claim does not recite a specific improvement to the functioning of a patient support apparatus, a controller, and a replaceable component, or any other technology. The claim language merely recites performing a determination of functionality based on an authorization for use, without specifying particular signal processing techniques, sensor arrangements, sampling/processing parameters, hardware configuration, or other limitations that would meaningfully integrate the abstract idea into a technical application. See Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) (eligible where claims recite specific improvement to computer functionality).
4. The only physical elements recited (a patient support apparatus, a controller, and a replaceable component, user interface) are recited at a high level of generality and serve as the field of use for the claimed abstract idea. The “determining that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus” is Collecting and analyzing information to detect misuse and notifying a user when misuse is detected (FairWarning); the remainder of the claim results in an informational determination (that the replaceable device is not authorized to be used and an authorization code is requested for the functionality of the replaceable component with the patient support apparatus). There is no recited transformation of an article or specific machine integral to the claimed steps beyond generic computer/monitoring implementation. See Diamond v. Diehr, 450 U.S. 175 (1981) (claims eligible when directed to a process that effects a physical transformation); (claims that merely collect and analyze information held abstract).
Step 2B — “Significantly More” Analysis
5. The additional elements of the claim—“determining that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus”, and “prompting a user to enter an authorization code at the user interface before executing the functionality of the replaceable component” is to determine correspondence—are well-understood, routine, and conventional activities for monitoring systems and signal-analysis implementations absent specific non-conventional detail. As recited, these elements amount to Collecting and analyzing information to detect misuse and notifying a user when misuse is detected (FairWarning);.
6. The ordered combination of steps— determining that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus → Conclude to prompt a user to enter an authorization code at the user interface before executing the functionality of the replaceable component”—reflects a conventional information-processing workflow (collect/analyze/attribute/report) and does not recite an unconventional arrangement that effects a technological improvement. Absent claim limitations or evidence demonstrating that the recited “determining that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus” and “prompting a user to enter an authorization code at the user interface before executing the functionality of the replaceable component” is unconventional or yields a concrete technical improvement, the claim does not provide “significantly more.” See BASCOM Global Internet Servs. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016); Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018) (factual showing required to rebut a finding of well understood, routine, conventional).
Conclusion:
7. For the reasons stated above, Claim 1 is directed to an abstract idea (mental process of event correlation and attribution) and the additional recited elements, individually and as an ordered combination, do not add significantly more. Therefore, Claim 1 is rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Regarding dependent claims 2-20:
Dependent claims 2-20, The Judicial exception is not integrated into a practical application and said claims does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Therefore, the claims are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the functionality" in lines 12 and 16. There is insufficient antecedent basis for this limitation in the claim.
Claims 2-20 are rejected as stated above because due to their dependency from claim 1. Claims 2-20 are also indefinite.
Claim 2 recites the limitation "the functionality" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claims 3-10 are rejected as stated above because due to their dependency from claim 2. Claims 3-10 are also indefinite.
Claim 6 recites the limitation "the presence" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 6 recites the limitation "the functionality" in line 5. There is insufficient antecedent basis for this limitation in the claim.
Claims 7-10 are rejected as stated above because due to their dependency from claim 6. Claims 7-10 are also indefinite.
Claim 11 recites the limitation "the presence" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation "the functionality" in line 5. There is insufficient antecedent basis for this limitation in the claim.
Claims 12-20 are rejected as stated above because due to their dependency from claim 6. Claims 7-10 are also indefinite.
Claim 16 recites the limitation "the predefined acceptable operating condition" in lines 6-7. There is insufficient antecedent basis for this limitation in the claim.
Claims 17-20 are rejected as stated above because due to their dependency from claim 16. Claims 17-20 are also indefinite.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
1. Claim(s) 1-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Riley et al. (US2011/0068935A1) hereafter Riley in view of Bielstein (US2016/0117496A1), and further in view of Hampapuram et al. (US2016/0212783A1) hereafter Hampapuram.
Regarding claim 1, Riley discloses a patient support apparatus (fig 1:3014; par[0035]: The person support apparatus 3014 supports a person support surface 3026 on the upper frame 3018 as shown in FIGS. 2 and 3.) comprising,
a controller (fig 5:3074; par[0048], [0050]: The control module 3038 includes a controller 3074 or processor 3074 and memory 3076 as shown in FIG. 5), the controller coupled to memory (fig 5:3076; par[0048], [0050]: The controller 3074 is configured to receive input signals corresponding to signals from the sensors 3036 and/or output signals from other modules 3038 via the network 3042. The information is stored in the memory 3076, which is operatively coupled to the controller 3074 as shown in FIG. 5. It should be appreciated that the memory 3076 is integrated into the controller in some embodiments. The controller 3074 is configured to execute operating logic 3078 that defines various control, management, and/or regulation functions. This operating logic 3078 can be in the form of software, firmware, and/or dedicated hardware, such as, a series of programmed instructions, code, electronic files, or commands using general purpose or special purpose programming languages or programs that are executed on one or more general purpose or special purpose computers, processors, other control circuitry, or networks; a hardwired state machine ), and
a user interface (par[0058]: controller 3074 automatically calculates the condition score without the need for any further actions on the part of caregivers or users. However, it is within the scope of this disclosure for some or all of the needed physiological data to be entered by a caregiver using a user interface of the apparatus 3014.).
Riley does not explicitly disclose the patient support apparatus comprising: memory which stores a specific serial number for the patient support apparatus, a replaceable component, the replaceable component including memory which stores a specific serial number for the replaceable component, and wherein the controller is operable to determine that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus, and if the replacement component is not properly authorized for use with the patient support apparatus, the controller is operable to prompt a user to enter an authorization code at the user interface before executing the functionality of the replaceable component.
Bielstein discloses a patient support apparatus comprising,
a controller (fig 2:223; par[0017]: The host medical device 221 includes a controller 223, which further includes a processor 225 and a central memory 227), memory which stores a specific serial number for the patient support apparatus (fig 2:235; par[0017], [0018]: The authenticator memory 235 includes a data store 237 of one or more secrets. As above, the secret(s) may each be a lengthy binary number, hexadecimal number, or other alphanumeric value sufficiently distinct that it is computationally difficult to predict),
a replaceable component (fig 2:201; par[0025]: In operation, when a new accessory 201 is attached to the host medical device 221, such as may occur during a replacement), the replaceable component including memory which stores a specific serial number for the replaceable component (fig 2:205; par[0015], [0020]: The accessory 201 includes an authenticator 203 and a memory 205. The memory 205 further includes a “secret” 207. when the accessory 201 is manufactured, it is programmed with a given “secret” value (secret 207). The secret 207 could be a value unique to only that one specific accessory 201, or it could be a value unique to a particular model of accessory, or it could simply be a value assigned by the manufacturer and known only to the manufacturer.), and
wherein the controller is operable to determine that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus (Bielstein par[0028]: if the authenticator co-processor 231 is unable to match the MAC returned from the accessory 201 with any locally-generated MAC using valid stored secrets, then the host medical device 221 rejects the accessory 201 as being unauthorized. In the simplest example, unauthorized could mean that the accessory is simply out of date (expired). Alternatively, unauthorized could mean that the accessory 201 was not manufactured by an authorized manufacturer.), and if the replacement component is not properly for use with the patient support apparatus (Bielstein par[0028]: if the authenticator co-processor 231 is unable to match the MAC returned from the accessory 201 with any locally-generated MAC using valid stored secrets, then the host medical device 221 rejects the accessory 201 as being unauthorized).
One of ordinary skill in the art would be aware of both the Riley and the Bielstein references since both pertain to the field of medical systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the downhole inductive coupling system of Riley to implement the replacement component feature as disclosed by Bielstein to gain the functionality of providing intelligent accessories, which may be used as replacement components of a host medical device, wherein the intelligent accessories are configured with an onboard processor, which performs computations to authenticate the accessory to the host medical device, may evaluate and report other characteristics of the accessory to ensure that it is the proper accessory for the host medical device.
Riley in view of Bielstein does not explicitly disclose the feature of prompting a user to enter an authorization code at the user interface before executing the functionality of the replaceable component.
Hampapuram discloses the patient support apparatus wherein the controller is operable to prompt a user to enter an authorization code at the user interface before executing the functionality of the replaceable component (par[0081]: Communications may initially be established using a fixed key. The fixed key can be based on a transmitter identifier or a portion of a transmitter identifier printed on the continuous glucose sensor system 100 or transmitter 101. The user may enter the transmitter identifier into the dedicated display 104a and display 106a to establish communications. The transmitter identifier may also be sent from continuous glucose sensor system 100 to the dedicated display 104a and display 106a, so that a comparison can be made between the transmitter identifier received from the continuous glucose sensor system 100 and the transmitter identifier entered by a user. When the transmitter identifiers match, communications may be allowed, or additional security steps may occur to further authenticate the two devices).
One of ordinary skill in the art would be aware of the Riley, Bielstein and Hampapuram references since both pertain to the field of medical systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the downhole inductive coupling system of Riley to implement the user feature as disclosed by Hampapuram to gain the functionality of providing secure communications within the system by ensuring that communications only occur between approved, authenticated devices can be a key to offering users an appropriate level of security given the sensitive nature of the data being transmitted.
Regarding claim 2, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 1, wherein, if the controller determines that the functionality of the replaceable component is properly authorized by comparing the serial number of the patient support apparatus and the serial number of the replaceable component (Bielstein par[0025], [0027]: In operation, when a new accessory 201 is attached to the host medical device 221, such as may occur during a replacement, the accessory 201 authenticates itself to the host medical device 221. In one embodiment, such authentication occurs as a challenge/response secure authentication between the authenticator 203 of the accessory 201 and the authenticator co-processor 231 of the host medical device 221. The host medical device 221 provides the seed value to the authenticator 203 of the accessory. The authenticator 203 then creates a Message Authentication Code (“MAC”) value based on the seed value from the host in combination with the accessory's stored secret 207. In one particular implementation, the MAC value is created using a hashing algorithm (e.g., the SHA-256 hashing algorithm) on a combination of the seed value and the accessory's stored secret 207. It will be appreciated that the hashing algorithm creates a unique hash value for every different input data. Thus, a hash of the stored secret 207 will always return the same hash value provided the same hashing algorithm is used. However, by hashing a combination of the seed value with the stored secret 207, a different hash value (MAC) will always result so long as the seed values are different.), and only enables operation of the replacement component if an acceptable authorization code has been entered (par[0026], [0027], [0028]: If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201.).
Regarding claim 3, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 2, wherein the controller determines the authorization code based, at least in part, on the serial number of the replaceable component (Bielstein par[0026], [0027]: In one implementation, the accessory 201 is connected to the host medical device 221, the authenticator co-processor 231 initiates the authentication by providing to the authenticator 203 some seed value, such as a pseudo random value generated by random number generator 233. The seed is considered pseudo random because it may be created in such a manner that it cannot be recreated later. In other words, the pseudo random value may be generated in such a way that it would not be a valid value if created at a later date (e.g., by being partially based on the current date). Such a feature helps reduce the possibility that the challenge/response authentication scheme could be copied and reproduced later by an unauthorized device. The host medical device 221 provides the seed value to the authenticator 203 of the accessory. The authenticator 203 then creates a Message Authentication Code (“MAC”) value based on the seed value from the host in combination with the accessory's stored secret 207. In one particular implementation, the MAC value is created using a hashing algorithm (e.g., the SHA-256 hashing algorithm) on a combination of the seed value and the accessory's stored secret 207. It will be appreciated that the hashing algorithm creates a unique hash value for every different input data. Thus, a hash of the stored secret 207 will always return the same hash value provided the same hashing algorithm is used.).
Regarding claim 4, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 3, wherein the authorization code is based, at least in part, on the serial number of the patient support apparatus (Bielstein par[0028]: The authenticator 203 returns the MAC to the host medical device 221. The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237. If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201).
Regarding claim 5, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 2, wherein the authorization code is based, at least in part, on the serial number of the patient support apparatus (Bielstein par[0028]: The authenticator 203 returns the MAC to the host medical device 221. The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237. If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201).
Regarding claim 6, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 2, wherein the controller monitors for the presence of the replaceable component and regularly compares the serial number of the replaceable component with a serial number of an authorized replaceable component (Bielstein par[0025], [0028]: In operation, when a new accessory 201 is attached to the host medical device 221, such as may occur during a replacement, the accessory 201 authenticates itself to the host medical device 221. In one embodiment, such authentication occurs as a challenge/response secure authentication between the authenticator 203 of the accessory 201 and the authenticator co-processor 231 of the host medical device 221. The authenticator 203 returns the MAC to the host medical device 221. The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237.) to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component (Bielstein par[0028]: if the authenticator co-processor 231 is unable to match the MAC returned from the accessory 201 with any locally-generated MAC using valid stored secrets, then the host medical device 221 rejects the accessory 201 as being unauthorized. In the simplest example, unauthorized could mean that the accessory is simply out of date (expired). Alternatively, unauthorized could mean that the accessory 201 was not manufactured by an authorized manufacturer) if a different replaceable component has been connected to the controller (Bielstein par[0028]: If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201).
Regarding claim 7, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 6, wherein, if the controller determines that the different replaceable component has been substituted (Bielstein par[0028]: The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237. If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201), the controller prompts the user to enter an authorization code for the substituted replaceable component at the user interface (Hampapuram par[00810], [0081]: Communications may initially be established using a fixed key. The fixed key can be based on a transmitter identifier or a portion of a transmitter identifier printed on the continuous glucose sensor system 100 or transmitter 101. The user may enter the transmitter identifier into the dedicated display 104a and display 106a to establish communications. When the transmitter identifiers match, communications may be allowed, or additional security steps may occur to further authenticate the two devices. After pairing devices, a user may also enter a prompt through a display to switch to another device. In one embodiment, the user may be actively communicating with the continuous glucose sensor system 100 using a dedicated display and a smart phone and may want to switch to using the dedicated display and a tablet. The user may enter a command through a user interface on any of the smart phone, the dedicated display, or the tablet to request the switch).
Regarding claim 8, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 7, wherein the patient support apparatus comprises a detection and notification system for monitoring at least one vital sign of a patient supported on the patient support apparatus (Riley fig 5:3036; par[0042]: The sensors 3036 are configured to sense a variety of parameters, including, but not limited to, for example, a person's physiological information, a position of a person on the person support apparatus 3014 and/or person support surface 3026, a pressure of the fluid inside the bladders 3028 in the person support surface 3026, or other various parameters. In one illustrative embodiment, the contact sensors 3044 include blood pressure sensors 3048 that are configured to sense the person's blood pressure; oxygen saturation level (SpO2) sensors 3050 that are configured to sense the amount of hemoglobin binding sites in the person's bloodstream occupied by oxygen; temperature sensors 3052 that are configured to sense the person's body temperature; heart rate sensors 3054 that are configured to sense the rate at which a person's heart contracts; and respiration rate sensors 3056 that are configured to sense the person's breathing rate as shown in FIG. 5. It should be appreciated that the SpO2 sensors 3050 comprise a pulse oximeter device in some embodiments. It should be appreciated that the contact sensors 3044 are configured to measure other physiological and biochemical parameters in other embodiments.) and the replaceable component is a vital sign sensor (Hampapuram fig 1:103; par[0056], [0058]: A small sensor 103 can be placed on or into the patient to obtain readings of glucose values using, for example, subcutaneous glucose or blood glucose readings. The sensor portion 103 of the continuous glucose sensor system 100 may be removable and replaceable, allowing a patient to change to a new sensor periodically, such as every week).
Regarding claim 9, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 8, wherein the detection and notification system comprises multiple sensors (Riley fig 5:3036; par[0042]: The sensors 3036 are configured to sense a variety of parameters, including, but not limited to, for example, a person's physiological information, a position of a person on the person support apparatus 3014 and/or person support surface 3026, a pressure of the fluid inside the bladders 3028 in the person support surface 3026, or other various parameters. In one illustrative embodiment, the contact sensors 3044 include blood pressure sensors 3048 that are configured to sense the person's blood pressure; oxygen saturation level (SpO2) sensors 3050 that are configured to sense the amount of hemoglobin binding sites in the person's bloodstream occupied by oxygen; temperature sensors 3052 that are configured to sense the person's body temperature; heart rate sensors 3054 that are configured to sense the rate at which a person's heart contracts; and respiration rate sensors 3056 that are configured to sense the person's breathing rate as shown in FIG. 5. It should be appreciated that the SpO2 sensors 3050 comprise a pulse oximeter device in some embodiments. It should be appreciated that the contact sensors 3044 are configured to measure other physiological and biochemical parameters in other embodiments.), each sensor being monitored by the controller to determine that the patient support apparatus has been authorized for each of the sensors (Bielstein par[0025], [0028]: In operation, when a new accessory 201 is attached to the host medical device 221, such as may occur during a replacement, the accessory 201 authenticates itself to the host medical device 221. In one embodiment, such authentication occurs as a challenge/response secure authentication between the authenticator 203 of the accessory 201 and the authenticator co-processor 231 of the host medical device 221. The authenticator 203 returns the MAC to the host medical device 221. The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237.).
Regarding claim 10, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 9, wherein the controller provides an indication of a status of the authorization at the user interface (Bielstein par[0037]: In this exchange the host initiates an authentication with the accessory and computes a message authentication code (MAC) based on data and a secret (step 501). If host cannot verify the MAC (step 503), the authentication fails and the user may be notified (step 505). If the accessory is deemed authentic (step 503) the host will send to the accessory the current date (step 507). The accessory then determines whether the accessory is expired by comparing (step 509) the current date (from the host) with stored information about when it expires or, perhaps, when the accessory was created together with information about how long the accessory is valid. Based on whether the accessory has expired (step 511) or has not expired (step 513), the accessory will report the proper response to the host. The host can notify the user whether the accessory is authentic, expired (if applicable) and other useful data such as, perhaps, preprocessed functionality (step 515).).
Regarding claim 11, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus of claim 1, wherein the controller monitors for the presence of a replaceable component and regularly compares the serial number of the replaceable component with the serial number of the authorized replaceable component (Bielstein par[0025], [0028]: In operation, when a new accessory 201 is attached to the host medical device 221, such as may occur during a replacement, the accessory 201 authenticates itself to the host medical device 221. In one embodiment, such authentication occurs as a challenge/response secure authentication between the authenticator 203 of the accessory 201 and the authenticator co-processor 231 of the host medical device 221. The authenticator 203 returns the MAC to the host medical device 221. The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237.) to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component (Bielstein par[0028]: if the authenticator co-processor 231 is unable to match the MAC returned from the accessory 201 with any locally-generated MAC using valid stored secrets, then the host medical device 221 rejects the accessory 201 as being unauthorized. In the simplest example, unauthorized could mean that the accessory is simply out of date (expired). Alternatively, unauthorized could mean that the accessory 201 was not manufactured by an authorized manufacturer) if a different replaceable component has been connected to the controller (Bielstein par[0028]: If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201).
Regarding claim 12, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus wherein, if the controller determines that a replaceable component has been substituted (Bielstein par[0028]: The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237. If a comparison of the MAC returned from the accessory 201 results in a match with any MAC locally created by the authenticator co-processor 231 from valid stored secrets, then the host medical device 221 accepts that the accessory 201 is an authorized accessory 201), the controller prompts the user to enter an authorization code for the substituted replaceable component at the user interface (Hampapuram par[00810], [0081]: Communications may initially be established using a fixed key. The fixed key can be based on a transmitter identifier or a portion of a transmitter identifier printed on the continuous glucose sensor system 100 or transmitter 101. The user may enter the transmitter identifier into the dedicated display 104a and display 106a to establish communications. When the transmitter identifiers match, communications may be allowed, or additional security steps may occur to further authenticate the two devices. After pairing devices, a user may also enter a prompt through a display to switch to another device. In one embodiment, the user may be actively communicating with the continuous glucose sensor system 100 using a dedicated display and a smart phone and may want to switch to using the dedicated display and a tablet. The user may enter a command through a user interface on any of the smart phone, the dedicated display, or the tablet to request the switch. ).
Regarding claim 13, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus wherein the patient support apparatus comprises a detection and notification system for monitoring at least one vital sign of a patient supported on the patient support apparatus (Riley fig 5:3036; par[0042]: The sensors 3036 are configured to sense a variety of parameters, including, but not limited to, for example, a person's physiological information, a position of a person on the person support apparatus 3014 and/or person support surface 3026, a pressure of the fluid inside the bladders 3028 in the person support surface 3026, or other various parameters. In one illustrative embodiment, the contact sensors 3044 include blood pressure sensors 3048 that are configured to sense the person's blood pressure; oxygen saturation level (SpO2) sensors 3050 that are configured to sense the amount of hemoglobin binding sites in the person's bloodstream occupied by oxygen; temperature sensors 3052 that are configured to sense the person's body temperature; heart rate sensors 3054 that are configured to sense the rate at which a person's heart contracts; and respiration rate sensors 3056 that are configured to sense the person's breathing rate as shown in FIG. 5. It should be appreciated that the SpO2 sensors 3050 comprise a pulse oximeter device in some embodiments. It should be appreciated that the contact sensors 3044 are configured to measure other physiological and biochemical parameters in other embodiments.) and the replaceable component is a vital sign sensor (Hampapuram fig 1:103; par[0056], [0058]: A small sensor 103 can be placed on or into the patient to obtain readings of glucose values using, for example, subcutaneous glucose or blood glucose readings. The sensor portion 103 of the continuous glucose sensor system 100 may be removable and replaceable, allowing a patient to change to a new sensor periodically, such as every week).
Regarding claim 14, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus wherein the detection and notification system comprises multiple sensors (Riley fig 5:3036; par[0042]: The sensors 3036 are configured to sense a variety of parameters, including, but not limited to, for example, a person's physiological information, a position of a person on the person support apparatus 3014 and/or person support surface 3026, a pressure of the fluid inside the bladders 3028 in the person support surface 3026, or other various parameters. In one illustrative embodiment, the contact sensors 3044 include blood pressure sensors 3048 that are configured to sense the person's blood pressure; oxygen saturation level (SpO2) sensors 3050 that are configured to sense the amount of hemoglobin binding sites in the person's bloodstream occupied by oxygen; temperature sensors 3052 that are configured to sense the person's body temperature; heart rate sensors 3054 that are configured to sense the rate at which a person's heart contracts; and respiration rate sensors 3056 that are configured to sense the person's breathing rate as shown in FIG. 5. It should be appreciated that the SpO2 sensors 3050 comprise a pulse oximeter device in some embodiments. It should be appreciated that the contact sensors 3044 are configured to measure other physiological and biochemical parameters in other embodiments.), each sensor being monitored by the controller to determine that the patient support apparatus has been authorized for each of the sensors (Bielstein par[0025], [0028]: In operation, when a new accessory 201 is attached to the host medical device 221, such as may occur during a replacement, the accessory 201 authenticates itself to the host medical device 221. In one embodiment, such authentication occurs as a challenge/response secure authentication between the authenticator 203 of the accessory 201 and the authenticator co-processor 231 of the host medical device 221. The authenticator 203 returns the MAC to the host medical device 221. The authenticator co-processor 231 then performs its own hash of the seed value (which the host created) with each of the valid secrets 237 stored in the authentication memory 235. Again, because the authenticator co-processor 231 uses the same hashing algorithm as the authenticator 203, the authenticator co-processor 231 will be able to recreate the same MAC by hashing the known seed in combination with the stored valid secrets 237.).
Regarding claim 15, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus wherein the controller provides an indication of a status of the authorization at the user interface (Bielstein par[0037]: In this exchange the host initiates an authentication with the accessory and computes a message authentication code (MAC) based on data and a secret (step 501). If host cannot verify the MAC (step 503), the authentication fails and the user may be notified (step 505). If the accessory is deemed authentic (step 503) the host will send to the accessory the current date (step 507). The accessory then determines whether the accessory is expired by comparing (step 509) the current date (from the host) with stored information about when it expires or, perhaps, when the accessory was created together with information about how long the accessory is valid. Based on whether the accessory has expired (step 511) or has not expired (step 513), the accessory will report the proper response to the host. The host can notify the user whether the accessory is authentic, expired (if applicable) and other useful data such as, perhaps, preprocessed functionality (step 515).).
2. Claims 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Riley in view of Bielstein and Hampapuram, and further in view of Zerhusen et al. (US2014/0259410A1) hereafter Zerhusen.
Regarding claim 16, Riley in view of Bielstein and Hampapuram discloses the patient support apparatus wherein the notification system is operable to process signals from the vital sign sensor which provide an indication of a vital sign (Riley par[0051], [0065]: The controller 3074 includes operating logic 3078 in the form of procedure 3080, for example, as shown in the flowchart of FIG. 6. Procedure 3080 includes operations/conditionals shown at blocks 3082, 3084, 3086, and 3088. Procedure 3080 is used to generate a condition score corresponding to the condition of a person, which is compared to a threshold in order to predict the onset of an adverse condition. Further, figure 6 discloses in the operation of block 3090, the controller 3074 compares the calculated condition score (referred to sometimes in FIG. 6 as an "index value" or simply an "index") with the predetermined thresholds to determine at least one of the likelihood that an adverse condition will occur, an amount of time before an adverse condition will occur, and/or how close the condition score is to the threshold), compare the vital sign to a predefined acceptable limit, and, if the vital sign deviates from the predefined acceptable limit (Riley fig 6:3110, par[0066]: the conditional of block 3100, if the controller 3074 determines that the condition score is greater than the threshold, then, in one illustrative embodiment, a status update including the condition score is communicated to a caregiver through the signaling and communication system 3012 and/or is displayed on the display 3040 as indicated at block 3110).
Riley in view of Bielstein and Hampapuram does not explicitly disclose the patient support apparatus wherein the at least one sensor able provide a visual indication of the deviation by illuminating a first iconic representation of vital signs in a first manner; if the vital sign does not deviate from the predefined acceptable operating condition for that component, illuminating the first iconic representation in a second manner.
Zerhusen discloses the patient support apparatus wherein the at least one sensor able provide a visual indication of the deviation by illuminating a first iconic representation of vital signs in a first manner (Zerhusen par[0160], [0161]: Control circuitry 72 controls the illumination of alert light based on the sleep state of the patient, as measured by sensor(s) 800, so as to indicate an optimal time for a caregiver to take at least one vital sign of the patient. The optimal time for the caregiver to take the at least one vital sign is when the signal from sensor 800 indicates that the sleep state of the patient is a deep sleep state. In other instances, the optimal time for the caregiver to take the at least one vital sign is when the signal from the sensor 800 indicates that the sleep state of the patient is an alert state of sleep), if the status of the particular component does not deviate from the established acceptable operating condition for that component, illuminating the first iconic representation in a second manner (Zerhusen par[0160], [0161]: Control circuitry 72 controls the illumination of alert light based on the sleep state of the patient, as measured by sensor(s) 800, so as to indicate an optimal time for a caregiver to take at least one vital sign of the patient. The optimal time for the caregiver to take the at least one vital sign is when the signal from sensor 800 indicates that the sleep state of the patient is a deep sleep state. In other instances, the optimal time for the caregiver to take the at least one vital sign is when the signal from the sensor 800 indicates that the sleep state of the patient is an alert state of sleep).
One of ordinary skill in the art would be aware of the Riley, Bielstein, Hampapuram and Zerhusen references since all pertain to the field of patient support apparatuses. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the patient support apparatus of Riley to implement the feature of illumination as disclosed by Zerhusen to gain the functionality of illuminating an alert light in a manner indicating an optimal time for taking a patient's vital signs.
Regarding claim 17, Riley in view of Bielstein, Hampapuram and Zerhusen discloses the patient support apparatus of claim 16, wherein the notification system is operable to project the first iconic representation to a surface spaced apart from the patient support apparatus (Zerhusen fig 20:418, par[0140], [0141]: Some of the light emitted from the respective light emitters (e.g. green LED and amber LED) passes through the respective cutout 416 and projects an image 418 of the cutout on the floor as shown in FIG. 20. Only one image 418 is projected on the floor in the illustrative example).
Regarding claim 18, Riley in view of Bielstein, Hampapuram and Zerhusen discloses the patient support apparatus of claim 17, wherein the first iconic representation is simultaneously illuminated on a surface of the patient support apparatus and projected onto the surface spaced apart from the patient support apparatus (Zerhusen fig 20:4411, par[0140], [0141]: wherein the iconic representations are projected on frames of the bed) and projected onto the surface spaced apart from the patient support apparatus (Zerhusen fig 20:418, par[0140], [0141]: Some of the light emitted from the respective light emitters (e.g. green LED and amber LED) passes through the respective cutout 416 and projects an image 418 of the cutout on the floor as shown in FIG. 20. Only one image 418 is projected on the floor in the illustrative example).
Regarding claim 19, Riley in view of Bielstein, Hampapuram and Zerhusen discloses the patient support apparatus of claim 18, wherein the first iconic representation is projected to the surface spaced apart from the patient support apparatus by a projector located on the patient support apparatus (Zerhusen fig 20:418, par[0140], [0141]: Some of the light emitted from the respective light emitters (e.g. green LED and amber LED) passes through the respective cutout 416 and projects an image 418 of the cutout on the floor as shown in FIG. 20. Only one image 418 is projected on the floor in the illustrative example).
Regarding claim 20, Riley in view of Bielstein, Hampapuram and Zerhusen discloses the patient support apparatus of claim 19, wherein illuminating the first iconic representation in a first manner comprises illuminating the first iconic representation in a first color (Zerhusen fig 20:418, par[0140], [0141], [0142]: two differently colored light emitters are located side-by-side in the interior region of housing 402 of module 400 for each of zones 411, 412, 413, 414, then the position of the image 418 on the floor will shift by a slight amount when module 400 switches from emitting light from the first light emitter to emitting light form the second light emitter, and vice versa. Thus, the spacing between the light emitters of each zone 411, 412, 413, 414 dictates how far the image 418 shifts on the floor) and illuminating the first iconic representation in a second manner comprises illuminating the first iconic representation in a second color (Zerhusen fig 20:418, par[0140], [0141]: two differently colored light emitters are located side-by-side in the interior region of housing 402 of module 400 for each of zones 411, 412, 413, 414, then the position of the image 418 on the floor will shift by a slight amount when module 400 switches from emitting light from the first light emitter to emitting light form the second light emitter, and vice versa. Thus, the spacing between the light emitters of each zone 411, 412, 413, 414 dictates how far the image 418 shifts on the floor).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
1. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over U.S. Patent No. US 12465295B2 hereafter Co-1.
Although the claims at issue are not identical, they are not patentably distinct from each other because both the instant Application and the Patent Application teaches the same concept of invention by disclosing a patient support apparatus comprising, a controller, a replaceable component, the replaceable component including memory which stores a specific serial number for the particular replaceable component, and a user interface, wherein the controller is operable determine that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus, and if the replacement component is not properly authorized for use with the patient support apparatus, the controller is operable to prompt a user to enter an authorization code at the user interface before executing the functionality of the replaceable component.
Instant Application # 19024475
Patent Application # Co-1
1. (Currently Amended) A patient support apparatus comprising, a controller, the controller coupled to memory which stores a specific serial number for the patient support apparatus, a replaceable component, the replaceable component including memory which stores a specific serial number for the particular replaceable component, and a user interface, wherein the controller is operable determine that the functionality of the replaceable component is not properly authorized for use with the patient support apparatus, and if the replacement component is not properly authorized for use with the patient support apparatus, the controller is operable to prompt a user to enter an authorization code at the user interface before executing the functionality of the replaceable component.
1. A patient support apparatus comprising, a controller, the controller coupled to memory which stores a first specific serial number for the patient support apparatus, a replaceable component, the replaceable component including the memory which stores a second specific serial number for the replaceable component, and a user interface, wherein the controller is operable to verify that the patient support apparatus is properly authorized to execute functionality of the replaceable component by detecting a presence of the replaceable component, evaluating the first serial number of the patient support apparatus, determining an authorization for use of the functionality of the replaceable component, and, if the functionality of the replaceable component is properly authorized, enabling operation of the replaceable component, wherein, if the controller determines that the functionality of the replaceable component is not properly authorized, the controller is operable to prompt a user to enter an authorization code before executing the functionality of the replaceable component at the user interface and only enables the operation of the replaceable component if an acceptable authorization code has been entered.
2. (Currently Amended) The patient support apparatus of claim 1, wherein, [[if]] the controller determines that the functionality of the replaceable component is properly authorized by comparing the serial number of the patient support apparatus and the serial number of the replaceable component and only enables operation of the replacement component if an acceptable authorization code has been entered.
5. The patient support apparatus of claim 1, wherein the controller monitors for the presence of the replaceable component and regularly compares the second serial number of the replaceable component with a serial number of an authorized replaceable component to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component if the different replaceable component has been connected to the controller.
3. (Currently Amended) The patient support apparatus of claim 2, wherein the controller determines the authorization code based, at least in part, on the serial number of the replaceable component.
2. The patient support apparatus of claim 1, wherein the controller determines the authorization code based, at least in part, on the second serial number of the replaceable component.
4. (Original) The patient support apparatus of claim 3, wherein the authorization code is based, at least in part, on the serial number of the patient support apparatus.
3. The patient support apparatus of claim 2, wherein the authorization code is based, at least in part, on the first serial number of the patient support apparatus.
5. (Original) The patient support apparatus of claim 2, wherein the authorization code is based, at least in part, on the serial number of the patient support apparatus.
3. The patient support apparatus of claim 2, wherein the authorization code is based, at least in part, on the first serial number of the patient support apparatus.
6. (Currently Amended) The patient support apparatus of claim 2, wherein the controller monitors for the presence of the replaceable component and regularly compares the serial number of the replaceable component with a serial number of an authorized replaceable component to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component if a different replaceable component has been connected to the controller.
5. The patient support apparatus of claim 1, wherein the controller monitors for the presence of the replaceable component and regularly compares the second serial number of the replaceable component with a serial number of an authorized replaceable component to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component if the different replaceable component has been connected to the controller.
7. (Currently Amended) The patient support apparatus of claim 6, wherein, if the controller determines that the different replaceable component has been substituted, the controller prompts the user to enter an authorization code for the substituted replaceable component at the user interface.
6. The patient support apparatus of claim 5, wherein, if the controller determines that the different replaceable component has been substituted, the controller prompts the user to enter the authorization code for the substituted different replaceable component at the user interface.
8. (Original) The patient support apparatus of claim 7, wherein the patient support apparatus comprises a detection and notification system for monitoring at least one vital sign of a patient supported on the patient support apparatus and the replaceable component is a vital sign sensor.
7. The patient support apparatus of claim 6, wherein the patient support apparatus comprises a detection and notification system for monitoring at least one vital sign of a patient supported on the patient support apparatus and the replaceable component is a vital sign sensor.
9. (Currently Amended) The patient support apparatus of claim 8, wherein the detection and notification system comprises multiple sensors, each sensor being monitored by the controller to determine that the patient support apparatus has been authorized for each of the sensors.
8. The patient support apparatus of claim 7, wherein the detection and notification system comprises multiple sensors, each sensor of the multiple sensors being monitored by the controller to determine that the patient support apparatus has been authorized for each of the multiple sensors.
10. (Currently Amended) The patient support apparatus of claim 9, wherein the controller provides an indication of a status of the authorization at the user interface.
9. The patient support apparatus of claim 8, wherein the controller provides an indication of a status of the authorization for the use of the functionality of the replaceable component at the user interface.
11. (Currently Amended) The patient support apparatus of claim 1, wherein the controller monitors for the presence of the replaceable component and regularly compares the serial number of the replaceable component with a serial number of an authorized replaceable component to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component if a different replaceable component has been connected to the controller.
10. The patient support apparatus of claim 1, wherein the controller monitors for the presence of the replaceable component and regularly compares the second serial number of the replaceable component with a serial number of an authorized replaceable component to determine if a different replaceable component has been substituted and disables the functionality of the replaceable component if the different replaceable component has been connected to the controller.
12. (Original) The patient support apparatus of claim 11, wherein, if the controller determines that a replaceable component has been substituted, the controller prompts the user to enter an authorization code for the substituted replaceable component at the user interface.
11. The patient support apparatus of claim 10, wherein, if the controller determines that the replaceable component has been substituted, the controller prompts the user to enter the authorization code for the substituted replaceable component at the user interface.
13. (Original) The patient support apparatus of claim 12, wherein the patient support apparatus comprises a detection and notification system for monitoring at least one vital sign of a patient supported on the patient support apparatus and the replaceable component is a vital sign sensor.
12. The patient support apparatus of claim 11, wherein the patient support apparatus comprises a detection and notification system for monitoring at least one vital sign of a patient supported on the patient support apparatus and the replaceable component is a vital sign sensor.
14. (Currently Amended) The patient support apparatus of claim 13, wherein the detection and notification system comprises multiple sensors, each sensor being monitored by the controller to determine that the patient support apparatus has been authorized for each of the particular sensor sensors.
13. The patient support apparatus of claim 12, wherein the detection and notification system comprises multiple sensors, each sensor of the multiple sensors being monitored by the controller to determine that the patient support apparatus has been authorized for each of the multiple sensors.
15. (Currently Amended) The patient support apparatus of claim 14, wherein the controller provides an indication of a status of the authorization at the user interface.
14. The patient support apparatus of claim 13, wherein the controller provides an indication of a status of the authorization for the use of the functionality of the replaceable component at the user interface.
16. (Currently Amended) The patient support apparatus of claim 13, wherein the notification system is operable to process signals from the replaceable vital sign sensor which provide an indication of a vital sign, compare the vital sign to a predefined acceptable limit, and, if the vital sign deviates from the established predefined acceptable limit, provide a visual indication of the deviation by illuminating a first iconic representation of vital signs in a first manner, if the status of the particular component vital sign does not deviate from the established predefined acceptable operating condition for that component, illuminating the first iconic representation in a second manner.
15. The patient support apparatus of claim 12, wherein the detection and notification system is operable to process vital signals from the vital sign sensor which provide an indication of the at least one vital sign, compare the at least one vital sign to a predefined acceptable limit, and, if the at least one vital sign deviates from the predefined acceptable limit, provide a visual indication of the deviation from the predefined acceptable limit by illuminating a first iconic representation of the vital signs in a first manner, if the at least one vital sign does not deviate from the predefined acceptable limit for the replaceable component, illuminating the first iconic representation in a second manner.
17. (Original) The patient support apparatus of claim 16, wherein the notification system is operable to project the first iconic representation to a surface spaced apart from the patient support apparatus.
16. The patient support apparatus of claim 15, wherein the detection and notification system is operable to project the first iconic representation to a surface spaced apart from the patient support apparatus.
18. (Original) The patient support apparatus of claim 17, wherein the first iconic representation is simultaneously illuminated on a surface of the patient support apparatus and projected onto the surface spaced apart from the patient support apparatus.
17. The patient support apparatus of claim 16, wherein the first iconic representation is simultaneously illuminated on the surface of the patient support apparatus and projected onto the surface spaced apart from the patient support apparatus.
19. (Original) The patient support apparatus of claim 18, wherein the first iconic representation is projected to the surface spaced apart from the patient support apparatus by a projector located on the patient support apparatus.
18. The patient support apparatus of claim 17, wherein the first iconic representation is projected to the surface spaced apart from the patient support apparatus by a projector located on the patient support apparatus.
20. (Original) The patient support apparatus of claim 19, wherein illuminating the first iconic representation in a first manner comprises illuminating the first iconic representation in a first color and illuminating the first iconic representation in a second manner comprises illuminating the first iconic representation in a second color.
19. The patient support apparatus of claim 18, wherein said illuminating the first iconic representation in the first manner comprises illuminating the first iconic representation of the vital signs in a first color and illuminating the first iconic representation in the second manner comprises illuminating the first iconic representation in a second color.
Conclusion
Patent US11071666B2 to Emmons discloses a sleep apparatus, such as a mattress, comprises a head support surface sized to support a person's head, and a torso support surface sized to support a person's torso. The head support surface is generally laterally sloped moving from a first side toward a second side of the mattress, and the torso support surface is generally laterally sloped moving from the first side toward the second side. In some embodiments, the lateral slope of the head support surface is at least about 15°, the lateral slope of the head support surface is greater than the lateral slope of the torso support surface, and/or, the sleep apparatus slopes in the longitudinal direction as well.
US2020/0297955A1 to Shouldice discloses Systems and methods assist with managing a chronic disease of a user such as a chronic respiratory or cardiac disease. The system may include a physiological monitor adapted to be carried by the user and operative to sense a physiological parameter of the user. The system may include a management device operatively coupled with the physiological monitor to receive the sensed physiological parameter of the user. The management device, such as with an included processor, may be configured to analyze the physiological and/or environmental parameters to detect a trigger pattern of the parameters, the trigger pattern indicative of a probable event of exacerbation of the chronic respiratory and/or cardiac condition. The management device may then generate automated responses based on the trigger pattern such as by providing instructions for activities and/or treatment for the chronic condition.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMINE BENLAGSIR whose telephone number is (571)270-5165. The examiner can normally be reached (571)270-5165.
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, Curtis Kuntz can be reached on (571) 272 - 7499. 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.
/AMINE BENLAGSIR/Primary Examiner, Art Unit 2687