DETAILED ACTION
Claims 21-40 are presented for examination. Claims 21, 24, 31, 34, 36 and 39 are amended. This office action is response to the submission on 3/16/2026.
Response to Arguments
With respect to 35 U.S.C. §112(b) Rejections:
Applicant’s arguments, see pages 7-8 of applicant response filed 3/16/2026, with respect to claims 21, 31 and 36-37 have been fully considered and are persuasive. The 35 U.S.C. §112(b) Rejections of claims 21, 31 and 36-37 has been withdrawn.
With respect to 35 U.S.C. §102 Rejections:
Applicant’s arguments, see pages 8-9 of applicant response filed 3/16/2026, with respect to claims 21 and 31 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments, see pages 8-9 of applicant response filed 3/16/2026, with respect to claim 36 have been fully considered but they are not persuasive. Examiner notes that applicant’s argument relies upon the newly added “receiving the health operational status according to a predetermined schedule” limitation to claims 21 and 31. However, a similar limitation has not been added to claim 36.
With respect to 35 U.S.C. §103 Rejections:
Applicant’s arguments, see pages 9-10 of applicant response filed 3/16/2026, with respect to claims 22, 26, 32 and 37 have been considered but are moot because applicant’s argument relies solely on the arguments with respect to the 35 U.S.C. §102 Rejections addressed above.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 36 and 38-40 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Sinha et al. (US20220107632A1).
Claim 36:
Sinha teaches “A computer-implemented method for converting an operational status of a fixture for transmission to a building management system, the method being executed by a processor and comprising: receiving the operational status from an end-point device via a gateway device, (Sinha teaches devices 430 which may include a smart flushometer i.e. a fixture located within a facility comprising an electro-mechanical (EM) element which may be configured to send and receive communications in Sinha [0049] "Devices 430 may be smart connected building devices configured to send and receive communications with one or more controllers. For example, devices 430 may include a smart flushometers configured to send consumption data and receive duty flushing commands. In various embodiments, devices 430 are Bluetooth devices. In some embodiments, devices 430 may integrate with a building management system (such as BMS 460, etc.). For example, a conversion layer may convert Bluetooth packets from devices 430 into a protocol used by BMS 460 (e.g., BACnet, Modbus, etc.) to facilitate bi-directional communication. In various embodiments, devices 430 are electronic devices such as automatic soap dispensers or touchless faucets."; Sinha teaches that devices 430 may be a variety of device types and that they may dispense soap for example i.e. the device 430 is communicably coupled to the EM element in Sinha [0050] "Devices 430 are shown to include faucets 402, sanitizing dispensers 404, driers 406, flushing systems 408, towel dispenser 410, water dispenser 412, cleaning system 414, locking system 416, activity sensor(s) 418, occupancy sensor(s) 420, blockage detection 422, leak detection 424, lighting 426, and disinfectant systems 428. Faucets 402 may be or include a valve for controlling the release of a liquid such as water for use in hand washing. In some embodiments, faucets 402 are automatic (e.g., touchless faucet, etc.). Sanitizing dispensers 404 may be or include a device that dispenses soap or other disinfectants such as alcohol based disinfectants."; Sinha teaches that devices may transmit a current status i.e. the device 430 may receive a health status from the EM element in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project."; Sinha teaches that the hardware and data processing components i.e. devices 430 may be implemented using a processor in Sinha [0158] "The hardware and data processing components used to implement the various processes, operations, illustrative logics, logical blocks, modules and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, or, any conventional processor, controller, microcontroller, or state machine."),
“wherein the operational status is converted for transmission pursuant to a first networking protocol;” (Sinha teaches devices 430 communicating with controller 440 which communicates with Gateway 450 in order to convert the signal to communicate with a BMS 460 in Sinha [0053-0054] "In various embodiments, devices 430 connect to controller 440. Controller 440 may be a dedicated controller within a BMS. In some embodiments, controller 440 is a cloud-based server (i.e. an internet-based server). For example, controller 440 may be physically located in one or more server farms and accessible via an internet connection. In some embodiments, controller 440 is a standalone device in a peer-to-peer (P2P) network. Controller 440 may communicate via various connections such as cellular (3G, 4G, LTE, CDMA, etc.), Wi-Fi, ZigBee, Bluetooth, RF, LoRa, etc. Controller 440 may include wired interfaces such as USB, Firewire, Lightning Connectors, CATS (wired internet), UART, serial (RS-232, RS-485), etc. In some embodiments, controller 440 may include a network connection, such as a BACnet network connection. Controller 440 may be or include a Bluetooth router. In various embodiments, controller 440 is configured to convert between various communication protocols. For example, controller 440 may facilitate integration of Bluetooth devices with a BMS, translation of memory maps between systems/devices, and seamless integration of new devices. In some embodiments, controller 440 is physically located in proximity to devices 430. In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."),
“providing, via the gateway device, the operational status to a remote server” (Sinha teaches the gateway 450 being a bridge between devices 430 and network 470 which is connected to data platform 480 i.e. the remote server in Sinha [0054] "In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."; Sinha teaches data platform 480 receiving information from devices 430 i.e. the health status in Sinha [0056] "In various embodiments, gateway 450 communicates with data platform 480 via network 470. Data platform 480 may facilitate analysis and control of devices 430 based on information from devices 430. For example, data platform 480 may include a graph data structure that represents one or more spaces where devices 430 are deployed and data platform 480 may receive information from devices 430, update the graph data structure, and determine actions associated with the spaces based on the graph data structure (e.g., ordering maintenance, refilling consumables, identifying alarms, etc.). Data platform 480 may facilitate performing statistical operations on data received from devices 430 and identifying actions based thereon."; Sinha teaches that a smart leak detector may send a leak alarm to a data platform 480 i.e. the leak detector may communicate with the data platform 480 via the gateway 450 in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project."),
“a remote server configured to provide, to the building management system, an alert generated when the health status is outside a threshold; generating an alert when the operational status is outside a threshold; and providing an alert to a building management system via the gateway device.” (Sinha teaches receiving device data and determining whether a threshold for run time has passed indicating a need for a battery change i.e. it determines if the status is outside a threshold and may trigger a maintenance request i.e. an alert in Sinha [0098] "Referring now to FIG. 10A, method 1000 for performing predictive maintenance. In various embodiments, analytics system 810 performs method 1000. For example, analytics system 810 may perform method 1000 to provide predictive maintenance to devices 430. At step 1002, analytics system 810 may receive device context data. The context data may include timeseries and/or trend data associated with devices 430. Additionally or alternatively, the context data may include alarm and/or event data from devices 430. In some embodiments, the context data includes device state data indicating a state of the device (e.g., on, off, sleep, error, fault #303, etc.). At step 1004, analytics system 810 may monitor a device state associated with the device context data. In some embodiments, step 1004 includes checking for outliers associated with the context data. For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016)."; Sinha teaches that analytics system 810 may be integrated into system 400 i.e. in order to send the maintenance request it may communicate via the gateway to the BMS in Sinha [0078] "Referring now to FIG. 8, analytics system 810 is shown, according to an exemplary embodiment. In various embodiments, analytics system 810 is integrated into system 400 and/or BMS 460. For example, analytics system 810 may perform one or more of the data analysis operations described herein. Analytics system 810 is shown to include processing circuit 820 and knowledge graph 830. Processing circuit 820 includes processor 840 and memory 850.”).
Claim 38:
Sinha teaches “The method of claim 36, wherein the remote server is further configured to: detect an energy level below the threshold, wherein the threshold is a predetermined energy level;” (Sinha teaches receiving device data and determining whether a threshold for run time has passed indicating a need for a battery change i.e. it determines if the energy level is below a threshold and may trigger a maintenance request i.e. an alert in Sinha [0098] "For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016)."; Sinha teaches displaying a battery level associated with a device in Sinha [0145] "Referring now to FIG. 25, list view 2500 is shown, according to an exemplary embodiment. List view 2500 may display various parameters associated with devices and/or spaces within a space. For example, list view 2500 may display operational parameters associated with one or more devices 430 within a bathroom. List view 2500 is shown to include list 2502. List 2502 may display one or more devices within a selected space. List 2502 may display various information associated with each device such as device name 2504, device type 2506, device block 2508, device space 2510, average consumption 2512 (e.g., water consumption in gallons, etc.), total consumption 2514 (e.g., water consumption in gallons, etc.), total activations 2516, level 2518, and/or alert 2520. In various embodiments, level 2518 displays a battery level associated with the device. Alert 2520 may display an alert status associated with the device. For example, alert 2520 may display a green check mark if a device is in proper working order and may display a red exclamation point if the device has an alarm."), and
“and convert the alert pursuant to a second networking protocol consistent with a second network connection with the building management system.” (Sinha Fig. 4 [As shown in claim 21] teaches Data platform 480 communicating with BMS 460 through gateway 450 i.e. in order to communicate with the BMS, the gateway has to convert the networking protocol to a protocol suitable for the BMS.).
Claim 39:
Sinha teaches “The method of claim 36, wherein the operational status includes (Sinha teaches that devices may transmit a measurements i.e. associated data in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project.").
Claim 40:
Sinha in view of Hannon teaches “The method of claim 36, wherein the alert includes a maintenance alert,(Sinha teaches that analytics system 810 may trigger a maintenance request i.e. a maintenance alert in Sinha [0098] "Referring now to FIG. 10A, method 1000 for performing predictive maintenance. In various embodiments, analytics system 810 performs method 1000. For example, analytics system 810 may perform method 1000 to provide predictive maintenance to devices 430. At step 1002, analytics system 810 may receive device context data. The context data may include timeseries and/or trend data associated with devices 430. Additionally or alternatively, the context data may include alarm and/or event data from devices 430. In some embodiments, the context data includes device state data indicating a state of the device (e.g., on, off, sleep, error, fault #303, etc.). At step 1004, analytics system 810 may monitor a device state associated with the device context data. In some embodiments, step 1004 includes checking for outliers associated with the context data. For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016).").
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.
Claims 21, 23-25, 27-31 and 33-35 are rejected under 35 U.S.C. 103 as being unpatentable over Sinha et al. (US20220107632A1) in view of Hannon et al. (US20200064797A1).
Claim 21:
Sinha teaches “A system for converting an operational status of a fixture for transmission to a building management system, the system comprising: the fixture located within a facility and comprising an electro-mechanical (EM) element;” (Sinha teaches devices 430 which may include a smart flushometer i.e. a fixture located within a facility comprising an electro-mechanical (EM) element in Sinha [0049] "Devices 430 may be smart connected building devices configured to send and receive communications with one or more controllers. For example, devices 430 may include a smart flushometers configured to send consumption data and receive duty flushing commands. In various embodiments, devices 430 are Bluetooth devices. In some embodiments, devices 430 may integrate with a building management system (such as BMS 460, etc.). For example, a conversion layer may convert Bluetooth packets from devices 430 into a protocol used by BMS 460 (e.g., BACnet, Modbus, etc.) to facilitate bi-directional communication. In various embodiments, devices 430 are electronic devices such as automatic soap dispensers or touchless faucets."),
“a remote server;” (Sinha teaches data platform 480 i.e. a remote server in Sinha [0058] "Data platform 480 may operate as a remote system that receives and processes data provided by smart connected devices and/or equipment from many different buildings."),
“and an end-point device communicably coupled to the EM element and configured to: receive the operational status (Sinha teaches that devices 430 may be a variety of device types and that they may dispense soap for example i.e. the device 430 is communicably coupled to the EM element in Sinha [0050] "Devices 430 are shown to include faucets 402, sanitizing dispensers 404, driers 406, flushing systems 408, towel dispenser 410, water dispenser 412, cleaning system 414, locking system 416, activity sensor(s) 418, occupancy sensor(s) 420, blockage detection 422, leak detection 424, lighting 426, and disinfectant systems 428. Faucets 402 may be or include a valve for controlling the release of a liquid such as water for use in hand washing. In some embodiments, faucets 402 are automatic (e.g., touchless faucet, etc.). Sanitizing dispensers 404 may be or include a device that dispenses soap or other disinfectants such as alcohol based disinfectants."; Sinha teaches that devices may transmit a current status i.e. the device 430 may receive a health status from the EM element in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project."),
“convert the operational status for transmission, pursuant to a first networking protocol consistent with a first network connection, to a gateway device;” (Sinha teaches devices 430 communicating with controller 440 which communicates with Gateway 450 in order to convert the signal to communicate with a BMS 460 in Sinha [0053-0054] "In various embodiments, devices 430 connect to controller 440. Controller 440 may be a dedicated controller within a BMS. In some embodiments, controller 440 is a cloud-based server (i.e. an internet-based server). For example, controller 440 may be physically located in one or more server farms and accessible via an internet connection. In some embodiments, controller 440 is a standalone device in a peer-to-peer (P2P) network. Controller 440 may communicate via various connections such as cellular (3G, 4G, LTE, CDMA, etc.), Wi-Fi, ZigBee, Bluetooth, RF, LoRa, etc. Controller 440 may include wired interfaces such as USB, Firewire, Lightning Connectors, CATS (wired internet), UART, serial (RS-232, RS-485), etc. In some embodiments, controller 440 may include a network connection, such as a BACnet network connection. Controller 440 may be or include a Bluetooth router. In various embodiments, controller 440 is configured to convert between various communication protocols. For example, controller 440 may facilitate integration of Bluetooth devices with a BMS, translation of memory maps between systems/devices, and seamless integration of new devices. In some embodiments, controller 440 is physically located in proximity to devices 430. In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."
PNG
media_image1.png
694
594
media_image1.png
Greyscale
),
“and provide, via the gateway device, the operational status to the remote server,” (Sinha teaches the gateway 450 being a bridge between devices 430 and network 470 which is connected to data platform 480 i.e. the remote server in Sinha [0054] "In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."; Sinha teaches data platform 480 receiving information from devices 430 i.e. the health status in Sinha [0056] "In various embodiments, gateway 450 communicates with data platform 480 via network 470. Data platform 480 may facilitate analysis and control of devices 430 based on information from devices 430. For example, data platform 480 may include a graph data structure that represents one or more spaces where devices 430 are deployed and data platform 480 may receive information from devices 430, update the graph data structure, and determine actions associated with the spaces based on the graph data structure (e.g., ordering maintenance, refilling consumables, identifying alarms, etc.). Data platform 480 may facilitate performing statistical operations on data received from devices 430 and identifying actions based thereon."; Sinha teaches that a smart leak detector may send a leak alarm to a data platform 480 i.e. the leak detector may communicate with the data platform 480 via the gateway 450 in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project."),
“wherein the remote server is configured to: receive the operational status from the end-point device via the gateway device;” (Sinha teaches that data platform 480 may facilitate analysis and control of devices 430 based on information from devices 430 i.e. data platform 480 receives the health status from the end point devices in Sinha [0056] "In various embodiments, gateway 450 communicates with data platform 480 via network 470. Data platform 480 may facilitate analysis and control of devices 430 based on information from devices 430. For example, data platform 480 may include a graph data structure that represents one or more spaces where devices 430 are deployed and data platform 480 may receive information from devices 430, update the graph data structure, and determine actions associated with the spaces based on the graph data structure (e.g., ordering maintenance, refilling consumables, identifying alarms, etc.). Data platform 480 may facilitate performing statistical operations on data received from devices 430 and identifying actions based thereon. For example, data platform 480 may perform Bayesian analysis of alarm data from devices 430 to predict device failures and automatically order maintenance for devices 430. In some embodiments, data platform 480 is implemented within a single computer (e.g., one server, one housing, etc.). Additionally or alternatively, data platform 480 may be distributed across multiple servers or computers (e.g., that can exist in distributed locations)."; Sinha teaches that gateway 450 is a bridge between devices 430 and network 470 which is connected to data platform 480 in Sinha [0054] "In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."),
“generate an alert when the operational status is outside a threshold;” (Sinha teaches receiving device data and determining whether a threshold for run time has passed indicating a need for a battery change i.e. it determines if the status is outside a threshold and may trigger a maintenance request i.e. an alert in Sinha [0098] "Referring now to FIG. 10A, method 1000 for performing predictive maintenance. In various embodiments, analytics system 810 performs method 1000. For example, analytics system 810 may perform method 1000 to provide predictive maintenance to devices 430. At step 1002, analytics system 810 may receive device context data. The context data may include timeseries and/or trend data associated with devices 430. Additionally or alternatively, the context data may include alarm and/or event data from devices 430. In some embodiments, the context data includes device state data indicating a state of the device (e.g., on, off, sleep, error, fault #303, etc.). At step 1004, analytics system 810 may monitor a device state associated with the device context data. In some embodiments, step 1004 includes checking for outliers associated with the context data. For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016)."), and
“and provide the alert to the building management system via the gateway device.” (Sinha teaches that analytics system 810 may be integrated into system 400 i.e. in order to send the maintenance request it may communicate via the gateway to the BMS in Sinha [0078] "Referring now to FIG. 8, analytics system 810 is shown, according to an exemplary embodiment. In various embodiments, analytics system 810 is integrated into system 400 and/or BMS 460. For example, analytics system 810 may perform one or more of the data analysis operations described herein. Analytics system 810 is shown to include processing circuit 820 and knowledge graph 830. Processing circuit 820 includes processor 840 and memory 850.”).
Sinha does not appear to explicitly teach “and an end-point device communicably coupled to the EM element and configured to: receive the operational status according to a predetermined schedule from the EM element;” However, Hannon does teach this claim limitation (Hannon teaches that health status of devices may be announced periodically to a designated device in Hannon [0136-0137] "In some embodiments, the one or more other devices may respond to a ping with health information (e.g., heartbeat data, telemetry data, log data, notifications, and/or the like), such that a failure or potential failure of the one or more devices may be detected.... In other embodiments, each of the devices in the device group may announce its health information to one or more other devices (e.g., via one or more network channels 610) periodically or at desired (e.g., pre-configured) times. For example, in various embodiments, each of the devices in the device group may announce its health information to all of the other devices in the device group, or may announce its health information to one or more particular devices in the device group (e.g., a designated device, proxy device, parent device, master device, always on device, or the like).... Similarly, in other embodiments, each of the devices in the device group may analyze its own health information to determine whether the device itself is experiencing a failure or potential failure. For example, in some embodiments, each of the devices in the device group may analyze its own health information periodically, at desired (e.g., pre-configured times), or in response to an event (e.g., an error) to determine if the device itself is experiencing a failure or potential failure.").
Sinha and Hannon are analogous art because they are from the same field of endeavor of monitoring devices. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Sinha and Hannon before him/her, to modify the teachings of Systems and methods for monitoring and controlling a bathroom of Sinha to include the periodic announcement of health information of Hannon because adding the System and method for distributed device configuration and authorization of Hannon would allow for the user to configure how often the status is transmitted, which a person having ordinary skill in the art would recognize as an improvement to the customization of the devices as described in Hannon [0136] " In some embodiments, the one or more other devices may respond to a ping with health information (e.g., heartbeat data, telemetry data, log data, notifications, and/or the like), such that a failure or potential failure of the one or more devices may be detected. For example, in some embodiments, the one or more other devices may respond to the ping with any suitable notification or data generated based on changes in a digital twin of the device, or device disconnection notification or data within a predetermined interval detected by a network configuration or cloud service. In other embodiments, each of the devices in the device group may announce its health information to one or more other devices (e.g., via one or more network channels 610) periodically or at desired (e.g., pre-configured) times. For example, in various embodiments, each of the devices in the device group may announce its health information to all of the other devices in the device group, or may announce its health information to one or more particular devices in the device group (e.g., a designated device, proxy device, parent device, master device, always on device, or the like).”
Claim 23:
Sinha in view of Hannon teaches “The system of claim 21, wherein the remote server is further configured to: detect an energy level below the threshold, wherein the threshold is a predetermined energy level;” (Sinha teaches receiving device data and determining whether a threshold for run time has passed indicating a need for a battery change i.e. it determines if the energy level is below a threshold and may trigger a maintenance request i.e. an alert in Sinha [0098] "For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016)."; Sinha teaches displaying a battery level associated with a device in Sinha [0145] "Referring now to FIG. 25, list view 2500 is shown, according to an exemplary embodiment. List view 2500 may display various parameters associated with devices and/or spaces within a space. For example, list view 2500 may display operational parameters associated with one or more devices 430 within a bathroom. List view 2500 is shown to include list 2502. List 2502 may display one or more devices within a selected space. List 2502 may display various information associated with each device such as device name 2504, device type 2506, device block 2508, device space 2510, average consumption 2512 (e.g., water consumption in gallons, etc.), total consumption 2514 (e.g., water consumption in gallons, etc.), total activations 2516, level 2518, and/or alert 2520. In various embodiments, level 2518 displays a battery level associated with the device. Alert 2520 may display an alert status associated with the device. For example, alert 2520 may display a green check mark if a device is in proper working order and may display a red exclamation point if the device has an alarm."), and
“and convert the alert pursuant to a second networking protocol consistent with a second network connection with the building management system.” (Sinha Fig. 4 [As shown above in claim 21] teaches Data platform 480 communicating with BMS 460 through gateway 450 i.e. in order to communicate with the BMS, the gateway has to convert the networking protocol to a protocol suitable for the BMS.).
Claim 24:
Sinha in view of Hannon teaches “The system of claim 21, wherein the operational status includes (inha teaches that devices may transmit a measurements i.e. associated data in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project.").
Claim 25:
Sinha in view of Hannon teaches “The system of claim 21, wherein the alert includes a maintenance alert,(Sinha teaches that analytics system 810 may trigger a maintenance request i.e. a maintenance alert in Sinha [0098] "Referring now to FIG. 10A, method 1000 for performing predictive maintenance. In various embodiments, analytics system 810 performs method 1000. For example, analytics system 810 may perform method 1000 to provide predictive maintenance to devices 430. At step 1002, analytics system 810 may receive device context data. The context data may include timeseries and/or trend data associated with devices 430. Additionally or alternatively, the context data may include alarm and/or event data from devices 430. In some embodiments, the context data includes device state data indicating a state of the device (e.g., on, off, sleep, error, fault #303, etc.). At step 1004, analytics system 810 may monitor a device state associated with the device context data. In some embodiments, step 1004 includes checking for outliers associated with the context data. For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016).").
Claim 27:
Sinha in view of Hannon teaches “The system of claim 25, wherein the water alert is based on a calculated water usage.” (Sinha teaches monitoring water flow and generating an alert based on a flow threshold i.e. calculated water usage in Sinha [0031] "In some embodiments, systems of the present disclosure may monitor water pressure and/or flow and generate alerts based on thresholds (e.g., a sudden drop in pressure, etc.).").
Claim 28:
Sinha in view of Hannon teaches “The system of claim 21, wherein the alert is provided to a display device.” (Sinha teaches an application layer 490 which facilitates data visualization in Sinha [0070] "Referring now to FIG. 6, application layer 490 is shown according to an exemplary embodiment. Application layer 490 may facilitate data visualization and generating actions based on analysis from data platform 480. In various embodiments, application layer 490 may include one or more mobile applications. Additionally or alternatively, application layer 490 may include desktop applications or applications running on a remote server (e.g., accessible over the Internet, etc.)." Sinha teaches providing a notification i.e. alert in the event of a detected leak in Sinha [0074] "Leak detection 640 may facilitate detecting and locating leaks. For example, a user may receive a notification on a mobile device indicating that a leak associated with a faucet has been detected."
PNG
media_image2.png
888
430
media_image2.png
Greyscale
).
Claim 29:
Sinha in view of Hannon teaches “The system of claim 21, wherein the facility includes a restroom.” (Sinha teaches the system facilitating information associated with a bathroom in Sinha [0048] "Turning now to FIG. 4, system 400 for monitoring and controlling devices and/or spaces is shown, according to an exemplary embodiment. System 400 may facilitate interactions with one or more devices, such as the devices of FIG. 3. For example, system 400 may facilitate collecting interaction information associated with use of a bathroom and/or controlling one or more devices within a bathroom."
PNG
media_image3.png
884
391
media_image3.png
Greyscale
).
Claim 30:
Sinha in view of Hannon teaches “The system of claim 21, wherein the fixture is a faucet or flushometer.” (Sinha teaches a device 430 being a flushometer in Sinha [0049] "Devices 430 may be smart connected building devices configured to send and receive communications with one or more controllers. For example, devices 430 may include a smart flushometers configured to send consumption data and receive duty flushing commands."; Sinha teaches a device 430 being a faucet in Sinha [0050] "Devices 430 are shown to include faucets 402").
Claim 31:
Sinha teaches “A computer-implemented method for converting an operational status of a fixture for transmission to a building management system, the method being executed by a processor and comprising: receiving the operational status (Sinha teaches devices 430 which may include a smart flushometer i.e. a fixture located within a facility comprising an electro-mechanical (EM) element which may be configured to send and receive communications in Sinha [0049] "Devices 430 may be smart connected building devices configured to send and receive communications with one or more controllers. For example, devices 430 may include a smart flushometers configured to send consumption data and receive duty flushing commands. In various embodiments, devices 430 are Bluetooth devices. In some embodiments, devices 430 may integrate with a building management system (such as BMS 460, etc.). For example, a conversion layer may convert Bluetooth packets from devices 430 into a protocol used by BMS 460 (e.g., BACnet, Modbus, etc.) to facilitate bi-directional communication. In various embodiments, devices 430 are electronic devices such as automatic soap dispensers or touchless faucets."; Sinha teaches that devices 430 may be a variety of device types and that they may dispense soap for example i.e. the device 430 is communicably coupled to the EM element in Sinha [0050] "Devices 430 are shown to include faucets 402, sanitizing dispensers 404, driers 406, flushing systems 408, towel dispenser 410, water dispenser 412, cleaning system 414, locking system 416, activity sensor(s) 418, occupancy sensor(s) 420, blockage detection 422, leak detection 424, lighting 426, and disinfectant systems 428. Faucets 402 may be or include a valve for controlling the release of a liquid such as water for use in hand washing. In some embodiments, faucets 402 are automatic (e.g., touchless faucet, etc.). Sanitizing dispensers 404 may be or include a device that dispenses soap or other disinfectants such as alcohol based disinfectants."; Sinha teaches that devices may transmit a current status i.e. the device 430 may receive a health status from the EM element in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project."; Sinha teaches that the hardware and data processing components i.e. devices 430 may be implemented using a processor in Sinha [0158] "The hardware and data processing components used to implement the various processes, operations, illustrative logics, logical blocks, modules and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, or, any conventional processor, controller, microcontroller, or state machine."),
“converting the operational status for transmission pursuant to a first networking protocol consistent with a first network connection with a gateway device;” (Sinha teaches devices 430 communicating with controller 440 which communicates with Gateway 450 in order to convert the signal to communicate with a BMS 460 in Sinha [0053-0054] "In various embodiments, devices 430 connect to controller 440. Controller 440 may be a dedicated controller within a BMS. In some embodiments, controller 440 is a cloud-based server (i.e. an internet-based server). For example, controller 440 may be physically located in one or more server farms and accessible via an internet connection. In some embodiments, controller 440 is a standalone device in a peer-to-peer (P2P) network. Controller 440 may communicate via various connections such as cellular (3G, 4G, LTE, CDMA, etc.), Wi-Fi, ZigBee, Bluetooth, RF, LoRa, etc. Controller 440 may include wired interfaces such as USB, Firewire, Lightning Connectors, CATS (wired internet), UART, serial (RS-232, RS-485), etc. In some embodiments, controller 440 may include a network connection, such as a BACnet network connection. Controller 440 may be or include a Bluetooth router. In various embodiments, controller 440 is configured to convert between various communication protocols. For example, controller 440 may facilitate integration of Bluetooth devices with a BMS, translation of memory maps between systems/devices, and seamless integration of new devices. In some embodiments, controller 440 is physically located in proximity to devices 430. In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."),
“and providing, via the gateway device, the operational status to a remote server” (Sinha teaches the gateway 450 being a bridge between devices 430 and network 470 which is connected to data platform 480 i.e. the remote server in Sinha [0054] "In various embodiments, controller 440 communicates with gateway 450. Gateway 450 may be or include an internet of things (IoT) gateway configured to create a memory map of devices 430, register standard objects such as sensors, and manage devices 430. In various embodiments, gateway 450 is a bridge between devices 430, BMS 460, and/or network 470. For example, gateway 450 may receive Bluetooth signals from controller 440 and communicate the signal using a BACnet protocol to BMS 460 and an MQTT protocol to network 470."; Sinha teaches data platform 480 receiving information from devices 430 i.e. the health status in Sinha [0056] "In various embodiments, gateway 450 communicates with data platform 480 via network 470. Data platform 480 may facilitate analysis and control of devices 430 based on information from devices 430. For example, data platform 480 may include a graph data structure that represents one or more spaces where devices 430 are deployed and data platform 480 may receive information from devices 430, update the graph data structure, and determine actions associated with the spaces based on the graph data structure (e.g., ordering maintenance, refilling consumables, identifying alarms, etc.). Data platform 480 may facilitate performing statistical operations on data received from devices 430 and identifying actions based thereon."; Sinha teaches that a smart leak detector may send a leak alarm to a data platform 480 i.e. the leak detector may communicate with the data platform 480 via the gateway 450 in Sinha [0052] "Devices 430 may transmit a current status, analytics results, fault detections, measurements, an identity, an equipment model that represents each device, and/or other information to the various entities with which devices 430 are connected or communicably coupled to. For example, a smart faucet may interact with an occupant, an OEM, and a contractor directly. A leak alarm from a smart leak detector may be sent to data platform 480 to orchestrate replacement or initiate a maintenance project."), and
“a remote server configured to provide, to the building management system, an alert generated when the operational status is outside a threshold.” (Sinha teaches receiving device data and determining whether a threshold for run time has passed indicating a need for a battery change i.e. it determines if the status is outside a threshold and may trigger a maintenance request i.e. an alert in Sinha [0098] "Referring now to FIG. 10A, method 1000 for performing predictive maintenance. In various embodiments, analytics system 810 performs method 1000. For example, analytics system 810 may perform method 1000 to provide predictive maintenance to devices 430. At step 1002, analytics system 810 may receive device context data. The context data may include timeseries and/or trend data associated with devices 430. Additionally or alternatively, the context data may include alarm and/or event data from devices 430. In some embodiments, the context data includes device state data indicating a state of the device (e.g., on, off, sleep, error, fault #303, etc.). At step 1004, analytics system 810 may monitor a device state associated with the device context data. In some embodiments, step 1004 includes checking for outliers associated with the context data. For example, analytics system 810 may identify a sudden increase in alarms associated with a soap dispenser. In some embodiments, step 1004 includes monitoring performance parameters associated with a device. For example, for a DC powered device, run hours, a number of state changes, and time since last battery change may indicate a need to change a battery. As an additional example, for devices that have not been used beyond a time threshold, an age of the device, a state of the device (e.g., an “off” state, etc.) may be used to determine whether predictive maintenance is required for the device. If no outliers are found, analytics system 810 may continue processing the context data as normal (e.g., step 1006). If an outlier is found, analytics system 810 may trigger maintenance associated with the outlier (e.g., step 1016)."; Sinha teaches that analytics system 810 may be integrated into system 400 i.e. in order to send the maintenance request it may communicate via the gateway to the BMS in Sinha [0078] "Referring now to FIG. 8, analytics system 810 is shown, according to an exemplary embodiment. In various embodiments, analytics system 810 is integrated into system 400 and/or BMS 460. For example, analytics system 810 may perform one or more of the data analysis operations described herein. Analytics system 810 is shown to include processing circuit 820 and knowledge graph 830. Processing circuit 820 includes processor 840 and memory 850.").
Sinha does not appear to explicitly teach “receiving the operational status according to a predetermined schedule from an electro-mechanical (EM) element of the fixture;” However, Hannon does teach this claim limitation (Hannon teaches that health status of devices may be announced periodically to a designated device in Hannon [0136-0137] "In some embodiments, the one or more other devices may respond to a ping with health information (e.g., heartbeat data, telemetry data, log data, notifications, and/or the like), such that a failure or potential failure of the one or more devices may be detected.... In other embodiments, each of the devices in the device group may announce its health information to one or more other devices (e.g., via one or more network channels 610) periodically or at desired (e.g., pre-configured) times. For example, in various embodiments, each of the devices in the device group may announce its health information to all of the other devices in the device group, or may announce its health information to one or more particular devices in the device group (e.g., a designated device, proxy device, parent device, master device, always on device, or the like).... Similarly, in other embodiments, each of the devices in the device group may analyze its own health information to determine whether the device itself is experiencing a failure or potential failure. For example, in some embodiments, each of the devices in the device group may analyze its own health information periodically, at desired (e.g., pre-configured times), or in response to an event (e.g., an error) to determine if the device itself is experiencing a failure or potential failure.").
Sinha and Hannon are analogous art because they are from the same field of endeavor of monitoring devices. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Sinha and Hannon before him/her, to modify the teachings of Systems and methods for monitoring and controlling a bathroom of Sinha to include the periodic announcement of health information of Hannon because adding the System and method for distributed device configuration and authorization of Hannon would allow for the user to configure how often the status is transmitted, which a person having ordinary skill in the art would recognize as an improvement to the customization of the devices as described in Hannon [0136] " In some embodiments, the one or more other devices may respond to a ping with health information (e.g., heartbeat data, telemetry data, log data, notifications, and/or the like), such that a failure or potential failure of the one or more devices may be detected. For example, in some embodiments, the one or more other devices may respond to the ping with any suitable notification or data generated based on changes in a digital twin of the device, or device disconnection notification or data within a predetermined interval detected by a network configuration or cloud service. In other embodiments, each of the devices in the device group may announce its health information to one or more other devices (e.g., via one or more network channels 610) periodically or at desired (e.g., pre-configured) times. For example, in various embodiments, each of the devices in the device group may announce its health information to all of the other devices in the device group, or may announce its health information to one or more particular devices in the device group (e.g., a designated device, proxy device, parent device, master device, always on device, or the like).”
Claims 33-35:
The limitations of claims 33-35 are substantially the same as claims 23-25 respectively and they are rejected for the same reasons.
Claims 22, 32, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Sinha et al. (US20220107632A1), in view of Hannon et al. (US20200064797A1), further in view of Dayton et al. (US20080262755A1).
Claim 22:
Sinha in view of Hannon teaches “The system of claim 21, wherein the remote server is further configured to: estimate a water flow rate;” (Sinha teaches using flow rate data i.e. in order to estimate a water flow rate in Sinha [0058] "For example, a smart faucet may report water consumption to data platform 480 and data platform 480 may combine the water consumption data with flow rate data collected from flow sensors in piping feeding the smart faucet to identify leaks in the piping feeding the smart faucet."),
“compare the water usage to the threshold;” (Sinha teaches monitoring water flow and generating an alert based on a threshold in Sinha [0031] "In some embodiments, systems of the present disclosure may monitor water pressure and/or flow and generate alerts based on thresholds (e.g., a sudden drop in pressure, etc.)."), and
“and convert the alert pursuant to a second networking protocol consistent with a second network connection with the building management system.” (Sinha Fig. 4 [As shown above in claim 21] teaches Data platform 480 communicating with BMS 460 through gateway 450 i.e. in order to communicate with the BMS, the gateway has to convert the networking protocol to a protocol suitable for the BMS.).
Sinha and Hannon do not appear to explicitly teach “calculate water usage based on a duration of time a valve of the fixture remains open and the estimated water flow rate;” However, Dayton does teach this claim limitation (Dayton teaches determining water usage based on a flow rate and the water consumption time interval i.e. the duration of time a valve remained open in Dayton [0006] "In an aspect of the invention, a method of calculating an attribute of water usage with a water usage meter may comprise determining a flow rate of a household faucet as an interval of time over which an amount of water is consumed, measuring a water consumption time interval during a water consuming activity at the household faucet, calculating a volume of water consumed using the flow rate and the water consumption time interval, and calculating potential water savings if at least one of the flow rate and the water consumption time interval were to be adjusted.").
Sinha, Hannon, and Dayton are analogous art because they are from the same field of endeavor of monitoring devices. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Sinha, Hannon, and Dayton before him/her, to modify the teachings of Systems and methods for monitoring and controlling a bathroom of Sinha modified to include the periodic announcement of health information of Hannon to include the calculation of water usage based on flow rate and water consumption time interval of Dayton because adding the Faucet flow timing system that monitors volume of water usage of Dayton would be a simple substitution of one known element for another to obtain predictable results. Dayton differs from Sinha in that to determine the water usage, Dayton uses the amount of time the faucet was on and the flow rate to determine the volume of water usage while Sinha describes finding usage and flow rate information but is silent on how it calculates a total volume of water usage. There is a substantial amount of prior art available with respect to water usage tracking devices. The level of ordinary skill in the art is an individual with multiple years of experience installing building monitoring systems. The substituted method and components are known in the art – calculating a total volume of water by using the flow rate and time the faucet is on is a simple calculation which is described in Dayton. It would have been predictable to calculate the total volume of water using the calculation and Sinha describes the required components to do so.
Claims 32, 37:
The limitations of claims 32 and 37 are substantially the same as claim 22 and they are rejected for the same reasons.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Sinha et al. (US20220107632A1), in view of Hannon et al. (US20200064797A1), further in view of Jovel et al. (US20240218643A1).
Claim 26:
Sinha in view of Hannon teaches “The system of claim 25,” as described above.
Sinha and Hannon do not appear to explicitly teach “wherein the low energy alert is a graphical representation.” However, Jovel does teach this claim limitation (Jovel teaches that if a battery drops below a threshold, a server may issue an alert to replace a battery in Jovel [0052-0053] "In some embodiments, a control system may be able to monitor battery status and may allow for initiation of a service ticket, inventory management, service planning, proactive repair and/or battery replacement, monitoring of battery life versus other trends, etc. A battery status may be communicated to a computing device and/or cloud/server to log and analyze. For example, monitoring of a battery status may allow for preemptive recharging or replacement of batteries to avoid or prevent functions of a faucet from being inoperable due to an inoperable battery. Thus, monitoring and logging of the battery status may improve the overall efficiencies of a system. Electric power may be delivered via a battery and/or a building power supply. In some embodiments, if a battery drops below a threshold, for instance about 5.6V, a computer device and/or a cloud server may issue an alert to notify a technician or analyst, allowing time to replace and/or recharge the battery. In some embodiments, if a battery power drops below a lower threshold, for instance about 5.4V, a control system may be configured to “shut off” a faucet or collection of faucets, for instance directing a solenoid to remain closed, as well as to alert a technician or analyst."; Jovel Fig. 2A teaches pending alerts 217 which may include a low battery alert i.e. a graphical depiction
PNG
media_image4.png
888
546
media_image4.png
Greyscale
).
Sinha, Hannon, and Jovel are analogous art because they are from the same field of endeavor of monitoring devices. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Sinha, Hannon, and Jovel before him/her, to modify the teachings of Systems and methods for monitoring and controlling a bathroom of Sinha modified to include the periodic announcement of health information of Hannon to include the low battery alert of Jovel because adding the Connected faucet systems of Jovel would allow for preemptive replacement of batteries, improving efficiencies of a system as described in Jovel [0052] "In some embodiments, a control system may be able to monitor battery status and may allow for initiation of a service ticket, inventory management, service planning, proactive repair and/or battery replacement, monitoring of battery life versus other trends, etc. A battery status may be communicated to a computing device and/or cloud/server to log and analyze. For example, monitoring of a battery status may allow for preemptive recharging or replacement of batteries to avoid or prevent functions of a faucet from being inoperable due to an inoperable battery. Thus, monitoring and logging of the battery status may improve the overall efficiencies of a system.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Nies et al. (US20150268670A1) teaches a control unit that sends a sensor flag status every minute in Nies [0054-0055] "According to one embodiment, the VU periodically wakes up and checks in to the CU (e.g., every minute). The CU responds by sending the valve and moisture sensor commands to the VU. The VU acknowledges receipt of the commands by repeating back the commands, and adding its battery and moisture sensor status. This data includes:
PNG
media_image5.png
254
896
media_image5.png
Greyscale
The Sensor Flag status may also include bits to indicate if a sensor receiver is connected, and its functional status along with the sensor water and battery flags."
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zachary A Cain whose telephone number is (571)272-4503. The examiner can normally be reached Mon-Fri 7:00-3:30 CST.
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, Kenneth M Lo can be reached at (571) 272-9774. 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.
/Z.A.C./ Examiner, Art Unit 2116 /KENNETH M LO/Supervisory Patent Examiner, Art Unit 2116
Prosecution Insights