Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to amendment filed on 03/04/2026. Claims 1, 5, 15 and 20 have been amended. Claims 1-20 are pending, of which claims, of which claim 1, 15 and 20 are in independent form. Accordingly, this action has been made FINAL.
Response to Argument
3. Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
Status of Claims
4. Claims 1-20 are pending, of which claims, of which claim 1, claim 15 and claim 20 are in independent form.
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.
5. Claims 1-8, 10, and 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tai (US 20230367584– hereinafter Tai), in view of Nightingale (US 10,452,375 – hereinafter Nightingale) and further in view of Joshy (US 20220292372 – hereinafter Joshy).
Claim 1 is rejected, Tai teaches a computer-implemented method for managing firmware updates for a fleet of controllers, the method comprising(Tai, abstract and summary):
identifying a plurality of controllers for a firmware update based on a predefined controller grouping, wherein the plurality of controllers each include an on-board memory with a current firmware (Tai, US 20230367584, para. [0012-0015], "the plurality of firmware driven devices includes at least one group of (e.g., substantially) identical devices which utilize (e.g., substantially) identical firmware". Para. [0068], “The groups may be of components of the same type, of the same version, of the same housing (e.g., in the same ensemble), of the same facility section (e.g., the same floor or of the same building), and/or having a common group software or firmware version.”);
determining a set of controllers located in a building, the set of controllers determined based on a controller mapping, and the set of controllers included in the plurality of controllers for the firmware update (Tai, para. [0054-0055], "At least a portion of the floors of the multi-story building may have components controlled by the control system (e.g., at least a portion of the floors of the multi-story building may be controlled by the control system).");
retrieving client data corresponding to the set of controllers(Tai, fig. 4, blocks 404 and 405 and para. [0077], automatically install or user approves to install the firmware.);
determining, based on a client-defined constraint in the client data, approval is required to perform the firmware update on the set of controllers (Tai, fig. 4, blocks 404 and 405 and para. [0077], “At operation 404 it is determined whether a newly added update should be (e.g., automatically) installed. If not, then the update may be placed into a queue or other populated list for presentation to a user as an available update at operation 405. If a user consults the list but decides at 406 to defer installation to a later time, then the list is maintained and will be presented again later at 405. The user may optionally select a target time to install the update (not shown). When an update is to be installed (e.g., manually) or when the user chooses to proceed, then the firmware update manager is prompted to perform a handshake at operation 407.”. Para. [0075-0076], , “a user is automatically prompted with a request for authorizing an update”);
requesting, automatically, the approval to perform the firmware update on the set of controllers (Tai, fig. 4, blocks 404 and 405 and para. [0077], automatically install or user approves to install the firmware. Para. [0075-0076], , “a user is automatically prompted with a request for authorizing an update”);
receiving authorization to perform the firmware update on the set of controllers in response to requesting the approval (Tai, fig. 4, blocks 404 and 405 and para. [0077], “At operation 404 it is determined whether a newly added update should be (e.g., automatically) installed. If not, then the update may be placed into a queue or other populated list for presentation to a user as an available update at operation 405. If a user consults the list but decides at 406 to defer installation to a later time, then the list is maintained and will be presented again later at 405. The user may optionally select a target time to install the update (not shown). When an update is to be installed (e.g., manually) or when the user chooses to proceed, then the firmware update manager is prompted to perform a handshake at operation 407.” Para. [0075-0076], “a user is automatically prompted with a request for authorizing an update”.);
communicating, over a network, the firmware update to a first controller in the set of controllers based on the authorization(Tai, fig. 4, blocks 407 and 408 and para. [0077], “After a successful handshake, the update (e.g., update image) file is transferred at operation 408”.); and
initiating, over the network, performance of the firmware update on the first controller in the set of controllers based on the authorization(Tai, fig. 4, blocks 409 and para. [0077], “installed at operation 409. Following successful installation of the update, the targeted device confirms the installation at operation 410. ”.).
The Office would like to use prior art Nightingale to back up Tai to further to teach limitation
based on a predefined controller grouping(Nightingale, US 10,452,375, fig. 1 and column 3, line 66 to column 4, line 24, “computing devices 110 can be organized into racks, action zones, groups, sets, or other suitable divisions. For example, in the illustrated example, computing devices 110 are grouped into three host sets identified individually as first, second, and third host sets 112a-112c.”. Column 17, line 22 to 29, “when a release is made available to a group of IoT devices via a deployment, it will not be made available to all IoT devices in the group simultaneously. Instead, in these examples, each release is made available in a rolling deployment. For example, a rolling deployment may start by deploying to a small subset of targeted IoT devices. As updates complete successfully, the number of IoT devices eligible for deployment increases.”. Column 20, line 64 to column 21, line 52, priority groups.)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Nightingale into Tai's invention to have a device which include a memory adapted to store run-time data for the device, and a processor that is adapted to execute processor-executable code that enables the device to perform actions. A staging is performed to generate a list of install targets for the first priority group based on a list of software for installation in a memory and software present in the memory. A list of purge targets are generated for the first priority group based on list of software for installation in memory and software present in memory. The purge targets are deleted from the memory, and the install targets are deleted from the back-up partition. A list of install targets are generated for the second priority group based on the list of the software for installation in the memory. The updating of the software is caused in the memory based on the install targets, the purge targets are deleted from the memory, and the install targets are deleted from the back-up partition as suggested by Nightingale (See abstract and summary).
Tai and Nightingale do not explicitly teach
identifying, based on determination the approval is required, a client device and contact information corresponding to the client device from the client data;
requesting, automatically, the approval to perform the firmware update on the set of controllers, the approval requested from the client device via the contact information corresponding to the client device;
However, Joshy teaches
identifying, based on determination the approval is required, a client device and contact information corresponding to the client device from the client data(Joshy, US 20220292372, Fig. 1 and para [0016-0020], Each client device 106 may include any type of mobile terminal, fixed terminal, or other device, By way of example, client device 106 may include a desktop computer, a notebook computer, a tablet computer, a smartphone, a wearable device, or other client device. Users may, for instance, utilize one or more client devices 106 to interact with one another, one or more servers, or other components of system 100. Para [0021-0022], Upon receiving an approval request from the application 108 (e.g., a user 124 of the application 108), the system 100 obtains a configuration file associated with the process corresponding to the approval request, obtains information regarding approvers authorized to approve the approval request from the configuration file and send approval notifications (e.g., via email, text or other notification) to the approvers (e.g., approver 126). Upon receiving the response from the approvers, the system 100 may update the status of the approval request (e.g., approved, rejected, pending or other status information) in the database 132 and send a notification to the user 124 accordingly. Fig. 3 and para [0030], The configuration file 305 also indicates information related to approvers (e.g., name, email ID, mobile phone number, or other approver related information) in each approval level. The configuration file 305 may also include notification parameter that may specify the information to be provided in an approval request notification sent to the approver. The configuration file 305 may also include a conditions parameter that indicates whether the process is associated with pre-authorized approval information and a name of a file having the conditions for pre-authorized approval.);
requesting, automatically, the approval to perform the firmware update on the set of controllers, the approval requested from the client device via the contact information corresponding to the client device(Joshy, para [0038], Upon receiving the first approval request, the approval subsystem 114 extracts the process ID from the first approval request and obtains the configuration file, such as the configuration file 305, from the database 132 based on the process ID. The approval subsystem 114 obtains information regarding the approvers from the configuration file and determines whether an approver has provided a pre-authorization approval, such as the pre-authorized approval information 325, for approving the first approval request automatically. If no pre-authorization approval is provided, a notification (e.g., email, text, or other notification) is sent to the approver. The notification may include information regarding the first approval request such as requesting user, subject of the request, a link to the first approval request in the application 108, or other such information that may be needed for the approver to approve the first approval request. The approver 126 may access the first approval request using the information provided in the notification. As an example, the approval subsystem 114 may provide a GUI that may display various information regarding the first approval request to the approver. For example, the GUI may present request parameters, such as user related parameters (e.g., user ID, name, email, or other information) of the user who initiated the first approval request, product/service-related parameters of a product or service requested (e.g., name of product, configuration of product, price of the product, or other information). In some embodiments, the GUI may also display the predicted approval score or predicted approver sentiment for the first approval request, which the approver may use as reference for determining whether to approve or reject the first approval request.);
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Joshy into Tai and Nightingale 's invention to enable improving accuracy of automatic approvals by using the score or sentiment as additional data in determining whether to automatically approve or reject the approval request. The method allows a machine learning model to be trained using data related to a number of approval requests approved or rejected by an approver to generate the score, thus predicting a sentiment of the approver in approving or rejecting an approval request in an efficient manner as suggested by Joshy (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, further comprising:
determining the first controller in the set of controllers includes sufficient on-board memory to simultaneously store the firmware update and the current firmware (Nightingale, column 19, line 3 to 34, “The method above describes an example of an image update when sufficient free space exists for the updated version”); and
communicating, over the network, the firmware update to the first controller for storage in the on-board memory with the current firmware based on determining the first controller includes sufficient on-board memory to simultaneously store the firmware update and the current firmware(Nightingale, column 17, line 11 to 21, “ the cloud services are capable of initiating both upgrades and downgrades in the release. In some examples, the cloud can force IoT devices to rollback to an old release. As discussed in greater detail below, in some examples, the IoT devices include backup copies of previous updates. In some examples, the cloud can force an IoT device to downgrade to a previous update release that is stored as a backup copy on the IoT device. In some examples, there is insufficient space to store an uncompressed backup copy, and the backup copy of the last known good version is stored in a compressed state.”).
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, further comprising:
determining the first controller in the set of controllers includes insufficient on-board memory to simultaneously store the firmware update and the current firmware (Nightingale, column 17, line 64 to column 18, line 7, “there is insufficient RAM on the IoT device to store the image binaries in memory”);
receiving, over the network, the current firmware of the first controller based on determining the first controller in the set of controllers includes insufficient on-board memory to simultaneously store the firmware update and the current firmware(Nightingale, column 17, line 64 to column 18, line 7, “ In some examples, there is insufficient RAM on the IoT device to store the image binaries in memory, and so instead each image binary is streamed to the IoT device”.);
storing the current firmware of the first controller in a cloud storage (Nightingale, column 17, line 45 to 63, the IoT device then determines which image binaries should be downloaded from the cloud service to ultimately be installed as part of the update process. In some examples, for each image binary that the IoT device determined should be downloaded from the cloud service, the daemon sends a corresponding request to the cloud service to download the image binary. In some examples, the cloud service sends to the daemon the location of each download in response to a request for the location of each image binary, and then the daemon sends requests to the indicated locations to download each image binary.); and
communicating, over the network, the firmware update to the first controller for storage in the on-board memory in place of the current firmware in response to storing the current firmware of the first controller in the cloud storage(Nightingale, column 17, line 45 to 63, the IoT device then determines which image binaries should be downloaded from the cloud service to ultimately be installed as part of the update process. In some examples, for each image binary that the IoT device determined should be downloaded from the cloud service, the daemon sends a corresponding request to the cloud service to download the image binary. In some examples, the cloud service sends to the daemon the location of each download in response to a request for the location of each image binary, and then the daemon sends requests to the indicated locations to download each image binary.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, wherein the network comprises a first network and a second network and communicating the firmware update to a first controller includes communicating, over the first network, the firmware update to a building controller that relays, over a second network, the firmware update to the first controller(Nightingale, fig. 1 and column 4, line 1 to line 24, “TOR network nodes 120a-120c can then be operatively coupled to additional network nodes 120 to form a computer network in a hierarchical, flat, mesh, or other suitable types of topology that allows communications between computing devices 110 and external network 140.”).
Claim 5 is rejected for the reasons set forth hereinabove for claim 4, Tai, Nightingale and Joshy teach the computer-implemented method of claim 4, further comprising:
determining the first controller in the set of controllers includes insufficient on-board memory to simultaneously store the firmware update and the current firmware (Nightingale, column 17, line 64 to column 18, line 7, “there is insufficient RAM on the IoT device to store the image binaries in memory”); and
instructing the building controller to backup the current firmware on the first controller prior to relaying, over the second network, the firmware update to the first controller(Nightingale, column 17, line 10 to 21, “(Nightingale, column 17, line 64 to column 18, line 7, “the cloud can force an IoT device to downgrade to a previous update release that is stored as a backup copy on the IoT device.”. Fig. 1 and column 4, line 1 to line 24, “TOR network nodes 120a-120c can then be operatively coupled to additional network nodes 120 to form a computer network in a hierarchical, flat, mesh, or other suitable types of topology that allows communications between computing devices 110 and external network 140.”).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, wherein the authorization is subject to at least one client-defined condition received in conjunction with the authorization(Tai, para. [0075-0077], , “a user is automatically prompted with a request for authorizing an update”. Para. [0009-0012], “the method further comprises selecting by a user a timing for distributing and/or installing the one or more firmware updates”).
Claim 7 is rejected for the reasons set forth hereinabove for claim 6, Tai, Nightingale and Joshy teach the computer-implemented method of claim 6, wherein the at least one client-defined condition received in conjunction with the authorization comprises a timing constraint for performing the firmware update(Tai, para. [0075-0077], , “a user is automatically prompted with a request for authorizing an update”. Para. [0009-0012], “the method further comprises selecting by a user a timing for distributing and/or installing the one or more firmware updates”).
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, wherein the client-defined constraint in the client data includes a first client-defined constraint and the method further comprises initiating, over the network, performance of the firmware update on the first controller in the set of controllers based on a second client-defined constraint in the client data and sensor data associated with the building the first controller is located in(Tai, fig. 4, blocks 404 and 405 and para. [0077], “At operation 404 it is determined whether a newly added update should be (e.g., automatically) installed. If not, then the update may be placed into a queue or other populated list for presentation to a user as an available update at operation 405. If a user consults the list but decides at 406 to defer installation to a later time, then the list is maintained and will be presented again later at 405. The user may optionally select a target time to install the update (not shown). When an update is to be installed (e.g., manually) or when the user chooses to proceed, then the firmware update manager is prompted to perform a handshake at operation 407.”. Para. [0075-0076], , “a user is automatically prompted with a request for authorizing an update”. Para. [0004], “The operating systems to be controlled can include tintable windows (e.g., having am insulated glass unit comprising an electrochromic device), building management systems, environmental sensors, and/or actuators (e.g., HVAC systems).”. Para. [0009], sensor. ”. Para. [0009-0012], “the method further comprises selecting by a user a timing for distributing and/or installing the one or more firmware updates.).
Claim 10 is rejected for the reasons set forth hereinabove for claim 8, Tai, Nightingale and Joshy teach the computer-implemented method of claim 8, wherein the sensor data indicates an operational parameter of a device controlled by the first controller and the second client-defined constraint comprises a threshold for the operational parameter of the device, and wherein the operational parameter of the device includes at least one of a current capacity, a current resource consumption, a current revolutions per minute, and a current loading (Tai, para [0001], “ Controlling the environment may be with the aim to increase occupant related advantage(s) (e.g., including comfort, health, productivity, and/or safety of occupant(s)), and/or to reduce power consumption and improving efficiency of systems controlling the environment of a facility (e.g., heater, cooler, vent, and/or lighting).” Para. [0058], energy consumption. Para [0093], reducing energy consumption).
Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, further comprising:
determining performance of the firmware update on the first controller was successful(Nightingale, column 17, line 22 to 29, “when a release is made available to a group of IoT devices via a deployment, it will not be made available to all IoT devices in the group simultaneously. Instead, in these examples, each release is made available in a rolling deployment. For example, a rolling deployment may start by deploying to a small subset of targeted IoT devices. As updates complete successfully, the number of IoT devices eligible for deployment increases.”.); and
initiating, over the network, performance of the firmware update on a second controller in the set of controllers in response to determining the firmware update on the first controller was successful(Nightingale, column 17, line 22 to 29, “when a release is made available to a group of IoT devices via a deployment, it will not be made available to all IoT devices in the group simultaneously. Instead, in these examples, each release is made available in a rolling deployment. For example, a rolling deployment may start by deploying to a small subset of targeted IoT devices. As updates complete successfully, the number of IoT devices eligible for deployment increases.”.).
Claim 13 is rejected for the reasons set forth hereinabove for claim 12, Tai, Nightingale and Joshy teach the computer-implemented method of claim 12, wherein the firmware update is performed on the second controller using the firmware update stored in the on-board memory of the first controller(Nightingale, column 17, line 52 to 63, “In some examples, for each image binary that the IoT device determined should be downloaded from the cloud service, the daemon sends a corresponding request to the cloud service to download the image binary. In some examples, the cloud service sends to the daemon the location of each download in response to a request for the location of each image binary, and then the daemon sends requests to the indicated locations to download each image binary.”)..
Claim 14 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale and Joshy teach the computer-implemented method of claim 1, wherein the first controller controls operation of a heating, ventilation, and air conditioning (HVAC) component of the building(Tai, fig. 6 and para [0083], “control heating, cooling, lightening, and/or venting of an enclosure, or any combination thereof”.) .
As per claim 15, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above.
Claim 17 is rejected for the reasons set forth hereinabove for claim 15, Tai, Nightingale and Joshy teach the server computer system of claim 15, the processor coupled to the memory further configured to:
determine, by the server system, performance of the firmware update on the first controller was unsuccessful (Nightingale, column 17, line 11 to 21, the cloud can force IoT devices to rollback to an old release. As discussed in greater detail below, in some examples, the IoT devices include backup copies of previous updates. In some examples, the cloud can force an IoT device to downgrade to a previous update release that is stored as a backup copy on the IoT device. In some examples, there is insufficient space to store an uncompressed backup copy, and the backup copy of the last known good version is stored in a compressed state.); and
initiate, over the network and by the server system, restoration of the current firmware on the first controller in response to determining the firmware update on the first controller was unsuccessful(Nightingale, column 17, line 11 to 21, the cloud can force IoT devices to rollback to an old release. As discussed in greater detail below, in some examples, the IoT devices include backup copies of previous updates. In some examples, the cloud can force an IoT device to downgrade to a previous update release that is stored as a backup copy on the IoT device. In some examples, there is insufficient space to store an uncompressed backup copy, and the backup copy of the last known good version is stored in a compressed state.).
Claim 18 is rejected for the reasons set forth hereinabove for claim 17, Tai, Nightingale and Joshy teach the server computer system of claim 17, the processor coupled to the memory further configured to determine, by the server system, performance of the firmware update on the first controller was unsuccessful in response to failing to receive an update confirmation from the first controller within a threshold amount of time (Tai, para [0009-0012], “In some embodiments, the bidirectional communication further includes at least one confirmation message forwarded from the at least one of the devices to the update manager. In some embodiments, a communication message of the at least one confirmation message includes a version information after successful install of the firmware update”. Para. [0076], “During update, the targeted component may send regular progress messages (e.g., once per two minutes, or more frequently) to the update manager, e.g., so that faults during installation can be detected. Upon successful completion of an installation, the targeted component may send a confirmation message to the update manager. The confirmation can include details on the new version status of the component. The message can be relayed to the database and/or the dashboard.”).
Claim 19 is rejected for the reasons set forth hereinabove for claim 15, Tai, Nightingale and Joshy teach the server computer system of claim 15, wherein the server system comprises a cloud-based computing system (Tai, para. [0009-0012], “the update manager is included in a controller disposed externally relative to the facility, and is coupled to the network by a cloud connection”. Para. [0055] and [0064-0066], cloud. Nightingale, column 17, line 11 to 21, cloud system ) .
As per claim 20, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
6. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Tai (US 20230367584– hereinafter Tai), in view of Nightingale (US 10,452,375 – hereinafter Nightingale), in view of Joshy (US 20220292372 – hereinafter Joshy) and further in view of Abraham (US 20240151416– hereinafter Abraham).
With respect to claim 9, Tai, Nightingale and Joshy do not teach all limitations of claim 9.
However, Abraham teaches
Claim 9 is rejected for the reasons set forth hereinabove for claim 8, Tai, Nightingale, Joshy and Abraham teach the computer-implemented method of claim 8, wherein the sensor data indicates an occupancy level in the building and the second client-defined constraint comprises a threshold occupancy level for performing the firmware update ( Abraham, US 20240151416, fig. 4 and para [0089-0093], the maintenance supervision software may be configured to operate a cloud maintenance supervisor executing on the cloud server and/or a local maintenance supervisor executing on a local controller. It will be understood that although the procedure 400 shows an example for applying firmware updates when the criteria for certain rules are met (e.g., room is empty and checked out), the procedure 400 may include fewer or additional criteria for completion of one or more rules (e.g., time window, time since a prior firmware update, etc.). Para [0061], the triggering criteria may include a rule to perform the update to firmware or the programming data when a room is vacant and/or checked out. In another example, the triggering criteria may include a rule that when the room is checked out and has been checked out or vacant for a predefined period of time for the update to the firmware or the programming data to be performed. This may allow for a period of time during which an occupant may return to the room after leaving before performing the update to the firmware or the programming data. In another example, the triggering criteria may include a rule that the update be performed when the room is checked out, and the room is scheduled to be occupied on a certain date, and the next occupant is scheduled to be an owner or other person with a status capable of performing system configuration. Fig. 5 and para [0103-106], The local maintenance supervisor of the local controller may monitor the triggering criteria for the programming update maintenance task. At 513, the local maintenance supervisor on a local controller may identify the triggering criteria for the programming update. The local maintenance supervisor on the local controller may determine that the triggering criteria include a rule that a room or other defined space is vacant or the programming update to be performed. At 514, the local maintenance supervisor of the local controller may determine whether the room is vacant. For example, the local maintenance supervisor may receive data from a sensor that indicates an occupancy or vacancy event within a predefined period of time and determine that the room is vacant. If the room is not vacant, the local maintenance supervisor of the local controller may continue to monitor the triggering criteria. When the room is determined to be vacant, at 514, the local controller may update the programming data at 516 for performing load control based on the control settings stored in one or more control devices. The control devices may be updated at least based on a priority level that indicates a priority of control devices or types of control devices to be updated prior to other control devices or device types. The update in the programming of the control settings may be performed by sending a message to the control devices that include the updated control settings or an identifier of the programming update and/or a location at which the programming update may be accessed (e.g., a location in storage at the cloud server and/or the local controller).).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Araham into Tai Nightingale and Joshy 's invention to enable reducing problems that may be caused by the performance of the maintenance tasks in the presence of a user and/or when the user may be attempting to utilize the load control devices being maintained. The method enables performing certain maintenance at specific time periods or times of day that can be challenging to avoid interrupting the control of the occupant or other users. The method enables allowing for a period of time during which an occupant return to the room after leaving before performing the update to the firmware or the programming data.as suggested by Abraham (See abstract and summary).
7. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Tai (US 20230367584– hereinafter Tai), in view of Nightingale (US 10,452,375 – hereinafter Nightingale), in view of Joshy (US 20220292372 – hereinafter Joshy) and further in view of Stalker (US 20210203712 – hereinafter Stalker).
With respect to claim 9, Tai, Nightingale and Joshy do not teach all limitations of claim 9.
However, Stalker teaches
Claim 11 is rejected for the reasons set forth hereinabove for claim 1, Tai, Nightingale, Joshy and Stalker teach the computer-implemented method of claim 1, further comprising communicating, over a network, the firmware update to the first controller for storage in the on-board memory with the current firmware based on determining an available bandwidth of the network for communication with the first controller exceeds a threshold amount of bandwidth (Stalker, US 20210203712, para [0033], Upon receiving such file or set of files, the app of the user system 155 can determine whether the file or set of files can be sent in a single communication signal 195 to the one or more intended electrical devices 102. This determination can depend on one or more of a number of factors, including but not limited to the communication technology/protocol capability (e.g., BLE) of each of the intended electrical devices 102, the maximum size that such communication technology/protocol facilitates in a single communication signal 195, and the available bandwidth. If the app of the user system 155 determines that the file or set of files can be sent in one communication signal 195 to an electrical device 102, the app will use the capabilities (e.g., control engine, transceiver, communication module, storage repository) to do so. The communication protocol (e.g., Zigbee) used for the user system 155 to receive the file or set of files from the network manager 180 and/or a WAC 185 can be different than the communication protocol (e.g., BLE) used for the user system 155 to send the communication signals 195 to the electrical devices 102. Para [0038], bandwidth is overloaded. Para [0078 and 0088], bandwidth conservation. Para [0109], limited bandwidth. Para [0159], low bandwidth.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Stalker into Tai, Nightingale and Joshy 's invention to provide an electrical device updating system that synchronizes user systems to help ensure that the electrical devices are receiving each of the communication signals broadcasted by the user systems. Efficiently updates instructions used to operate the electrical devices. Ensures improved improve communication, safety, maintenance, costs, and operating efficiency as suggested by Stalker (See abstract and summary).
Conclusion
8. THIS ACTION IS MADE FINAL. 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 DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199