DETAILED ACTION
Claims 1-20 are presented for examination. This office action is response to the submission on 3/22/2026. Claims 1-3, 8-10, 12-17 are amended.
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 .
Response to Arguments
With respect to 35 U.S.C. §103 Rejections:
Applicant’s arguments, see pages 9-10 of applicant response filed 3/22/2026, with respect to claim 1 have been fully considered and are persuasive. Examiner agrees that Patel et al. (US20210034024A1) does not disclose determining a proxy limit value based on predicted future values of one or more controlled variables or predicting future controlled-variable values for the purpose of determining constraint reachability. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Risbeck et al. (US20210041127A1).
Applicant’s arguments, see page 10 of applicant response filed 3/22/2026, with respect to claim 1 have been fully considered and are not persuasive. Applicant argues that Patel does not teach computing or communicating a metric that represents how far a controlled variable can be adjusted before a constraint is violated. Examiner disagrees. As described in the previous office action, Patel determines a minimum and maximum temperature, which is a constraint that determines how far a controlled variable can be adjusted in Patel [0247].
Applicant’s arguments, see pages 10-12 of applicant response filed 3/22/2026, with respect to claim 1 have been fully considered and are moot. Applicant argues that Sprinkle et al. (US20150378373A1) does not teach the proxy limit computations as specified in claim 1. Sprinkle is not relied upon to teach these claim limitations. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. (US20210034024A1), in view of Sprinkle et al. (US20150378373A1), further in view of Risbeck et al. (US20210041127A1).
Claim 1:
Patel teaches “A computer-implemented method for optimizing carbon emissions and/or energy usage of a site comprising: obtaining a planning model for optimizing carbon emissions and/or energy usage of the site at a site-wide model predictive control (MPC) controller;” (Patel teaches a high-level MPC controller 608 i.e. a site-wide model predictive controller including high-level optimizer 712 which formulates an optimization problem i.e. a planning model that minimizes the total cost of energy consumed of the MPC system i.e. optimizes energy usage in Patel [0221] "High-level optimizer 712 can use the energy cost model, airside power consumption model, demand charge model, building temperature model, thermal energy storage model, waterside demand model, and optimization constraints to formulate an optimization problem. In some embodiments, high-level optimizer 712 seeks to minimize the total cost of energy consumed by the aggregate airside/waterside system subject to the building temperature constraints and other constraints provided by the high-level models described herein"
PNG
media_image1.png
625
839
media_image1.png
Greyscale
),
“receiving at least one proxy limit value from the one or more unit MPC controllers at the site-wide MPC controller (Patel teaches low-level MPC 612-616 i.e. unit MPC controllers providing aggregate building parameters and variables i.e. proxy limit values to high-level MPC controllers i.e. site-wide MPC controller in Patel [0258] "In some embodiments, model aggregator 818 provides the aggregate building parameters and variables Tb, Cb, Hb, and {dot over (Q)}other,b to high-level MPC 608. High-level MPC 608 can use such values as inputs to the high-level models, constraints, and optimization function used in the high-level optimization. Advantageously, the model aggregation performed by model aggregator 818 helps to reduce the amount of information exchanged between each low-level airside MPC 612-616 and high-level MPC 608. For example, each low-level MPC 612-616 can provide high-level MPC 608 with the aggregate values described above rather than individual values of such variables and parameters for each building zone."
PNG
media_image2.png
636
854
media_image2.png
Greyscale
),
“wherein the at least one proxy limit value identifies a feasible region that is an extent to which the one or more controlled variables controlled by the one or more unit MPC controllers are adjustable without violating one or more controlled variable constraints;” (Patel teaches that model aggregator 818 of the low-level MPC controller provides constraints including the building heat transfer coefficient Hb which would identify how quickly the building could change temperature from the low-level model to the high-level model in Patel [0258] "In some embodiments, model aggregator 818 provides the aggregate building parameters and variables Tb, Cb, Hb, and {dot over (Q)}other,b to high-level MPC 608. High-level MPC 608 can use such values as inputs to the high-level models, constraints, and optimization function used in the high-level optimization."; Patel teaches setting a minimum and maximum temperature for a zone i.e. a proxy limit value with a feasible region that is an extent to which temperature is adjustable using the constraints modeler 810 of the low-level airside model predictive controller 612 in Patel [0247] "Still referring to FIG. 8, low-level airside MPC 612 is shown to include a constraints modeler 810. Constraints modeler 810 can generate and impose optimization constraints on the optimization procedure performed by low-level optimizer 812. Constraints imposed by constraints modeler 810 can include, for example, equipment capacity constraints and zone temperature constraints. In some embodiments, constraints modeler 810 imposes constraints on the zone temperature Ti. For example, constraints modeler 810 can constrain the zone temperature Ti between a minimum temperature Tmin and a maximum temperature Tmax as shown in the following equation:T min ≤T i ≤T maxwhere the values of Tmin and Tmax can be adjusted based on the temperature setpoints of the building."),
“and performing site-wide optimization at the site-wide MPC controller using the planning model and the at least one proxy limit value,” (Patel teaches that high-level controller provides a load profile to each low-level controller in Patel [0174] "The high-level problem can be solved by high-level controller 608 to determine a load profile for each low-level airside subsystem 632-636 and a demand profile for waterside system 30. In some embodiments, high-level controller 608 uses active TES models and aggregate low-level models for each airside subsystem 632-636 to reduce computational complexity. High-level controller 608 can determine load profiles that optimize (e.g., minimize) the total operational cost of MPC system 600 over the optimization period. Each load profile can include a load value for each time step in the optimization period. Low-level airside controllers 612-616 can use the load profiles as constraints defining maximum permissible load values for each airside subsystem 632-636 for each time step in the optimization period. High-level controller 608 can provide the load profiles to each of the low-level airside controller 612-616."; Patel teaches that the MPC layer 610 may determine optimal values of the decision variables subject to constraints in Patel [0172] "MPC layer 610 can receive measurements from regulatory layer 620 and provide setpoints to regulatory layer 620. MPC layer 610 can generate optimal values for various decision variables including, for example, zone temperature setpoints, equipment on/off decisions, and TES charging/discharging rates. MPC layer 610 can determine the optimal values of the decision variables using system models such a zone temperature to cooling/heating duty model, a cooling/heating duty to temperature setpoint model, equipment models, and active TES models. MPC layer 610 can determine the optimal values of the decision variables by performing an optimization process subject to several constraints. The constraints can include comfort bounds on the zone air temperatures, equipment capacity constraints, TES tank size, and rate of change bounds on the equipment of regulatory layer 620."), and
“wherein the one or more controlled variables includes at least one of temperature, (Patel [0166] "Still referring to FIG. 6, distributed MPC system 600 is shown to include a MPC layer 610 and a regulatory layer 620. MPC layer 610 is shown to include a high-level model predictive controller 608 and several low-level model predictive controllers 612-618. Controllers 612, 614, and 616 are shown as low-level airside model predictive controllers, whereas controller 618 is shown as a low-level waterside model predictive controller. MPC layer 610 can be configured to determine and provide optimal temperature setpoints and equipment operating setpoints to the equipment of regulatory layer 620. "; Patel teaches that MPC system 600 can be used in combination with airside system 300 in Patel [0163] "Referring now to FIG. 6, a block diagram of a distributed model predictive control (MPC) system 600 is shown, according to some embodiments. MPC system 600 uses a MPC technique to determine optimal setpoints for the equipment of an airside system and a waterside system over a time horizon. MPC system 600 can be used in combination with HVAC system 20, waterside system 20, airside system 50, HVAC system 100, waterside system 120, airside system 130, waterside system 200, airside system 300, BMS 400, and/or BMS 500, as described with reference to FIGS. 1A-5. For example, MPC system 600 can determine optimal temperature setpoints for the airside equipment 622-626 of airside system 50 and/or airside system 300."; Patel [0123] "Still referring to FIG. 3, AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 positioned within supply air duct 312. Fan 338 can be configured to force supply air 310 through cooling coil 334 and/or heating coil 336 and provide supply air 310 to building zone 306. AHU controller 330 can communicate with fan 338 via communications link 340 to control a flow rate of supply air 310. In some embodiments, AHU controller 330 controls an amount of heating or cooling applied to supply air 310 by modulating a speed of fan 338."
PNG
media_image3.png
628
911
media_image3.png
Greyscale
).
Patel does not appear to explicitly teach “sending at least one optimization request from the site-wide However, Sprinkle does teach this claim limitation (Sprinkle teaches a monitor outputting a query i.e. optimization request to a thermostat i.e. unit controller in Sprinkle [0056] "FIGS. 5A and 5B are flowcharts of processes S1 and S2 performed by the monitor 112 illustrated in FIG. 1 according to an exemplary embodiment of the present invention. The monitor performs the process S1 illustrated in FIG. 5A and the process S2 illustrated in FIG. 5B concurrently. In process S1, the monitor 112 determines if a sampling period n (for example, 5 minutes) has elapsed in step 502. After the sampling period n has elapsed (Step 502: Yes), the monitor 112 outputs a query to the thermostat 114 requesting data in step 504. The data may be, for example, the current setpoint r, the current indoor temperature x, and the time that has elapsed since the last query. The monitor 112 receives current setpoint r in step 506, the current indoor temperature x in step 508, and the time that has elapsed since the last query in step 510. The data is saved in step 512 and output to the server in step 514."; Sprinkle teaches that monitor 112 may output optimized HVAC setpoints in Sprinkle [0053] "In step 314, the end user decides whether to run the HVAC unit 116 based on the optimized HVAC setpoints r*. If so, the monitor 112 outputs optimized HVAC setpoints r* to the thermostat 114 for controlling the HVAC unit 116 in step 320."), and
“receiving at least one proxy limit value from the one or more unit (Sprinkle teaches that monitor 112 may receive a current setpoint i.e. a proxy limit in response to a query i.e. optimization request in Sprinkle [0056] "FIGS. 5A and 5B are flowcharts of processes S1 and S2 performed by the monitor 112 illustrated in FIG. 1 according to an exemplary embodiment of the present invention. The monitor performs the process S1 illustrated in FIG. 5A and the process S2 illustrated in FIG. 5B concurrently. In process S1, the monitor 112 determines if a sampling period n (for example, 5 minutes) has elapsed in step 502. After the sampling period n has elapsed (Step 502: Yes), the monitor 112 outputs a query to the thermostat 114 requesting data in step 504. The data may be, for example, the current setpoint r, the current indoor temperature x, and the time that has elapsed since the last query. The monitor 112 receives current setpoint r in step 506, the current indoor temperature x in step 508, and the time that has elapsed since the last query in step 510. The data is saved in step 512 and output to the server in step 514.").
Patel and Sprinkle are analogous art because they are from the same field of endeavor of HVAC. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Patel and Sprinkle before him/her, to modify the teachings of a high-level model predictive controller (MPC), and a plurality of low-level airside MPCs of Patel to include the system and method for data-driven HVAC optimization of Sprinkle because adding the teachings of outputting a query and receiving setpoints in response to the query of Sprinkle would enable the user to better balance comfort and cost as described in Sprinkle [0038] “In response to HVAC setpoints r input by an end user, the HVAC prediction engine 126 and the cost modelling unit 124 may determine an estimated cost C over a specified time and output the estimated cost C to the end user, for example, via the GUI 140. By providing immediate feedback, the system 100 enables the end user to better balance comfort and cost. Additionally, the system 100 may be configured to determine optimized HVAC setpoints r* based on a desired cost C0 received from the end user, for example, via the GUI 140 and output the optimized HVAC setpoints r* to the thermostat 114 to control the HVAC unit 116.”
Neither Patel or Sprinkle appear to explicitly teach “wherein the at least one proxy limit value is computed by each of the one or more unit MPC controllers based on predicted future values of one or more controlled variables and a set of active unit constraints, wherein the future values of the one or more controlled variables are predicted using one or more MPC model associated with the one or more unit MPC controllers, and” However, Risbeck does teach this claim limitation (Risbeck teaches calculating a predicted future temperature using an MPC in Risbeck [0169] "Still referring to FIG. 7, process 700 is shown to include predicting the zone temperature Tz over the time period by performing model predictive control using the linear physics model and the predicted values of the heat load disturbance {dot over (Q)}other over the time period (step 708). In some embodiments, step 708 is performed by model predictive controller 622 as described with reference to FIG. 6." and in Risbeck [0174] "Step 708 may include executing the model predictive control process (i.e., solving the linear optimization problem subject to the constraints) to determine the optimal values of the decision variables, including the optimal values of Qt, Qh,t, Qc,t, and/or {dot over (Q)}HVAC,t, for each time step t in the optimization period. Step 708 may include using the linear physics model and/or the constraint in Eq. 99 to predict the system states Tzt and Tm,t resulting from the optimal values of Qt, Qh,t, Qc,t, and/or {dot over (Q)}HVAC,t over the optimization period."; Risbeck teaches calculating a temperature setpoint i.e. proxy limit value that is within the domain of the model based on the predicted temperature Tz in Risbeck [0175] "Still referring to FIG. 7, process 700 is shown to include back-calculating the temperature setpoint trajectory Tsp over the time period using an inverse controller model and the predicted zone temperature trajectory Tz (step 710). The inverse controller model c−1(⋅) used in step 710 may be the inverse of the closed-loop controller model c(⋅) 414. As discussed above, controller model 414 may be a closed-loop model configured to predict the value of Tz at time t+1 (i.e., {circumflex over (T)}z,t+1) given values of Tz and/or Tsp at time t. Several examples of controller model 414 are provided in Eqs. 12-14." and in Risbeck [0180] "For the controller models c1(⋅) and c2(⋅) discussed above, the constraints shown in Eqs. 115-117 are either trivial or implementable as linear constraints. Advantageously, these constraints ensure that the trajectory of zone air temperatures Tz,t and/or the trajectory of heating or cooling duties {dot over (Q)}HVAC,t for t=1 . . . N generated in step 708 are within the domain of the inverted controller model c−1(⋅) and therefore can be translated into temperature setpoints Tsp,t by setpoint back-calculator 632. For example, with these constraints satisfied, step 710 may include back-calculating the temperature setpoints Tsp,t using the following equation:T sp,t =c −1(T t ,T t+1) (Eq. 118)A value of the temperature setpoint Tsp,t may be calculated for each time step of the time period, resulting in a trajectory or time series of the temperature setpoint Tsp.").
Risbeck additionally teaches “wherein the at least one proxy limit value identifies a feasible region that is an extent to which the one or more controlled variables controlled by the one or more unit MPC controllers are adjustable without violating one or more controlled variable constraints;” (Risbeck teaches that the temperature may be maintained in a setpoint range i.e. the setpoint may be a range that is adjustable without violating constraints in Risbeck [0045] "HVAC equipment 206 may operate to provide heating or cooling {dot over (Q)}HVAC to zone 202 to maintain the temperature Tz of zone 202 at or near a desired temperature (e.g., at a temperature setpoint, within a setpoint range, etc.) to promote the comfort of occupants within zone 200 and/or to meet other needs of zone 200."; Risbeck teaches that the setpoint is within the domain of the controller model based on the constraints in Risbeck [0180] "For the controller models c1(⋅) and c2(⋅) discussed above, the constraints shown in Eqs. 115-117 are either trivial or implementable as linear constraints. Advantageously, these constraints ensure that the trajectory of zone air temperatures Tz,t and/or the trajectory of heating or cooling duties {dot over (Q)}HVAC,t for t=1 . . . N generated in step 708 are within the domain of the inverted controller model c−1(⋅) and therefore can be translated into temperature setpoints Tsp,t by setpoint back-calculator 632. For example, with these constraints satisfied, step 710 may include back-calculating the temperature setpoints Tsp,t using the following equation:T sp,t =c −1(T t ,T t+1) (Eq. 118)A value of the temperature setpoint Tsp,t may be calculated for each time step of the time period, resulting in a trajectory or time series of the temperature setpoint Tsp.").
Patel, Sprinkle, and Risbeck are analogous art because they are from the same field of endeavor of HVAC. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Patel, Sprinkle, and Risbeck before him/her, to modify the teachings of a high-level model predictive controller (MPC), and a plurality of low-level airside MPCs of Patel modified to include the system and method for data-driven HVAC optimization of Sprinkle to include the determination of a setpoint range based on a predicted future temperature of Risbeck because adding the teachings of a Building hvac system with modular cascaded model of Risbeck would provide the advantage of reducing computation time as described in Risbeck [0171] “Advantageously, the model predictive control process performed in step 708 may be an entirely linear model predictive control process, but may be used to model and control a partially nonlinear system. The nonlinear portion of the system (i.e., the heat disturbance {dot over (Q)}other and/or the functions F(⋅), G(⋅), and H(⋅)) is predicted or calculated in step 706 as a pre-processing step and provided as a fixed input to the model predictive control process in step 708. The remaining temperature dynamics of building zone 202 are entirely linear and can be modeled using a linear model predictive control framework as previously described. This advantage allows model predictive controller 622 to use only the linear state-space model (i.e., the linear physics model) when performing the model predictive control process, which reduces computation time and uses fewer processing resources due to the linear physics model not including any nonlinear components.”
Claim 2:
Patel in view of Sprinkle, further in view of Risbeck teaches “The method of claim 1, wherein receiving the at least one proxy limit value comprises receiving at least one proxy limit value that is based on the one or more MPC models used by the one or more unit MPC controllers.” (Patel teaches that the aggregate values i.e. proxy limit values are calculated using model aggregator 818 of low-level MPC in Patel [0257] "Model aggregator 818 can calculate aggregate values for other building parameters or variables such as the building thermal capacitance Cb, the building heat transfer coefficient Hb, and the estimated building disturbance {dot over (Q)}other,b. In some embodiments, model aggregator 818 calculates the aggregate values for these variables and parameters using the following equations:
PNG
media_image4.png
164
124
media_image4.png
Greyscale
where the building thermal capacitance Cb is the summation of the zone thermal capacitance Ci values for each building zone, the building heat transfer coefficient Hb is the summation of the zone heat transfer coefficients Hi values for each building zone, and the estimated building disturbance {dot over (Q)}other,b is the summation of the estimated building disturbances {dot over (Q)}other,i for each building zone.").
Claim 3:
Patel in view of Sprinkle, further in view of Risbeck teaches “The method of claim 2, wherein the one or more unit MPC controllers control one or more actuators used to control one or more manipulated variables,” (Patel teaches that MPC system 600 may be used in combination with airside system 300 in Patel [0163] "Referring now to FIG. 6, a block diagram of a distributed model predictive control (MPC) system 600 is shown, according to some embodiments. MPC system 600 uses a MPC technique to determine optimal setpoints for the equipment of an airside system and a waterside system over a time horizon. MPC system 600 can be used in combination with HVAC system 20, waterside system 20, airside system 50, HVAC system 100, waterside system 120, airside system 130, waterside system 200, airside system 300, BMS 400, and/or BMS 500, as described with reference to FIGS. 1A-5. For example, MPC system 600 can determine optimal temperature setpoints for the airside equipment 622-626 of airside system 50 and/or airside system 300."; Patel teaches dampers that may be operated by an actuator in Patel [0122] "Each of dampers 316-320 can be operated by an actuator. For example, exhaust air damper 316 can be operated by actuator 324, mixing damper 318 can be operated by actuator 326, and outside air damper 320 can be operated by actuator 328. Actuators 324-328 can communicate with an AHU controller 330 via a communications link 332. Actuators 324-328 can receive control signals from AHU controller 330 and can provide feedback signals to AHU controller 330. Feedback signals can include, for example, an indication of a current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators 324-328), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that can be collected, stored, or used by actuators 324-328. AHU controller 330 can be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control actuators 324-328."), and
“wherein changes to the one or more manipulated variables result in changes to the one or more controlled variables.” (Patel teaches that adjusting damper position controls the amount of outside air in the supply air in Patel [0121] "AHU 302 can be configured to operate exhaust air damper 316, mixing damper 318, and outside air damper 320 to control an amount of outside air 314 and return air 304 that combine to form supply air 310.”).
Claim 4:
Patel in view of Sprinkle, further in view of Risbeck teaches “The method of claim 3, wherein the one or more actuators includes an actuator for adjusting the damper position of an HVAC system.” (Patel teaches that damper position may be controlled in Patel [0121] "AHU 302 can be configured to operate exhaust air damper 316, mixing damper 318, and outside air damper 320 to control an amount of outside air 314 and return air 304 that combine to form supply air 310.”).
Claim 5:
Patel in view of Sprinkle, further in view of Risbeck teaches “The method of claim 1, wherein each proxy limit value identifies a maximum or minimum value obtainable for one of the one or more controlled variable without violating any controlled variable constraints.” (Patel teaches that a maximum and minimum temperature setting may be determined based on information received from low-level airside controller in Patel [0199] "In some embodiments, constraints modeler 710 imposes constraints on the building temperature Tb. For example, constraints modeler 710 can constrain the building temperature Tb between a minimum temperature Tmin and a maximum temperature Tmax as shown in the following equation:
T min ≤T b ≤T max
where the values of Tmin and Tmax can be adjusted based on the temperature setpoints of the building. In some embodiments, constraints modeler 710 automatically adjusts the values of Tmin and Tmax based on information received from the low-level airside controller and/or BMS for the building.").
Claim 6:
Patel in view of Sprinkle, further in view of Risbeck teaches “The method of claim 1, wherein the site-wide MPC controller during the site-wide optimization generates a real-time planning solution within a closed-loop control system.” (Patel teaches that the distributed MPC system 600 generates a load profile i.e. a real-time planning solution for each time step in the optimization period in Patel [0174] "As shown in FIG. 6, distributed MPC system 600 can decompose the overall MPC problem into a high-level optimization problem and a low-level optimization problem. The high-level problem can be solved by high-level controller 608 to determine a load profile for each low-level airside subsystem 632-636 and a demand profile for waterside system 30. In some embodiments, high-level controller 608 uses active TES models and aggregate low-level models for each airside subsystem 632-636 to reduce computational complexity. High-level controller 608 can determine load profiles that optimize (e.g., minimize) the total operational cost of MPC system 600 over the optimization period. Each load profile can include a load value for each time step in the optimization period. Low-level airside controllers 612-616 can use the load profiles as constraints defining maximum permissible load values for each airside subsystem 632-636 for each time step in the optimization period. High-level controller 608 can provide the load profiles to each of the low-level airside controller 612-616."; Patel teaches that demand charge modeler has a current optimization period i.e. the optimization period is repeated in a closed-loop control system in Patel [0220] "If the demand charge period begins before the optimization period, it is possible that the maximum peak power consumption during the demand charge period occurred prior to the beginning of the optimization period. Demand charge modeler 718 can implement the following demand charge constraint:
PNG
media_image5.png
36
126
media_image5.png
Greyscale
{dot over (W)} peak,past ≤{dot over (W)} peak
to ensure that the peak power consumption {dot over (W)}peak is always greater than or equal to the maximum power consumption {dot over (W)}peak,past that occurred during the same demand charge period, even if the maximum power consumption occurred prior to the beginning of the current optimization period.").
Claim 7:
Patel in view of Sprinkle, further in view of Risbeck teaches “The method of claim 1, wherein the site includes at least one of a building, a (Patel [0168] "In some embodiments, distributed MPC system 600 includes a load/rate predictor 602. Load/rate predictor 602 can provide MPC layer 610 with load and rate predictions including, for example, disturbance forecasts, electricity prices, demand charge prices, and outside air temperatures. Load/rate predictor 602 is shown receiving weather forecasts from a weather service 604. In some embodiments, load/rate predictor 602 generates the disturbance forecasts as a function of the weather forecasts. In some embodiments, load/rate predictor 602 uses feedback from regulatory layer 620 to generate the disturbance forecasts. Feedback from regulatory layer 620 can include various types of sensory inputs (e.g., temperature, flow, humidity, enthalpy, etc.) or other data relating to the controlled building or campus (e.g., building occupancy data, building electric load, etc.).").
Claim 8:
Patel teaches “A system for optimizing carbon emissions and/or energy usage of a site comprising: a site-wide model predictive control (MPC) controller comprising:” (Patel teaches a high-level MPC controller 608 that may control a site in Patel [0174] "As shown in FIG. 6, distributed MPC system 600 can decompose the overall MPC problem into a high-level optimization problem and a low-level optimization problem. The high-level problem can be solved by high-level controller 608 to determine a load profile for each low-level airside subsystem 632-636 and a demand profile for waterside system 30. In some embodiments, high-level controller 608 uses active TES models and aggregate low-level models for each airside subsystem 632-636 to reduce computational complexity. High-level controller 608 can determine load profiles that optimize (e.g., minimize) the total operational cost of MPC system 600 over the optimization period."),
“at least one memory configured to store a planning model for an industrial facility;” (Patel [0189] "Memory 708 can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory 708 can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions."; Patel [0206] "High-level optimizer 712 can use the energy cost model, demand charge model, building temperature model, thermal energy storage model, waterside demand model, and optimization constraints to formulate an optimization problem i.e. planning model. In some embodiments, high-level optimizer 712 seeks to minimize the total cost of energy consumed by waterside system 30 (i.e., energy cost and demand charge) subject to the building temperature constraints and other constraints provided by the high-level models described herein."; Patel Fig. 7 [As shown above in claim 1] teaches that memory 708 includes high-level optimizer 712.),
“at least one network interface configured to communicate with one or more unit MPC controllers;” (Patel [0186] "Communications interface 702 can be a network interface configured to facilitate electronic data communications between high-level MPC 608 and various external systems or devices (e.g., weather service 604, utilities 606, low-level controllers 612-618, BMS equipment, etc.)."),
“and at least one processing device configured to: obtain a planning model for optimizing carbon emissions and/or energy usage of the site;” (Patel teaches a high-level MPC controller 608 i.e. a site-wide model predictive controller including high-level optimizer 712 which formulates an optimization problem i.e. a planning model that minimizes the total cost of energy consumed of the MPC system i.e. optimizes energy usage in Patel [0221] "High-level optimizer 712 can use the energy cost model, airside power consumption model, demand charge model, building temperature model, thermal energy storage model, waterside demand model, and optimization constraints to formulate an optimization problem. In some embodiments, high-level optimizer 712 seeks to minimize the total cost of energy consumed by the aggregate airside/waterside system subject to the building temperature constraints and other constraints provided by the high-level models described herein"),
“receive at least one proxy limit value from the one or more unit MPC controllers (Patel teaches low-level MPC 612-616 i.e. unit MPC controllers providing aggregate building parameters and variables i.e. proxy limit values to high-level MPC controllers i.e. site-wide MPC controller in Patel [0258] "In some embodiments, model aggregator 818 provides the aggregate building parameters and variables Tb, Cb, Hb, and {dot over (Q)}other,b to high-level MPC 608. High-level MPC 608 can use such values as inputs to the high-level models, constraints, and optimization function used in the high-level optimization. Advantageously, the model aggregation performed by model aggregator 818 helps to reduce the amount of information exchanged between each low-level airside MPC 612-616 and high-level MPC 608. For example, each low-level MPC 612-616 can provide high-level MPC 608 with the aggregate values described above rather than individual values of such variables and parameters for each building zone."),
“wherein the at least one proxy limit value identifies a feasible region that is an extent to which the one or more controlled variables controlled by the one or more unit MPC controllers are adjustable without violating one or more controlled variable constraints;” (Patel teaches that model aggregator 818 of the low-level MPC controller provides constraints including the building heat transfer coefficient Hb which would identify how quickly the building could change temperature from the low-level model to the high-level model in Patel [0258] "In some embodiments, model aggregator 818 provides the aggregate building parameters and variables Tb, Cb, Hb, and {dot over (Q)}other,b to high-level MPC 608. High-level MPC 608 can use such values as inputs to the high-level models, constraints, and optimization function used in the high-level optimization." ; Patel teaches setting a minimum and maximum temperature for a zone i.e. a proxy limit value with a feasible region that is an extent to which temperature is adjustable using the constraints modeler 810 of the low-level airside model predictvie controller 612 in Patel [0247] "Still referring to FIG. 8, low-level airside MPC 612 is shown to include a constraints modeler 810. Constraints modeler 810 can generate and impose optimization constraints on the optimization procedure performed by low-level optimizer 812. Constraints imposed by constraints modeler 810 can include, for example, equipment capacity constraints and zone temperature constraints. In some embodiments, constraints modeler 810 imposes constraints on the zone temperature Ti. For example, constraints modeler 810 can constrain the zone temperature Ti between a minimum temperature Tmin and a maximum temperature Tmax as shown in the following equation:T min ≤T i ≤T maxwhere the values of Tmin and Tmax can be adjusted based on the temperature setpoints of the building."),
“and perform site-wide optimization using the planning model and the at least one proxy limit value,” (Patel teaches that high-level controller provides a load profile to each low-level controller in Patel [0174] "The high-level problem can be solved by high-level controller 608 to determine a load profile for each low-level airside subsystem 632-636 and a demand profile for waterside system 30. In some embodiments, high-level controller 608 uses active TES models and aggregate low-level models for each airside subsystem 632-636 to reduce computational complexity. High-level controller 608 can determine load profiles that optimize (e.g., minimize) the total operational cost of MPC system 600 over the optimization period. Each load profile can include a load value for each time step in the optimization period. Low-level airside controllers 612-616 can use the load profiles as constraints defining maximum permissible load values for each airside subsystem 632-636 for each time step in the optimization period. High-level controller 608 can provide the load profiles to each of the low-level airside controller 612-616."; Patel teaches that the MPC layer 610 may determine optimal values of the decision variables subject to constraints in Patel [0172] "MPC layer 610 can receive measurements from regulatory layer 620 and provide setpoints to regulatory layer 620. MPC layer 610 can generate optimal values for various decision variables including, for example, zone temperature setpoints, equipment on/off decisions, and TES charging/discharging rates. MPC layer 610 can determine the optimal values of the decision variables using system models such a zone temperature to cooling/heating duty model, a cooling/heating duty to temperature setpoint model, equipment models, and active TES models. MPC layer 610 can determine the optimal values of the decision variables by performing an optimization process subject to several constraints. The constraints can include comfort bounds on the zone air temperatures, equipment capacity constraints, TES tank size, and rate of change bounds on the equipment of regulatory layer 620."), and
“wherein the one or more controlled variables includes at least one of temperature, (Patel [0166] "Still referring to FIG. 6, distributed MPC system 600 is shown to include a MPC layer 610 and a regulatory layer 620. MPC layer 610 is shown to include a high-level model predictive controller 608 and several low-level model predictive controllers 612-618. Controllers 612, 614, and 616 are shown as low-level airside model predictive controllers, whereas controller 618 is shown as a low-level waterside model predictive controller. MPC layer 610 can be configured to determine and provide optimal temperature setpoints and equipment operating setpoints to the equipment of regulatory layer 620. "; Patel teaches that MPC system 600 can be used in combination with airside system 300 in Patel [0163] "Referring now to FIG. 6, a block diagram of a distributed model predictive control (MPC) system 600 is shown, according to some embodiments. MPC system 600 uses a MPC technique to determine optimal setpoints for the equipment of an airside system and a waterside system over a time horizon. MPC system 600 can be used in combination with HVAC system 20, waterside system 20, airside system 50, HVAC system 100, waterside system 120, airside system 130, waterside system 200, airside system 300, BMS 400, and/or BMS 500, as described with reference to FIGS. 1A-5. For example, MPC system 600 can determine optimal temperature setpoints for the airside equipment 622-626 of airside system 50 and/or airside system 300."; Patel [0123] "Still referring to FIG. 3, AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 positioned within supply air duct 312. Fan 338 can be configured to force supply air 310 through cooling coil 334 and/or heating coil 336 and provide supply air 310 to building zone 306. AHU controller 330 can communicate with fan 338 via communications link 340 to control a flow rate of supply air 310. In some embodiments, AHU controller 330 controls an amount of heating or cooling applied to supply air 310 by modulating a speed of fan 338."
Patel does not appear to explicitly teach “send at least one optimization request to one or more unit However, Sprinkle does teach this claim limitation (Sprinkle teaches a monitor outputting a query i.e. optimization request to a thermostat i.e. unit controller in Sprinkle [0056] "FIGS. 5A and 5B are flowcharts of processes S1 and S2 performed by the monitor 112 illustrated in FIG. 1 according to an exemplary embodiment of the present invention. The monitor performs the process S1 illustrated in FIG. 5A and the process S2 illustrated in FIG. 5B concurrently. In process S1, the monitor 112 determines if a sampling period n (for example, 5 minutes) has elapsed in step 502. After the sampling period n has elapsed (Step 502: Yes), the monitor 112 outputs a query to the thermostat 114 requesting data in step 504. The data may be, for example, the current setpoint r, the current indoor temperature x, and the time that has elapsed since the last query. The monitor 112 receives current setpoint r in step 506, the current indoor temperature x in step 508, and the time that has elapsed since the last query in step 510. The data is saved in step 512 and output to the server in step 514."; Sprinkle teaches that monitor 112 may output optimized HVAC setpoints in Sprinkle [0053] "In step 314, the end user decides whether to run the HVAC unit 116 based on the optimized HVAC setpoints r*. If so, the monitor 112 outputs optimized HVAC setpoints r* to the thermostat 114 for controlling the HVAC unit 116 in step 320."), and
“receive at least one proxy limit value from the one or more unit (Sprinkle teaches that monitor 112 may receive a current setpoint i.e. a proxy limit in response to a query i.e. optimization request in Sprinkle [0056] "FIGS. 5A and 5B are flowcharts of processes S1 and S2 performed by the monitor 112 illustrated in FIG. 1 according to an exemplary embodiment of the present invention. The monitor performs the process S1 illustrated in FIG. 5A and the process S2 illustrated in FIG. 5B concurrently. In process S1, the monitor 112 determines if a sampling period n (for example, 5 minutes) has elapsed in step 502. After the sampling period n has elapsed (Step 502: Yes), the monitor 112 outputs a query to the thermostat 114 requesting data in step 504. The data may be, for example, the current setpoint r, the current indoor temperature x, and the time that has elapsed since the last query. The monitor 112 receives current setpoint r in step 506, the current indoor temperature x in step 508, and the time that has elapsed since the last query in step 510. The data is saved in step 512 and output to the server in step 514.").
Patel and Sprinkle are analogous art because they are from the same field of endeavor of HVAC. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Patel and Sprinkle before him/her, to modify the teachings of a high-level model predictive controller (MPC), and a plurality of low-level airside MPCs of Patel to include the system and method for data-driven HVAC optimization of Sprinkle because adding the teachings of outputting a query and receiving setpoints in response to the query of Sprinkle would enable the user to better balance comfort and cost as described in Sprinkle [0038] “In response to HVAC setpoints r input by an end user, the HVAC prediction engine 126 and the cost modelling unit 124 may determine an estimated cost C over a specified time and output the estimated cost C to the end user, for example, via the GUI 140. By providing immediate feedback, the system 100 enables the end user to better balance comfort and cost. Additionally, the system 100 may be configured to determine optimized HVAC setpoints r* based on a desired cost C0 received from the end user, for example, via the GUI 140 and output the optimized HVAC setpoints r* to the thermostat 114 to control the HVAC unit 116.”
Neither Patel or Sprinkle appear to explicitly teach “wherein the at least one proxy limit value is computed by each of the one or more unit MPC controllers based on predicted future values of one or more controlled variables and a set of active unit constraints, wherein the future values of the one or more controlled variables are predicted using one or more MPC model associated with the one or more unit MPC controllers, and” However, Risbeck does teach this claim limitation (Risbeck teaches calculating a predicted future temperature using an MPC in Risbeck [0169] "Still referring to FIG. 7, process 700 is shown to include predicting the zone temperature Tz over the time period by performing model predictive control using the linear physics model and the predicted values of the heat load disturbance {dot over (Q)}other over the time period (step 708). In some embodiments, step 708 is performed by model predictive controller 622 as described with reference to FIG. 6." and in Risbeck [0174] "Step 708 may include executing the model predictive control process (i.e., solving the linear optimization problem subject to the constraints) to determine the optimal values of the decision variables, including the optimal values of Qt, Qh,t, Qc,t, and/or {dot over (Q)}HVAC,t, for each time step t in the optimization period. Step 708 may include using the linear physics model and/or the constraint in Eq. 99 to predict the system states Tzt and Tm,t resulting from the optimal values of Qt, Qh,t, Qc,t, and/or {dot over (Q)}HVAC,t over the optimization period."; Risbeck teaches calculating a temperature setpoint i.e. proxy limit value that is within the domain of the model based on the predicted temperature Tz in Risbeck [0175] "Still referring to FIG. 7, process 700 is shown to include back-calculating the temperature setpoint trajectory Tsp over the time period using an inverse controller model and the predicted zone temperature trajectory Tz (step 710). The inverse controller model c−1(⋅) used in step 710 may be the inverse of the closed-loop controller model c(⋅) 414. As discussed above, controller model 414 may be a closed-loop model configured to predict the value of Tz at time t+1 (i.e., {circumflex over (T)}z,t+1) given values of Tz and/or Tsp at time t. Several examples of controller model 414 are provided in Eqs. 12-14." and in Risbeck [0180] "For the controller models c1(⋅) and c2(⋅) discussed above, the constraints shown in Eqs. 115-117 are either trivial or implementable as linear constraints. Advantageously, these constraints ensure that the trajectory of zone air temperatures Tz,t and/or the trajectory of heating or cooling duties {dot over (Q)}HVAC,t for t=1 . . . N generated in step 708 are within the domain of the inverted controller model c−1(⋅) and therefore can be translated into temperature setpoints Tsp,t by setpoint back-calculator 632. For example, with these constraints satisfied, step 710 may include back-calculating the temperature setpoints Tsp,t using the following equation:T sp,t =c −1(T t ,T t+1) (Eq. 118)A value of the temperature setpoint Tsp,t may be calculated for each time step of the time period, resulting in a trajectory or time series of the temperature setpoint Tsp.").
Risbeck additionally teaches “wherein the at least one proxy limit value identifies a feasible region that is an extent to which the one or more controlled variables controlled by the one or more unit MPC controllers are adjustable without violating one or more controlled variable constraints;” (Risbeck teaches that the temperature may be maintained in a setpoint range i.e. the setpoint may be a range that is adjustable without violating constraints in Risbeck [0045] "HVAC equipment 206 may operate to provide heating or cooling {dot over (Q)}HVAC to zone 202 to maintain the temperature Tz of zone 202 at or near a desired temperature (e.g., at a temperature setpoint, within a setpoint range, etc.) to promote the comfort of occupants within zone 200 and/or to meet other needs of zone 200."; Risbeck teaches that the setpoint is within the domain of the controller model based on the constraints in Risbeck [0180] "For the controller models c1(⋅) and c2(⋅) discussed above, the constraints shown in Eqs. 115-117 are either trivial or implementable as linear constraints. Advantageously, these constraints ensure that the trajectory of zone air temperatures Tz,t and/or the trajectory of heating or cooling duties {dot over (Q)}HVAC,t for t=1 . . . N generated in step 708 are within the domain of the inverted controller model c−1(⋅) and therefore can be translated into temperature setpoints Tsp,t by setpoint back-calculator 632. For example, with these constraints satisfied, step 710 may include back-calculating the temperature setpoints Tsp,t using the following equation:T sp,t =c −1(T t ,T t+1) (Eq. 118)A value of the temperature setpoint Tsp,t may be calculated for each time step of the time period, resulting in a trajectory or time series of the temperature setpoint Tsp.").
Patel, Sprinkle, and Risbeck are analogous art because they are from the same field of endeavor of HVAC. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Patel, Sprinkle, and Risbeck before him/her, to modify the teachings of a high-level model predictive controller (MPC), and a plurality of low-level airside MPCs of Patel modified to include the system and method for data-driven HVAC optimization of Sprinkle to include the determination of a setpoint range based on a predicted future temperature of Risbeck because adding the teachings of a Building hvac system with modular cascaded model of Risbeck would provide the advantage of reducing computation time as described in Risbeck [0171] “Advantageously, the model predictive control process performed in step 708 may be an entirely linear model predictive control process, but may be used to model and control a partially nonlinear system. The nonlinear portion of the system (i.e., the heat disturbance {dot over (Q)}other and/or the functions F(⋅), G(⋅), and H(⋅)) is predicted or calculated in step 706 as a pre-processing step and provided as a fixed input to the model predictive control process in step 708. The remaining temperature dynamics of building zone 202 are entirely linear and can be modeled using a linear model predictive control framework as previously described. This advantage allows model predictive controller 622 to use only the linear state-space model (i.e., the linear physics model) when performing the model predictive control process, which reduces computation time and uses fewer processing resources due to the linear physics model not including any nonlinear components.”
Claims 9-14:
Claims 9-14 are substantially the same as claims 2-7 respectively and they are rejected for the same reasons.
Claim 15:
Patel teaches “A non-transitory computer-readable medium containing instructions for optimizing carbon emissions and/or energy usage of a site, the non-transitory computer-readable medium storing instructions that, when executed by at least one processor, configure the at least one processor for: obtaining a planning model for optimizing carbon emissions and/or energy usage of the site at a site-wide model predictive control (MPC) controller;” (Patel teaches a non-volatile memory i.e. non-transitory computer-readable medium which includes computer code for executing the processes described herein in Patel [0189] "Memory 708 can include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory 708 can include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory 708 can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory 708 can be communicably connected to processor 706 via processing circuit 704 and can include computer code for executing (e.g., by processor 706) one or more processes described herein. When processor 706 executes instructions stored in memory 708, processor 706 generally configures high-level MPC 608 (and more particularly processing circuit 704) to complete such activities."; Patel teaches a high-level MPC controller 608 i.e. a site-wide model predictive controller including high-level optimizer 712 which formulates an optimization problem i.e. a planning model that minimizes the total cost of energy consumed of the MPC system i.e. optimizes energy usage in Patel [0221] "High-level optimizer 712 can use the energy cost model, airside power consumption model, demand charge model, building temperature model, thermal energy storage model, waterside demand model, and optimization constraints to formulate an optimization problem. In some embodiments, high-level optimizer 712 seeks to minimize the total cost of energy consumed by the aggregate airside/waterside system subject to the building temperature constraints and other constraints provided by the high-level models described herein"),
“receiving at least one proxy limit value from the one or more unit MPC controllers at the site-wide MPC controller(Patel teaches low-level MPC 612-616 i.e. unit MPC controllers providing aggregate building parameters and variables i.e. proxy limit values to high-level MPC controllers i.e. site-wide MPC controller in Patel [0258] "In some embodiments, model aggregator 818 provides the aggregate building parameters and variables Tb, Cb, Hb, and {dot over (Q)}other,b to high-level MPC 608. High-level MPC 608 can use such values as inputs to the high-level models, constraints, and optimization function used in the high-level optimization. Advantageously, the model aggregation performed by model aggregator 818 helps to reduce the amount of information exchanged between each low-level airside MPC 612-616 and high-level MPC 608. For example, each low-level MPC 612-616 can provide high-level MPC 608 with the aggregate values described above rather than individual values of such variables and parameters for each building zone."),
“wherein the at least one proxy limit value identifies a feasible region that is an extent to which one or more controlled variables controlled by the one or more unit MPC controllers are adjustable without violating one or more controlled variable constraints;” (Patel teaches that model aggregator 818 of the low-level MPC controller provides constraints including the building heat transfer coefficient Hb which would identify how quickly the building could change temperature from the low-level model to the high-level model in Patel [0258] "In some embodiments, model aggregator 818 provides the aggregate building parameters and variables Tb, Cb, Hb, and {dot over (Q)}other,b to high-level MPC 608. High-level MPC 608 can use such values as inputs to the high-level models, constraints, and optimization function used in the high-level optimization."; Patel teaches setting a minimum and maximum temperature for a zone i.e. a proxy limit value with a feasible region that is an extent to which temperature is adjustable using the constraints modeler 810 of the low-level airside model predictvie controller 612 in Patel [0247] "Still referring to FIG. 8, low-level airside MPC 612 is shown to include a constraints modeler 810. Constraints modeler 810 can generate and impose optimization constraints on the optimization procedure performed by low-level optimizer 812. Constraints imposed by constraints modeler 810 can include, for example, equipment capacity constraints and zone temperature constraints. In some embodiments, constraints modeler 810 imposes constraints on the zone temperature Ti. For example, constraints modeler 810 can constrain the zone temperature Ti between a minimum temperature Tmin and a maximum temperature Tmax as shown in the following equation:T min ≤T i ≤T maxwhere the values of Tmin and Tmax can be adjusted based on the temperature setpoints of the building."),
“and performing site-wide optimization at the site-wide MPC controller using the planning model and the at least one proxy limit value,” (Patel teaches that high-level controller provides a load profile to each low-level controller in Patel [0174] "The high-level problem can be solved by high-level controller 608 to determine a load profile for each low-level airside subsystem 632-636 and a demand profile for waterside system 30. In some embodiments, high-level controller 608 uses active TES models and aggregate low-level models for each airside subsystem 632-636 to reduce computational complexity. High-level controller 608 can determine load profiles that optimize (e.g., minimize) the total operational cost of MPC system 600 over the optimization period. Each load profile can include a load value for each time step in the optimization period. Low-level airside controllers 612-616 can use the load profiles as constraints defining maximum permissible load values for each airside subsystem 632-636 for each time step in the optimization period. High-level controller 608 can provide the load profiles to each of the low-level airside controller 612-616."; Patel teaches that the MPC layer 610 may determine optimal values of the decision variables subject to constraints in Patel [0172] "MPC layer 610 can receive measurements from regulatory layer 620 and provide setpoints to regulatory layer 620. MPC layer 610 can generate optimal values for various decision variables including, for example, zone temperature setpoints, equipment on/off decisions, and TES charging/discharging rates. MPC layer 610 can determine the optimal values of the decision variables using system models such a zone temperature to cooling/heating duty model, a cooling/heating duty to temperature setpoint model, equipment models, and active TES models. MPC layer 610 can determine the optimal values of the decision variables by performing an optimization process subject to several constraints. The constraints can include comfort bounds on the zone air temperatures, equipment capacity constraints, TES tank size, and rate of change bounds on the equipment of regulatory layer 620."), and
“wherein the one or more controlled variables includes at least one of temperature, (Patel [0166] "Still referring to FIG. 6, distributed MPC system 600 is shown to include a MPC layer 610 and a regulatory layer 620. MPC layer 610 is shown to include a high-level model predictive controller 608 and several low-level model predictive controllers 612-618. Controllers 612, 614, and 616 are shown as low-level airside model predictive controllers, whereas controller 618 is shown as a low-level waterside model predictive controller. MPC layer 610 can be configured to determine and provide optimal temperature setpoints and equipment operating setpoints to the equipment of regulatory layer 620. "; Patel teaches that MPC system 600 can be used in combination with airside system 300 in Patel [0163] "Referring now to FIG. 6, a block diagram of a distributed model predictive control (MPC) system 600 is shown, according to some embodiments. MPC system 600 uses a MPC technique to determine optimal setpoints for the equipment of an airside system and a waterside system over a time horizon. MPC system 600 can be used in combination with HVAC system 20, waterside system 20, airside system 50, HVAC system 100, waterside system 120, airside system 130, waterside system 200, airside system 300, BMS 400, and/or BMS 500, as described with reference to FIGS. 1A-5. For example, MPC system 600 can determine optimal temperature setpoints for the airside equipment 622-626 of airside system 50 and/or airside system 300."; Patel [0123] "Still referring to FIG. 3, AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 positioned within supply air duct 312. Fan 338 can be configured to force supply air 310 through cooling coil 334 and/or heating coil 336 and provide supply air 310 to building zone 306. AHU controller 330 can communicate with fan 338 via communications link 340 to control a flow rate of supply air 310. In some embodiments, AHU controller 330 controls an amount of heating or cooling applied to supply air 310 by modulating a speed of fan 338."
Patel does not appear to explicitly teach “sending at least one optimization request from the site-wide MPC controller to one or more unit However, Sprinkle does teach this claim limitation (Sprinkle teaches a monitor outputting a query i.e. optimization request to a thermostat i.e. unit controller in Sprinkle [0056] "FIGS. 5A and 5B are flowcharts of processes S1 and S2 performed by the monitor 112 illustrated in FIG. 1 according to an exemplary embodiment of the present invention. The monitor performs the process S1 illustrated in FIG. 5A and the process S2 illustrated in FIG. 5B concurrently. In process S1, the monitor 112 determines if a sampling period n (for example, 5 minutes) has elapsed in step 502. After the sampling period n has elapsed (Step 502: Yes), the monitor 112 outputs a query to the thermostat 114 requesting data in step 504. The data may be, for example, the current setpoint r, the current indoor temperature x, and the time that has elapsed since the last query. The monitor 112 receives current setpoint r in step 506, the current indoor temperature x in step 508, and the time that has elapsed since the last query in step 510. The data is saved in step 512 and output to the server in step 514."; Sprinkle teaches that monitor 112 may output optimized HVAC setpoints in Sprinkle [0053] "In step 314, the end user decides whether to run the HVAC unit 116 based on the optimized HVAC setpoints r*. If so, the monitor 112 outputs optimized HVAC setpoints r* to the thermostat 114 for controlling the HVAC unit 116 in step 320."), and
“receiving at least one proxy limit value from the one or more unit (Sprinkle teaches that monitor 112 may receive a current setpoint i.e. a proxy limit in response to a query i.e. optimization request in Sprinkle [0056] "FIGS. 5A and 5B are flowcharts of processes S1 and S2 performed by the monitor 112 illustrated in FIG. 1 according to an exemplary embodiment of the present invention. The monitor performs the process S1 illustrated in FIG. 5A and the process S2 illustrated in FIG. 5B concurrently. In process S1, the monitor 112 determines if a sampling period n (for example, 5 minutes) has elapsed in step 502. After the sampling period n has elapsed (Step 502: Yes), the monitor 112 outputs a query to the thermostat 114 requesting data in step 504. The data may be, for example, the current setpoint r, the current indoor temperature x, and the time that has elapsed since the last query. The monitor 112 receives current setpoint r in step 506, the current indoor temperature x in step 508, and the time that has elapsed since the last query in step 510. The data is saved in step 512 and output to the server in step 514.").
Patel and Sprinkle are analogous art because they are from the same field of endeavor of HVAC. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Patel and Sprinkle before him/her, to modify the teachings of a high-level model predictive controller (MPC), and a plurality of low-level airside MPCs of Patel to include the system and method for data-driven HVAC optimization of Sprinkle because adding the teachings of outputting a query and receiving setpoints in response to the query of Sprinkle would enable the user to better balance comfort and cost as described in Sprinkle [0038] “In response to HVAC setpoints r input by an end user, the HVAC prediction engine 126 and the cost modelling unit 124 may determine an estimated cost C over a specified time and output the estimated cost C to the end user, for example, via the GUI 140. By providing immediate feedback, the system 100 enables the end user to better balance comfort and cost. Additionally, the system 100 may be configured to determine optimized HVAC setpoints r* based on a desired cost C0 received from the end user, for example, via the GUI 140 and output the optimized HVAC setpoints r* to the thermostat 114 to control the HVAC unit 116.”
Neither Patel or Sprinkle appear to explicitly teach “wherein the at least one proxy limit value is computed by each of the one or more unit MPC controllers based on predicted future values of one or more controlled variables and a set of active unit constraints, wherein the future values of the one or more controlled variables are predicted using one or more MPC model associated with the one or more unit MPC controllers, and” However, Risbeck does teach this claim limitation (Risbeck teaches calculating a predicted future temperature using an MPC in Risbeck [0169] "Still referring to FIG. 7, process 700 is shown to include predicting the zone temperature Tz over the time period by performing model predictive control using the linear physics model and the predicted values of the heat load disturbance {dot over (Q)}other over the time period (step 708). In some embodiments, step 708 is performed by model predictive controller 622 as described with reference to FIG. 6." and in Risbeck [0174] "Step 708 may include executing the model predictive control process (i.e., solving the linear optimization problem subject to the constraints) to determine the optimal values of the decision variables, including the optimal values of Qt, Qh,t, Qc,t, and/or {dot over (Q)}HVAC,t, for each time step t in the optimization period. Step 708 may include using the linear physics model and/or the constraint in Eq. 99 to predict the system states Tzt and Tm,t resulting from the optimal values of Qt, Qh,t, Qc,t, and/or {dot over (Q)}HVAC,t over the optimization period."; Risbeck teaches calculating a temperature setpoint i.e. proxy limit value that is within the domain of the model based on the predicted temperature Tz in Risbeck [0175] "Still referring to FIG. 7, process 700 is shown to include back-calculating the temperature setpoint trajectory Tsp over the time period using an inverse controller model and the predicted zone temperature trajectory Tz (step 710). The inverse controller model c−1(⋅) used in step 710 may be the inverse of the closed-loop controller model c(⋅) 414. As discussed above, controller model 414 may be a closed-loop model configured to predict the value of Tz at time t+1 (i.e., {circumflex over (T)}z,t+1) given values of Tz and/or Tsp at time t. Several examples of controller model 414 are provided in Eqs. 12-14." and in Risbeck [0180] "For the controller models c1(⋅) and c2(⋅) discussed above, the constraints shown in Eqs. 115-117 are either trivial or implementable as linear constraints. Advantageously, these constraints ensure that the trajectory of zone air temperatures Tz,t and/or the trajectory of heating or cooling duties {dot over (Q)}HVAC,t for t=1 . . . N generated in step 708 are within the domain of the inverted controller model c−1(⋅) and therefore can be translated into temperature setpoints Tsp,t by setpoint back-calculator 632. For example, with these constraints satisfied, step 710 may include back-calculating the temperature setpoints Tsp,t using the following equation:T sp,t =c −1(T t ,T t+1) (Eq. 118)A value of the temperature setpoint Tsp,t may be calculated for each time step of the time period, resulting in a trajectory or time series of the temperature setpoint Tsp.").
Risbeck additionally teaches “wherein the at least one proxy limit value identifies a feasible region that is an extent to which the one or more controlled variables controlled by the one or more unit MPC controllers are adjustable without violating one or more controlled variable constraints;” (Risbeck teaches that the temperature may be maintained in a setpoint range i.e. the setpoint may be a range that is adjustable without violating constraints in Risbeck [0045] "HVAC equipment 206 may operate to provide heating or cooling {dot over (Q)}HVAC to zone 202 to maintain the temperature Tz of zone 202 at or near a desired temperature (e.g., at a temperature setpoint, within a setpoint range, etc.) to promote the comfort of occupants within zone 200 and/or to meet other needs of zone 200."; Risbeck teaches that the setpoint is within the domain of the controller model based on the constraints in Risbeck [0180] "For the controller models c1(⋅) and c2(⋅) discussed above, the constraints shown in Eqs. 115-117 are either trivial or implementable as linear constraints. Advantageously, these constraints ensure that the trajectory of zone air temperatures Tz,t and/or the trajectory of heating or cooling duties {dot over (Q)}HVAC,t for t=1 . . . N generated in step 708 are within the domain of the inverted controller model c−1(⋅) and therefore can be translated into temperature setpoints Tsp,t by setpoint back-calculator 632. For example, with these constraints satisfied, step 710 may include back-calculating the temperature setpoints Tsp,t using the following equation:T sp,t =c −1(T t ,T t+1) (Eq. 118)A value of the temperature setpoint Tsp,t may be calculated for each time step of the time period, resulting in a trajectory or time series of the temperature setpoint Tsp.").
Patel, Sprinkle, and Risbeck are analogous art because they are from the same field of endeavor of HVAC. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Patel, Sprinkle, and Risbeck before him/her, to modify the teachings of a high-level model predictive controller (MPC), and a plurality of low-level airside MPCs of Patel modified to include the system and method for data-driven HVAC optimization of Sprinkle to include the determination of a setpoint range based on a predicted future temperature of Risbeck because adding the teachings of a Building hvac system with modular cascaded model of Risbeck would provide the advantage of reducing computation time as described in Risbeck [0171] “Advantageously, the model predictive control process performed in step 708 may be an entirely linear model predictive control process, but may be used to model and control a partially nonlinear system. The nonlinear portion of the system (i.e., the heat disturbance {dot over (Q)}other and/or the functions F(⋅), G(⋅), and H(⋅)) is predicted or calculated in step 706 as a pre-processing step and provided as a fixed input to the model predictive control process in step 708. The remaining temperature dynamics of building zone 202 are entirely linear and can be modeled using a linear model predictive control framework as previously described. This advantage allows model predictive controller 622 to use only the linear state-space model (i.e., the linear physics model) when performing the model predictive control process, which reduces computation time and uses fewer processing resources due to the linear physics model not including any nonlinear components.”
Claims 16-20:
Claims 16-20 are substantially the same as claims 2-6 respectively and they are rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zachary A Cain whose telephone number is (571)272-4503. The examiner can normally be reached Mon-Fri 7:00-3:30 CST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kenneth M Lo can be reached at (571) 272-9774. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Z.A.C./ Examiner, Art Unit 2116
/KENNETH M LO/ Supervisory Patent Examiner, Art Unit 2116
Prosecution Insights