Prosecution Insights
Last updated: July 17, 2026
Application No. 18/870,719

PRESSURE DATA FOR UTILITY MONITORING

Final Rejection §101§103
Filed
Dec 02, 2024
Priority
Jun 02, 2022 — provisional 63/348,195 +1 more
Examiner
MOLNAR, HUNTER A
Art Unit
3628
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Resideo Usa LLC
OA Round
2 (Final)
50%
Grant Probability
Moderate
3-4
OA Rounds
1y 6m
Est. Remaining
82%
With Interview

Examiner Intelligence

Grants 50% of resolved cases
50%
Career Allowance Rate
130 granted / 259 resolved
-1.8% vs TC avg
Strong +32% interview lift
Without
With
+32.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
33 currently pending
Career history
295
Total Applications
across all art units

Statute-Specific Performance

§101
10.5%
-29.5% vs TC avg
§103
84.8%
+44.8% vs TC avg
§102
1.6%
-38.4% vs TC avg
§112
1.3%
-38.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 259 resolved cases

Office Action

§101 §103
DETAILED ACTION Notice of 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 . Status of the Application Claims 1-20 were pending and were rejected in the previous office action. Claims 1 and 11 are amended. Claims 1-20 remain pending and are examined in this office action. Priority This application claims priority to U. S. Provisional Application No. 63/348,195, filed June 2, 2022. Information Disclosure Statement The Information Disclosure Statement filed 5/6/2026 has been considered. Response to Arguments Claim Objections: Claim 1 was objected to for reciting “the utility” instead of “the utility device.” Claim 1 is amended to correct this issue, and the objection is withdrawn. Claim Interpretation: Applicant’s arguments with respect to the previous § 112(f) claim interpretation have been fully considered and are persuasive. Claims 1 and 11 are amended to recite sufficient structure defining the controller to perform the claimed functions, and no longer invoke § 112(f). 35 USC § 101: Applicant’s arguments with respect to the § 101 rejection of claims 1-20 (pgs. 9-12, remarks filed 5/6/2026) have been fully considered, but they are not persuasive. Step 2A Prong One: Applicant argues, regarding Step 2A Prong One (pg. 10, remarks), that: “Under Step 2A, Prong One, the amended claim no longer reasonably can be characterized as a concept that can practically be performed in the human mind with pen and paper. The claim requires extracting pressure noise data from pressure data collected by a pressure sensor, storing that pressure data in controller memory, determining a utility- specific pressure change using the extracted pressure noise data, determining a predetermined pressure-change threshold associated with an operational state indication from the utility device based on the pressure data, and transmitting a maintenance request to another device in association with the resulting alert. These operations are rooted in sensor-generated pressure-noise data and time-dependent utility operating conditions, and they require a claimed system architecture including a pressure sensor, a utility device, programmable processing circuitry, memory, and communication with another device. The claim therefore does not merely recite an observation, evaluation, judgment, or opinion of the type identified in the Office Action. See Office Action ¶¶21-22.” However, the examiner respectfully disagrees that the claims do not recite an abstract idea at Step 2A Prong One, as test at Step 2A Prong One is whether or not the claims include limitations that recite an abstract idea. See MPEP 2106.04(a)(2)(III)(B), showing “If a claim recites a limitation that can practically be performed in the human mind, with or without the use of a physical aid such as pen and paper, the limitation falls within the mental processes grouping, and the claim recites an abstract idea.” and MPEP 2106.04(a)(2)(III)(C) showing “Claims can recite a mental process even if they are claimed as being performed on a computer.” Using claim 1 as representative, the claim recites various limitations which fall under the mental processes category of abstract ideas. For example, the steps to “receive an operational state indication” and “receive the first air pressure and the second air pressure” describe observations which can be mentally observed from an external source. Further, the steps to “extract pressure noise data from pressure…and store the pressure data…,” “determine a change in pressure at the utility device using at least the extracted pressure noise data and the first air pressure and the second air pressure,” “determine a first predetermined utility pressure change threshold that is associated with the operational state indication based on the pressure data,” “compare the change in pressure at the utility device to the first predetermined utility pressure change threshold,” and “when the change in pressure at the utility device matches the first predetermined utility pressure change threshold, generate an alert relating to the utility device, the alert corresponding to a determination that the utility requires maintenance” describes evaluations or judgements related to the previously received pressure data. Furthermore, “transmitting a maintenance request in associated with the alert…,” but for the performance using generic computer functions (“transmitting” data), is otherwise analogous to a human issuing a maintenance request or requesting maintenance using pen and paper. The examiner notes that the specific step presented in the amendments to “extract pressure noise data…,” under the broadest reasonable interpretation, could describe mentally analyzing observed pressure data and identifying variations or fluctuations across the pressure data, and does not recite functions that are unable to be performed by the human mind. The claims/specification also never indicate in any manner that the noise data specifically refers to acoustic/sound noise (which is not disclosed or suggested in the specification) or the like, and therefore one of ordinary skill in the art would understand pressure noise as covering any type of noise (including variations or fluctuations across the received pressure data). While the first air pressure and second air pressure are recited as being received from (and detected by) a pressure sensor, the pressure sensor is an additional element analyzed under Step 2A Prong Two and Step 2B. The same applies to the utility device, controller comprising programmable processing circuitry and a memory, and “another device,” which are analyzed as additional elements under Step 2A Prong Two and Step 2B. Therefore, the examiner maintains that the claims recite an abstract idea (by reciting limitations that fall under the “mental processes” category of abstract idea) at Step 2A Prong One. Step 2A Prong Two: Applicant further argues, at Step 2A Prong Two (pgs. 10-11, remarks), that: “Even assuming, for purposes of discussion only and without conceding as much, that claim 1 recites an abstract idea, the claim integrates any such idea into a practical application under Step 2A, Prong Two. The amended claim uses pressure-noise information collected from a physical utility environment to determine a maintenance condition of the utility device and initiate a maintenance workflow by transmitting a maintenance request in association with the alert. This is not a generic instruction to "apply" an abstract idea on a computer. The claim instead applies a specific sensor-data processing technique to a utility device to identify maintenance needs based on pressure behavior associated with an operational state of the utility device. The specification confirms this practical application. The disclosure explains that embodiments "utilize at least pressure data to determine one or more characteristics relating to a utility and, in some instances, use such determined characteristic(s) relating to the utility to determine one or more action." Specification ¶[0011]. The specification further describes a diagnostic tool that collects pressure data, including pressure noise data, from pressure sensors at or adjacent to a utility and stores the sensor data in a historical database "to identify nuances, changes, or adjustments in the pressure sensor data that may relate to the state of a utility," including notifying a user of a potential failure "so that maintenance may be performed." Specification ¶[0012]. The specification also describes extracting pressure noise data from collected pressure data, storing that data over time, using historical pressure sensor data to identify variances or nuances in pressure noise data, determining the state of a utility, determining whether the utility requires maintenance, and generating an output for notification. Specification ¶[0015]. In one example, pressure noise data that becomes greater over time near a boiler may indicate debris buildup on the boiler's heat exchanger, and the utility module can notify the user that the boiler should be scheduled for maintenance. Specification ¶[0016]. Thus, the amended claim addresses the Office Action's concern that the prior claim language merely used generic components for data gathering and reporting. See Office Action ¶¶23-29. The amended claim does not simply receive pressure values and issue an alert. It recites a particular ordered combination in which pressure noise data is extracted from sensor-collected pressure data, stored in memory, used with an operational state indication to determine an applicable utility pressure-change threshold, used to determine a pressure change at the utility device, and then used to generate a maintenance-based alert and transmit a maintenance request to another device. This ordered combination ties the claimed processing to a physical utility device and pressure-sensor environment and produces a concrete maintenance-related action.” However, the examiner respectfully disagrees. First, the amended limitation where the controller is transmitting a maintenance request to another device simply carries out the abstract step of outputting a maintenance request within a computer environment by using computers in their ordinary capacity to receive/transmit data, and at most, adds insignificant post-solution activity for outputting/transmitting a result of the determination that the utility requires maintenance. Such a limitation does not integrate the abstract idea into a practical application under any of the considerations discussed in MPEP 2106.04(d)(I), such as: An improvement in the functioning of a computer, or an improvement to other technology or technical field, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a); Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, as discussed in MPEP § 2106.04(d)(2); Implementing a judicial exception with, or using a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, as discussed in MPEP § 2106.05(b); Effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP § 2106.05(c); and Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP § 2106.05(e). The cited portions of the specification above, while discussing how or why the claimed invention may be useful in the context of utility maintenance, do not disclose an improvement to the functioning of a computer or an improvement to any other technology or technical field, nor do they recite other meaningful limitations that would integrate the abstract idea into a practical application, such as controlling or changing operations of the utility device (e.g. switching off or modifying operations of a boiler or other utility device based on the results of the abstract idea, similar to operating a rubber molding press in Diehr). The steps of extracting pressure noise data from collected pressure data and storing pressure data, generating an alert based on a pressure change, and issuing a maintenance request in associated with the alert describes the abstract idea itself, and that the steps are being carried out by a controller including processing circuitry and memory (via the performance of generic computer functions such as storing pressure data in memory and “transmitting” data to another device) adds mere instructions to apply the abstract idea using generic computer components. That the pressure data is collected by the pressure sensor recites the use of a pressure sensor in its ordinary capacity and does not indicate an improved pressure sensor or improvement to how the detection of pressure data is performed. The controller later transmitting a maintenance request to another device merely applies the abstract step of outputting a maintenance request within a computer environment by using computers in their ordinary capacity, and/or adding insignificant post-solution activity. Therefore, the examiner maintains that the current claims are directed to an abstract idea at Step 2A Prong Two. Step 2B: Applicant further argues, at Step 2B (pgs. 11-12, remarks), that: “For similar reasons, the amended claim also recites significantly more than any alleged abstract idea under Step 2B. The additional elements are not merely appended generic computer functions. The claimed controller, memory, pressure sensor, and utility device cooperate in a specific way to process pressure noise data from a monitored utility environment and initiate maintenance handling for the utility device. The claim therefore recites more than generic receiving, storing, comparing, and reporting; it recites a specific utility diagnostic workflow that uses pressure-noise information and operational-state information to determine a maintenance condition and transmit a maintenance request associated with the alert.” However, the examiner respectfully disagrees. As discussed above, the pressure sensor is being used as a generic pressure sensor operating in its ordinary capacity to measure and provided pressure data and pressure readings. The controller comprising programmable processing circuitry and a memory, and in communication with the utility device and the pressure sensor, are generic computer components used to carry out the abstract idea by performing generic computer functions. As mentioned above, the steps for generating an alert and transmitting a maintenance request to another device simply describes outputting a maintenance request within a computer environment by using computers in their ordinary capacity to receive and transmit data, and at most, amounts to insignificant post-solution activity for outputting/transmitting a result of the determination that the utility requires maintenance. The courts have identified “Receiving or transmitting data over a network” as well-understood, routine, and conventional computer functions. See MPEP 2106.04(d)(II), citing Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). Therefore, the examiner maintains that the current claims are directed to an abstract idea without significantly more. 35 USC § 102 and § 103 – Prior Art: Applicant’s arguments with respect to the previous § 102 and § 103 rejections of claims 1-20 (pgs. 12-14, remarks filed 5/6/2026) have been considered but are moot, as they do not apply to the current grounds of rejection applied in the § 103 rejections of claims 1-20, in response to applicant’s amendments. Please see the current § 103 rejections of claims 1-20 below. 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 a judicial exception (i.e. an abstract idea) without significantly more. Step 1: Claims 1-10 recite “A system comprising: a utility device; a pressure sensor…and a controller…” (i.e. a machine); and claims 11-20 recite “A utility tamper detection assembly comprising: a utility housing…a pressure sensor…and a controller…” (i.e. a machine). These claims fall under one of the four categories of statutory subject matter and as a result, pass Step 1 of the subject matter eligibility test. However, “Determining that a claim falls within one of the four enumerated categories of patentable subject matter recited in 35 U.S.C. 101 (i.e., process, machine, manufacture, or composition of matter) in Step 1 does not end the eligibility analysis, because claims directed to nothing more than abstract ideas (such as a mathematical formula or equation), natural phenomena, and laws of nature are not eligible for patent protection.” See MPEP 2106.04. Accordingly, the examiner continues the subject matter eligibility analysis below. Step 2A Prong One: Independent claim 1 recites limitations to: receive an operational state indication of a utility device receive a first air pressure that was detected at a first time at the utility device and a second air pressure that was detected at a second time at the utility device, the first time being different than the second time, extract pressure noise data from pressure data and store the pressure data determine a change in pressure at the utility device using at least the extracted pressure noise data and the first air pressure and the second air pressure, determine a first predetermined utility pressure change threshold that is associated with the operational state indication based on the pressure data, compare the change in pressure at the utility device to the first predetermined utility pressure change threshold, when the change in pressure at the utility device matches the first predetermined utility pressure change threshold, generate an alert relating to the utility device, the alert corresponding to a determination that the utility requires maintenance; and [output] a maintenance request in association with the alert Independent claim 11 recites similar limitations for: receive a first air pressure that was detected at a utility housing at a first time and a second air pressure that was detected at a utility housing at a second time, the first time being different than the second time, extract pressure noise from pressure data collected by the pressure sensor and store the pressure data determine a change in pressure at a utility housing using at least the extracted pressure noise data and the first air pressure and the second air pressure, compare the change in pressure at the utility housing to a first predetermined utility housing pressure change threshold, when the change in pressure at the utility housing matches the first predetermined utility housing pressure change threshold, generate a tamper alert relating to the utility housing, the alert corresponding to a determination that the utility requires maintenance, and [output] a maintenance request in association with the alert The limitations of independent claims 1 and 11 above are determined to recite an abstract idea (i.e. collecting and analyzing air pressure information including pressure noise data against a pressure change threshold, generating a maintenance alert when the pressure change threshold is exceeded, and outputting a maintenance request associated with the maintenance alert) for the reasons discussed in the following continued Step 2A Prong One analysis. Note that “An abstract idea can generally be described at different levels of abstraction.” Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1240-41 (Fed. Cir. 2016). As described in MPEP 2106.04(a)(2)(III), “[T]he "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions.” and “If a claim recites a limitation that can practically be performed in the human mind, with or without the use of a physical aid such as pen and paper, the limitation falls within the mental processes grouping, and the claim recites an abstract idea.” The limitations recited by the representative independent claims 1 and 11 above, under the broadest reasonable interpretation and but for the use of generic computer components, cover concepts (e.g. observation, evaluation, judgment, and opinion) that can reasonably be performed in the human mind or by the human mind with the aid of simple tools such as pen and paper. For example, the steps to receive an operational state indication and receive first and second air pressures of claim 1, and the steps to receive first and second air pressures of claim 11 are observations. The “extract,” “determine,” “determine,” “compare,” and “generate an alert” steps of claim 1 and the “extract,” “determine,” “compare,” and “generate a tamper alert” steps of claim 11 are evaluations, judgments, and opinions. The step to transmit a maintenance request is also analogous to outputting or issuing a maintenance request via the human mind using pen and paper (note that the generic computer implementation to “transmit…to another device” is analyzed as an additional element below). Therefore, as the processes above described by the representative independent claims 1 and 11 can be characterized as mental processes (i.e. observation, evaluation, judgment, and opinion), but for the recitation of generic computer components in the claims, the claims fall under the “mental processes” category of judicial exceptions (i.e. abstract ideas). Step 2A Prong Two: The judicial exception (i.e. abstract idea) recited in claims 1 and 11 is not integrated into a practical application because the claims recite mere instructions to apply the abstract idea (i.e. collecting and analyzing air pressure information including pressure noise data against a pressure change threshold, generating a maintenance alert when the pressure change threshold is exceeded, and outputting a maintenance request associated with the maintenance alert) using generic computers/computer components (i.e. a system comprising…a controller comprising programmable processing circuitry and a memory, a utility device, a pressure sensor, and another device of claim 1; and a system comprising…a controller comprising programmable processing circuitry and a memory, a pressure sensor, and another device of claim 11). See MPEP 2106.05(f), showing “[C]laims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp.” The recitation of “a utility device” and “a pressure sensor,” where the operational state information and the pressure readings correspond to the utility device (claim 1), and “A utility tamper detection assembly comprising: a utility housing at least partially enclosing a utility device,” and “a pressure sensor at the utility housing,” where the pressure readings correspond to a utility housing (claim 11), merely generally links the performance of the abstract idea to a particular field of use/technological environment (the abstract idea is carried out in the context of a utility device including a pressure sensor, or a temper detection assembly comprising a utility housing and a pressure sensor). The use of a pressure sensor to detect first and second air pressures, and to collect pressure data merely describes the use of a generic pressure sensor in its ordinary capacity, and does not indicate an improved pressure sensor or improvement to the detection of pressure data. The limitations of claims 1 and 11 describing that the pressure sensor and the other computing devices (a utility device, a controller) are in communication with one another, and to “store the pressure data in the memory” recites the use of computer elements in their ordinary capacity to receive, store, or transmit data. The use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, but instead indicates mere instructions apply the abstract idea using a generic computer or computer components. Similarly, the limitation to “transmit a maintenance request in associated with the alert to another device” merely describe generic computer functions for transmitting data to another device, and uses generic computers in their ordinary capacity to apply the abstract idea. Transmitting this maintenance request based on a determination that maintenance is needed also at best describes insignificant post-solution activity. The recited additional elements do not improve the functioning of a computer/the controller itself, improve the way in which pressure sensors detect air pressures (e.g. improved accuracy or improved detection mechanisms), or provide a specific configuration/arrangement of these additional elements that solves a specific technical problem, but instead uses generic or “off the shelf” components in conjunction with a controller comprising processing circuitry and memory to automate the abstract idea of collecting and analyzing air pressure information including pressure noise data against a pressure change threshold, generating a maintenance alert when the pressure change threshold is exceeded, and outputting a maintenance request associated with the maintenance alert. Therefore, because the claims, considered as a whole, do not recite anything that integrates the abstract idea into a practical application, the claims are directed to an abstract idea. Step 2B: Claims 1 and 11 do not include additional elements, whether considered alone or as an ordered combination, that are sufficient to amount to significantly more than the judicial exception (i.e. abstract idea) because as mentioned above, the claims recite mere instructions to apply the abstract idea (i.e. collecting and analyzing air pressure information including pressure noise data against a pressure change threshold, generating a maintenance alert when the pressure change threshold is exceeded, and outputting a maintenance request associated with the maintenance alert) using generic computers/computer components (i.e. a system comprising…a controller comprising programmable processing circuitry and a memory, a utility device, a pressure sensor, and another device of claim 1; and a system comprising…a controller comprising programmable processing circuitry and a memory, a pressure sensor, and another device of claim 11). See MPEP 2106.05(f), showing “[C]laims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp.” The recitation of “a utility device” and “a pressure sensor,” where the operational state information and the pressure readings correspond to the utility device (claim 1), “A utility tamper detection assembly comprising: a utility housing at least partially enclosing a utility device,” and “a pressure sensor at the utility housing,” where the pressure readings correspond to a utility housing (claim 11), merely generally links the performance of the abstract idea to a particular field of use/technological environment (the abstract idea is carried out in the context of a utility device including a pressure sensor, or a temper detection assembly comprising a utility housing and a pressure sensor). The use of a pressure sensor to detect first and second air pressures, and to collect pressure data merely describes the use of a generic pressure sensor in its ordinary capacity, and does not indicate an improved pressure sensor or improvement to the detection of pressure data. The limitations of claims 1 and 11 describing that the pressure sensor and the other computing devices (a utility device, a controller) are in communication with one another, and to “store the pressure data in the memory” recites the use of computer elements in their ordinary capacity to receive, store, or transmit data. The use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not provide significantly more. Similarly, the limitation to “transmit a maintenance request in associated with the alert to another device” merely describe generic computer functions for transmitting data to another device, and uses generic computers in their ordinary capacity to apply the abstract idea. Transmitting this maintenance request based on a determination that maintenance is needed also at best describes insignificant post-solution activity. The courts have identified similar limitations “Receiving or transmitting data over a network” between devices as well-understood, routine, and conventional computer functions. See MPEP 2106.04(d)(II), citing Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). The recited additional elements do not improve the functioning of a computer/the controller itself, improve the way in which pressure sensors detect air pressures (e.g. improved accuracy or improved detection mechanisms), or provide a specific configuration/arrangement of these additional elements that solves a specific technical problem, but instead uses generic or “off the shelf” components in conjunction with a controller comprising processing circuitry and memory to automate the abstract idea of collecting and analyzing air pressure information including pressure noise data against a pressure change threshold, generating a maintenance alert when the pressure change threshold is exceeded, and outputting a maintenance request associated with the maintenance alert. Considering the additional elements as an ordered combination does not alter the analysis above or otherwise add significantly more than the abstract idea. Therefore, claims 1 and 11 are directed to an abstract idea without significantly more. Dependent Claims 2-10 and 12-20: Dependent claims 2-10 and 12-20 are directed to the same abstract idea as independent claims 1 and 11 above as they do not recite anything that integrates the abstract idea into a practical application or amounts to significantly more than the abstract idea. Claims 2-4 further describe the abstract idea by reciting limitations for determining if a warranty for the utility device applies according to various conditions and other information about the warranty (claims 2-4). These abstract limitations are applied using generic computer components already addressed above (“the controller” of claims 2-4). Claim 5 recites the use of the controller to store warranty data packets, which describes generic computers functions/use a controller in its ordinary capacity (storing data in memory), and recites further instructions to apply the abstract idea (“select a first warranty packet…”) using a generic computer component (the controller). Claims 6 and 8 similarly uses the controller to perform generic computers functions/use computers in their ordinary capacity (“wherein the controller is configured to transmit a maintenance scheduling request to a third party when the controller determines that the warranty for the utility device applies” of claim 6; and “wherein the controller is configured to transmit the alert to a remote user device”) to carry out the abstract idea. Claims 7, 10 and 14-15 do not introduce additional elements beyond those already addressed above but merely further describe the abstract idea by reciting limitations for: “wherein the alert…includes a notice that the utility device needs maintenance” (claim 7); “wherein the operational state indication…includes data relating to an operation being executed by the utility device…” (claim 10); “wherein the tamper alert relates to the access door being open” (claim 14); and “wherein when the access door is closed the utility device is concealed within the utility housing and when the access door is open the utility device is accessible within the utility housing” (claim 15). Regarding claims 9 and 19: claim 9 recites “wherein the utility device is selected from the group consisting of: a heating, ventilation, and air conditioning (HVAC) unit and a water heater,” and claim 19 recites “wherein the utility device is selected from the group consisting of. an electrical meter and a boiler” which at best merely further describes the field of use in which the abstract idea is performed, i.e. generally links the performance of the abstract idea to a particular field of use/technical environment. Claims 12 and 16 recite further steps describing the abstract idea (“receive an operational state indication from the utility device and determine the first predetermined utility housing pressure change threshold using the operational state indication” of claim 12; “generate the tamper alert when a time at which the change in pressure at the utility housing matches the first predetermined utility housing pressure change threshold differs from a prescheduled utility device maintenance time” of claim 16) being applied using generic computer components (“wherein the controller is in communication with the utility device” and “the controller is further configured to” of claims 12, 16). Claim 13 further describes the utility housing above (“an access door at the utility housing”) which generally links the performance of the abstract idea to a particular field of use/technological environment, while further describing the abstract idea above (“wherein the first time is when the access door is closed and the second time is when the access door is open”) – and does not integrate the abstract idea into a practical application or add significantly more. Claims 17, 18 and 20 recite further limitations which merely recite the use of computers or other machinery (“the controller,” “a remote user device,” “the utility device”) in their ordinary capacity to receive, transmit, or store data: “the controller is configured to receive and store a utility maintenance schedule that includes the prescheduled utility device maintenance time” (claim 17), “the controller is configured to transmit the tamper alert to a remote user device” (claim 18); and “the controller is in communication with the utility device, wherein the controller is further configured to receive an operational state indication…” (claim 20). Such limitations do not integrate the abstract idea into a practical application or add significantly more, but instead invokes computers or other machinery merely as a tool to perform the abstract idea. Therefore, claims 1-20 are ineligible under § 101. 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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 and 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120323375 A1 to Dean-Hendricks et al. (Dean-Hendricks) in view of US 20220100802 A1 to Saini et al. (Saini), and further in view of US 20210207833 A1 to Dameno et al. (Dameno). Claim 1: Dean-Hendricks teaches: A system (Dean-Hendricks: Fig. 1, ¶ 0039-0047 showing HVAC system) comprising: a utility device (Dean-Hendricks: Fig. 1, 0046 showing HVAC system includes at least air filter monitor 34 associated with air filter 30); a pressure sensor (Dean-Hendricks: ¶ 0046 showing “differential pressure sensor” for detecting a differential pressure associated with the air filter; see ¶ 0010-0013, ¶ 0072) configured to detect a first air pressure at the utility device at a first time (Dean-Hendricks: ¶ 0071-0072 showing the sensor measures a differential pressure across a clean air filter of an HVAC system to obtain a first differential pressure value when the air filter is clean) and a second air pressure at the utility device at a second time, the first time being different than the second time (Dean-Hendricks: ¶ 0136-0137 showing measuring a subsequent differential pressure value); and a controller comprising programmable processing circuitry and a memory (Dean-Hendricks: ¶ 0047-0051 showing controller including a processor 44 and memory 52), the controller in communication with the utility device and the pressure sensor (Dean-Hendricks: ¶ 0047, ¶ 0072, ¶ 0122, ¶ 0135 controller in communication with the air filter monitoring including pressure sensor), With respect to the limitation: the controller is configured to: receive an operational state indication from the utility device; While Dean-Hendricks describes the HVAC system as operating in one of a plurality of modes or states, as instructed by the controller (Dean-Hendricks: ¶ 0071-0073 “the controller may instruct the HVAC system to operate in a selected mode or state”, ¶ 0085-0087, ¶ 0111-0114), and thus is clearly aware of the state or mode of operation in which the HVAC system is in, but Dean-Hendricks falls short of explicitly stating that the controller receives an indication of the current operational state. However, Saini teaches a BMS (building management system) controller that receives information on temperatures, operating statuses, diagnostics, etc.) from an HVAC utility device (e.g. air handling unit controller device) (Saini: ¶ 0055-0056). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the controller receiving operating status information from a utility device of Saini in the monitoring system of Dean-Hendricks with a reasonable expectation of success of arriving at the claimed invention, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Dean-Hendricks, as modified above, further teaches: receive the first air pressure (Dean-Hendricks: ¶ 0072-0073, ¶ 0089 showing receiving first differential pressure for clean air filter, and used as baseline for calculating air filter change threshold) and the second air pressure from the pressure sensor (Hendricks: ¶ 0136-0138 showing the controller receives measurement of at least one subsequent differential pressure value from sensors of air filter monitoring device); With respect to the limitation: extract pressure noise data from pressure data collected by the pressure sensor and store the pressure data in the memory; Dean-Hendricks teaches accounting for system variations and calibrating the filter monitor to account for variations (Dean-Hendricks: ¶ 0068), and further teaches storing pressure data in memory (Dean-Hendricks: ¶ 0077, ¶ 0092, ¶ 0124, ¶ 0127) – but Dean-Hendricks/Saini do not explicitly teach extracting pressure noise data from the pressure data. However, Dameno teaches receiving pressure data from a pressure sensor (Dameno: ¶ 0058-0059 showing sensing assembly including a pressure sensor positioned within an air duct of an HVAC system), passing the pressure data to a digital low pass filter to remove, i.e. extract, noise from the pressure data (Dameno: ¶ 0059 “The digitized pressure and temperature is passed to the digital low pass filter 312 to remove noise. A digital output of the low pass filter is transmitted…”; also see ¶ 0118 “The calculating could include a filtering step that removes anomalies or spikes in data that are considered noise or an abnormality…” and ¶ 0106), and storing the compensated/adjusted pressure data in memory (Dameno: ¶ 0059 “The compensated pressure data Pcomp and compensated temperature data Tcomp may be stored in data registers in the controller 316 or in a separate memory”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the screening and removal of noise from sensed pressure data and then storing pressure data in memory of Dameno in the monitoring system of Dean-Hendricks/Saini with a reasonable expectation of success of arriving at the claimed invention, with the motivation to “reduce noise from first and second sensor data” (Dameno: ¶ 0106) and that “By tracking the performance of each filter in real-time or at some periodic interval each air filter can be used fully and air filters with issues can be more quickly identified” (Dameno: ¶ 0006). In addition, it would have also been obvious to one of ordinary skill in the art before the effective filing date of the invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim Interpretation Note: The specification as filed 12/2/2024 recites in [0012] “Certain embodiments of the present disclosure provide a diagnostic tool for utility life expectancy in which the diagnostic tool collects pressure data, including pressure noise data, from one or more pressure sensors (e.g., micro pressure sensors at or adjacent to the utility) and stores the sensor data in a historical database to identify nuances, changes, or adjustments in the pressure sensor data that may relate to the state of a utility and compares the state of the utility to a warranty in order to notify the user of a potential failure so that maintenance may be performed.” Therefore, the “noise” recited in claim 1 appears to cover nuances or changes (e.g. variation or noise in data) in the pressure data, under the broadest reasonable interpretation in view of the specification. With respect to the limitation: determine a change in pressure at the utility device using at least the extracted pressure noise data and the first air pressure and the second air pressure Dean-Hendricks teaches determining a change in pressure at the utility device using at least the first air pressure and the second air pressure (Dean-Hendricks: ¶ 0136-0138 showing based on the controller receives measurement of a subsequent differential pressure value, and compares it against the previously determined air filter change threshold value, which as per ¶ 0072-0073, ¶ 0089, and ¶ 0138 represents a threshold difference/offset from the first measured differential pressure value; therefore, the controller determines whether the subsequent differential pressure value has changed by a threshold amount (a threshold difference) from the first differential pressure based on a clean air filter; also see ¶ 0044 and ¶ 0046 for context, describing that over time, the differential pressure of a clean air filter increases as it becomes dirty, and the air filter monitor measures and reports the change in this value over time), but Dean-Hendricks/Saini do not explicitly teach that determined change in pressure is determined according to the pressure data from which extraction of the noise data has been performed. However, Dameno teaches filtering pressure measurements such that noise is removed, i.e. extracted, from the pressure measurement data (Dameno: ¶ 0058-0059, ¶ 0106, ¶ 0118 as above), wherein these pressure measurements are subsequently used to determine whether a pressure change is greater than a threshold value for determining whether an air filter change is needed (Dameno: ¶ 0006, ¶ 0066, ¶ 0092, ¶ 0111 showing using the pressure measurements to determine whether a pressure change is greater than a threshold value). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the collection of pressure data, removal of noise from sensed pressure data and then using the adjusted pressure data for determining whether a difference in pressure measurements is greater than a threshold value of Dameno in the monitoring system of Dean-Hendricks/Saini/Dameno, for the same reasons described in the limitations above. Dean-Hendricks, as modified above, further teaches: determine a first predetermined utility pressure change threshold that is associated with the operational state indication based on the pressure data (Dean-Hendricks: Fig. 10, ¶ 0072-0073, ¶ 0089 as cited above showing the original determination of an “air filter change threshold value” that is indicative of a measured pressure differential value, i.e. pressure data, that indicates a dirty air filter, which is determined and used as a threshold increase or “offset” in differential pressure above the measured differential pressure when a filter is clean and which the current differential pressure is measured against, according to a selected mode or state in which the HVAC system is set to operate; also see ¶ 0128-0140, ¶ 0077, ¶ 0106 showing this threshold value is used to compare measurements of pressure differential values against the air filter change threshold value), compare the change in pressure at the utility device to the first predetermined utility pressure change threshold (Dean-Hendricks: ¶ 0138-0140, ¶ 0077, ¶ 0106 showing comparing the current/subsequently measured pressure differential value against the air filter change threshold value, which represents whether the current/subsequently measured pressure differential value of the filter has increased enough over the original differential value of the clean air filter used to calibrate the threshold value, such that it exceeds the air filter change threshold value); when the change in pressure at the utility device matches the first predetermined utility pressure change threshold, generate an alert relating to the utility device, the alert corresponding to a determination that the utility requires maintenance (Dean-Hendricks: ¶ 0138-0140, ¶ 0070, ¶ 0077, ¶ 0094, ¶ 0106 showing when the current differential pressure exceeds the air filter change threshold value amount (i.e. the differential pressure has changed by a threshold amount such that it is exceeds the air filter change threshold), generating alerts or filter change notifications notifying the user that the air filter is dirty and needs to be replaced; see Fig. 17D-17F, ¶ 0147 showing “replace air filter now” notice); With respect to the following limitations, Dean-Hendricks teaches generating an alert indicating that maintenance is needed (Dean-Hendricks: ¶ 0138-0140, ¶ 0070, ¶ 0077, ¶ 0094, ¶ 0106 and Fig. 17D-17F, ¶ 0147 as above), but does not explicitly teach transmitting a maintenance request associated with the alert. However, Saini teaches: and transmit a maintenance request in associated with the alert to another device (Saini: ¶ 0136 “the automated corrective action can include generating a work order and/or scheduling a maintenance activity for faulty equipment. The work order or maintenance request can be transmitted to a work order computer system, for example, or may be transmitted to a user device…a notification or alert may be generated and transmitted to the user's device as a text message, an email, a voice call, a push notification, etc.”) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included transmitting an alert to a user’s device of Saini in the monitoring system of Dean-Hendricks/Saini/Dameno (such that a message associated with the maintenance alert of Dean-Hendricks is also transmitted to a user’s device) with a reasonable expectation of success of arriving at the claimed invention, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim 7: Dean-Hendricks/Saini/Dameno teach claim 1. Dean-Hendricks, as modified above, further teaches: wherein the alert relating to the utility device includes a notice that the utility device needs maintenance (Dean-Hendricks: ¶ 0138-0140, ¶ 0070, ¶ 0077, ¶ 0094, ¶ 0106 showing when the current differential pressure exceeds the air filter change threshold value amount (i.e. the differential pressure has changed by a threshold amount such that it is exceeds the air filter change threshold), generating and transmitting alerts or filter change notifications notifying the user that the air filter is dirty and needs to be replaced; see Fig. 17D-17F, ¶ 0147 showing “replace air filter now” notice) Claim 8: Dean-Hendricks/Saini/Dameno teach claim 7. With respect to the following limitation, while Dean-Hendricks teaches generating and displaying an alert in response to an air filter condition requiring maintenance (Dean-Hendricks: ¶ 0138-0140, ¶ 0070, ¶ 0077, ¶ 0094, ¶ 0106), Dean-Hendricks does not explicitly teach transmitting the alert to a remote user device. However, Saini teaches: wherein the controller is configured to transmit the alert to a remote user device (Saini: ¶ 0136 showing an indication of a fault condition is “generated and transmitted to the user's device as a text message, an email, a voice call, a push notification, etc.”) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included transmitting an alert to a user’s device of Saini in the monitoring system of Dean-Hendricks/Saini/Dameno (such that the alert of Dean-Hendricks is transmitted to a user’s device) with a reasonable expectation of success of arriving at the claimed invention, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim 9: Dean-Hendricks/Saini/Dameno teach claim 1. Dean-Hendricks, as modified above, further teaches: wherein the utility device is selected from the group consisting of: a heating, ventilation, and air conditioning (HVAC) unit (Dean-Hendricks: Dean-Hendricks: Fig. 1, ¶ 0046 showing HVAC system including various devices/HVAC units, including air filter monitoring unit) and a water heater Claim 10: Dean-Hendricks/Saini/Dameno teach claim 9. Dean-Hendricks, as modified above (such that as per Saini the controller receives the operational state indication), further teaches: wherein the operational state indication from the utility device includes data relating to an operation being executed by the utility device when the first air pressure and the second air pressure are received from the pressure sensor (Dean-Hendricks: ¶ 0071-0072, ¶ 0085 showing operational modes such as fan only mode, heating mode, cooling mode, etc.; and ¶ 0072 showing “While the HVAC system is operating in the selected mode, the controller (e.g., controller 18) may command or require the air filter monitor 34 to measure one or more parameters related to the current condition of the one or more air filters 30 of the HVAC system 4 with one or more sensors…”) Claims 2 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over US 20120323375 A1 to Dean-Hendricks et al. (Dean-Hendricks) in view of US 20220100802 A1 to Saini et al. (Saini), further in view of US 20210207833 A1 to Dameno et al. (Dameno), and further in view of US 20230141593 A1 to Ramer et al. (Ramer). Note: The “Ramer” reference claims priority to US Provisional Application No. 63276770, filed on 11/08/2021. The provisional application provides support for the teachings relied upon herein. Claim 2: Dean-Hendricks/Saini/Dameno teach claim 1. With respect to the limitation: wherein, when the change in pressure at the utility device matches the first predetermined utility pressure change threshold, the controller is further configured to determine if a warranty for the utility device applies Dean-Hendricks teaches triggering an alert that maintenance is needed when the current differential pressure exceeds the determined air filter change threshold as per above (Dean-Hendricks: ¶ 0138-0140, ¶ 0070, ¶ 0077, ¶ 0094, ¶ 0106 as above) – but Dean-Hendricks/Saini/Dameno do not explicitly teach, upon this determination that maintenance is needed, whether a warranty applies. However, Ramer teaches, in response to determining that a maintenance/repair is needed, determining whether the maintenance/repair is covered by a home warranty service (Ramer: ¶ 0237-0240 showing automatically determining and scheduling a needed maintenance/repair with service provider to create a warranty claim, wherein “If the claim management system 1100 determines that the service request is a covered claim, the claim management system 1100 may instruct the servicer management system 1110 to create a job associated with the claim/service request and may assign a servicer to the job”; also generally see ¶ 0100, ¶ 0108, ¶ 0132, ¶ 0237, ¶ 0379 for context and showing applicability to HVAC systems and HVAC air filter replacement). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included determining whether a warranty covers a service request, upon detection that maintenance or repair at a property is needed as taught Ramer in the monitoring system of Dean-Hendricks/Saini/Dameno with a reasonable expectation of success of arriving at the claimed invention, with the motivation to “improve outcomes, including cost management outcomes, customer satisfaction outcomes, job completion outcomes, total customer value outcomes” (Ramer: ¶ 0240). Claim 5: Dean-Hendricks/Saini/Dameno/Ramer teach claim 2. With respect to the following limitations, Dean-Hendricks/Saini/Dameno do not explicitly teach, however, Ramer teaches: wherein the controller is configured to store a plurality of warranty data packets relating to different utility devices (Ramer: ¶ 0178-0180 showing a plurality of labels associated with each component and subcomponent (e.g. an HVAC system, and its corresponding parts) at a subscriber's premises that may be “covered” by the home service plan, and are “stored in a graph structure, such as a directed acyclic graph, which may be stored in a graph database”; also see ¶ 0026), and wherein the controller is configured to select a first warranty data packet, from the plurality of warranty data packets, as relating to the utility device using a utility device identifier received from the utility device (Ramer: ¶ 0039-0042, ¶ 0312-0314 showing each service request including one or more taxonomy of repair labels that may be associated with the at least one repair service, and/or a system taxonomy label that may identify a component or an aspect of the property that may be a subject of the at least one repair service; also see, with ¶ 0069-0071, ¶ 0239 showing automatically creating the service request) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included storing a label corresponding covered parts in the home service plan and including one or more corresponding labels in service requests as taught Ramer in the monitoring system of Dean-Hendricks/Saini/Dameno/Ramer, with a reasonable expectation of success of arriving at the claimed invention, for the same reasons described in the rejection of claim 2 above. Claim 6: Dean-Hendricks/Saini/Dameno/Ramer teach claim 5. With respect to the following limitation, Dean-Hendricks/Saini/Dameno do not explicitly teach, however, Ramer teaches: wherein the controller is configured to transmit a maintenance scheduling request to a third party when the controller determines that the warranty for the utility device applies (Ramer: ¶ 0239 showing determining claim is covered, and then creating a job for the service request that is assigned to a servicer; see ¶ 0498, ¶ 0014 showing the service request can be forwarded to one or more selected servicers, i.e. one of a plurality of third party servicers) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included assigning the request to a servicer in response to determining the repair claim is covered as taught Ramer in the monitoring system of Dean-Hendricks/Saini/Dameno/Ramer, with a reasonable expectation of success of arriving at the claimed invention, for the same reasons described in the rejection of claim 2 above. Claims 11 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20230041634 A1 to Iliev in view of US 20090018782 A1 to Sameda et al. (Sameda), and further in view of US 20130119974 A1 to Chamarti et al. (Chamarti). Claim 11: Iliev teaches: A utility tamper detection assembly (Iliev: Fig. 2 and ¶ 0019, an example gas meter 200 having a gas-environment 202 and an air-environment 204; ¶ 0030, ¶ 0054 showing tamper detection) comprising: a utility housing at least partially enclosing a utility device (Iliev: Fig. 2, ¶ 0022 “The air-environment 204 of the gas meter 200 is separated from the gas-environment 202 by portions of the enclosure 224 of the gas meter 200. Accordingly, gas is not able to enter the air-environment (and vice versa)”); a pressure sensor at the utility housing (Iliev: Fig. 2, ¶ 0019-0021, ¶ 0023-0025 showing index PCBA (printed circuit board assembly) 220 in communication with sensors 206, 208 within the utility housing, and where both sensors report to index PCBA as per ¶ 0046-0047; also note that the combined configuration of sensors 206, 208 can be considered a single sensor assembly as the index PCBA receives the measurements of both sensors via bus controller) and configured to detect a first air pressure at the utility housing at a first time (Iliev: ¶ 0046 “At block 402, an index PCBA, within an air-environment of the gas meter, receives a first pressure value”) and a second air pressure at the utility housing at a second time, the first time being different than the second time (Iliev: ¶ 0047 “At block 404, the index PCBA measures a second pressure value”; which as per Fig. 4, block 404 occurs after block 402, i.e. second time); and a controller comprising programmable processing circuitry and a memory, the controller in communication with the pressure sensor, the controller is configured to: receive the first air pressure and the second air pressure from the pressure sensor (Iliev: ¶ 0015-0016, ¶ 0024 showing index PCBA includes processor and memory for executing programming instructions, and ¶ 0025 “the processor 224 may utilize techniques described in FIGS. 3-9 to process and utilize the pressure data”; ¶ 0046-0047 as above showing index PCBA receives the first and second sensor measurements), With respect to the limitations: extract pressure noise data from pressure data collected by the pressure sensor and store the pressure data in the memory; Iliev teaches receiving and storing pressure data received from at least one pressure sensor in memory (Iliev: ¶ 0039 “ the index PCBA 220 has in memory device 226 the gas-pressure value received from the MIG PCBA and an atmospheric (barometric) air-pressure value from the air pressure sensor 208…”), but does not explicitly teach extracting pressure noise data from the pressure data. However, Sameda teaches extracting/removing pressure noise data from measured pressure data (Sameda: ¶ 0019, ¶ 0115-0116, ¶ 0120, ¶ 0125-0128 showing noise removal processing to remove noise from pressure data collected by pressure sensor). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include removing/extracting noise from pressure data as taught by Sameda in the gas meter tamper detection system of Iliev, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. It would have also been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to do so, with a reasonable expectation of success of arriving at the claimed invention, with the motivation that “According to this noise removal processing, it is possible to convert the data into data which can be readily handled in the subsequent object extraction processing or pressure related characteristics extraction processing, by removing noise from the instantaneous flow volume data and pressure data. In particular, a merit is obtained in that the accuracy of the removal of noise from the instantaneous flow volume data and pressure data can be improved” (Sameda: ¶ 0127). With respect to the limitation: determine a change in pressure at the utility housing using at least the extracted pressure noise data and the first air pressure and the second air pressure Iliev teaches determining a change in pressure at the utility housing using at least the first air pressure and the second air pressure (Iliev: ¶ 0048 “a pressure difference value is calculated to be equal to the first pressure value minus the second pressure value”), but does not explicitly teach that extracted pressure noise data from the pressure data. However, Sameda teaches extracting/removing noise data from pressure data prior to analysis of changes in pressure data (Sameda: ¶ 0019, ¶ 0115-0116, ¶ 0120, ¶ 0125-0128 showing noise removal processing to remove noise from pressure data collected by pressure sensor; with ¶ 0148-0152 providing context for detecting leak/issues with gas meter based on pressure changes in the pressure data). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include removing/extracting noise from pressure data for determining pressure changes as taught by Sameda in the gas meter tamper detection system of Iliev/Sameda (such that the noise removal is performed on the pressure data of Iliev prior to analysis for pressure changes), for the same reasons described in the limitations above. Iliev, as modified above, further teaches: compare the change in pressure at the utility housing to a first predetermined utility housing pressure change threshold (Iliev: ¶ 0049 “the pressure difference value is compared to a threshold value”); when the change in pressure at the utility housing matches the first predetermined utility housing pressure change threshold (Iliev: Fig. 5 and ¶ 0050, with Fig. 5 showing “responsive to the pressure difference exceeding the threshold value, perform an action”), generate a tamper alert relating to the utility housing (Iliev: Fig. 4 showing the responsive action 508 “send a message indicating tampering with the gas meter”; and ¶ 0054 “a message indicating tampering with the gas meter may be sent”), With respect to the following limitations: the alert corresponding to a determination that the utility requires maintenance transmit a maintenance request in association with the alert to another device Iliev teaches generating a tamper alert related to the utility housing and sending a message indicating tampering to an external device/computer (Iliev: Fig. 4, ¶ 0054 as above) – however, to the extent that this does not relate to a maintenance request, Chamarti teaches a tamper detection alert corresponding to detection of a tampering event that requires a technician to reset the meter to restore normal operation, i.e. maintenance is required (Chamarti: ¶ 0059 specifically, and see ¶ 0057-0059 generally) and transmitting the alert and notifying a utility provider to enable the utility provider to take the appropriate action, i.e. maintenance request (Chamarti: ¶ 0025 “information pertaining to the potential tamper event may be transmitted to a utility provider. The information may include, by way of non-limiting examples, a time of the tamper event, identification data of the meter, an identifier of the customer, GPS data, or any combination thereof” and ¶ 0019 “the processor may record the potential tampering event locally (e.g., in nonvolatile memory) and, in certain embodiments, may remotely notify a utility provider of the situation to enable the utility provider to take an appropriate action”; note that under the broadest reasonable interpretation, the claim does not specify information included in the “maintenance request” and notifying the utility provider such that the utility provider make take the appropriate action reads on a maintenance request). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the tamper detection alert requiring reset to restore power to the meter of Chamarti in the tamper detection system of Iliev with a reasonable expectation of success of arriving at the claimed invention, with the motivation “to detect a potential tamper situation” “to enable the utility provider to take an appropriate action” (Chamarti: ¶ 0019). Furthermore, it would have also been obvious to one of ordinary skill in the art before the effective filing date of the invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim 18: Iliev/Sameda/Chamarti teach claim 11. Iliev, as modified above, further teaches: wherein the controller is configured to transmit the tamper alert to a remote user device (Iliev: ¶ 0054 – “a message indicating tampering with the gas meter may be sent. In an example, the message is sent to a headend device, such as a utility company server, main office computing center, etc.”) Claim 19: Iliev/Sameda/Chamarti teach claim 11. With respect to the limitation: wherein the utility device is selected from the group consisting of an electrical meter and a boiler Iliev teaches a utility device such as a gas meter (Iliev: Fig. 2, ¶ 0019), but Iliev/Sameda not explicitly teach the utility device being an electrical meter or boiler. However, Chamarti teaches the utility device being any type of energy meter including gas meters, electricity meter, or a combination thereof (Chamarti: ¶ 0020 “meters in accordance with the disclosed embodiments may monitor any one or a combination of electricity, heat, gas, water, or any other utility. Therefore, while the disclosed embodiments are presented in the context of tamper-detect energy meters, other tamper-detect utility meters, such as tamper-detect heat meters, tamper-detect gas meters, tamper-detect water meters, or any combination thereof, are presently contemplated. Furthermore, energy meters, as presently discussed, may include gas meters, electricity meters, or a combination thereof”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a utility device including an electrical meter as taught by Chamarti in the tamper detection system of Iliev/Sameda/Chamarti, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim 20: Iliev/Sameda/Chamarti teach claim 19. Iliev, as modified above, further teaches: wherein the controller is in communication with the utility device (Iliev: ¶ 0020-0024 showing the index PCBA comprising processor 224 is in communication with the MIG PCBA, and ¶ 0020 “Each MIG PCBA may be configured to operate one or more devices, such as a valve, valve motor, sensor, switch, etc. In an example, a main gas shutoff valve 228 and valve motor 228 is controlled by the MIG PCBA 214”; also see ¶ 0015 showing FMU which (flow measuring unit) in communication with the index PCBA and processor), wherein the controller is further configured to receive an operational state indication from the utility device (Iliev: ¶ 0015 “The index PCBA may include a processor and memory, and may be configured to receive gas consumption data and gas pressure data from the FMU and/or one or more MIG PCBA or sensor devices”; also see ¶ 0042 showing reporting an operation or event from the MIG PCBA to the index PCBA that a main gas valve has been closed), and wherein the operational state indication from the utility device includes data relating to an operation being executed by the utility device when the first air pressure and the second air pressure are received from the pressure sensor (Iliev: ¶ 0042, Fig. 3 showing after comparing pressure differences to threshold, an operational state may be change to close a gas valve and then report the valve closed information to the index PCBA) Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over US 20230041634 A1 to Iliev in view of US 20090018782 A1 to Sameda et al. (Sameda), further in view of US 20130119974 A1 to Chamarti et al. (Chamarti), and further in view of US 20180023989 A1 to Droin et al. (Droin). Claim 12: Iliev/Sameda/Chamarti teach claim 11. Iliev, as modified above, further teaches: wherein the controller is in communication with the utility device (Iliev: ¶ 0020-0024 showing the index PCBA comprising processor 224 is in communication with the MIG PCBA, and ¶ 0020 “Each MIG PCBA may be configured to operate one or more devices, such as a valve, valve motor, sensor, switch, etc. In an example, a main gas shutoff valve 228 and valve motor 228 is controlled by the MIG PCBA 214”; also see ¶ 0015 showing FMU which (flow measuring unit) in communication with the index PCBA and processor), wherein the controller is further configured to receive an operational state indication from the utility device (Iliev: ¶ 0015 “The index PCBA may include a processor and memory, and may be configured to receive gas consumption data and gas pressure data from the FMU and/or one or more MIG PCBA or sensor devices”) With respect to the limitation: and determine the first predetermined utility housing pressure change threshold using the operational state indication Iliev teaches at least one predetermined utility housing pressure change threshold in order to detect an abnormal operating state/issue or tampering relating to a utility device (Iliev: ¶ 0045-0055 generally), but Iliev/Sameda/Chamarti do not explicitly teach adjusting a threshold based upon an operational state of a utility device. However, Droin teaches fraud/tampering detection thresholds of a meter which may be adjusted dynamically according to the current operating conditions related to the utility device (Droin: ¶ 0047-0048, with ¶ 0048 showing “One or more of the thresholds may be adjusted dynamically in response to conditions relating to the water mains network…” and ¶ 0050-0055, with ¶ 0054 showing “One or more of the thresholds may be adjusted dynamically in response to conditions relating to the location of the meter…”; also see ¶ 0084). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included adjusting thresholds based upon current utility operating conditions related to the meter of Droin in the tamper detection system of Iliev/Sameda/Chamarti with a reasonable expectation of success of arriving at the claimed invention, with the motivation to “provide more accurate tamper detection and reduce the occurrence of false alarms” (Droin: ¶ 0049). Claims 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20230041634 A1 to Iliev in view of US 20090018782 A1 to Sameda et al. (Sameda), further in view of US 20130119974 A1 to Chamarti et al. (Chamarti), and further in view of US 20020190865 A1 to Horibe et al. (Horibe). Claim 13: Iliev/Sameda/Chamarti teach claim 11. With respect to the limitations: further comprising: an access door at the utility housing, wherein the first time is when the access door is closed and the second time is when the access door is open Iliev teaches an enclosure, i.e. utility housing, associated with a utility meter as per claim 11 above (Iliev: Fig. 2, ¶ 0022), but Iliev/Sameda are silent regarding the presence of an access door or cover to access to the meter housing, and detecting pressure changes when the door is closed and opened. However, Chamarti teaches a gas meter including a cover enclosure, i.e. a type of access door, that can be opened and closed to access the gas meter (Chamarti: ¶ 0004-0006, ¶ 0036-0041 showing meter cover, i.e. door), and recording a time/date when the access cover is removed/opened to detect tampering (Chamarti: ¶ 0025 “a time and/or date in which a cover (FIG. 3) of the meter 20 has been removed may be recorded. As discussed below, information pertaining to the potential tamper event may be transmitted to a utility provider”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include the meter access cover that is monitored to detect tampering as taught by Chamarti in the tamper detection system for a gas meter of Iliev/Sameda/Chamarti (such that the enclosure of Iliev includes an access cover/door), since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Still, Iliev/Sameda/Chamarti do not explicitly teach that the pressure detection corresponds to times at which a door is opened and closed. However, Horibe teaches an enclosure with a door that is opened and closed (Horibe: ¶ 0040-0043) and using a pressure sensor to detect intrusion in an enclosed space, including detecting pressure changes at the specific time that the door to the enclosure is closed, and specific times where the door to the enclosure is opened, i.e. at least a first and second time where the door is open and closed (Horibe: ¶ 0040-0043, Figs. 3A-3B, with Fig. 3B showing pressure wave form at a time when door is closed, and pressure wave form at a time when door is opened; also see Fig. 12B, ¶ 0069-0070 showing pressure change over time, as door goes from closed to open). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the pressure monitoring system for detecting when a door of an enclosure is opened or closed of Horibe in the tamper detection system of Iliev/Sameda/Chamarti with a reasonable expectation of success of arriving at the claimed invention, with the motivation “provide a pressure sensor and a door opening/closing monitoring system which will solve the problems as described above, is small and capable of detecting the opening/dosing of the door with high sensitivity, allowing a detection of an operation condition, that is, whether the door is opened or closed, is subjected to less limitation in an installation position thereof and can be installed such that the sensor is not readily noticeable from outside” (Horibe: ¶ 0009). Furthermore, it would also have been obvious to one of ordinary skill in the art before the effective filing date of the invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim 14: Iliev/Sameda/Chamarti/Horibe teach claim 13. With respect to the following limitation, Iliev teaches an alert corresponding to a tamper alert (Iliev: Fig. 4, ¶ 0054), but Iliev/Sameda do not explicitly teach the following. However, Chamarti teaches: wherein the tamper alert relates to the access door being open (Chamarti: ¶ 0025 “The processor 46 may also store information relating to events in which a possible tamper situation has occurred. For example, a time and/or date in which a cover (FIG. 3) of the meter 20 has been removed may be recorded. As discussed below, information pertaining to the potential tamper event may be transmitted to a utility provider. The information may include, by way of non-limiting examples, a time of the tamper event, identification data of the meter, an identifier of the customer, GPS data, or any combination thereof”; also see at least ¶ 0019) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included transmitting the tamper alert when the access cover is removed, i.e. opened of Chamarti in the tamper detection system of Iliev/Sameda/Chamarti/Horibe with a reasonable expectation of success of arriving at the claimed invention, for the same reasons discussed in the rejection of claim 11 above. Claim 15: Iliev/Sameda/Chamarti/Horibe teach claim 13. With respect to the following limitation, Iliev/Sameda do not explicitly teach the following, however, Chamarti teaches: wherein when the access door is closed the utility device is concealed within the utility housing and when the access door is open the utility device is accessible within the utility housing (Chamarti: ¶ 0004-0005, ¶ 0036-0037, ¶ 0018-0019, ¶ 0050 describing access cover, which may have various coupling mechanisms such as rectangular and hinged design (i.e. door), which conceals the utility meter and which is removed or opened to access the utility meter base) It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include the configuration of the access cover to conceal or provide access to the utility meter in the tamper detection system of Iliev/Sameda/Chamarti/Horibe, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20230041634 A1 to Iliev in view of US 20090018782 A1 to Sameda et al. (Sameda), further in view of US 20130119974 A1 to Chamarti et al. (Chamarti), and further in view of US 20130154833 A1 to Kiss et al. (Kiss). Claim 16: Iliev/Sameda/Chamarti teach claim 11. With respect to the limitation: wherein the controller is configured to generate the tamper alert when a time at which the change in pressure at the utility housing matches the first predetermined utility housing pressure change threshold differs from a prescheduled utility device maintenance time Iliev teaches wherein the controller is configured to generate the tamper alert when the change in pressure at the utility housing matches the first predetermined utility housing pressure change threshold (Iliev: ¶ 0049-0050, Fig. 5; see rejection of claim 11 above), but Iliev/Sameda/Chamarti do not explicitly teach that the alert is only generated when it differs from a prescheduled utility device maintenance time. However, Kiss teaches ignoring a detected tampering alert associated with a door of a utility device enclosure being opened, when a metering device is placed into an “ignore mode” during a time associated with scheduled maintenance (Kiss: ¶ 0034-0038; also see ¶ 0002-0004, ¶ 0031-0033 generally), but if the ignore conditions are not satisfied (“differs from a prescheduled utility device maintenance time”), the device does not ignore a disconnect command and disconnects the utility (Kiss: ¶ 0040, ¶ 0046) including setting a tamper status flag to generate an alarm relating to tampering (Kiss: ¶ 0032). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included conditionally triggering the tampering signal/alert based on whether or not the utility device is an “ignore mode” according to a maintenance schedule of Kiss in the tamper detection system of Iliev/Sameda/Chamarti with a reasonable expectation of success of arriving at the claimed invention, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Claim 17: Iliev/Sameda/Chamarti/Kiss teach claim 16. With respect to the following limitation, Iliev/Sameda/Chamarti do not explicitly teach, however, Kiss teaches: wherein the controller is configured to receive and store a utility maintenance schedule that includes the prescheduled utility device maintenance time (Kiss: ¶ 0034 “the back office 210 schedules maintenance for a particular enclosure 400 for Tuesday between the hours of 1:00 a.m. and 4:00 a.m. Therefore, to ensure that the end-devices 125 only ignore openings of the door 402 during the scheduled maintenance time, the back office 210 sends the end-devices 125 an "ignore" command at 1:00 a.m. on Tuesday and a "stop ignoring" at 4:00 a.m. on Tuesday” and ¶ 0035 “Alternatively, the back office 210 can send an "ignore" command to the end-devices 125 at any time before 1:00 a.m. on Tuesday and can use the "ignore` conditions to specify a Tuesday, 1:00 a.m. start time and a Tuesday, 4:00 a.m. end time. Based on the "ignore" conditions, the NIC 302 can automatically set the status flag at 1:00 a.m. on Tuesday and can automatically unset the status flag at 4:00 a.m. on Tuesday without requiring further commands or signals from the back office 210”; see ¶ 0031, ¶ 0033 showing the NIC 302 can store and reference the information and conditions relating to the ignore command) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included receiving and storing the “ignore mode” command and conditions (which pertain to maintenance schedule times) for the utility device of Kiss in the tamper detection system of Iliev/Sameda/Chamarti/Kiss with a reasonable expectation of success of arriving at the claimed invention, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Novelty/Non-Obviousness Claims 3-4 are novel and non-obvious over the prior art for the following reasons: As seen above, claim 2 is rendered obvious over the combination of US 20120323375 A1 to Dean-Hendricks et al. (Dean-Hendricks) in view of US 20220100802 A1 to Saini et al. (Saini), further in view of US 20210207833 A1 to Dameno et al. (Dameno), and even further in view of US 20230141593 A1 to Ramer et al. (Ramer). Claim 3 recites further limitations for wherein the controller is configured to determine if the warranty applies by comparing a time at which the change in pressure at the utility device matches the first predetermined utility pressure change threshold and a term of the warranty. Dean-Hendricks teaches comparing a time at which the change in pressure at the utility device matches the first predetermined utility pressure change threshold to determine and generate an alert that an HVAC air filter change is needed (Dean-Hendricks: ¶ 0138-0140, ¶ 0070, ¶ 0077, ¶ 0094, ¶ 0106), and Ramer teaches checking claim coverage for a home warranty (Ramer: ¶ 0237-0240 as above) and determining an age of a home protection plan/payment status as factor in claim adjudication process (Ramer: ¶ 0342-0344), but Dean-Hendricks, Saini, Dameno, and Ramer all fail to teach comparing a specific time at which the change is pressure matches the first predetermined utility pressure change threshold to a term of the warranty to determine if a warranty applies. While US 20180240124 A1 to Natarajan is the closest prior art and teaches determining whether a warranty applies based on whether a term of the warranty has expired (Natarajan: ¶ 0043 “if the actual warranty expiration date has not yet expired, a warranty service provider is notified to schedule an appointment with the customer…”) – one of ordinary skill in the art would not have found it obvious to further modify the existing 4+ reference combination of Dean-Hendricks, Saini, Dameno, and Ramer to arrive at the claimed limitations for comparing a specific time at which the change is pressure matches the first predetermined utility pressure change threshold to terms of a warranty to determine if the warranty applies. None of the other previously cited or newly cited references (including US 20090018782 A1 to Sameda and US 20130119974 A1 to Chamarti) cure the deficiencies above. Therefore, claim 3 is not rendered obvious by the prior art. Claim 4 depends from claim 3 and is also novel and non-obvious. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hunter Molnar whose telephone number is (571)272-8271. The examiner can normally be reached Monday - Friday, 7:30 - 4:00 EST. 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, Jeffrey Zimmerman can be reached at (571) 272-4602. 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. /HUNTER MOLNAR/Examiner, Art Unit 3628
Read full office action

Prosecution Timeline

Dec 02, 2024
Application Filed
Feb 24, 2026
Non-Final Rejection mailed — §101, §103
May 06, 2026
Response Filed
Jul 01, 2026
Final Rejection mailed — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12651211
SYSTEM AND METHOD FOR EFFICIENTLY TRAINING A MACHINE LEARNING MODEL WITH OPTIMIZED NUMBER OF DATA ELEMENTS FOR PREDICTING TRAVEL INTENT
2y 5m to grant Granted Jun 09, 2026
Patent 12639773
CONSTRUCTION MANAGEMENT SYSTEM, DATA PROCESSING DEVICE, AND CONSTRUCTION MANAGEMENT METHOD
2y 9m to grant Granted May 26, 2026
Patent 12630172
INCENTIVE PROVIDING SYSTEM, INCENTIVE PROVIDING METHOD, AND PROGRAM
2y 9m to grant Granted May 19, 2026
Patent 12632818
Camera and Systems for Integrated, Secure, and Verifiable Home Services
2y 4m to grant Granted May 19, 2026
Patent 12632799
A COMMUNICATIONS SERVER, A METHOD, A USER DEVICE AND A BOOKING SYSTEM
2y 6m to grant Granted May 19, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

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

Prosecution Projections

3-4
Expected OA Rounds
50%
Grant Probability
82%
With Interview (+32.1%)
3y 1m (~1y 6m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 259 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month