Prosecution Insights
Last updated: August 15, 2026
Application No. 18/394,876

AUTO-CONFIGURATION OF AQUATIC EQUIPMENT

Non-Final OA §102§103
Filed
Dec 22, 2023
Priority
Dec 29, 2022 — provisional 63/477,778
Examiner
PATEL, CHANDNI
Art Unit
2118
Tech Center
2100 — Computer Architecture & Software
Assignee
Pentair Inc.
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
9 currently pending
Career history
9
Total Applications
across all art units

Statute-Specific Performance

§103
66.7%
+26.7% vs TC avg
§102
23.8%
-16.2% vs TC avg
§112
9.5%
-30.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 0 resolved cases

Office Action

§102 §103
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is responsive to communications filed on 12/22/2023. As per claims filed on 12/22/2023 Claims 1-20 are currently pending. Claims 1, 9, 16 are independent claims. Priority Acknowledgment is made of applicant’s claim for priority based United States provisional applicant number 63/477,778, filed on December 29, 2022. Priority Listed herein below are the prior art references relied upon in this office action: Davito (US 11,451,445 B2 which has a priority date of 04/10/2018), referred to as Davito herein. Booth et al. (US 2023/0145631 A1, which has a priority date of 11/11/2022), referred to as Booth herein. Corwin (US 10,329,784 B1, which has a priority date of 09/07/2017), referred to as Corwin herein. Spero (US 2016/0195856 A1, which has a priority date of 01/07/2015), referred to as Spero herein. McKinley et al. (US 2016/0012707 A1, which has a priority date of 07/09/2015), referred to as McKinley herein. Nainar et al. (US 2017/0302663 A1, which has a priority date of 04/14/2016), referred to as Nainar herein. 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)(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. Claim(s) 9-10, 14-15 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Booth. Regarding Claim 9, Booth teaches a connected aquatic equipment system, comprising: a first pool component with a first identification element; a second pool component with a second identification element; (“The system includes a master control unit and at least one slave node connected to a piece of pool equipment and serially connected to at least one other slave node in a daisy-chain configuration for transmitting power and data between the nodes.” (Abstract) and “The master node will scan and receive the UUID from the node, and assign a unique network address for the node associated to the UUID.” (¶ 0095), meaning each equipment node in the network carries a unique identifier that the master unit reads directly off the node itself and the system’s architecture is explicitly built around more than one such node coexisting on the same chain. Together, this establishes both the first and second pool components as separately identifiable units within a single network. This satisfies the claim’s requirement of two distinct components and each bearing its own identification element); a first sensing device designed to collect a first data set including operating parameters of the first pool component; (“Sensor nodes include a plurality of sensors for measuring water chemistry and transmit the measurements to the master node. Valve actuator nodes are connected valves to adjust the position of the connected valve and report the position of the valve to the master node. Power injector nodes are connected to a power source to inject power into the multi-node network.” (¶ 0008), disclosing dedicated hardware whose function is taking a physical measurement at the component and forwarding that measurement onward as data); a second sensing device designed to collect a second data set including the operating parameters of the second pool component; (“Sensor nodes include a plurality of sensors for measuring water chemistry and transmit the measurements to the master node. Valve actuator nodes are connected valves to adjust the position of the connected valve and report the position of the valve to the master node. Power injector nodes are connected to a power source to inject power into the multi-node network.” (¶ 0008), disclosing more than one such sensor equipped node. The same disclosed sensing function applies independently to a first and a second component, each producing its own data set); and a central controller designed to automatically detect and configure the first pool component and the second pool component based on the operating parameters of the first pool component and the second pool component. (“The water quality analysis 226 may include a report or warning sent to the user device (i.e., user device 164 if the water chemistry is outside an acceptable range. The water quality analysis 226 may include commands sent to the main control unit (i.e., main control unit 123 in FIG. 1) to adjust pool water chemistry by controlling operation of relevant equipment such as a chlorinator.” (¶ 0084), meaning the master unit resolving each node's identity without manual setup, which means it is "automatically detect". Furthermore, analysis of collected readings is translated directly into commands issued to the central unit governing equipment operation. Reading the identity evidence together with this analysis to command pathway shows one controller performing both halves of the claimed function, which is recognizing each component and then acting on it based on the data that component reports. This satisfies the conditional requirement of the claim); therefore, Booth anticipates all the limitation of claim 9. Regarding Claim 10, Booth teaches the connected aquatic system of claim 9 further comprising: a database configured to store user data; (“a typical weekly swim schedule, user input run time overrides and user reported equipment failure.” (¶ 0078), meaning the specific categories of user originated data the system retains and later draws on schedule preferences, manual overrides, and failure reports. This describes the data itself and that it's fed into cloud hosted processing. However, the storage mechanism is reasonably inferred (the data has to persist somewhere for the engine to reference it repeatedly)); an advanced analytics module of a server configured to process the user data to update a configuration setting of the first pool component and the second pool component. (“a prediction and scheduling engine hosted on the cloud is configured to dynamically generate, or update, equipment run schedules for control of pool equipment based on a plurality of inputs without additional user intervention.” (¶ 0011), meaning the cloud hosted engine takes in stored inputs, including the user originated data, as one its plurality of inputs and produces equipment run schedules as its output. And “The water quality analysis 226 may include commands sent to the main control unit (i.e., main control unit 123 in FIG. 1) to adjust pool water chemistry by controlling operation of relevant equipment such as a chlorinator.” (¶ 0084), disclosing the cloud side analysis. The water quality analysis, resulting in specific commands transmitted to the main control unit that change how a named piece of equipment, a chlorinator, operates. This shows the process taking in user originated data and producing commands that alter a specific piece of connected equipment’s operation, rather than a determination that remains internal to the server. This satisfies the conditional requirement of the claim). Regarding Claim 14, Booth teaches the connected aquatic system of claim 9, wherein the first data set and the second data set are stored in a database provided in a form of a lookup table. (“A network query table is created on the master node in the main control unit 123 to record which ID corresponds to each connected node in the daisy-chain, its capabilities and roles.” (¶ 0058), disclosing a structure that maps each node's identity to its associated data, organized for lookup by identifier, is functionally a lookup table by definition (records indexed by key rather than accessed sequentially). Because this table is described as holding the identity and status information tied to every connected node, it necessarily holds the first and second data sets together within the same structure. This satisfies the conditional requirement of the claim). Regarding Claim 15, Booth teaches the connected aquatic system of claim 14, wherein the database can include: an update lookup module configured to communicate with an advanced analytics module to determine whether the operating parameters should be updated; (“A network query table is created on the master node in the main control unit 123 to record which ID corresponds to each connected node in the daisy-chain, its capabilities and roles.” (¶ 0058), meaning the table's role in flagging which nodes' data has been analyzed and whether a resulting change is warranted is the determination function, checking status against the analytics output before deciding an update is needed); and an output lookup module configured to store the operating parameters detected by the first sensing device and the second sensing device. (“A network query table is created on the master node in the main control unit 123 to record which ID corresponds to each connected node in the daisy-chain, its capabilities and roles.” (¶ 0057), disclosing same table and its storage function is recording the readings reported by each sensor equipped node as they come in. Because the claimed "update lookup module" and "output lookup module" are two functions (determining vs. storing) rather than two separate physical structures, one table performs both functions of checking against the analytics module and separately holding the raw sensor readings. This satisfies the conditional requirement of the claim). Claim Rejections - 35 USC § 103 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 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. Claim(s) 1-2, 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davito in view of Booth further in view of Corwin. Regarding Claim 1, Davito does not teach a method for configuring a connected aquatic system. However, Booth teaches a method for configuring a connected aquatic system, (“The system includes a master control unit and at least one slave node connected to a piece of pool equipment and serially connected to at least one other slave node in a daisy-chain configuration for transmitting power and data between the nodes.” (Abstract), meaning a central processing unit governing a network of interconnected equipment modules, each tied to a piece of pool infrastructure, arranged so that commands and status data can pass between the central unit and every module on the network. Because this architecture exists specifically to install, address, and command equipment, operating it necessarily amounts to configuring a connected aquatic system); Davito teaches the method comprising: receiving a data set including an identification element of a component and an operating parameter of the component; (“a method 400 begins at step 402, where central controller 156 obtains QR code data based on a scan of a QR code. The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), meaning a single scan produces one unified block of information that the processor reads in one action, and that block simultaneously carries two distinct categories of content: information identifying which specific unit is being addressed and information describing how that unit should run. Both categories arrive together as one payload rather than through separate transmissions. This satisfies the conditional requirement of the claim); Davito teaches extracting the identification element of the component using a processor of a central controller; (“central controller 156 generates and provisions a device controller 158 for controlling the IoT device.” (Col 9, line 15-16), meaning before the system can stand up a control instance dedicated to one particular unit, it first has to determine which unit that instance is meant to govern. That determination is only possible once the processor has isolated the identifying content from the scanned data and resolved it to a specific piece of equipment. This necessary antecedent resolution step can be characterized as extraction of the identification element); Davito teaches extracting the operating parameter of the component using the processor of the central controller; (“At step 404, central controller 156 extracts the operating parameters associated with the IoT device from the QR code data.” (Col 9, line 12-14), meaning the processor pulls the performance related content out of that same scanned payload, separate from the identifying content already discussed above. It is the direct counterpart to the claim’s requirement that the processor isolate the component’s operating parameter from the received data); Davito teaches initiating a configuration process to analyze the operating parameter of the component; (“At step 408, central controller 156 configures device controller 158 based on the operating parameters extracted from the QR code data.” (Col 9, line 19-21), meaning once the performance related content has been isolated, the processor does not merely store it. It uses that content as the analytical input to a routine that establishes how the newly provisioned instance will actually. Thereby, using isolated data as the input to a setup routine); Davito does not teach identifying a proposed update to the operating parameter based on an output of the configuration process. However, Corwin teaches identifying a proposed update to the operating parameter based on an output of the configuration process; (“The ACS 10 will realize if a card 41 has been added or removed, and will automatically adjust.” (Col 10, line 52-54), meaning “realize” describes the system reaching a specific determination that a change has occurred in a connected component’s status, and “will automatically adjust” describes update, the specific corrective action that follows directly from that determination. Applied to the configured process already established through Davito’s extraction and analysis of the operating parameter, this teaches that once the operating parameter has been analyzed, the system determines a specific responsive action before that action is actually carried out. This determination of a specific change constitutes identifying a proposed update to the operating parameter, because the adjustment identified is a direct consequence of the output of the prior analysis); Davito teaches initiating an update process to execute the proposed update; (“At step 410, central controller 156 initiates centralized control of the IoT device using device controller 158.” (Col 9, line 24-26), meaning with the new settings determined, the system activates the mechanism that carries them into effect going forward. Triggering that follow-through mechanism is the update process. The proposal becomes an active instruction here, rather than remaining as unused calculated value); Corwin teaches and updating the operating parameter of the component based on the output of the update process. (“If an expansion card 41 has been removed, the pool ACS 10 will automatically deactivate the configuration and the features that were on the removed card. If the same type of expansion card 41 is then replaced in the same slot 23, those stored configurations will be reactivated.” (Col 10, line 56-61), meaning deactivation and reactivation are each a concrete and observable change in the state of the component’s configuration. The configuration is not merely calculated but is altered as a direct result of the condition detected, first deactivated upon removal, and later reactivated upon replacement using the values that had been stored. This before and after change in the component’s actual operating state is the update to the operating parameter. It occurs based on the output of the update process. This satisfies the conditional requirement of the claim). At the time of the invention, it would have been obvious to a person of ordinary skill in the art to combine Davito’s method of receiving a combined identification and operating parameter data set, extracting each element form that data set, and configuring a device controller based on the extracted operating parameter, with Booth’s networked pool automation environment, in which a central control unit governs multiple pool equipment components connected as part of a single aquatic system. The combination further incorporates Corwin’s teaching of automatically recognizing a change in a connected component’s status and adjusting, deactivating, or reactivating that component’s configuration accordingly. Corwin’s teaching supplies the specific mechanism by which the operating parameter identifies and configured through Davito’s method is subsequently updated within the combined system. The motivation for doing so would have been to reduce the manual burden associated with individually addressing and configuring each piece of equipment connected to a central controller. Rather than requiring a technician to separately record a component’s identity and then separately enter its operating parameters, a single scan under Davito’s method accomplishes both tasks, decreasing installation time and reducing the risk of a component being identified without its corresponding parameters ever being captured. Further incorporating Corwin’s teaching would have been to supply an established mechanism by which the identified and configured component’s operating parameter is carried into effect and kept current as the physical connection status of the equipment changes over time. Applying this known mechanism to the combined Davito and Booth system therefore would have amounted to using an established technique for its already recognized purpose, yielding the predictable result of a pool equipment component whose configuration remains accurate and responsive to changes in that component’s actual connection status. Regarding Claim 2, Booth teaches the method for configuring the connected aquatic system of claim 1, wherein the configuration process includes: determining if updated operating parameters are recommended to improve system performance for the connected aquatic system. (“According to an aspect, a prediction and scheduling engine hosted on the cloud is configured to dynamically generate, or update, equipment run schedules for control of pool equipment based on a plurality of inputs without additional user intervention.” (¶ 0011), disclosing a remote analytical component that continuously reassesses incoming operational data and on its own initiative, decides whether the equipment’s current settings should change going forward. This ongoing and self-directed reassessment, deciding whether a change is warranted, rather than applying a fixed rule, functions as determining whether updated operating parameters are recommended, and doing so with the aim of running the pool equipment more effectively). Regarding Claim 5, Booth teaches the method for configuring the connected aquatic system of claim 1, further comprising: receiving user data including trend data, user preferences, a schedule, or a combination thereof. (“The prediction and scheduling engine may blend a user uploaded planned pool use schedule with other inputs to generate an optimized equipment run schedule based on pool usage.” (¶ 0011), meaning a pool use schedule originating from the user is one of the inputs the system takes in before generating its output. This satisfies the conditional requirement of the claim). Regarding Claim 6, Booth teaches the method for configuring the connected aquatic system of claim 5, wherein the configuration process analyses the user data when identifying the proposed update to the operating parameter. (“The prediction and scheduling engine may blend a user uploaded planned pool use schedule with other inputs to generate an optimized equipment run schedule based on pool usage.” (¶ 0011), meaning the schedule is not simply stored after being received. It is actively combined with the system’s other inputs as part of producing the optimized output. Folding user supplied data into the same analytical step that generates the equipment run schedule thereby teaches the configuring process analyzing the user data when identifying the proposed update). Claim(s) 3-4, 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davito, Booth and Corwin, and further in view of Spero. Regarding Claim 3, Davito, Booth and Corwin do not teach analyzing the operating parameter of the pool component using an advanced analytics module configured to determine a recommended operating parameter based on other pool components connected to the connected aquatic system. However, Spero teaches analyzing the operating parameter of the component using an advanced analytics module configured to determine a recommended operating parameter based on other components connected to the connected system. (“as the user purchases and adds to the docking station a speaker system, its onboard circuitry upon installation sends data to the controller on the sound generating characteristics. The controller, from a stored look up table of characteristics determines and sets flags in the code that the new speaker is the preferred sound generation device for the smoke detector upon alarm, but not during test.” (¶ 0089), meaning one unit’s operating behavior is reconfigured based on characteristics reported by an entirely separate unit that has just joined the network. The resulting decision is not derived from that first unit’s own reading, but from data originating at a second, independently connected unit. Thereby, teaching a mechanism where a recommended setting for one component is derived using data sourced from a different connected component). At the time of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate Spero’s teaching of deriving on connected component’s configuration from data reported by a second, independently connected component into a networked pool equipment system in which a central controller identifies each connected component, extracts and analyzes that component’s operating parameters, and updates that component’s configuration accordingly. Incorporating Spero’s teaching would extend such a system so that the recommended operating parameter determined for one pool equipment component is derived not only form that component’s own reported data, but also from data reported by a second connected pool equipment component. The motivation for doing so would have been to produce operating parameter recommendations that properly account for the interdependent relationships that exist between connected pool equipment components. Spero states “Within this disclosure a superior solution is proposed which is termed “intelligent”—which may be defined as being able to autonomously adapt to surroundings. The operation of “intelligent” devices is thus inherently automatic with as you go teaching being used seamlessly in a machine learning environment.” (¶ 0004). This framing indicates that Spero’s cross component determination mechanism was understood, at the time of the invention, as a general technique for improving coordination among the components of any system in which multiple interdependent devices are connected to a common controller. Applying that known solution within the pool equipment context would improve the system, yielding the predictable result of operating parameter recommendations that properly account for the state of other connected pool equipment. Regarding Claim 4, Davito, Booth and Corwin do not teach the advanced analytics module is provided in a form of an iteratively trained learning module. However, Spero teaches the advanced analytics module is provided in a form of an iteratively trained learning module. (“The machine learning system records events and uses code to analyze user feedback in reaction to actions which were automatically deduced regarding user needs and/or environmental changes that the controller decided require intervention. This is done by the AI system using algorithms to determine the best practice operation of devices to meet needs in real time. When contradicted in a decision automatically made after one or many such learning events the AI system has code for machine learning known in the art for altering the stored best practice data.” (¶ 0075), disclosing a system that gets measurably better as its task purely through accumulated operating history, to the point where a person needs to intervene less over time. This repeatedly refining itself against new data is the defining characteristic of a module trained through successive iterations). Regarding Claim 7, Davito teaches wherein the component is a first component with a first identification element, the data set is a first data set, and the operating parameter is a first operating parameter, (“a method 400 begins at step 402, where central controller 156 obtains QR code data based on a scan of a QR code. The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), meaning a single scan produces one unified block of information that the processor reads in one action, and that block simultaneously carries two distinct categories of content: information identifying which specific unit is being addressed and information describing how that unit should run. Both categories arrive together as one payload rather than through separate transmissions and can be assigned the label “first”. This satisfies the conditional requirement of the claim); Davito does not teach the method further comprising: receiving a second data set including a second identification element of a second pool component and a second operating parameter of the second pool component. However, Booth teaches the method further comprising: receiving a second data set including a second identification element of a second pool component and a second operating parameter of the second pool component; (“The system includes a master control unit and at least one slave node connected to a piece of pool equipment and serially connected to at least one other slave node in a daisy-chain configuration for transmitting power and data between the nodes.” (Abstract), meaning that more than one slave mode exists on the network. The phrase “at least one” allows to establish a second, distinct node using Davito’s technique of reading a combined identity and operating parameters payload in a single action, parsing it into its two elements. Therefore, the same receive and scan sequence repeats each time the central controller encounters an additional node. This also satisfies the conditional requirement of the claim); Davito teaches extracting the second identification element of the second component using the processor of the central controller; (“central controller 156 generates and provisions a device controller 158 for controlling the IoT device.” (Col 9, line 15-16), meaning before the system can stand up a control instance dedicated to one particular unit, it first has to determine which unit that instance is meant to govern. That determination is only possible once the processor has isolated the identifying content from the scanned data and resolved it to a specific piece of equipment. This necessary antecedent resolution step can be characterized as extraction of the identification element. This is the standard procedure the central controller runs against whatever device is scanned. Therefore, it repeats, reads and extracts the identification element of the second pool component); Davito teaches extracting the second operating parameter of the second component using the processor of the central controller; (“At step 404, central controller 156 extracts the operating parameters associated with the IoT device from the QR code data.” (Col 9, line 12-14), meaning the processor pulls the performance related content out of that same scanned payload, separate from the identifying content already discussed above. It is the direct counterpart to the claim’s requirement that the processor isolate the component’s operating parameter from the received data. This is the standard procedure the central controller runs against whatever device is scanned. Therefore, it repeats, reads and extracts the operating parameter of the second pool component); Davito, Booth and Corwin do not teach initiating the configuring process to analyze the second operating parameter of the second pool component based on the first operating parameter of the first pool component. However, Spero teaches initiating the configuration process to analyze the second operating parameter of the second component based on the first operating parameter of the first component; (“as the user purchases and adds to the docking station a speaker system, its onboard circuitry upon installation sends data to the controller on the sound generating characteristics. The controller, from a stored look up table of characteristics determines and sets flags in the code that the new speaker is the preferred sound generation device for the smoke detector upon alarm, but not during test.” (¶ 0089), meaning one unit’s operating behavior here is reconfigured based on characteristics reported by an entirely separate unit that has just joined the network. The resulting decision is not derived from that first unit’s own reading, but from data originating at a second, independently connected unit. Thereby, teaching a mechanism where a recommended setting for one component is derived using data sourced from a different connected component); Davito teaches identifying the proposed update based on the output of the configuration process; (“Central controller 156 could, for example, set various constants included in device controller 158 with corresponding values specified in the extracted operating parameters.” (Col 9, line 21-24), meaning the output of that routine is specific settings within the instance are assigned particular values drawn directly from the prior analysis. Thereby, teaching selecting which settings change and to what values. This does not change depending on how many components are involved); Davito teaches initiating the update process to execute the proposed update; (“At step 410, central controller 156 initiates centralized control of the IoT device using device controller 158.” (Col 9, line 24-26), meaning with the new settings determined, the system activates the mechanism that carries them into effect going forward. Triggering that follow-through mechanism is the update process. The proposal becomes an active instruction here, rather than remaining as unused calculated value. This does not change depending on how many components are involved); Spero teaches and updating the first operating parameter of the first component and the second operating parameter of the second component based on the output of the update process. (“as the user purchases and adds to the docking station a speaker system, its onboard circuitry upon installation sends data to the controller on the sound generating characteristics. The controller, from a stored look up table of characteristics determines and sets flags in the code that the new speaker is the preferred sound generation device for the smoke detector upon alarm, but not during test.” (¶ 0089), meaning the smoke detector’s configuration changed specifically because of what the newly connected speaker reported. This is a change to one component’s setting driven by the other component’s data within a single coordinated outcome. This is the combined and coordinated updating of both component’s parameters from one update process. This satisfies the conditional requirement of the claim). The motivation to combine Spero with Davito, Booth and Corwin is seen in claim 3 above. Regarding Claim 8, Booth teaches the method of configuring the connected aquatic system of claim 7, wherein the first pool component is configured to detect and identify the second pool component. (“relaying data/signals between pool infrastructure components and the main control unit 123.” (¶ 0055), meaning each node in the chain does not just communicate to the central controller. It sits physically in the data path and passes along data associated with the other components connected further down the chain. Functioning as that relay point, handling and forwarding data tied to an adjacent component before it reaches the controller, is what satisfies a component being configured to detect and identify another component). Claim(s) 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davito and Booth, and further in view of Spero. Regarding Claim 16, Davito teaches providing a first component defined by a first identification element and a first operational parameter; (“a method 400 begins at step 402, where central controller 156 obtains QR code data based on a scan of a QR code. The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), disclosing a component paired with a scannable code that carries both its identity and its operating characteristics together is a component "defined by" an identification element and an operational parameter. Both properties are attached to and retrievable from the same physical unit before any connection step occurs. This satisfies the conditional requirement of the claim); Davito does not teach connecting the first pool component to a controller. However, Booth teaches connecting the first pool component to a controller; (“The system includes a master control unit and at least one slave node connected to a piece of pool equipment and serially connected to at least one other slave node in a daisy-chain configuration for transmitting power and data between the nodes.” (Abstract), meaning a pool equipment associated unit is joined to a central control unit, prior to any second unit entering); Davito teaches providing a second component defined by a second identification element and a second operational parameter; (“a method 400 begins at step 402, where central controller 156 obtains QR code data based on a scan of a QR code. The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), disclosing a component paired with a scannable code that carries both its identity and its operating characteristics together is a component "defined by" an identification element and an operational parameter. Both properties are attached to and retrievable from the same physical unit before any connection step occurs. The onboarding process is not limited to a single unit, so the identity and parameter pairing also applies to the second component. This satisfies the conditional requirement of the claim); Booth teaches automatically connecting the second pool component to the controller and the first pool component via the second identification element; (“The master node will scan and receive the UUID from the node, and assign a unique network address for the node associated to the UUID.” (¶ 0095), meaning a new unit joining the network is recognized and addressed without manual configuration steps. Additionally, Davito teaches “a method 400 begins at step 402, where central controller 156 obtains QR code data based on a scan of a QR code. The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), meaning a scan that immediately yields both the new unit's identity and its data, accomplishing automatic connection. Combined, they show a newly added component being brought into a live network with the controller (and, by extension, whatever else is already on that network) purely through its own identification element being read. This satisfies the conditional requirement of the claim); Davito and Booth do not teach adjusting the first operational parameter in response to the second pool component connecting to the controller. However, Spero teaches and adjusting the first operational parameter in response to the second component connecting to the controller. (“as the user purchases and adds to the docking station a speaker system, its onboard circuitry upon installation sends data to the controller on the sound generating characteristics. The controller, from a stored look up table of characteristics determines and sets flags in the code that the new speaker is the preferred sound generation device for the smoke detector upon alarm, but not during test.” (¶ 0089), meaning an existing unit's settings changing specifically because a new unit just joined, not the new unit configuring itself, but a change to the one that was already there. This satisfies the conditional requirement of the claim). At the time of the invention, it would have been obvious to a person of ordinary skill in the art to combine Davito's scan-based identity and parameter extraction mechanism (the specific means by which that connection happens automatically), Booth's networked connection architecture (auto-addressing a newly joined unit), and Spero's cross device reconfiguration behavior (an existing unit's settings changing in response to a new connection). They can be layered together so that Booth's pool network gains both an automatic, scan-based onboarding process and the capability for already installed equipment to react to what just joined. The motivation for doing so would have been to eliminate the two remaining points of manual intervention in an otherwise automated pool network: getting a new device recognized in the first place and getting existing equipment to actually respond to that new device rather than continuing to operate as if nothing changed. A system that only does the first half is only partially automated, leaving a technician to manually retune every other affected component by hand, which defeats much of the purpose of building an automated network at all. Davito's scan-based approach is the natural mechanism to adopt given Booth's own reference to barcode or QR style identification, and Spero's demonstrated cross device reconfiguration is the obvious next step once a new device's data is available to the controller. There is no missing engineering step between "the controller now has data from a new device" and "the controller uses that data to update something else," making this combination not just plausible but the expected, low risk design choice a PHOSITA would reach for. Regarding Claim 17, Spero teaches the method of claim 16, further comprising: adjusting the second operational parameter based on the first operational parameter associated with the first component. (“as the user purchases and adds to the docking station a speaker system, its onboard circuitry upon installation sends data to the controller on the sound generating characteristics. The controller, from a stored look up table of characteristics determines and sets flags in the code that the new speaker is the preferred sound generation device for the smoke detector upon alarm, but not during test.” (¶ 0089), meaning mechanism is not described as one directional. The same lookup and flag setting process lets a new device's characteristics drive a change elsewhere works equally well in the other direction, since it's the stored comparison doing the work, not some property unique to which unit arrived first. A second component's settings being derived from a first component's already known parameter is the same category of cross device dependency, just applied to the newly joining unit instead of the pre-existing one). Regarding Claim 18, Davito teaches the method of claim 17, wherein the first identification element is provided in a form of a QR code. (“a method 400 begins at step 402, where central controller 156 obtains QR code data based on a scan of a QR code. The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), meaning a scannable code affixed to the device, which is by definition a QR code implementation of the identification element already established for the first pool component in Claim 16). Regarding Claim 19, Davito teaches the method of claim 18, wherein the QR code is pre-configured with user data provided in a form of at least one of a name, number, device type, address, or model type. (“The QR code is affixed to an IoT device, such as a node 130, and encodes operating parameters and other metadata associated with that device.” (Col 9, line 5-9), meaning identifying information beyond just operating parameters which includes “other metadata”. By definition, metadata would include something like a name, device type, or model designation). Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Booth further in view of Spero. Regarding Claim 11, Booth does not teach the connected aquatic system of claim 10, wherein the advanced analytics module can be provided in a form of an iteratively trained learning module. However, Spero teaches the connected aquatic system of claim 10, wherein the advanced analytics module can be provided in a form of an iteratively trained learning module. (“The machine learning system records events and uses code to analyze user feedback in reaction to actions which were automatically deduced regarding user needs and/or environmental changes that the controller decided require intervention. This is done by the AI system using algorithms to determine the best practice operation of devices to meet needs in real time. When contradicted in a decision automatically made after one or many such learning events the AI system has code for machine learning known in the art for altering the stored best practice data.” (¶ 0075), disclosing a system that gets measurably better as its task purely through accumulated operating history, to the point where a person needs to intervene less over time. This repeatedly refining itself against new data is the defining characteristic of a module trained through successive iterations). At the time of the invention, it would have been obvious to a person of ordinary skill in the art to implement the advanced analytics module of claim 10 which processes stored user data and outputs equipment level commands using Spero’s event recording and feedback driven mechanism for revising its own stored operating data over time. The motivation for doing so would have been to improve the accuracy of the module’s output as more data accumulates, rather than relying on a fixed determination process that does not change regardless of outcome. Booth’s module already evaluated a plurality of inputs to produce commands changing equipment operation. Spero’s mechanism for revising stored data based on whether a prior automatically made decision was later contradicted is a direct and known enhancement to the evaluation process, applying a known technique to a known type of device to yield a predictable result. Claim(s) 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Booth further in view of McKinley. Regarding Claim 12, Booth does not teach a deployment module of a server configured to generate and transmit a notification to a third-party system using a notification module. However, McKinley teaches a deployment module of a server configured to generate and transmit a notification to a third-party system using a notification module. (“cause the server 1400 to send the alert to a mobile service device, system operator, and/or dispatcher in addition to equipment operators and owners of record” (¶ 0064), meaning a server sided component whose function is to generate an alert and route it outward to a recipient outside the monitoring system itself (a dispatcher), not the equipment owner or the system's own operator. This outward directed, third-party facing and routing function teaches a deployment or notification module transmitting a notification to a third-party system. This satisfies the conditional requirement of the claim). At the time of the invention, it would have been obvious to a person of ordinary skill in the art to combine McKinley’s alert generating and dispatch mechanism which analyzes incoming equipment signals and when a qualifying condition is detected, it automatically routes a notification to an external service party with Booth’s pool equipment network. So that Booth's existing controller, upon detecting an equipment problem through its own sensing and analysis pathway, triggers McKinley's dispatch mechanism to notify a servicing party outside the system. The motivation for doing so would have been to detect a problem and notify the people who can actually fix the problem. Without this addition, Booth's system can detect a problem but has no disclosed mechanism for getting that problem in front of a person who can actually fix it, the detection capability stops short of producing an actionable outcome. McKinley closes the loop between automated detection and human intervention with the purpose of its design. Therefore, a person of ordinary skill in the art implementing Booth's system would recognize this missing piece and would include McKinley's purpose-built dispatch architecture as the obvious solution. Regarding Claim 13, McKinley teaches the connected aquatic system of claim 12, wherein the notification can include a service request to repair or replace the first component or the second component. (“using the analyzed signals to send alerts to one or more mobile service devices operated by technicians when emergency maintenance is required for the piece of equipment.” (Abstract), disclosing both who receives the alert (technicians) and why it's sent (a maintenance need has arisen). Because "maintenance" is triggered by a detected equipment problem requiring technician intervention, it functions as the same category of action as a service request to repair. Thereby, the alert is not informational only, it's a call for corrective service on the affected equipment. This satisfies the conditional requirement of the claim). Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davito, Booth, and Spero, and further in view of Nainar. Regarding Claim 20, Davito, Booth and Spero do not teach the user data is stored in a sequential system of recording data elements. However, Nainar teaches the user data is stored in a sequential system of recording data elements. (“A block chain begins with the creation of a ‘genesis’ block. Each subsequent block then includes a hash of the previous block in the block chain.” (¶ 0023), meaning a structure where every new record is cryptographically bound to the one immediately before it and can only be read in the order it was created. Records cannot be reordered, inserted, or altered after the fact without breaking that chain. This strict, verifiable ordering is what "a sequential system of recording data elements" describes, not just data stored one after another, but data whose sequence is itself locked in by the storage mechanism). At the time of the invention, it would have been obvious to a person of ordinary skill in the art to combine Nainar’s chained block recordation structure and applied to how Booth, Davito and Spero's QR derived user data gets stored once extracted rather than storing that data in an ordinary, freely editable record, it gets committed to a sequentially linked structure where each new entry is bound to the one before it. The motivation for doing so would have been to protect device identifying and user data from being silently altered or reordered after the fact. Once a QR derived record is used to configure equipment automatically, the integrity of that record matters. If a bad element or a software fault could quietly rewrite past entries, the system would have no way of detecting it. Nainar stated “Changing environmental conditions may also affect device communications” (¶ 0002), so a person of ordinary skill in the art implementing Booth, Davito and Spero's data extraction scheme in a real-world, security conscious deployment would look to precisely this kind of established, purpose-built solution. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892. Contact Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHANDNI PATEL whose telephone number is (571)272-9661. The examiner can normally be reached Monday-Friday 7am-4pm, every other Friday off. 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, Scott Baderman can be reached at (571)272-3644. 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. /CHANDNI PATEL/Examiner, Art Unit 2118 /SCOTT T BADERMAN/Supervisory Patent Examiner, Art Unit 2118
Read full office action

Prosecution Timeline

Dec 22, 2023
Application Filed
Jul 27, 2026
Non-Final Rejection mailed — §102, §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month