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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 18, 2026 has been entered.
Claims 1, 5, 11 and 15 have been amended.
Claims 2, 6, 7, 8, 9, 10, 12, 16 - 20 are originals.
Claims 3, 4, 13-14 are previously presented.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture, or composition of matter? MPEP 2106.03.
Step 1, claims 1-10 are directed to a system, and claim 11-20 are directed to a method. Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claim 1 and 11 is (claim 1 being representative):
A method, comprising:
receiving, by a data processing system comprising one or more processors and memory, from a client device via a network, an identifier of a lighting fixture detected by the client device;
receiving, by the data processing system from the client device, location information and sensor data collected by a sensor of the client device that provides an indication of performance of the lighting fixture , wherein the sensor data comprises information related to luminous flux output by the lighting fixture, color temperature output by the lighting fixture, or flicker in output by the lighting fixture;
determining, by the data processing system, lighting fixture is active based on a combination of the indication of the performance provided by the sensor data, the location information, and the identifier;
generating, by the data processing system based on the status of the warranty, an action to improve performance in at least one of the luminous flux, the color temperature or the flicker in output of the lighting fixture by a selection of a corrective operation associated with the determined performance indication; and
automatically executing, by the data processing system, the generated action by transmission, via the network, a machine-readable control instruction to the lighting fixture that causes the lighting fixture to modify at least one operational parameter to cause the improvement to the performance of the lighting fixture.
The abstract idea steps italicized above are those which could be performed mentally, including with pen and paper. The steps describe, at a high level, receiving and executing information on performance of a light fixture. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, including receiving, determining, generating and executing, then it falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally, and alternatively, the abstract idea steps italicized above relate to the rules or instructions pertaining to detecting faults in light fixtures, which constitutes a process that, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people. This is further supported by [0040] of applicant’s specification as filed. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior relationships, interactions between people, including social activities, teaching, and/or following rules or instructions, then it falls within the Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f).
Claim 1 and 11 recites the following additional elements: processors and memory, client device, a data processing system, a network, an identifier of a lighting fixture and a sensor data.
These elements are merely instructions to apply the abstract idea to a computer, per MPEP 2106.05(f). Applicant has only described generic computing elements in their specification, as seen in {[0077]} of applicant’s specification as filed, for example.
Further, the combination of these elements is nothing more than a generic computing system applied to the tasks of the abstract idea. Because the additional elements are merely instructions to apply the abstract idea to a generic computing system, they do not integrate the abstract idea into a practical application, when viewed in combination. See MPEP 2106.05(f).
Therefore, per Step 2A Prong Two, the additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two pertaining to MPEP 2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitate the tasks of the abstract idea, as described in MPEP 2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system with QR code, sensors, lighting fixture and Firmware. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
Dependent claims 2-10, 12-20 contains additional steps that further narrow the abstract idea above.
Claim 3-6, 8-10, 13-16 and 18- 20 recites the following additional elements: Data processing, client device, sensor, a graphical user interface, light fixture. Applicant has only described generic computing elements in their specification, as seen in {[0029]} of applicant’s specification as filed. This does not integrate the abstract idea into practical application and/or add significantly more. The claim is ineligible. Refer to MPEP 2106.05(F).
Claim 2 and 12 recites the following additional elements: QR code. Applicant has only described generic computing elements in their specification, as seen in {[0026]} of applicant’s specification as filed. This does not integrate the abstract idea into practical application and/or add significantly more. The claim is ineligible. Refer to MPEP 2106.05(F).
Claim 7 and 17 recites the following additional elements: firmware. Applicant has only described generic computing elements in their specification, as seen in {[0077]} of applicant’s specification as filed. This does not integrate the abstract idea into practical application and/or add significantly more. The claim is ineligible. Refer to MPEP 2106.05(F).
Accordingly, claims 1-20 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non - statutory subject matter.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3-11, 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Potucek et al [2017/0212489], hereafter Potucek, in view of Secretin et al [ES 2926326T3], hereafter Secretin.
As per claim(s) 1 and 11 (Similar scope and language);
Potucek discloses;
A system, comprising:
a data processing system comprising one or more processors and memory to:
{[0053] A processor 22 provides local processing capability for each of the subsystems 12 a-12 h. The processor 22 is in communication with a random-access memory 24, and one or more non-volatile memories 28. The non-volatile memory 28 could store one or more local control programs 30 for providing local control of the pool or spa equipment in which the subsystem is installed. A TCP/IP stack 26 is provided for allowing each of the subsystems to obtain an Internet protocol address, and to provide Internet connectivity for each of the subsystems. The processor 22 could communicate with a wired communication subsystem 36, a wireless communication subsystem 34, a sensor interface subsystem 38, and an actuator interface subsystem 40 via a bus 32. The wired communication subsystem 36 could include an Ethernet transceiver 42, and a serial transceiver 44.}
Potucek discloses;
receive, from a client device via a network, an identifier of a lighting fixture detected by the client device; receive, from the client device,
{[0096] For example, the pump control logic 84 could receive input from an external device to identify an operating profile. In another example, the pump control logic 84 could determine the most efficient turn-over rate based on the volume of the body of water.}
Potucek does not discloses the indication of performance of the lighting fixture, however, Secretin discloses;
location information and sensor data collected by a sensor of the client device that provides an indication of performance of the lighting fixture ,
{[Page 4, paragraph 7] In yet another illustrative embodiment, the remote device may be detecting a faulty light fixture based on information received from the light fixture, such as fault or diagnostic data sent by the light fixture to the remote device. This will trigger an on-site fixture repair by an operator. However, it can be difficult for the operator to know, once on site, which street light needs to be repaired, just based on GPS data, for example. To help the operator identify the faulty luminaire detected by the remote device, actions could be taken through the mobile device. For example, the mobile device can provide the operator with a user interface that allows him to request a certain action in order to identify the luminaire, for example, make the faulty luminaire blink. Then, once repaired, the operator can use the mobile device to update the status of the luminaire on the remote device.}
Secretin discloses;
wherein the sensor data comprises information related to luminous flux output by the lighting fixture, color temperature output by the lighting fixture, or flicker in output by the lighting fixture;
{[Page 3, paragraph 8] In an illustrative embodiment, the method performed on the remote device may further comprise receiving the captured image of the luminaire from the mobile device. The selection may then be further based on the captured image, using, for example, image processing techniques. Such image processing techniques can recognize any of the following: a shape of the luminaire, dimensions of the luminaire, a distance from the mobile device to the luminaire, a color of the luminaire, a brand name of the luminaire, a change in intensity of light such as a flicker or intermittent pattern of a luminaire light source, a luminaire serial number, a quick response (QR) code on a luminaire housing or support pole or pole module, etc.}
Secretin discloses;
determine, is active based on a combination of the indication of the performance provided by the sensor data, the location information, and the identifier;
{[Page 3, paragraph 10] The diagnostic and/or operating status data may comprise any one or more of the following data: an operating temperature of the luminaire, a level of vibrations experienced by the luminaire, an operating power level of the luminaire, a number of off and/or on states of the luminaire, a number of operating luminous elements of the light source, an operating state of a surge protection device in the luminaire, an operating time of the luminaire, information on luminaire failure such as power supply failure signal, dimming profile data, light source failure data, calibration data, power consumption data, etc. The luminaire may comprise any one or more of the following sensors: a camera, a microphone or other sound sensor, a photosensitive sensor, an accelerometer, a wind sensor, a heat/thermal sensor, a thermometer, an RF sensor, an electromagnetic sensor, a smoke sensor, a dust sensor, an air quality sensor, a visibility sensor, a humidity sensor, an IR sensor, a motion sensor, an (ultra)sonic sensor, a sensor microwave, another type of environmental sensor, a radar or lidar-based sensor, etc.}
Secretin discloses;
generate, based on the status of the warranty, an action to improve performance in at least one of the luminous flux, the color temperature or the flicker in output of the lighting fixture by selecting a corrective operation associated with the determined performance indication; and
{[Page 4, paragraph 3] In more developed embodiments, the mobile device may use the information about one or more selected light fixtures to perform actions on said one or more selected light fixtures, such as control actions. For example, the mobile device can turn on one or more selected luminaires in off mode or standby mode based on, for example, information about the operating time of one or more selected luminaires, or it can adjust the light distribution of one or more selected luminaires based, for example, on information about the light distribution of one or more selected luminaires, or you can adjust the light intensity of one or more selected luminaires based, for example, on information about the time-vs. dimming profile or lumens data for that or more selected fixtures. Therefore, in these more developed embodiments, a control interface can be provided between the mobile device and one or more selected light fixtures. In this way, a triangular communication between a luminaire, a mobile device and a remote device is enabled. For example, the remote device may cause luminaires that are closer to the mobile device to change their emitted light, for example, change their light intensity and/or the color of the emitted light, and/or a flashing pattern (for example, the luminaires may flicker one after another). Optionally, the mobile device can be configured to select a luminaire based on this emitted light, and can further control said selected luminaire.}
Secretin discloses;
automatically execute the generated action by transmitting, via the network, a machine-readable control instruction to the lighting fixture that causes the lighting fixture to modify at least one operational parameter to cause the improvement to the performance of the lighting fixture.
{[Page 4, paragraph 5] This can be done manually by an operator or it can be done remotely by appropriately controlling an actuator within the luminaire head. For example, the mobile device may provide the user with a user interface that allows the user to input a desired change in light distribution, after which the mobile device communicates this input to the remote device. The remote device can then remotely control an actuator on the light fixture to make the desired change. The user interface may be an intuitive user interface, for example, allowing a user to modify a size and/or shape of the light beam directly on the captured image of the luminaire displayed on the mobile device. After the change, a database that stores information about the light distribution of the luminaire can be updated.}
[Page 2, paragraph 5] Furthermore, the transmission of location information to the remote device may be performed at the request of a user of the mobile device, or it may be performed automatically, eg, periodically, when a suitable application is run on the mobile device.
[Page 4, paragraph 9] According to yet another aspect, a data storage device is provided that encodes a program in machine-readable and machine-executable form for performing one or more steps of any of the embodiments of the methods described above. Furthermore, the invention relates to a mobile device that encodes a machine executable program of instructions to perform any of the method steps performed by the mobile device. Furthermore, the invention relates to a controller or server that stores computer-executable instructions for performing any of the method steps performed by the remote device, when the program is executed on a computer.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combined/modify/adjust the combination Potucek et al’s fault detection system to include Secretin et al’s location information and sensor data collected by a sensor of the client device that provides an indication of performance of the lighting fixture, wherein the sensor data comprises information related to luminous flux output by the lighting fixture, color temperature output by the lighting fixture, or flicker in output by the lighting fixture; determine, a status of a warranty for the lighting fixture is active based on a combination of the indication of the performance provided by the sensor data, the location information, and the identifier; generate, based on the status of the warranty, an action to improve performance in at least one of the luminous flux, the color temperature or the flicker in output of the lighting fixture by selecting a corrective operation associated with the determined performance indication; and automatically execute the generated action by transmitting, via the network, a machine-readable control instruction to the lighting fixture that causes the lighting fixture to modify at least one operational parameter to cause the improvement to the performance of the lighting fixture, since Potucek teaches the data processing system to receive, from the client device, the identifier as a bar code. See Potucek [0053, 0096]. The combination would have been obvious because a person of ordinary skill in the art to modify the fault resolution for lighting fixtures of Potucek to include a fault or diagnostic data, GPS data, a flicker, and a warranty status for the lighting fixture to enable a proper tracking and improvement to the performance of the lighting fixture. See Secretin [ Page 3 paragraph 8, page 4 paragraph 10, Page 4 paragraph 3, Page 4 paragraph 5] and [Page 4, paragraph 9].
As per claim 3 and 13 (Similar scope and language);
Potucek discloses;
The system of claim 1, comprising the data processing system to: receive, from the client device, the location information detected by a location sensor of the client device; and determine the status of the warranty based on the location information.
location information;
{[0305] Optionally, in step 3585, pool control logic 70 could receive the equipment bar code data scanned by the smart device. In step 3572, the smart device identifies the location of the scanned equipment (e.g., via GPS, geo-positioning application, etc.). In step 3574, the smart device transmits the location of the equipment and the date of service/installation to the cloud.}
Potucek discloses;
determine the status of the warranty based on the location information.
{[0095] The information can include, but is not limited to, date of installation, warranty registration, warranty possible claims, feedback of problems daily operating conditions, usage statistics, feedback of power supply conditions or quality, detailed profiles of pool pad setups, and information related to other equipment the pump may be controlling. The pump control logic 84 can also automatically register warranties and submit warranty claims should there be an issue with any piece of equipment in the system.
[0105] The fourth sequence begins in step 1070 where the pump control logic 84 retrieves factory warranty data from memory, e.g., a warranty expiration date. In step 1072, the pump control logic 84 determines an alert threshold, e.g., days left on factory warranty. In step 1074, the pump control logic 84 receives current date information.
[0351] Also contemplated is capturing specific equipment data (e.g., bar codes) by a smartphone camera at the site at the time of installation and connecting to an application. This can, at the same time, capture GPS coordinates for the address and date of installation for warranty registration, and automatically load the location of the pool into the pool control logic with cloud support for sunrise/sunset, real time and forecasted weather data.}
As per claim 4 and 14 (Similar scope and language);
Secretin discloses;
The system of claim 1, comprising the data processing system to: provide, for display via the client device, a graphical user interface; and receive, via input from the graphical user interface, the indication of performance of the light fixture.
{[Page 4, paragraph 7] In yet another illustrative embodiment, the remote device may be detecting a faulty light fixture based on information received from the light fixture, such as fault or diagnostic data sent by the light fixture to the remote device. This will trigger an on-site fixture repair by an operator. However, it can be difficult for the operator to know, once on site, which street light needs to be repaired, just based on GPS data, for example. To help the operator identify the faulty luminaire detected by the remote device, actions could be taken through the mobile device. For example, the mobile device can provide the operator with a user interface that allows him to request a certain action in order to identify the luminaire, for example, make the faulty luminaire blink. Then, once repaired, the operator can use the mobile device to update the status of the luminaire on the remote device.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combined/modify/adjust the combination Potucek et al’s fault detection system to include Secretin et al’s data processing system to: provide, for display via the client device, a graphical user interface; and receive, via input from the graphical user interface, the indication of performance of the light fixture, since Potucek teaches the data processing system to receive, from the client device, the identifier as a bar code. See Potucek [0053, 0096]. The combination would have been obvious because a person of ordinary skill in the art to modify the fault resolution for lighting fixtures of Potucek to include a remote device to detect and transmit a fault or a diagnostic data. See Secretin [Page 4, paragraph 7].
As per claim 5 and 15 (Similar scope and language);
Secretin discloses;
The system of claim 1, comprising the data processing system to: receive, via the client device, the sensor data collected by [[a]] the sensor of the client device, the sensor data comprising ambient light information corresponding to performance of the light fixture; and determine the performance of the light fixture based at least in part on the ambient light information.
{[Page 2, paragraph 8] The display comprises displaying luminaire data of the luminaire in the captured image based on the information received. For example, depending on the configuration of the mobile device, all the information received regarding the luminaire and the captured image, or part of the information received, can be displayed. In addition, the information received can be converted into a suitable format for display.
[Page 3, paragraph 10] The diagnostic and/or operating status data may comprise any one or more of the following data: an operating temperature of the luminaire, a level of vibrations experienced by the luminaire, an operating power level of the luminaire, a number of off and/or on states of the luminaire, a number of operating luminous elements of the light source, an operating state of a surge protection device in the luminaire, an operating time of the luminaire, information on luminaire failure such as power supply failure signal, dimming profile data, light source failure data, calibration data, power consumption data, etc. The luminaire may comprise any one or more of the following sensors: a camera, a microphone or other sound sensor, a photosensitive sensor, an accelerometer, a wind sensor, a heat/thermal sensor, a thermometer, an RF sensor, an electromagnetic sensor, a smoke sensor, a dust sensor, an air quality sensor, a visibility sensor, a humidity sensor, an IR sensor, a motion sensor, an (ultra)sonic sensor, a sensor microwave, another type of environmental sensor, a radar or lidar-based sensor, etc.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combined/modify/adjust the combination Potucek et al’s fault detection system to include Secretin et al’s data processing system to: receive, via the client device, the sensor data collected by [[a]] the sensor of the client device, the sensor data comprising ambient light information corresponding to performance of the light fixture; and determine the performance of the light fixture based at least in part on the ambient light information, since Potucek teaches the data processing system to receive, from the client device, the identifier as a bar code. See Potucek [0053, 0096]. The combination would have been obvious because a person of ordinary skill in the art to modify the fault resolution for lighting fixtures of Potucek to include a fault or diagnostic data, GPS data, a flicker, and a warranty status for the lighting fixture to enable a proper tracking and improvement to the performance of the lighting fixture. See Secretin [Page 2, paragraph 8] and [Page 3, paragraph 10].
As per claim 6 and 16 (Similar scope and language);
Potucek discloses;
The system of claim 1, comprising the data processing system to: receive, from the client device, authentication information; and determine the status of the warranty of the light fixture based at least in part on the authentication information.
{[0095] The information can include, but is not limited to, date of installation, warranty registration, warranty possible claims, feedback of problems daily operating conditions, usage statistics, feedback of power supply conditions or quality, detailed profiles of pool pad setups, and information related to other equipment the pump may be controlling. The pump control logic 84 can also automatically register warranties and submit warranty claims should there be an issue with any piece of equipment in the system.
[0105] The fourth sequence begins in step 1070 where the pump control logic 84 retrieves factory warranty data from memory, e.g., a warranty expiration date. In step 1072, the pump control logic 84 determines an alert threshold, e.g., days left on factory warranty. In step 1074, the pump control logic 84 receives current date information.
[0351] Also contemplated is capturing specific equipment data (e.g., bar codes) by a smartphone camera at the site at the time of installation and connecting to an application. This can, at the same time, capture GPS coordinates for the address and date of installation for warranty registration, and automatically load the location of the pool into the pool control logic with cloud support for sunrise/sunset, real time and forecasted weather data.}
As per claim 7 and 17 (Similar scope and language);
Potucek discloses;
The system of claim 1, comprising the data processing system to: generate the action to push a firmware update to the lighting fixture.
{[0347] personal data produced in conjunction with web or web enabled device (e.g., nest, phone, hub, etc.) such as location (e.g., home, away, on the way home, etc.), data usage, amount of web enabled devices used or connected (e.g., five downloaded apps could represent a family of five), energy used (e.g., fuel, electricity, etc.), data speed (e.g., upload/download rate (mbps), ping), etc.; and product data (e.g., in conjunction with registration) such as warranty, age, recalls, tech bulletins, replacement parts, specs, tech support, tutorials (e.g., instructional videos), specials (e.g., coupons, promotions, etc.), local support (e.g., authorized service center), firmware updates, new product releases, pool industry news, safety alerts, safety suggestions, etc.
Secretin discloses;
{[Page 4, paragraph 3] In more developed embodiments, the mobile device may use the information about one or more selected light fixtures to perform actions on said one or more selected light fixtures, such as control actions. For example, the mobile device can turn on one or more selected luminaires in off mode or standby mode based on, for example, information about the operating time of one or more selected luminaires, or it can adjust the light distribution of one or more selected luminaires based, for example, on information about the light distribution of one or more selected luminaires, or you can adjust the light intensity of one or more selected luminaires based, for example, on information about the time-vs. dimming profile or lumens data for that or more selected fixtures.
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combined/modify/adjust the combination Potucek et al’s fault detection system to include Secretin et al’s lighting fixture, since Potucek teaches the data processing system to receive, from the client device, the identifier as a bar code. See Potucek [0053, 0096]. The combination would have been obvious because a person of ordinary skill in the art to modify the fault resolution for lighting fixtures of Potucek to include a remote device to detect and transmit a fault or a diagnostic data of a lighting fixture. See Secretin [Page 4, paragraph 3].
As per claim 8 and 18 (Similar scope and language);
Potucek discloses;
The system of claim 1, comprising the data processing system to: responsive to receipt of the indication of the performance information from the client device,
{[0144] In step 4418, the pump control logic 84 provides an indication of system efficiency such as “efficiency mode,” “performance mode” etc. and assigns a push button to go to a selected mode with one push of a button. In step 4420, the pump control logic 84 calculates periods of hydraulic inefficiencies and in step 4422, it recommends ways to improve hydraulic efficiency. In step 4424, the pump control logic 84 auto-delivers the correct flow or speed to make the equipment more efficient.
[0086] Accordingly, variable speed pumping system and controller 4514 a could use the modularly upgradeable smart relays to control a variety of existing installed pool/spa equipment including single speed pumps, pressure cleaner booster pumps, LED and incandescent pool lights, and landscape lights. The modularly upgradeable control components can be used by pump control logic 84 to provide pump or system performance reporting and diagnostic functions (present and historical) including, but not limited to, phase current, torque, speed, horsepower, run time, and ramp rate. Pump control logic 84 could provide the system performance and diagnostic information to the cloud, or to a smart to a smart device via a Bluetooth or any of the other communication protocols disclosed herein.}
Potucek discloses;
determine a fault associated with the lighting fixture based on the indication and the status information;
{[0352] The smart light 5014 h could further include a display 5019 provided as a separate component or integrally provided with user input module 5018. The smart light 5014 h could accordingly be used to display an error message for a fault condition or warning message regarding pool chemistry, or could be used to display any other kind of visual media.
[0095] The information can include, but is not limited to, date of installation, warranty registration, warranty possible claims, feedback of problems daily operating conditions, usage statistics, feedback of power supply conditions or quality, detailed profiles of pool pad setups, and information related to other equipment the pump may be controlling. The pump control logic 84 can also automatically register warranties and submit warranty claims should there be an issue with any piece of equipment in the system.}
Potucek discloses;
and determine, based on the fault and the status of the warranty, to apply the warranty to improve performance of the light fixture.
{[0095] The information can include, but is not limited to, date of installation, warranty registration, warranty possible claims, feedback of problems daily operating conditions, usage statistics, feedback of power supply conditions or quality, detailed profiles of pool pad setups, and information related to other equipment the pump may be controlling. The pump control logic 84 can also automatically register warranties and submit warranty claims should there be an issue with any piece of equipment in the system.
[0105] The fourth sequence begins in step 1070 where the pump control logic 84 retrieves factory warranty data from memory, e.g., a warranty expiration date. In step 1072, the pump control logic 84 determines an alert threshold, e.g., days left on factory warranty. In step 1074, the pump control logic 84 receives current date information.}
[0352] The smart light 5014 h could accordingly be used to display an error message for a fault condition or warning message regarding pool chemistry, or could be used to display any other kind of visual media. Although previously discussed, it is noted that the network communication and local control subsystem 12 h could communicate with pool control logic 70, located in one or more of the pool/spa components discussed herein, using any of the communication protocols discussed herein, including but not limited to, power line carrier, ethernet, RF, Bluetooth, Wi-Fi, and ZigBee.}
Secretin discloses;
poll the lighting fixture to obtain status information;
{[Page 4, paragraph 7] However, it can be difficult for the operator to know, once on site, which street light needs to be repaired, just based on GPS data, for example. To help the operator identify the faulty luminaire detected by the remote device, actions could be taken through the mobile device. For example, the mobile device can provide the operator with a user interface that allows him to request a certain action in order to identify the luminaire, for example, make the faulty luminaire blink. Then, once repaired, the operator can use the mobile device to update the status of the luminaire on the remote device.}
[Page 5, Paragraph 4] Diagnostic and/or operating status data may comprise one or more of the following data: an operating temperature of the luminaire, a level of vibrations experienced by the luminaire, an operating power level of the luminaire, a number of off and/or on states of the luminaire, a number of operating luminous elements of the light source, an operating status of a surge protection device in the luminaire, an operating time of the luminaire, information on luminaire failure, such as a power failure signal, dimming profile data, light source failure data, calibration, energy consumption data, etc.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combined/modify/adjust the combination Potucek et al’s fault detection system to include Secretin et al’s poll the lighting fixture to obtain status information, since Potucek teaches the data processing system to receive, from the client device, the identifier as a bar code. See Potucek [0053, 0096]. The combination would have been obvious because a person of ordinary skill in the art to modify the fault resolution for lighting fixtures of Potucek to include a remote device to determine the status and transmit a fault or a diagnostic data. See Secretin [Page 4, paragraph 7].
As per claim 9 and 19 (Similar scope and language);
Potucek discloses;
The system of claim 1, wherein the status of the warranty comprises one of active or inactive.
{[0212] The sixth sequence begins in step 2034 where the lighting control logic 78 retrieves factory warranty data from memory. In step 2036, the lighting control logic 78 determines a maintenance threshold, e.g., 90% of the time period of the factory warranty has expired. In step 2038, the lighting control logic 78 receives operational data on lighting system runtime. In step 2040, the lighting control logic 78 determines if the lighting system runtime is greater than the threshold. If a negative determination is made, then the process returns to step 2038 and continues to receive operational data on lighting system runtime. If a positive determination is made, then the process proceeds to step 2042 where a preventative maintenance reminder is transmitted to a user, and the process ends.}
As per claim 10 and 20 (Similar scope and language);
Potucek discloses;
The system of claim 1, comprising the data processing system to: provide, for display via the client device, the status of the warranty and
{[0095] The information can include, but is not limited to, date of installation, warranty registration, warranty possible claims, feedback of problems daily operating conditions, usage statistics, feedback of power supply conditions or quality, detailed profiles of pool pad setups, and information related to other equipment the pump may be controlling. The pump control logic 84 can also automatically register warranties and submit warranty claims should there be an issue with any piece of equipment in the system.}
Potucek discloses;
an expiration date of the warranty
{[0105] The fourth sequence begins in step 1070 where the pump control logic 84 retrieves factory warranty data from memory, e.g., a warranty expiration date. In step 1072, the pump control logic 84 determines an alert threshold, e.g., days left on factory warranty. In step 1074, the pump control logic 84 receives current date information.}
Claim(s) 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Potucek et al, in view of Secretin et al, in further view of Witzgall et al [2016/0286630] hereafter Witzgall.
Potucek discloses;
The system of claim 1, comprising: the data processing system to receive, from the client device, the identifier as a QR code.
{[0305] FIG. 33AD is a flowchart illustrating processing steps carried out by the pool control logic 70 for communicating with a smart device in the possession of a servicer/installer. In step 3570 the smart device scans an equipment bar code (e.g., at time of service, installation, etc.). Optionally, in step 3585, pool control logic 70 could receive the equipment bar code data scanned by the smart device. In step 3572, the smart device identifies the location of the scanned equipment (e.g., via GPS, geo-positioning application, etc.). In step 3574, the smart device transmits the location of the equipment and the date of service/installation to the cloud.
[0306] FIG. 33AE is a flowchart illustrating processing steps carried out by the pool control logic 70 for communicating with an application used by a servicer/installer. In step 3586, a smart device scans an equipment bar code (e.g., at the time of service, installation, etc.). Optionally, in step 3606, pool control logic 70 could receive the equipment bar code data scanned by the smart device. In step 3588, an application on the smart device receives equipment information (e.g., web data from the equipment manufacturer).}
Potucek teaches the use of a bar code, however, Witzgall discloses the QR code.
Witzgall discloses;
{[0098] In some embodiments, the user inputs the fixture type or its static parameters plus a mapping of the location or a unique identifier, and the system accesses one or more databases that contain static properties of the fixture. The automated mapping technologies may include but are not limited to taking photos that are analyzed or importing mapped data such as lighting plans and fixture specifications. Alternatively, the user may input the relevant properties into the system. Still further, in other embodiments, there is a bar code or QR code or other code on each device and the user takes a picture of the code and transmits that code to the relevant central processing unit, which accesses a database that contains the static and variable properties.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combined/modify/adjust the combination Potucek et al’s fault detection system to include Witzgall et al’s QR code since Potucek teaches the data processing system to receive, from the client device, the identifier as a bar code. See Potucek [0053, 0096, 0144, 0086, 0305, 0065, 0105, 0178, 0095]. The combination would have been obvious to one ordinary skill in the art to modify Potucek to include a QR code as a unique identifier, to analyze the maintenance rate. See Witzgall [0098].
Rejection of Claims under 35 USC § 101
In response to the argument filled March 18, 2026, on page 7-12, regarding the 101 rejections, the Examiner Respectfully disagrees.
Applicant argues that the claims integrate an alleged judicial exception into a practical application and thus impose a meaningful limit on the judicial exception. Applicant argues that the claims reflect an improvement to technology, that the operations refer to sensor hardware, network communication, memory, and machine-readable control instructions that directly affect the operation of a physical lighting fixture.
Applicant also argues that the claims are technological functions which cannot be performed in the human mind and therefore fall outside the mental-process grouping. According to Applicant, the amended claim recites:
receive, from the client device, location information and sensor data
collected by a sensor of the client device that provides an indication of performance of the lighting fixture, wherein the sensor data comprises information related to luminous flux output by the lighting fixture, color temperature output by the lighting fixture, or flicker in output by the lighting fixture;
determine a status of a warranty for the lighting fixture is active based on a combination of the indication of the performance provided by the sensor data, the location information, and the identifier;
generate, based on the status of the warranty, an action to improve
performance in at least one of the luminous flux, the color temperature or the flicker in output of the lighting fixture by selecting a corrective operation associated with the determined performance indication; and
automatically execute the generated action by transmitting, via the network, a machine-readable control instruction to the lighting fixture that causes the lighting fixture to modify at least one operational parameter to cause the improvement to the performance of the lighting fixture.
Applicant contends that “the claimed operations refer to sensor hardware, network communication, memory, and machine-readable control instructions that directly affect the operation of a physical lighting fixture. Such steps cannot practically be performed in the human mind and therefore fall outside the mental-process grouping. Nor are the claims directed to mere information analysis or result-based data evaluation. Rather, the claims are directed to objective sensor-based measurement, automated decision logic based on warranty status, and device-level remediation”.
The Examiner respectfully disagrees. The Examiner views that the limitations provided by Applicant are steps of the recited abstract idea for executing instructions and information on performance of a lighting fixture. Specifically, the Examiner views receiving a performance from a device, locating and collecting information from a (sensor), determining (the status of the lighting fixture), generating (a corrective operation), executing and transmitting the information, recite steps for managing tasks and interactions among users rather than additional elements that could integrate the abstract idea into a practical application or adds significantly more.
The Examiner notes that the aspects pertaining receiving, determining, generating, transmitting and automatically executing a generated action to cause the improvement to the performance of a lighting fixture constitutes a process that, under its broadest reasonable interpretation, falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas.
The Examiner views Applicant’s proffered benefits of technological control of a physical system using real-world sensor inputs, network communication, memory and machine-readable control signals for a lighting fixture as benefits from performing the recited abstract idea rather than provided by the additional elements of the claim, which the Examiner identified under the Step 2A Prong 2 and 2B Analyses to be mere instructions to apply the abstract idea using generic computing components and does not integrate the abstract idea into a practical application or adds significantly more. MPEP 2106.05 (f)
Furthermore, the Examiner respectfully disagrees that the claims provide an improvement to technology, that the operations refer to sensor hardware, network communication, memory, and machine-readable control instructions that directly affect the operation of a physical lighting fixture. These falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. These are merely generic technology with no technical improvement rather an improvement to the abstract idea using generic technology. See specification {[0077]}.
The Examiner maintains these claims recite an abstract idea.
Therefore, for the foregoing reasons the Examiner has maintained the 35 USC 101 rejection.
Regarding the prior art rejections 35 USC102/103, the Examiner respectfully disagrees.
Applicant argues that the prior art of record fails to teach the claims specifically that the amended claim limitations recite "sensor data collected by a sensor of the client device that provides an indication of performance of the lighting fixture, wherein the sensor data comprises information related to luminous flux output by the lighting fixture, color temperature output by the lighting fixture, or flicker in output by the lighting fixture,"
The Examiner respectfully disagrees.
In response to the amended claims, Examiner includes the prior art of Secretin et al. to teach “sensor data collected by a sensor of the client device that provides an indication of performance of the lighting fixture, wherein the sensor data comprises information related to luminous flux output by the lighting fixture, color temperature output by the lighting fixture, or flicker in output by the lighting fixture”, See Secretin {[Page 3, paragraph 8] and [Page 4, paragraph 7].
Secretin does teach "determine a status of a warranty for the lighting fixture is active based on a combination of the indication of the performance provided by the sensor data, the location information, and the identifier," See Secretin [Page 3, paragraph 10] and
[Page 4, paragraph 3].
Secretin does teach "generate, based on the status of the warranty, an action to improve performance in at least one of the luminous flux, the color temperature or the flicker in output of the lighting fixture by selecting a corrective operation associated with the determined performance indication," See Secretin [Page 2, paragraph 8] and [Page 4, paragraph 3].
Secretin does teach "automatically execute the generated action by transmitting, via the network, a machine-readable control instruction to the lighting fixture that causes the lighting fixture to modify at least one operational parameter to cause the improvement to the performance of the lighting fixture," See Secretin [Page 4, paragraph 9] and [Page 4, paragraph 5]
In terms of the arguments Potucek, Secretin and Witzgall does teach specific limitations such as amended.
Based on the considered amendments cited, 35 USC 103 references have been utilized to teach the claimed invention (claim 1, 5, 11, and 15).
Lacking any further argument, claims 1-20 are maintaining the 35 USC 102/103 rejection, as considered above in light of the amended claim limitation above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Frank et el (CN 102318350 A) – directed towards an improvement to the digital picture optical projection system; And be used for the seamless fusion of the image of a plurality of digital picture projector projection; To produce the combination image of a plurality of projectors; This provides to the independent control of integration region and to the independent control of the image parameter in the said variable integration region for the user, for example brightness, contrast, unique color shading and gamma correction.
P. Amato, N. Izzo and C. Meijer, "Mobile Systems Secure State Management," 2022 25th Euromicro Conference on Digital System Design (DSD), Maspalomas, Spain, 2022, pp. 564-571 (Year: 2026)
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 VICTOR ESONU whose telephone number is (571)272 -4883. The examiner can normally be reached Monday - Friday 9:00 am - 5pm.
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, Sarah Monfeldt can be reached on (571) 270-1833. 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, vis it: 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.
/VICTOR ESONU/
Examiner, Art Unit 3629
/SARAH M MONFELDT/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights