DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 10, 2026 has been entered. Claims 1, 12, and 20 have been amended. Claims 1-20 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed March 10, 2026 have been fully considered but they are not persuasive.
Regarding the rejection under 35 U.S.C. § 101, Applicant submits that the features of the claims cannot be performed in the human mind (page 9 of Applicant’s response response). The Examiner maintains that, aside from a general recitation of the additional elements at a high level, a human user could indeed perform most of the recited operations, including receiving data, generating information, normalizing metrics, generating an aggregated performance metric, generating a ranking, generating a display of information, and automatically (i.e., in direct response to) make plans to perform a mitigation operation. A human user may also be instructed to execute a mitigation operation, which could involve making a decision to cease an operation or which could involve actively effecting a physical mitigation operation (which is an example of organizing human activity since a human may be instructed to perform a physical mitigation operation). As a matter of fact, dependent claim 11 recites “automatically performing the at least one recommended mitigation action by automatically adjusting one or more operational parameters of the particular poor-performance asset” and a human user can automatically adjust one or more operational parameters.
On page 9 of the response, Applicant argues:
…The subject matter of amended independent claim 1 operates in an industrial computing environment, gathering real-time data from multiple sensors and control modules associated with various types of physical equipment-such as pumps, valves, or other machinery-and applying a series of algorithmic transformations to convert heterogeneous operational data into standardized and actionable insights. This functionality extends far beyond generic software routines or mental processes, as it requires coordinated electronic processing, memory management, and execution of instructions within say, a system that directly interfaces with facility assets. By enabling consistent evaluation and ranking across distinct performance metric types, the subject matter of amended independent claim 1 establishes a unified framework for automated decision support and maintenance intervention, further enhanced by an embedded feedback loop that not only detects poor-performing equipment but also transmits corrective commands and autonomously implements mitigation actions thereby directly influencing the underlying physical process. As such, the subject matter of amended independent claim 1 improves both the monitoring and control architecture foundational to industrial asset management, providing tangible operational benefits by transforming raw data into targeted, real-world optimizations, and thus constitutes a technological advancement rather than an abstraction. See at least paragraphs [0040]-[0041], [0050], [0126], [0142], [0143], and [0160]-[0162] of published Specification as well.
The Examiner notes that specific details of how assets are physical assets and controlled in a feedback loop (for example) are not recited in the claims. There are also no sensors or control devices presented in the claims. Applicant is arguing limitations not recited in the claims.
On page 10 of the response, Applicant argues:
…For instance, the subject matter of amended independent claim 1 can be practically realized as, for instance, a specific, machine- implemented method for industrial asset monitoring and management that is rooted in technical operations and not abstract ideas. The claimed process comprises collecting varied performance data-such as temperature, flow rate, and vibration-from sensors and control devices across multiple types of physical assets like turbines, pumps, and compressors. The claimed process involves generating numerous performance metrics for each asset, normalizing these across diverse types to a common scale, and aggregating them to allow consistent cross-asset ranking. Such normalization and aggregation, as emphasized, cannot be performed mentally or using generic software, but require algorithmic and computational processing by an apparatus with a processor, memory, and executable instructions. The graphical user interface not only presents poor-performing assets and contributing factors visually, but also displays actionable recommendations that are automatically transmitted and executed by sending commands directly to the assets…
There are no sensors in the claims. Applicant is arguing limitations not recited in the claims. Regarding the normalization and aggregation, the corresponding analyses may be performed by a human user (in the mind and/or with pen and paper) and are part of the evaluated process related to “monitoring asset performance and generating rankings of assets based at least in part on asset performance” (Spec: ¶ 1), which (under its broadest reasonable interpretation) is an example of business relations (i.e., organizing human activity).
Furthermore, the Examiner points out that the claims do not present specific details regarding how such operations are managed in an industrial automation environment. The claims simply collect data needed to perform the analysis needed to make and implement mitigation decisions. Applicant refers to normalizing data between different units or scales. These types of unit and scale conversions have been performed by humans for years (mentally and/or with pen and paper). The claims lack specific technical details that would convey more than a general application of the additional elements to the judicial exceptions or more than a general link to a field of use.
Additionally, MPEP § 2106.05(a) states, “An important consideration in determining whether a claim improves technology is the extent to which the claim covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming the idea of a solution or outcome. McRO, 837 F.3d at 1314-15, 120 USPQ2d at 1102-03; DDR Holdings, 773 F.3d at 1259, 113 USPQ2d at 1107.” Even if the limitation of automatically performing the recommended mitigation action were interpreted as being initiated by an instruction from an additional element, this would still simply present the idea of a solution or outcome (as opposed to a particular technical solution to a technical problem).
Regarding the art rejections, Applicant argues that Laycock and Chiaramonte individually do not fully address the details amended into the step of normalizing (pages 12-14 of Applicant’s response). The Serrano and Flood references have been introduced into the rejections in order to help address the claim amendments.
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 non-statutory subject matter.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claimed invention is directed to “monitoring asset performance and generating rankings of assets based at least in part on asset performance” (Spec: ¶ 1) without significantly more.
Step
Analysis
1: Statutory Category?
Yes – The claims fall within at least one of the four categories of patent eligible subject matter. Process (claims 1-11), Apparatus (claims 12-19), Article of Manufacture (claim 20)
Independent claims:
Step
Analysis
2A – Prong 1: Judicial Exception Recited?
Yes – Aside from the additional elements identified in Step 2A – Prong 2 below, the claims recite:
[Claims 1, 12, 20] receiving monitored data associated with a plurality of assets;
generating, for each of the plurality of assets and using the monitored data, a plurality of performance metrics;
normalizing the plurality of performance metrics for each of the plurality of assets to generate a plurality of normalized performance metrics for each asset of the plurality of assets, wherein each performance metric of the plurality of normalized performance metrics indicates a level of performance of the corresponding asset, wherein a normalized performance metric of the plurality of normalized performance metrics comprises a value of a first-type performance metric that is normalized to facilitate comparison with a second-type performance metric different from the first-type performance metric;
generating an aggregated performance metric for each particular asset of the plurality of assets based at least in part on a combination of the plurality of normalized performance metrics corresponding to the asset; and
generating a ranking of the plurality of assets based at least in part on the aggregated performance metric for each asset, wherein the ranking of the plurality of assets indicates a level of poor performance for each asset of the plurality of assets;
generating a display based at least in part on the ranking to display one or more poor performance factors for a particular poor-performance asset of the plurality of assets with at least one recommended mitigation action;
transmitting a command indicative of the at least one recommended mitigation action to the particular poor-performing asset; and
automatically performing the at least one recommended mitigation action to alter one or more operations of the particular poor-performance asset.
Aside from the additional elements, the aforementioned claim details exemplify the abstract idea(s) of a mental process (since the details include concepts performed in the human mind, including an observation, evaluation, judgment, and/or opinion). As explained in MPEP § 2106(a)(2)(C)(III), “The courts consider a mental process (thinking) that ‘can be performed in the human mind, or by a human using a pen and paper’ to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, ‘methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’’ 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)).” The limitations reproduced above, as drafted, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting the additional elements identified in Step 2A – Prong 2 below, nothing in the claim elements precludes the steps from practically being performed in the mind and/or by a human using a pen and paper. For example, but for the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the respectively recited steps/functions of the claims, as drafted and set forth above, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or with the use of pen and paper. A human user could gather the recited data, perform the various analyses, and display information in accordance with the details cited above. A human user can also automatically (i.e., in direct response to) perform certain mitigation actions. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind (and/or with pen and paper) but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Aside from the additional elements, the aforementioned claim details exemplify a method of organizing human activity (since the details include examples of commercial or legal interactions, including advertising, marketing or sales activities or behaviors, and/or business relations and managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). More specifically, the evaluated process is related to “monitoring asset performance and generating rankings of assets based at least in part on asset performance” (Spec: ¶ 1), which (under its broadest reasonable interpretation) is an example of business relations (i.e., organizing human activity); therefore, aside from the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the limitations identified in the more detailed claim listing above encompass the abstract idea of organizing human activity. A human user can also automatically (i.e., in direct response to) perform certain mitigation actions, such as ones that simply involve providing direction to alter operations, which also means that human users can follow instructions to implement a mitigation action, which is another example of organizing human activity. As a matter of fact, dependent claim 11 recites “automatically performing the at least one recommended mitigation action by automatically adjusting one or more operational parameters of the particular poor-performance asset” and a human user can automatically adjust one or more operational parameters.
Various calculating steps are recited throughout the claims (as implied, for example, by the normalization of the performance metrics, generation of an aggregate performance metric for each asset, and generation of a ranking of the assets, as recited in independent claims 1, 12, and 20, and as further evidenced by the use of an average performance metric (recited in claim 15).
2A – Prong 2: Integrated into a Practical Application?
No – The judicial exception(s) is/are not integrated into a practical application.
Claim 1 and its dependent claims recite that the method is computer-implemented. Claim 1 further recites generating a graphical user interface via a computing device. Claim 1 recites that a command indicative of the at least one recommended mitigation action is transmitted from the computing device.
Claims 12 and its dependent claims recite a computing apparatus comprising at least one processor and at least one non-transitory memory having computer-coded instructions stored thereon, the computer coded instructions configured to, in execution with the at least one processor, cause the apparatus to perform the recited functions. Claim 12 further recites generating a graphical user interface via a computing device. Claim 12 recites that a command indicative of the at least one recommended mitigation action is transmitted from the computing device.
Claim 20 recites a computer program product comprising at least one non-transitory, computer-readable storage medium including instructions that, upon execution by at least one processor, configure the computer program product to perform the recited functions. Claim 20 further recites generating a graphical user interface via a computing device. Claim 20 recites that a command indicative of the at least one recommended mitigation action is transmitted from the computing device.
The claims as a whole merely describe how to generally “apply” the abstract idea(s) in a computer environment. The claimed processing elements are recited at a high level of generality and are merely invoked as a tool to perform the abstract idea(s). Simply implementing the abstract idea(s) on a general-purpose processor is not a practical application of the abstract idea(s); Applicant’s specification discloses that the invention may be implemented using general-purpose processing elements and other generic components (Spec: ¶¶ 189-201).
The use of a processor/processing elements (e.g., as recited in all of the claims) facilitates generic processor operations. The use of a memory or machine-readable media with executable instructions facilitates generic processor operations.
The additional elements are recited at a high-level of generality (i.e., as generic processing elements performing generic computer functions) such that the incorporation of the additional processing elements amounts to no more than mere instructions to apply the judicial exception(s) using generic computer components. There is no indication in the Specification that the steps/functions of the claims require any inventive programming or necessitate any specialized or other inventive computer components (i.e., the steps/functions of the claims may be implemented using capabilities of general-purpose computer components). Accordingly, the additional elements do not integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea(s).
The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
There is no transformation or reduction of a particular article to a different state or thing recited in the claims.
Additionally, even when considering the operations of the additional elements as an ordered combination, the ordered combination does not amount to significantly more than what is present in the claims when each operation is considered separately.
2B: Claim(s) Provide(s) an Inventive Concept?
No – The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception(s). As discussed above with respect to integration of the abstract idea(s) into a practical application, the use of the additional elements to perform the steps identified in Step 2A – Prong 1 above amounts to no more than mere instructions to apply the exceptions using a generic computer component(s). Mere instructions to apply an exception using a generic computer component(s) cannot provide an inventive concept. The claims are not patent eligible.
Dependent claims:
Step
Analysis
2A – Prong 1: Judicial Exception Recited?
Yes – Aside from the additional elements identified in Step 2A – Prong 2 below, the claims recite:
[Claim 2] generating an importance-weighted performance metric for each of the plurality of assets based at least in part on a importance factor corresponding to the asset and the aggregated performance metric corresponding to the asset; and
generating the ranking of the plurality of assets based at least in part on the importance-weighted performance metric.
[Claim 3] determining an asset type of each of the plurality of assets; and
generating the plurality of performance metrics for each particular asset of the plurality of assets based at least in part on the asset type corresponding to the particular asset.
[Claim 4] determining the importance factor for each particular asset of the plurality of assets based at least in part on the asset type corresponding to the particular asset.
[Claim 5] identifying the particular poor-performance asset from the plurality of assets based at least in part on the ranking; and
determining at least one poor performance factor for the particular poor-performing asset based at least in part on the plurality of normalized performance metrics associated with the particular poor-performance asset.
[Claim 6] generating a second ranking of the plurality of normalized performance metrics associated with the particular poor-performing asset, wherein the second ranking of the plurality of normalized performance metrics indicates a degree of difference between each normalized performance metric from a reference value corresponding to the performance metric; and
determining the at least one poor performance factor based at least in part on the second ranking of the plurality of normalized performance metrics.
[Claim 7] determining at least one poor performance factor for the particular poor-performing asset based a comparison between one or more predetermined thresholds and at least one performance metric of the plurality of performance metrics associated with the particular poor-performance asset.
[Claim 8] adjusting the one or more predetermined thresholds based at least in part on at least one of a downtime metric, a criticality metric, a cost metric, or other user-inputted metric.
[Claim 9] generating, using a model and the at least one poor performance factor, at least one recommended mitigation action associated with the particular poor-performing asset.
[Claim 10] wherein the model is a decision tree.
[Claim 11] automatically performing the at least one recommended mitigation action by automatically adjusting one or more operational parameters of the particular poor-performance asset.
[Claim 13] wherein an ordering of the plurality of assets in the ranking indicates poor-performing assets.
[Claim 14] wherein top-ranked entries of the ranking indicate poorest-performing assets.
[Claim 15] wherein the aggregated performance metric is an average performance metric.
[Claim 16] identify one or more poor-performing assets based at least in part on the ranking.
[Claim 17] provide the display to at least one user.
[Claim 18] wherein the display comprises at least one poor performance factor for at least one of the plurality of assets in the ranking.
[Claim 19] wherein the display further comprises at least one recommended action for mitigation of the at least one of the plurality of assets.
The dependent claims further present details of the abstract ideas identified above in regard to the independent claims.
Aside from the additional elements, the aforementioned claim details exemplify the abstract idea(s) of a mental process (since the details include concepts performed in the human mind, including an observation, evaluation, judgment, and/or opinion). As explained in MPEP § 2106(a)(2)(C)(III), “The courts consider a mental process (thinking) that ‘can be performed in the human mind, or by a human using a pen and paper’ to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, ‘methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’’ 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)).” The limitations reproduced above, as drafted, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting the additional elements identified in Step 2A – Prong 2 below, nothing in the claim elements precludes the steps from practically being performed in the mind and/or by a human using a pen and paper. For example, but for the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the respectively recited steps/functions of the claims, as drafted and set forth above, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or with the use of pen and paper. A human user could gather the recited data, perform the various analyses, and display information in accordance with the details cited above. A human user can also automatically (i.e., in direct response to) perform certain mitigation actions. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind (and/or with pen and paper) but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Aside from the additional elements, the aforementioned claim details exemplify a method of organizing human activity (since the details include examples of commercial or legal interactions, including advertising, marketing or sales activities or behaviors, and/or business relations and managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). More specifically, the evaluated process is related to “monitoring asset performance and generating rankings of assets based at least in part on asset performance” (Spec: ¶ 1), which (under its broadest reasonable interpretation) is an example of business relations (i.e., organizing human activity); therefore, aside from the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the limitations identified in the more detailed claim listing above encompass the abstract idea of organizing human activity. A human user can also automatically (i.e., in direct response to) perform certain mitigation actions, such as ones that simply involve providing direction to alter operations, which also means that human users can follow instructions to implement a mitigation action, which is another example of organizing human activity. As a matter of fact, dependent claim 11 recites “automatically performing the at least one recommended mitigation action by automatically adjusting one or more operational parameters of the particular poor-performance asset” and a human user can automatically adjust one or more operational parameters.
Various calculating steps are recited throughout the claims (as implied, for example, by the normalization of the performance metrics, generation of an aggregate performance metric for each asset, and generation of a ranking of the assets, as recited in independent claims 1, 12, and 20, and as further evidenced by the use of an average performance metric (recited in claim 15).
2A – Prong 2: Integrated into a Practical Application?
No – The judicial exception(s) is/are not integrated into a practical application.
The dependent claims incorporate the additional elements of the independent claim from which each depends.
Claim 1 and its dependent claims recite that the method is computer-implemented. Claim 1 further recites generating a graphical user interface via a computing device. Claim 1 recites that a command indicative of the at least one recommended mitigation action is transmitted from the computing device.
Claim 9 recites generating, using a machine learning model and the at least one poor performance factor, at least one recommended mitigation action associated with the particular poor-performing asset.
Claim 10 recites wherein the machine learning model is a decision tree.
Claims 12 and its dependent claims recite a computing apparatus comprising at least one processor and at least one non-transitory memory having computer-coded instructions stored thereon, the computer coded instructions configured to, in execution with the at least one processor, cause the apparatus to perform the recited functions. Claim 12 further recites generating a graphical user interface via a computing device. Claim 12 recites that a command indicative of the at least one recommended mitigation action is transmitted from the computing device.
Claim 17 recites wherein the one or more processors are further configured to:
generate a user interface based at least in part on the ranking; and
provide the user interface to at least one computing device.
Claim 18 recites wherein the user interface comprises at least one poor performance factor for at least one of the plurality of assets in the ranking.
Claim 19 recites wherein the user interface further comprises at least one recommended action for mitigation of the at least one of the plurality of assets.
Claim 20 recites a computer program product comprising at least one non-transitory, computer-readable storage medium including instructions that, upon execution by at least one processor, configure the computer program product to perform the recited functions. Claim 20 further recites generating a graphical user interface via a computing device. Claim 20 recites that a command indicative of the at least one recommended mitigation action is transmitted from the computing device.
The claims as a whole merely describe how to generally “apply” the abstract idea(s) in a computer environment. The claimed processing elements are recited at a high level of generality and are merely invoked as a tool to perform the abstract idea(s). Simply implementing the abstract idea(s) on a general-purpose processor is not a practical application of the abstract idea(s); Applicant’s specification discloses that the invention may be implemented using general-purpose processing elements and other generic components (Spec: ¶¶ 189-201).
The use of a processor/processing elements (e.g., as recited in all of the claims) facilitates generic processor operations. The use of a memory or machine-readable media with executable instructions facilitates generic processor operations.
The additional elements are recited at a high-level of generality (i.e., as generic processing elements performing generic computer functions) such that the incorporation of the additional processing elements amounts to no more than mere instructions to apply the judicial exception(s) using generic computer components. There is no indication in the Specification that the steps/functions of the claims require any inventive programming or necessitate any specialized or other inventive computer components (i.e., the steps/functions of the claims may be implemented using capabilities of general-purpose computer components). Accordingly, the additional elements do not integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea(s).
The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
Claim 9 recites generating, using a machine learning model and the at least one poor performance factor, at least one recommended mitigation action associated with the particular poor-performing asset. Claim 10 recites wherein the machine learning model is a decision tree. Considering that the implementation of the machine learning model and/or the training of the model is performed using processing elements, such an implementation is presented as a generic recitation of machine learning in the claims and as a general link to technology. The machine learning-based processing elements are simply tools to generally automate the underlying process that could be performed by a human. It is further noted that, as described in Applicant’s Specification, the machine learning operations are generic machine learning operations (Spec: ¶¶ 61, 164). The Specification presents no assertion that there is any improvement in the automated machine learning process itself. Such a generic recitation of machine learning, as recited in the claims, is little more than automating an analogous process that can be performed by a human.
There is no transformation or reduction of a particular article to a different state or thing recited in the claims.
Additionally, even when considering the operations of the additional elements as an ordered combination, the ordered combination does not amount to significantly more than what is present in the claims when each operation is considered separately.
2B: Claim(s) Provide(s) an Inventive Concept?
No – The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception(s). As discussed above with respect to integration of the abstract idea(s) into a practical application, the use of the additional elements to perform the steps identified in Step 2A – Prong 1 above amounts to no more than mere instructions to apply the exceptions using a generic computer component(s). Mere instructions to apply an exception using a generic computer component(s) cannot provide an inventive concept. The claims are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Laycock et al. (US 2020/0103871) in view of Chiaramonte et al. (US 2019/0147412) in view of Serrano et al. (US 2013/0318567) in view of Flood et al. (US 2019/0325669).
[Claim 1] Laycock discloses a computer-implemented method (¶ 40 – “FIG. 4A shows an example network diagram 400 comprising a disclosed computing system 410 including an analysis engine 416. The computing system 410 includes at least one processor 411 having an associated memory 412, and a display device 418.”), comprising:
receiving monitored data associated with a plurality of assets (¶ 45 – “The plant 470 may be configured with one or more computing devices that monitor plant operational data and report such operational data to the analysis engine 416. The plant 470 may comprise sensors that report operational data to the analysis engine 416 via the network 420.”; ¶ 50 – “The asset health platform 433 may be configured to collect information about the health of various plant assets, such as equipment. For example, the asset health platform 433 may monitor wear and tear on a periodically replaced component in a plant, such as a nozzle. The asset health platform 433 may be connected to one or more sensors on plant assets and/or may estimate asset health based on, for example, a depreciation schedule.”);
normalizing performance metrics for the plurality of assets to generate a plurality of normalized performance metrics for each asset of the plurality of assets, wherein each performance metric of the plurality of normalized performance metrics indicates a level of performance of the corresponding asset (¶ 81 – “A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.”; ¶ 82 – “The graphical user interface may include one or more indications of a health of a process or asset. For example, a visualization related to a process or asset may display a first color to indicate a first health level, a second color to indicate a second health level, a third color to indicate a third health level, and the like. For example, if a process or asset is operating smoothly and within normal operating thresholds, the visualization may show a first color in connection with the process or asset. If the process or asset has a minor issue (e.g., between a first threshold and a second threshold), the visualization may show a second color in connection with the process or asset. If the process or asset has a major issue (e.g., out of bounds beyond the second threshold), the visualization may show a third color in connection with the process or asset. Thus, one or more elements (e.g., color) of the visualization may indicate whether a process or asset is running smoothly (e.g., a within normal operating threshold).” A level of performance is determined relative to a threshold of normal operations for a particular asset, which is an example of evaluating a normalized performance of each asset.; ¶ 50 – “The asset health platform 433 may be configured to collect information about the health of various plant assets, such as equipment. For example, the asset health platform 433 may monitor wear and tear on a periodically replaced component in a plant, such as a nozzle. The asset health platform 433 may be connected to one or more sensors on plant assets and/or may estimate asset health based on, for example, a depreciation schedule.”; ¶ 83 – “Thus, the graphical user interface may filter lists of recommendations, processes, and assets to display recommendations, processes, and assets that are related to a selected recommendation, process, or asset.” As seen in ¶¶ 50 and 83, multiple assets may be monitored.); and
generating a ranking of the plurality of assets based at least in part on the performance metric for each asset, wherein the ranking of the plurality of assets indicates a level of poor performance for each asset of the plurality of assets (¶ 10 – “2. a second listing of worst performing ones of the processing equipment (e.g., with the top ranked processing equipment parameter problem based on a deviation from the model, excursions of limits, or change in processing equipment health or from machine learning of past actions) that when a selected poor performing one of the processing equipment is chosen by the user generates a ranked filtered view of suspected ones of the process parameters that may be affected by the selected poor performing processing equipment along with a filtered view of second recommendations for aiding the user to recognize what action to do in order to fix the selected poor performing processing equipment and at least one of the suspected ones of the process parameters (e.g., to return the plant to an optimal state of production).”);
generating a graphical user interface based at least in part on the ranking to display via a computing device one or more poor performance factors for a particular poor-performance asset of the plurality of assets with at least one recommended mitigation action (fig. 6A, ¶¶ 10-11, 79, 82 – Rankings of poorly performing process parameters and of poorly performing assets may be presented on a display device via a GUI.; ¶ 10 – “2. a second listing of worst performing ones of the processing equipment (e.g., with the top ranked processing equipment parameter problem based on a deviation from the model, excursions of limits, or change in processing equipment health or from machine learning of past actions) that when a selected poor performing one of the processing equipment is chosen by the user generates a ranked filtered view of suspected ones of the process parameters that may be affected by the selected poor performing processing equipment along with a filtered view of second recommendations for aiding the user to recognize what action to do in order to fix the selected poor performing processing equipment and at least one of the suspected ones of the process parameters (e.g., to return the plant to an optimal state of production).”; Further noted is that the content of the displayed information is non-functional descriptive material. Any manipulative steps of the invention would be performed the same regardless of the specific data. Further, any structural elements remain the same regardless of the specific data. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability as the claimed invention fails to present a new and unobvious functional relationship between the descriptive material and the substrate, see In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994); In re Ngai, 367 F.3d 1336, 1336, 70 USPQ2d 1862, 1863-64 (Fed. Cir. 2004). Another indication of the existence of non-functional descriptive material is that the content of the material is merely “directed towards conveying a message or meaning to a human reader independent of the supporting product.” Please see MPEP § 2111.05(I)(B).);
transmitting a command indicative of the at least one recommended mitigation action from the computing device to the particular poor-performance asset (¶ 10 – Poorly performing processes and assets/equipment are identified for remedial action.; ¶ 8 – “Disclosed aspects include methods, computing devices, and systems for collecting plant operational data, analyzing the plant operational data, determining tasks based on the analysis, and implementing such tasks (e.g., automatically adjusting plant processing equipment operating parameters). An analysis engine receives, from one or more devices in a plant, operational data. The operational data may comprise one or more alarms or warnings. The operational data may comprise information regarding plant profit and/or loss, equipment, chemical processes, workforce performance, automation system performance, safety system performance, and/or cybersecurity performance. The analysis engine analyzes the operational data to determine, e.g., one or more correlations. For example, the analysis engine may determine a root cause of a problem associated with the operational data being outside a specification.”; ¶ 73 – “ In step 504, equipment issues are determined. In step 505, recommendations to address process issues or equipment issues are determined, which may be determined based on the analysis of the operational data. A recommendation may include one or more tasks, which may correspond to one or more actions performed with respect to the plant. A task may be modifying one or more plant parameters (e.g., a burner temperature) of a plant, adding, modifying, or removing plant assets, or the like. For example, a task may be to replace a burner, alter the fuel flow to a burner, or to clean a burner. As another example, a task may be to add or remove a reactor. The task may comprise taking all or portions of the plant offline and/or shutting down the plant.”; fig. 6A; ¶ 81 – “The graphical user interface may depict a most important process issue at the top of the column of process issues. The graphical user interface may depict a most important asset issue at the top of the column of asset issues. The graphical user interface may depict a most important recommendation at the top of the column of recommendations. The most important process issue, asset issue, and/or recommendation may be determined based on one or more factors, and may change over time (e.g., in real time) based on current operation data received regarding a plant. Illustrative examples of the one or more factors for determining the ordering of the one or more columns may include an impact on a production of the plant, an impact on an efficiency of the plant, an impact on a projected operating life of the plant, an impact on a profit or loss of the plant, an impact on one or more other assets or processes of the plant, or the like.”); and
automatically performing the at least one recommended mitigation action to alter one or more operations of the particular poor-performance asset (¶ 10 – Poorly performing processes and assets/equipment are identified for remedial action.; ¶ 8 – “Disclosed aspects include methods, computing devices, and systems for collecting plant operational data, analyzing the plant operational data, determining tasks based on the analysis, and implementing such tasks (e.g., automatically adjusting plant processing equipment operating parameters). An analysis engine receives, from one or more devices in a plant, operational data. The operational data may comprise one or more alarms or warnings. The operational data may comprise information regarding plant profit and/or loss, equipment, chemical processes, workforce performance, automation system performance, safety system performance, and/or cybersecurity performance. The analysis engine analyzes the operational data to determine, e.g., one or more correlations. For example, the analysis engine may determine a root cause of a problem associated with the operational data being outside a specification.”; ¶ 73 – “ In step 504, equipment issues are determined. In step 505, recommendations to address process issues or equipment issues are determined, which may be determined based on the analysis of the operational data. A recommendation may include one or more tasks, which may correspond to one or more actions performed with respect to the plant. A task may be modifying one or more plant parameters (e.g., a burner temperature) of a plant, adding, modifying, or removing plant assets, or the like. For example, a task may be to replace a burner, alter the fuel flow to a burner, or to clean a burner. As another example, a task may be to add or remove a reactor. The task may comprise taking all or portions of the plant offline and/or shutting down the plant.”; fig. 6A; ¶ 81 – “The graphical user interface may depict a most important process issue at the top of the column of process issues. The graphical user interface may depict a most important asset issue at the top of the column of asset issues. The graphical user interface may depict a most important recommendation at the top of the column of recommendations. The most important process issue, asset issue, and/or recommendation may be determined based on one or more factors, and may change over time (e.g., in real time) based on current operation data received regarding a plant. Illustrative examples of the one or more factors for determining the ordering of the one or more columns may include an impact on a production of the plant, an impact on an efficiency of the plant, an impact on a projected operating life of the plant, an impact on a profit or loss of the plant, an impact on one or more other assets or processes of the plant, or the like.”).
Laycock evaluates the performance of assets, such as equipment, to identify poorly performing assets (as discussed above); however, Laycock does not explicitly disclose that each of the plurality of monitored assets has a plurality of performance metrics. More specifically, Laycock does not explicitly disclose the following:
generating, for each of the plurality of assets and using the monitored data, a plurality of performance metrics;
normalizing the plurality of performance metrics for each of the plurality of assets to generate a plurality of normalized performance metrics for each asset of the plurality of assets, wherein each performance metric of the plurality of normalized performance metrics indicates a level of performance of the corresponding asset, wherein a normalized performance metric of the plurality of normalized performance metrics comprises a value of a first-type performance metric that is normalized to facilitate comparison with a second-type performance metric different from the first-type performance metric;
generating an aggregated performance metric for each particular asset of the plurality of assets based at least in part on a combination of the plurality of normalized performance metrics corresponding to the asset; and
generating a ranking of the plurality of assets based at least in part on the aggregated performance metric for each asset, wherein the ranking of the plurality of assets indicates a level of poor performance for each asset of the plurality of assets.
Chiaramonte explains that the health state information may be determined in regard to an asset and its parts (Chiaramonte: ¶ 326 – “As shown in the example of FIG. 29, the health state processor 2905 receives asset health information 2640 from the health analytics 2620 and processes the asset health information 2640 to determine asset health level, asset life expectancy, asset durability and performance (e.g., along an asset flowpath and/or non-flowpath, etc.), etc., and provides the determined health information to the constraint analyzer 2920, which factors asset health into determining bounds or constraints by which tasks are generated to form a workscope for the target asset. For example, health state information can be provided for an asset, an asset module/part, a group of asset modules/parts, etc., to factor into task generation for the asset and/or module(s)/part(s) of the asset.”). Chiaramonte further describes an aggregate function indicative of performance and other factors related to an asset, based at least on aggregated performance metrics related to each of the parts/modules/components of the asset:
[0324] For example, a health state can be quantified using a health state transfer function, Hs, as a combination of performance, operability, and durability representing a useful remaining life of the target asset, the asset including n parts, modules, and/or components:
PNG
media_image1.png
34
206
media_image1.png
Greyscale
(Eq. 1),
where Pi represents a performance of part/module/component I, Oi represents a operability of part/module/component i, and Di represents a durability of part/module/component i, for example.
Chiaramonte provides an example in which an asset health quantifier (AHQ) is generated based on an average or weighted average of the individual AHQs of each of various sub-components of an asset (such as a fan section) and the AHQs of asset components (i.e., various assets, each consisting of sub-components) can be ranked in ascending order, descending order, by criticality, etc. (Chiaramonte: ¶ 185 – “In some examples, the health quantifier generator 410 calculates an actual AHQ of an asset component based on actual AHQ of sub-components of the asset component. For example, the health quantifier generator 410 can calculate an actual AHQ for the fan section 108 of FIG. 1 based on calculating an actual AHQ for sub-components of the fan section 108 based on the model inputs 335. For example, the health quantifier generator 410 can calculate an actual AHQ of sub-components such as a fan blade, a bearing, a speed sensor, etc., of the fan section 108 by executing the physics-based model 452 of the engine 102. In such an example, the health quantifier generator 410 can generate an actual AHQ of the fan section 108 based on calculating an average (e.g., a weighted average, etc.) of the actual AHQ of the fan blade, the bearing, the speed sensor, etc., of the fan section 108. In some examples, the health quantifier generator 410 can rank the actual AHQ of the asset components (e.g., the fan section 108, the booster compressor 114, etc.) in an ascending order, a descending order, by criticality (e.g., a quantitative measure of how critical an asset component is to a function of the engine 102, etc.), etc.”).
Additionally, Chiaramonte evaluates an AHQ for each asset in terms of various thresholds (e.g., an asset health quantifier threshold, a maintenance quantifier threshold, etc.) to determine if an asset should be scheduled for removal from service (Chiaramonte: ¶¶ 78-80).
Chiaramonte assesses criticality of different asset components in order to perform the ranking. While Chiaramonte may not be explicit in teaching that a normalized performance metric of the plurality of normalized performance metrics comprises a value of a first-type performance metric that is normalized to facilitate comparison with a second-type performance metric different from the first-type performance metric, Serrano and Flood both describe how metrics may vary for different types of assets and how they may be aggregated, normalized, and used for comparison purposes.
For example, Serrano explains that at least one security metric for each asset may be assessed and then the metrics may be normalized and averaged to compute an aggregated score for comparison to a threshold (Serrano: ¶ 27). The metrics and change effort may be normalized into a standard unit to make a recommendation regarding an asset(s) and actions that will have a large reduction in risk with relatively low effort (Serrano: ¶¶ 46-47, 58). A plurality of metrics may be associated with each asset (Serrano: ¶ 57), thereby implying that each asset has its own set of metrics.
Additionally, Flood normalizes performance of each of various different machines as normalized production units (Flood: ¶¶ 19, 21, 37) and each machine has its respective measurements (Flood: ¶ 34 – “Machine metric logic 244 generates quantity metrics that indicate measured variables, indicative of, or characterizing, an operation performed by mobile machine 104. That is, quantity metrics generated by machine metric logic 244 represent a measured variable that is specific to mobile machine 104 and sensor(s) 204. Each machine 104-110 at jobsite 101 might use different sensors or have different measurement calibrations of the same or similar sensors. Machine metric logic 244 is therefore configured to generate quantity metrics that are specific to the variables being sensed by sensors on that particular machine. A plurality of different quantity metrics can be provided by machine metric logic 244, where each quantity metric is provided according to the variables that are sensed or otherwise measured for a particular operation being performed at one of mobile machines 104-110.”; ¶ 36 – “Aggregation logic 246 aggregates the plurality of different quantity metrics to generate, for each mobile machine, a normalized production unit that is normalized across the plurality of different mobile machines. A normalized production unit generated by aggregation logic 246 generally represents a measured output of mobile machine 104 (e.g., the machine-specific quantity metric for mobile machine 104) in a normalized fashion. That is, where the measured variable for mobile machine 104 may initially be expressed in machine-specific measurements, such as a number of stems cut per hour, aggregation logic 246 translates the measured variable according to parameters that are defined for tracking performance across mobile machines 104-110.“; ¶ 35 – “In the example where mobile machine 104 is a harvester, machine metric logic 244 can use sensor signals obtained by sensor interface logic 242 to generate quantity metrics indicating measured lengths of stems cut by mobile machine 104. Where mobile machine 106 is a skidder, for example, machine metric logic 244 can generate quantity metrics representing a diameter of stems, as sensed by sensors specific to mobile machine 106. Examples of quantity metrics generated by machine metric logic 244 include measured characteristics of the material being processed, such as a calculated average stem length, average diameter, average weight, number of stems in a bundle, number of bundles moved, etc. Machine metric logic 244 can also generate quantity metrics that include a time parameter. For instance, machine metric logic 244 can generate a quantity metric that defines an amount of time that machine 104 operates (the uptime) to harvest a number of stems. It can generate a metric indicating how long it takes skidder 106 to move a bundle of logs (or an average time per bundle, an average time per volume of logs, etc.).”). The metrics may be aggregated and normalized to evaluate performance (Flood: ¶¶ 36-37).
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Laycock to perform the following steps:
generating, for each of the plurality of assets and using the monitored data, a plurality of performance metrics;
normalizing the plurality of performance metrics for each of the plurality of assets to generate a plurality of normalized performance metrics for each asset of the plurality of assets, wherein each performance metric of the plurality of normalized performance metrics indicates a level of performance of the corresponding asset, wherein a normalized performance metric of the plurality of normalized performance metrics comprises a value of a first-type performance metric that is normalized to facilitate comparison with a second-type performance metric different from the first-type performance metric;
generating an aggregated performance metric for each particular asset of the plurality of assets based at least in part on a combination of the plurality of normalized performance metrics corresponding to the asset; and
generating a ranking of the plurality of assets based at least in part on the aggregated performance metric for each asset, wherein the ranking of the plurality of assets indicates a level of poor performance for each asset of the plurality of assets
in order to improve the accuracy of the health assessments of assets (as suggested in ¶¶ 58-60 of Chiaramonte) while managing large amounts of data to identify and optimize asset management solutions that require trade-offs among various factors (such as durability, operability, performance, and financial metrics), as suggested in ¶ 310 of Chiaramonte. In other words, Laycock normalizes performance metrics by looking at a respectively appropriate threshold of operations for each asset (as explained above). Laycock simply does not evaluate the performance of each asset in light of an aggregate of multiple performance factors for each asset. Also explained above is that Chiaramonte shows that performance of a single asset may be assessed based on an aggregate of multiple factors and/or based on the multiple components of each asset, both of which fill in Laycock’s gaps related to an asset’s performance being based on an aggregate of multiple performance metrics. Chiaramonte also converts or scales sensor data (Chiaramonte: ¶ 127) and compares an asset health quantifier to a threshold and identifies one or more assets in need of attention (Chiaramonte: ¶¶ 128-129), which are additional examples of normalizing performance metrics. The Examiner maintains that these collective teachings are sufficient to suggest that, if one can normalize a performance metric for each asset to make comparisons more meaningful, then one can extend the normalization process to multiple contributors to performance of each asset (i.e., performance metrics for each asset) when multiple performance metrics are available for each asset (the existence of multiple performance metrics for each of multiple assets being taught by Chiaramonte) in order to enhance the granularity of the asset performance analysis.
Specifically regarding “wherein a normalized performance metric of the plurality of normalized performance metrics comprises a value of a first-type performance metric that is normalized to facilitate comparison with a second-type performance metric different from the first-type performance metric,” Serrano and Flood demonstrate that it was known in the art to assess performance of each of various assets/machines by distinct metrics relevant to each asset/machine and then to normalize the performance for further evaluation. Modifying Laycock wherein a normalized performance metric of the plurality of normalized performance metrics comprises a value of a first-type performance metric that is normalized to facilitate comparison with a second-type performance metric different from the first-type performance metric would have further allowed for the relative health of varying types of assets to be assessed for criticality on a more granular asset-by-asset level. As explained by Flood, this is important because “[a]s such, if a particular one of mobile machines 104-110 is performing poorly, that machine's poor performance can impact the ability of the downstream machines to perform their respective operations. For example, if mobile machine 104 is processing a load (some amount of material) too slowly, the downstream machines 106-110 might experience downtime while waiting for the load to reach their stage in machine dependency order 112. In such an example, the poor performance of mobile machine 104 limits the ability of other mobile machines 106-110 to operate at a desired level of performance. Thus, where performance of machines 104-110 can be understood in a normalized fashion, each machine can be evaluated and control signals can be generated to control each machine to improve the performance of each machine, and thereby improve performance of the collective operation having machine dependency order 112.” (Flood: ¶ 21).
[Claim 2] Laycock discloses:
generating an importance-weighted performance metric for each of the plurality of assets based at least in part on a importance factor corresponding to the asset and the performance metric corresponding to the asset (¶ 56 – “The analysis engine (e.g., contextual analytics mapping module 460) may generate one or more visual indicators of which asset issues may be impacting a process, and vice versa. The analysis engine may provide a single interface that allows even inexperienced users to instantly identify the relationship between key process and asset parameters. The interface may identify the related recommendations from both process and assets, guiding a user toward a better course of action.”; fig. 6A; ¶ 81 – “The graphical user interface may depict a most important process issue at the top of the column of process issues. The graphical user interface may depict a most important asset issue at the top of the column of asset issues. The graphical user interface may depict a most important recommendation at the top of the column of recommendations. The most important process issue, asset issue, and/or recommendation may be determined based on one or more factors, and may change over time (e.g., in real time) based on current operation data received regarding a plant. Illustrative examples of the one or more factors for determining the ordering of the one or more columns may include an impact on a production of the plant, an impact on an efficiency of the plant, an impact on a projected operating life of the plant, an impact on a profit or loss of the plant, an impact on one or more other assets or processes of the plant, or the like. A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.” In other words, ranking may be performed based on a factor identified as being most important.); and
generating the ranking of the plurality of assets based at least in part on the importance-weighted performance metric (¶ 56 – “The analysis engine (e.g., contextual analytics mapping module 460) may generate one or more visual indicators of which asset issues may be impacting a process, and vice versa. The analysis engine may provide a single interface that allows even inexperienced users to instantly identify the relationship between key process and asset parameters. The interface may identify the related recommendations from both process and assets, guiding a user toward a better course of action.”; fig. 6A; ¶ 81 – “The graphical user interface may depict a most important process issue at the top of the column of process issues. The graphical user interface may depict a most important asset issue at the top of the column of asset issues. The graphical user interface may depict a most important recommendation at the top of the column of recommendations. The most important process issue, asset issue, and/or recommendation may be determined based on one or more factors, and may change over time (e.g., in real time) based on current operation data received regarding a plant. Illustrative examples of the one or more factors for determining the ordering of the one or more columns may include an impact on a production of the plant, an impact on an efficiency of the plant, an impact on a projected operating life of the plant, an impact on a profit or loss of the plant, an impact on one or more other assets or processes of the plant, or the like. A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.” In other words, ranking may be performed based on a factor identified as being most important.).
Laycock does not explicitly disclose wherein the performance metric is an aggregated performance metric.
Chiaramonte explains that the health state information may be determined in regard to an asset and its parts (Chiaramonte: ¶ 326 – “As shown in the example of FIG. 29, the health state processor 2905 receives asset health information 2640 from the health analytics 2620 and processes the asset health information 2640 to determine asset health level, asset life expectancy, asset durability and performance (e.g., along an asset flowpath and/or non-flowpath, etc.), etc., and provides the determined health information to the constraint analyzer 2920, which factors asset health into determining bounds or constraints by which tasks are generated to form a workscope for the target asset. For example, health state information can be provided for an asset, an asset module/part, a group of asset modules/parts, etc., to factor into task generation for the asset and/or module(s)/part(s) of the asset.”). Chiaramonte further describes an aggregate function indicative of performance and other factors related to an asset, based at least on aggregated performance metrics related to each of the parts/modules/components of the asset:
[0324] For example, a health state can be quantified using a health state transfer function, Hs, as a combination of performance, operability, and durability representing a useful remaining life of the target asset, the asset including n parts, modules, and/or components:
PNG
media_image1.png
34
206
media_image1.png
Greyscale
(Eq. 1),
where Pi represents a performance of part/module/component I, Oi represents a operability of part/module/component i, and Di represents a durability of part/module/component i, for example.
Chiaramonte provides an example in which an asset health quantifier (AHQ) is generated based on an average or weighted average of the individual AHQs of each of various sub-components of an asset (such as a fan section) and the AHQs of asset components (i.e., various assets, each consisting of sub-components) can be ranked in ascending order, descending order, by criticality, etc. (Chiaramonte: ¶ 185 – “In some examples, the health quantifier generator 410 calculates an actual AHQ of an asset component based on actual AHQ of sub-components of the asset component. For example, the health quantifier generator 410 can calculate an actual AHQ for the fan section 108 of FIG. 1 based on calculating an actual AHQ for sub-components of the fan section 108 based on the model inputs 335. For example, the health quantifier generator 410 can calculate an actual AHQ of sub-components such as a fan blade, a bearing, a speed sensor, etc., of the fan section 108 by executing the physics-based model 452 of the engine 102. In such an example, the health quantifier generator 410 can generate an actual AHQ of the fan section 108 based on calculating an average (e.g., a weighted average, etc.) of the actual AHQ of the fan blade, the bearing, the speed sensor, etc., of the fan section 108. In some examples, the health quantifier generator 410 can rank the actual AHQ of the asset components (e.g., the fan section 108, the booster compressor 114, etc.) in an ascending order, a descending order, by criticality (e.g., a quantitative measure of how critical an asset component is to a function of the engine 102, etc.), etc.”).
Additionally, Chiaramonte evaluates an AHQ for each asset in terms of various thresholds (e.g., an asset health quantifier threshold, a maintenance quantifier threshold, etc.) to determine if an asset should be scheduled for removal from service (Chiaramonte: ¶¶ 78-80).
Furthermore, as discussed in the rejection of the independent claim above, Serrano and Flood both describe how metrics may vary for different types of assets and how they may be aggregated, normalized, and used for comparison purposes.
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Laycock wherein the performance metric is an aggregated performance metric in order to improve the accuracy of the health assessments of assets (as suggested in ¶¶ 58-60 of Chiaramonte) while managing large amounts of data to identify and optimize asset management solutions that require trade-offs among various factors (such as durability, operability, performance, and financial metrics), as suggested in ¶ 310 of Chiaramonte.
[Claim 3] Laycock discloses determining an asset type of each of the plurality of assets (¶ 59 – “FIG. 5 shows a flow chart of an example method of contextual analysis mapping that may be performed by a disclosed analysis engine. In step 500, the contextual analytics mapping module and/or the analysis engine may be configured. The analysis engine may be configured to collect operational data, e.g., at a predetermined rate or at predetermined times. The analysis engine may be configured with a threshold task importance, e.g., such that tasks assigned an importance value below the threshold are not acted upon. The analysis engine may be configured with baseline measurements or values, such as default temperatures for each of specific processing equipment in a particular plant. The analysis engine may be configured with a model of a plant such that the analysis engine may compare operational data received to model plant measurements. The analysis engine may be configured with one or more rules for how tasks may be implemented.”; ¶ 73 – “ In step 504, equipment issues are determined. In step 505, recommendations to address process issues or equipment issues are determined, which may be determined based on the analysis of the operational data. A recommendation may include one or more tasks, which may correspond to one or more actions performed with respect to the plant. A task may be modifying one or more plant parameters (e.g., a burner temperature) of a plant, adding, modifying, or removing plant assets, or the like. For example, a task may be to replace a burner, alter the fuel flow to a burner, or to clean a burner. As another example, a task may be to add or remove a reactor. The task may comprise taking all or portions of the plant offline and/or shutting down the plant.” In other words, processes and equipment are evaluated in an appropriate context which is appropriate to the respective type of process and type of equipment.).
Laycock does not explicitly perform the step of generating the plurality of performance metrics for each particular asset of the plurality of assets based at least in part on the asset type corresponding to the particular asset.
Chiaramonte explains that the health state information may be determined in regard to an asset and its parts (Chiaramonte: ¶ 326 – “As shown in the example of FIG. 29, the health state processor 2905 receives asset health information 2640 from the health analytics 2620 and processes the asset health information 2640 to determine asset health level, asset life expectancy, asset durability and performance (e.g., along an asset flowpath and/or non-flowpath, etc.), etc., and provides the determined health information to the constraint analyzer 2920, which factors asset health into determining bounds or constraints by which tasks are generated to form a workscope for the target asset. For example, health state information can be provided for an asset, an asset module/part, a group of asset modules/parts, etc., to factor into task generation for the asset and/or module(s)/part(s) of the asset.”). Chiaramonte further describes an aggregate function indicative of performance and other factors related to an asset, based at least on aggregated performance metrics related to each of the parts/modules/components of the asset:
[0324] For example, a health state can be quantified using a health state transfer function, Hs, as a combination of performance, operability, and durability representing a useful remaining life of the target asset, the asset including n parts, modules, and/or components:
PNG
media_image1.png
34
206
media_image1.png
Greyscale
(Eq. 1),
where Pi represents a performance of part/module/component I, Oi represents a operability of part/module/component i, and Di represents a durability of part/module/component i, for example.
Chiaramonte provides an example in which an asset health quantifier (AHQ) is generated based on an average or weighted average of the individual AHQs of each of various sub-components of an asset (such as a fan section) and the AHQs of asset components (i.e., various assets, each consisting of sub-components) can be ranked in ascending order, descending order, by criticality, etc. (Chiaramonte: ¶ 185 – “In some examples, the health quantifier generator 410 calculates an actual AHQ of an asset component based on actual AHQ of sub-components of the asset component. For example, the health quantifier generator 410 can calculate an actual AHQ for the fan section 108 of FIG. 1 based on calculating an actual AHQ for sub-components of the fan section 108 based on the model inputs 335. For example, the health quantifier generator 410 can calculate an actual AHQ of sub-components such as a fan blade, a bearing, a speed sensor, etc., of the fan section 108 by executing the physics-based model 452 of the engine 102. In such an example, the health quantifier generator 410 can generate an actual AHQ of the fan section 108 based on calculating an average (e.g., a weighted average, etc.) of the actual AHQ of the fan blade, the bearing, the speed sensor, etc., of the fan section 108. In some examples, the health quantifier generator 410 can rank the actual AHQ of the asset components (e.g., the fan section 108, the booster compressor 114, etc.) in an ascending order, a descending order, by criticality (e.g., a quantitative measure of how critical an asset component is to a function of the engine 102, etc.), etc.”).
Additionally, Chiaramonte evaluates an AHQ for each asset in terms of various thresholds (e.g., an asset health quantifier threshold, a maintenance quantifier threshold, etc.) to determine if an asset should be scheduled for removal from service (Chiaramonte: ¶¶ 78-80).
Furthermore, as discussed in the rejection of the independent claim above, Serrano and Flood both describe how metrics may vary for different types of assets and how they may be aggregated, normalized, and used for comparison purposes.
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Laycock to perform the step of generating the plurality of performance metrics for each particular asset of the plurality of assets based at least in part on the asset type corresponding to the particular asset in order to improve the accuracy of the health assessments of assets (as suggested in ¶¶ 58-60 of Chiaramonte) while managing large amounts of data to identify and optimize asset management solutions that require trade-offs among various factors (such as durability, operability, performance, and financial metrics), as suggested in ¶ 310 of Chiaramonte.
[Claim 4] Laycock discloses determining the importance factor for each particular asset of the plurality of assets based at least in part on the asset type corresponding to the particular asset (¶ 59 – “FIG. 5 shows a flow chart of an example method of contextual analysis mapping that may be performed by a disclosed analysis engine. In step 500, the contextual analytics mapping module and/or the analysis engine may be configured. The analysis engine may be configured to collect operational data, e.g., at a predetermined rate or at predetermined times. The analysis engine may be configured with a threshold task importance, e.g., such that tasks assigned an importance value below the threshold are not acted upon. The analysis engine may be configured with baseline measurements or values, such as default temperatures for each of specific processing equipment in a particular plant. The analysis engine may be configured with a model of a plant such that the analysis engine may compare operational data received to model plant measurements. The analysis engine may be configured with one or more rules for how tasks may be implemented.”; ¶ 73 – “In step 504, equipment issues are determined. In step 505, recommendations to address process issues or equipment issues are determined, which may be determined based on the analysis of the operational data. A recommendation may include one or more tasks, which may correspond to one or more actions performed with respect to the plant. A task may be modifying one or more plant parameters (e.g., a burner temperature) of a plant, adding, modifying, or removing plant assets, or the like. For example, a task may be to replace a burner, alter the fuel flow to a burner, or to clean a burner. As another example, a task may be to add or remove a reactor. The task may comprise taking all or portions of the plant offline and/or shutting down the plant.” In other words, processes and equipment are evaluated in an appropriate context which is appropriate to the respective type of process and type of equipment.).
[Claim 5] Laycock discloses identifying the particular poor-performance asset from the plurality of assets based at least in part on the ranking (¶ 10 – “2. a second listing of worst performing ones of the processing equipment (e.g., with the top ranked processing equipment parameter problem based on a deviation from the model, excursions of limits, or change in processing equipment health or from machine learning of past actions) that when a selected poor performing one of the processing equipment is chosen by the user generates a ranked filtered view of suspected ones of the process parameters that may be affected by the selected poor performing processing equipment along with a filtered view of second recommendations for aiding the user to recognize what action to do in order to fix the selected poor performing processing equipment and at least one of the suspected ones of the process parameters (e.g., to return the plant to an optimal state of production).”); and
determining at least one poor performance factor for the particular poor-performing asset based at least in part on the plurality of normalized performance metrics associated with the particular poor-performance asset (¶ 81 – “A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.”; ¶ 82 – “The graphical user interface may include one or more indications of a health of a process or asset. For example, a visualization related to a process or asset may display a first color to indicate a first health level, a second color to indicate a second health level, a third color to indicate a third health level, and the like. For example, if a process or asset is operating smoothly and within normal operating thresholds, the visualization may show a first color in connection with the process or asset. If the process or asset has a minor issue (e.g., between a first threshold and a second threshold), the visualization may show a second color in connection with the process or asset. If the process or asset has a major issue (e.g., out of bounds beyond the second threshold), the visualization may show a third color in connection with the process or asset. Thus, one or more elements (e.g., color) of the visualization may indicate whether a process or asset is running smoothly (e.g., a within normal operating threshold).” A level of performance is determined relative to a threshold of normal operations for a particular asset, which is an example of evaluating a normalized performance of each asset.; ¶ 50 – “The asset health platform 433 may be configured to collect information about the health of various plant assets, such as equipment. For example, the asset health platform 433 may monitor wear and tear on a periodically replaced component in a plant, such as a nozzle. The asset health platform 433 may be connected to one or more sensors on plant assets and/or may estimate asset health based on, for example, a depreciation schedule.”; ¶ 83 – “Thus, the graphical user interface may filter lists of recommendations, processes, and assets to display recommendations, processes, and assets that are related to a selected recommendation, process, or asset.” As seen in ¶¶ 50 and 83, multiple assets may be monitored.).
[Claim 6] Laycock does not explicitly disclose:
generating a second ranking of the plurality of normalized performance metrics associated with the particular poor-performing asset, wherein the second ranking of the plurality of normalized performance metrics indicates a degree of difference between each normalized performance metric from a reference value corresponding to the performance metric; and
determining the at least one poor performance factor based at least in part on the second ranking of the plurality of normalized performance metrics.
Chiaramonte explains that the health state information may be determined in regard to an asset and its parts (Chiaramonte: ¶ 326 – “As shown in the example of FIG. 29, the health state processor 2905 receives asset health information 2640 from the health analytics 2620 and processes the asset health information 2640 to determine asset health level, asset life expectancy, asset durability and performance (e.g., along an asset flowpath and/or non-flowpath, etc.), etc., and provides the determined health information to the constraint analyzer 2920, which factors asset health into determining bounds or constraints by which tasks are generated to form a workscope for the target asset. For example, health state information can be provided for an asset, an asset module/part, a group of asset modules/parts, etc., to factor into task generation for the asset and/or module(s)/part(s) of the asset.”). Chiaramonte further describes an aggregate function indicative of performance and other factors related to an asset, based at least on aggregated performance metrics related to each of the parts/modules/components of the asset:
[0324] For example, a health state can be quantified using a health state transfer function, Hs, as a combination of performance, operability, and durability representing a useful remaining life of the target asset, the asset including n parts, modules, and/or components:
PNG
media_image1.png
34
206
media_image1.png
Greyscale
(Eq. 1),
where Pi represents a performance of part/module/component I, Oi represents a operability of part/module/component i, and Di represents a durability of part/module/component i, for example.
Chiaramonte provides an example in which an asset health quantifier (AHQ) is generated based on an average or weighted average of the individual AHQs of each of various sub-components of an asset (such as a fan section) and the AHQs of asset components (i.e., various assets, each consisting of sub-components) can be ranked in ascending order, descending order, by criticality, etc. (Chiaramonte: ¶ 185 – “In some examples, the health quantifier generator 410 calculates an actual AHQ of an asset component based on actual AHQ of sub-components of the asset component. For example, the health quantifier generator 410 can calculate an actual AHQ for the fan section 108 of FIG. 1 based on calculating an actual AHQ for sub-components of the fan section 108 based on the model inputs 335. For example, the health quantifier generator 410 can calculate an actual AHQ of sub-components such as a fan blade, a bearing, a speed sensor, etc., of the fan section 108 by executing the physics-based model 452 of the engine 102. In such an example, the health quantifier generator 410 can generate an actual AHQ of the fan section 108 based on calculating an average (e.g., a weighted average, etc.) of the actual AHQ of the fan blade, the bearing, the speed sensor, etc., of the fan section 108. In some examples, the health quantifier generator 410 can rank the actual AHQ of the asset components (e.g., the fan section 108, the booster compressor 114, etc.) in an ascending order, a descending order, by criticality (e.g., a quantitative measure of how critical an asset component is to a function of the engine 102, etc.), etc.”).
Additionally, Chiaramonte evaluates an AHQ for each asset in terms of various thresholds (e.g., an asset health quantifier threshold, a maintenance quantifier threshold, etc.) to determine if an asset should be scheduled for removal from service (Chiaramonte: ¶¶ 78-80).
Furthermore, as discussed in the rejection of the independent claim above, Serrano and Flood both describe how metrics may vary for different types of assets and how they may be aggregated, normalized, and used for comparison purposes.
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Laycock to perform the following steps:
generating a second ranking of the plurality of normalized performance metrics associated with the particular poor-performing asset, wherein the second ranking of the plurality of normalized performance metrics indicates a degree of difference between each normalized performance metric from a reference value corresponding to the performance metric; and
determining the at least one poor performance factor based at least in part on the second ranking of the plurality of normalized performance metrics
in order to improve the accuracy of the health assessments of assets (as suggested in ¶¶ 58-60 of Chiaramonte) while managing large amounts of data to identify and optimize asset management solutions that require trade-offs among various factors (such as durability, operability, performance, and financial metrics), as suggested in ¶ 310 of Chiaramonte.
[Claim 7] Laycock discloses determining at least one poor performance factor for the particular poor-performing asset based a comparison between one or more predetermined thresholds and at least one performance metric of the plurality of performance metrics associated with the particular poor-performance asset (¶ 81 – “A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.”; ¶ 82 – “The graphical user interface may include one or more indications of a health of a process or asset. For example, a visualization related to a process or asset may display a first color to indicate a first health level, a second color to indicate a second health level, a third color to indicate a third health level, and the like. For example, if a process or asset is operating smoothly and within normal operating thresholds, the visualization may show a first color in connection with the process or asset. If the process or asset has a minor issue (e.g., between a first threshold and a second threshold), the visualization may show a second color in connection with the process or asset. If the process or asset has a major issue (e.g., out of bounds beyond the second threshold), the visualization may show a third color in connection with the process or asset. Thus, one or more elements (e.g., color) of the visualization may indicate whether a process or asset is running smoothly (e.g., a within normal operating threshold).” A level of performance is determined relative to a threshold of normal operations for a particular asset, which is an example of evaluating a normalized performance of each asset.; ¶ 50 – “The asset health platform 433 may be configured to collect information about the health of various plant assets, such as equipment. For example, the asset health platform 433 may monitor wear and tear on a periodically replaced component in a plant, such as a nozzle. The asset health platform 433 may be connected to one or more sensors on plant assets and/or may estimate asset health based on, for example, a depreciation schedule.”; ¶ 83 – “Thus, the graphical user interface may filter lists of recommendations, processes, and assets to display recommendations, processes, and assets that are related to a selected recommendation, process, or asset.” As seen in ¶¶ 50 and 83, multiple assets may be monitored.).
[Claim 8] Laycock discloses adjusting the one or more predetermined thresholds based at least in part on at least one of a downtime metric, a criticality metric, a cost metric, or other user-inputted metric (¶ 10 – Poorly performing processes and assets/equipment are identified for remedial action.; ¶ 8 – “Disclosed aspects include methods, computing devices, and systems for collecting plant operational data, analyzing the plant operational data, determining tasks based on the analysis, and implementing such tasks (e.g., automatically adjusting plant processing equipment operating parameters). An analysis engine receives, from one or more devices in a plant, operational data. The operational data may comprise one or more alarms or warnings. The operational data may comprise information regarding plant profit and/or loss, equipment, chemical processes, workforce performance, automation system performance, safety system performance, and/or cybersecurity performance. The analysis engine analyzes the operational data to determine, e.g., one or more correlations. For example, the analysis engine may determine a root cause of a problem associated with the operational data being outside a specification.”; ¶ 73 – “ In step 504, equipment issues are determined. In step 505, recommendations to address process issues or equipment issues are determined, which may be determined based on the analysis of the operational data. A recommendation may include one or more tasks, which may correspond to one or more actions performed with respect to the plant. A task may be modifying one or more plant parameters (e.g., a burner temperature) of a plant, adding, modifying, or removing plant assets, or the like. For example, a task may be to replace a burner, alter the fuel flow to a burner, or to clean a burner. As another example, a task may be to add or remove a reactor. The task may comprise taking all or portions of the plant offline and/or shutting down the plant.”; fig. 6A; ¶ 81 – “The graphical user interface may depict a most important process issue at the top of the column of process issues. The graphical user interface may depict a most important asset issue at the top of the column of asset issues. The graphical user interface may depict a most important recommendation at the top of the column of recommendations. The most important process issue, asset issue, and/or recommendation may be determined based on one or more factors, and may change over time (e.g., in real time) based on current operation data received regarding a plant. Illustrative examples of the one or more factors for determining the ordering of the one or more columns may include an impact on a production of the plant, an impact on an efficiency of the plant, an impact on a projected operating life of the plant, an impact on a profit or loss of the plant, an impact on one or more other assets or processes of the plant, or the like. A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.”).
[Claim 9] Laycock discloses generating, using a machine learning model and the at least one poor performance factor, at least one recommended mitigation action associated with the particular poor-performing asset (¶ 43 – “The analysis engine 416 processes and/or analyzes operational data. For example, the analysis engine 416 may be configured to execute code that compares operational data to threshold values and/or predetermined ranges. Machine learning algorithms may be used to process and/or interpret the operational data. For example, the analysis engine 416 may store and use historical operational data to teach a machine-learning algorithm acceptable ranges for operational data, and new operational data may be input into the machine learning algorithm to determine if an undesirable plant condition exists. Manual review by experts may be performed to process and/or interpret the operational data. For example, a certain range operational data (e.g., unexpectedly high temperature values) may involve manual review by an expert (e.g., a plant employee) using a user interface coupled to a computing device associated with the analysis engine 416.”).
[Claim 10] Laycock discloses wherein the machine learning model is a decision tree (figs. 4, 5; ¶¶ 43, 53-55 – Machine learning and a fault tree may be used.).
[Claim 11] Laycock discloses automatically performing the at least one recommended mitigation action by automatically adjusting one or more operational parameters of the particular poor-performance asset (¶ 10 – Poorly performing processes and assets/equipment are identified for remedial action.; ¶ 8 – “Disclosed aspects include methods, computing devices, and systems for collecting plant operational data, analyzing the plant operational data, determining tasks based on the analysis, and implementing such tasks (e.g., automatically adjusting plant processing equipment operating parameters). An analysis engine receives, from one or more devices in a plant, operational data. The operational data may comprise one or more alarms or warnings. The operational data may comprise information regarding plant profit and/or loss, equipment, chemical processes, workforce performance, automation system performance, safety system performance, and/or cybersecurity performance. The analysis engine analyzes the operational data to determine, e.g., one or more correlations. For example, the analysis engine may determine a root cause of a problem associated with the operational data being outside a specification.”; ¶ 73 – “ In step 504, equipment issues are determined. In step 505, recommendations to address process issues or equipment issues are determined, which may be determined based on the analysis of the operational data. A recommendation may include one or more tasks, which may correspond to one or more actions performed with respect to the plant. A task may be modifying one or more plant parameters (e.g., a burner temperature) of a plant, adding, modifying, or removing plant assets, or the like. For example, a task may be to replace a burner, alter the fuel flow to a burner, or to clean a burner. As another example, a task may be to add or remove a reactor. The task may comprise taking all or portions of the plant offline and/or shutting down the plant.”; fig. 6A; ¶ 81 – “The graphical user interface may depict a most important process issue at the top of the column of process issues. The graphical user interface may depict a most important asset issue at the top of the column of asset issues. The graphical user interface may depict a most important recommendation at the top of the column of recommendations. The most important process issue, asset issue, and/or recommendation may be determined based on one or more factors, and may change over time (e.g., in real time) based on current operation data received regarding a plant. Illustrative examples of the one or more factors for determining the ordering of the one or more columns may include an impact on a production of the plant, an impact on an efficiency of the plant, an impact on a projected operating life of the plant, an impact on a profit or loss of the plant, an impact on one or more other assets or processes of the plant, or the like. A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.”).
[Claim 12] Claim 12 recites limitations already addressed by the rejection of claim 1 above; therefore, the same rejection applies. Furthermore, Laycock and Chiaramonte each disclose a computing apparatus comprising at least one processor and at least one non-transitory memory having computer-coded instructions stored thereon, the computer coded instructions configured to, in execution with the at least one processor, cause the apparatus to perform the respectively disclosed operations (Laycock: ¶¶ 42, 77; Chiaramonte: ¶¶ 60, 63, 170, 198-200, 286, 288, 294, 302, 337, 338, 359, 417).
[Claim 13] Laycock discloses wherein an ordering of the plurality of assets in the ranking indicates poor-performing assets (¶ 10 – “2. a second listing of worst performing ones of the processing equipment (e.g., with the top ranked processing equipment parameter problem based on a deviation from the model, excursions of limits, or change in processing equipment health or from machine learning of past actions) that when a selected poor performing one of the processing equipment is chosen by the user generates a ranked filtered view of suspected ones of the process parameters that may be affected by the selected poor performing processing equipment along with a filtered view of second recommendations for aiding the user to recognize what action to do in order to fix the selected poor performing processing equipment and at least one of the suspected ones of the process parameters (e.g., to return the plant to an optimal state of production).”).
[Claim 14] Laycock discloses wherein top-ranked entries of the ranking indicate poorest-performing assets (¶ 10 – “2. a second listing of worst performing ones of the processing equipment (e.g., with the top ranked processing equipment parameter problem based on a deviation from the model, excursions of limits, or change in processing equipment health or from machine learning of past actions) that when a selected poor performing one of the processing equipment is chosen by the user generates a ranked filtered view of suspected ones of the process parameters that may be affected by the selected poor performing processing equipment along with a filtered view of second recommendations for aiding the user to recognize what action to do in order to fix the selected poor performing processing equipment and at least one of the suspected ones of the process parameters (e.g., to return the plant to an optimal state of production).”)
[Claim 15] Laycock does not explicitly disclose wherein the aggregated performance metric is an average performance metric.
Chiaramonte explains that the health state information may be determined in regard to an asset and its parts (Chiaramonte: ¶ 326 – “As shown in the example of FIG. 29, the health state processor 2905 receives asset health information 2640 from the health analytics 2620 and processes the asset health information 2640 to determine asset health level, asset life expectancy, asset durability and performance (e.g., along an asset flowpath and/or non-flowpath, etc.), etc., and provides the determined health information to the constraint analyzer 2920, which factors asset health into determining bounds or constraints by which tasks are generated to form a workscope for the target asset. For example, health state information can be provided for an asset, an asset module/part, a group of asset modules/parts, etc., to factor into task generation for the asset and/or module(s)/part(s) of the asset.”). Chiaramonte further describes an aggregate function indicative of performance and other factors related to an asset, based at least on aggregated performance metrics related to each of the parts/modules/components of the asset:
[0324] For example, a health state can be quantified using a health state transfer function, Hs, as a combination of performance, operability, and durability representing a useful remaining life of the target asset, the asset including n parts, modules, and/or components:
PNG
media_image1.png
34
206
media_image1.png
Greyscale
(Eq. 1),
where Pi represents a performance of part/module/component I, Oi represents a operability of part/module/component i, and Di represents a durability of part/module/component i, for example.
Chiaramonte provides an example in which an asset health quantifier (AHQ) is generated based on an average or weighted average of the individual AHQs of each of various sub-components of an asset (such as a fan section) and the AHQs of asset components (i.e., various assets, each consisting of sub-components) can be ranked in ascending order, descending order, by criticality, etc. (Chiaramonte: ¶ 185 – “In some examples, the health quantifier generator 410 calculates an actual AHQ of an asset component based on actual AHQ of sub-components of the asset component. For example, the health quantifier generator 410 can calculate an actual AHQ for the fan section 108 of FIG. 1 based on calculating an actual AHQ for sub-components of the fan section 108 based on the model inputs 335. For example, the health quantifier generator 410 can calculate an actual AHQ of sub-components such as a fan blade, a bearing, a speed sensor, etc., of the fan section 108 by executing the physics-based model 452 of the engine 102. In such an example, the health quantifier generator 410 can generate an actual AHQ of the fan section 108 based on calculating an average (e.g., a weighted average, etc.) of the actual AHQ of the fan blade, the bearing, the speed sensor, etc., of the fan section 108. In some examples, the health quantifier generator 410 can rank the actual AHQ of the asset components (e.g., the fan section 108, the booster compressor 114, etc.) in an ascending order, a descending order, by criticality (e.g., a quantitative measure of how critical an asset component is to a function of the engine 102, etc.), etc.”).
Additionally, Chiaramonte evaluates an AHQ for each asset in terms of various thresholds (e.g., an asset health quantifier threshold, a maintenance quantifier threshold, etc.) to determine if an asset should be scheduled for removal from service (Chiaramonte: ¶¶ 78-80).
Furthermore, as discussed in the rejection of the independent claim above, Serrano and Flood both describe how metrics may vary for different types of assets and how they may be aggregated, normalized, and used for comparison purposes.
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Laycock wherein the aggregated performance metric is an average performance metric in order to improve the accuracy of the health assessments of assets (as suggested in ¶¶ 58-60 of Chiaramonte) while managing large amounts of data to identify and optimize asset management solutions that require trade-offs among various factors (such as durability, operability, performance, and financial metrics), as suggested in ¶ 310 of Chiaramonte.
[Claim 16] Laycock discloses wherein the one or more processors are further configured to: identify one or more poor-performing assets based at least in part on the ranking (¶¶ 42, 77 – processor; ¶ 81 – “A process or asset might be having an issue that is seemingly small (e.g., is only operating slightly out of bounds), but that has a large impact on a combination of variables, while a different process or asset might be having an issue that is seemingly large (e.g., is operating far out of bounds), but that has only a small impact on the combination of variables, and therefore the process or asset that is only slightly out of bounds might be shown higher in the column relative to the process or asset that is operating far out of bounds.”; ¶ 82 – “The graphical user interface may include one or more indications of a health of a process or asset. For example, a visualization related to a process or asset may display a first color to indicate a first health level, a second color to indicate a second health level, a third color to indicate a third health level, and the like. For example, if a process or asset is operating smoothly and within normal operating thresholds, the visualization may show a first color in connection with the process or asset. If the process or asset has a minor issue (e.g., between a first threshold and a second threshold), the visualization may show a second color in connection with the process or asset. If the process or asset has a major issue (e.g., out of bounds beyond the second threshold), the visualization may show a third color in connection with the process or asset. Thus, one or more elements (e.g., color) of the visualization may indicate whether a process or asset is running smoothly (e.g., a within normal operating threshold).” A level of performance is determined relative to a threshold of normal operations for a particular asset, which is an example of evaluating a normalized performance of each asset.; ¶ 50 – “The asset health platform 433 may be configured to collect information about the health of various plant assets, such as equipment. For example, the asset health platform 433 may monitor wear and tear on a periodically replaced component in a plant, such as a nozzle. The asset health platform 433 may be connected to one or more sensors on plant assets and/or may estimate asset health based on, for example, a depreciation schedule.”; ¶ 83 – “Thus, the graphical user interface may filter lists of recommendations, processes, and assets to display recommendations, processes, and assets that are related to a selected recommendation, process, or asset.” As seen in ¶¶ 50 and 83, multiple assets may be monitored.).
.
[Claim 17] Laycock discloses wherein the one or more processors (¶¶ 42, 77 – processor) are further configured to: provide the user interface to at least one computing device (¶¶ 10-11, 82).
[Claim 18] Laycock discloses wherein the user interface comprises at least one poor performance factor for at least one of the plurality of assets in the ranking (fig. 6A, ¶¶ 10-11, 79, 82 – Rankings of poorly performing process parameters and of poorly performing assets may be presented on a display device via a GUI.)
[Claim 19] Laycock discloses wherein the user interface further comprises at least one recommended action for mitigation of the at least one of the plurality of assets (fig. 6A; ¶ 79 – “FIG. 6A depicts an illustrative graphical user interface 600 that may include one or more visualizations depicting one or more process issues, asset issues, and/or recommendations related to the process issues and/or asset issues.”).
[Claim 20] Claim 20 recites limitations already addressed by the rejection of claim 1 above; therefore, the same rejection applies. Furthermore, Laycock and Chiaramonte each disclose a computer program product comprising at least one non-transitory, computer-readable storage medium including instructions that, upon execution by at least one processor, configure the computer program product to perform the respectively disclosed operations (Laycock: ¶¶ 42, 77; Chiaramonte: ¶¶ 60, 63, 170, 198-200, 286, 288, 294, 302, 337, 338, 359, 417).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUSANNA M DIAZ whose telephone number is (571)272-6733. The examiner can normally be reached M-F, 8 am-4:30 pm.
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, Brian Epstein can be reached at (571) 270-5389. 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.
/SUSANNA M. DIAZ/
Primary Examiner
Art Unit 3625A