DETAILED ACTION
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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 12/12/2018 and 9/26/2019 were in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
Claims 1 and 21 are amended and claims 2, 6, and 20 are cancelled. Claims 1, 3-5, 7-19, and 21-22 are pending.
Response to Arguments
Applicant's arguments filed 2/5/2026 have been fully considered.
Regarding the objection to claim 1, and as noted by Applicant on pages 1-2 of the Remarks, claim 21 is amended to overcome the objection, which is withdrawn.
Regarding the rejection of claim 20 under 112(b), and as noted by Applicant on page 2 of the Remarks, claim 20 is cancelled such that the rejection is rendered moot and is withdrawn.
Regarding the rejections of independent claims 1 and 21 under 101, Applicant’s assertion on pages 3-6 that the amended claims overcome the rejections are found unpersuasive for the following reasons.
Regarding Step 2A Prong 1, Applicant contends on pages 3-4 of the response that claim 1 does not recite an abstract idea. In support, on page 3 Applicant notes that claim 1 is amended to recited “… automatically acquiring operational data …” and “receiving entry of field inspection data …” such that claims 1 and 21 are directed to more than mental processes.
Examiner acknowledges that the foregoing elements added/recharacterized by amendment do not fall within the abstract idea exception and furthermore, as asserted by Applicant, constitute affirmative limitations on the structure/function of the method/system in claims 1 and 21. However, and as explained in the current grounds of rejection, these elements, considered individually and in combination with the other elements of the claim, appear to represent relatively high-level data collection having no particularized functional relation to the steps falling within the abstract idea and therefore constitute extra solution activity that fails to integrate the judicial exception into a practical application or result in the claim as a whole amounting to significantly more than the judicial exception. Examiner therefore respectfully disagrees with Applicant’s contention on page 4 of the response that claims 1 and 21 are not “directed to” an abstract idea. Examiner notes that whether a claim is directed to an abstract idea is related to but distinct from the initial inquiry of whether the claim recites (rather than merely involves) an abstract idea. Applicant’s arguments on pages 3-4 do not clearly address the elements that have been found to fall within (recite) the abstract idea (e.g., why “generate” “an end-of-run prediction for the item based on the operational data and the field inspection data received via the one or more data collection interfaces” and “determine a maintenance recommendation based on the generated end-of-run prediction, wherein the maintenance recommendation is optimized for a plurality of interconnected equipment including the item” may not, individually or in combination, be performed as mental processes.
Regarding Step 2A Prong 2, Applicant contends on pages 4-5 of the response that claim 1 as a whole integrates any asserted judicial exception into a practical application. In support, Applicant asserts on pages 4-5 that the steps of “automatically acquiring operational data … using at least one sensor …” and “receiving entry of field inspection data … into a graphical user interface (GUI) …” clearly tie the claimed method to the manner in which the operational data and field inspection data are obtained.
Examiner acknowledges that the foregoing elements recited a manner for obtaining operational and field inspection data. However, Examiner submits that such manner is recited at a high-level having no particularized relation to the key elements falling within the judicial exception, such that an integration of the judicial exception into a practical application in terms of improvement to a technical field or use of a particular machine is not evident. Instead, the foregoing additional elements appear to merely link the abstract idea to field of application.
On page 5 of the response, Applicant asserts that the ability to acquire data by different means (via sensor and GUI entry) improves the functionality of the associated system in general by making the system more flexible and comprehensive. Applicant further notes on page 5 that Applicant’s specification discloses advantages of the system including the ability to accurately project into the future and predict and plan for end of run for components/equipment as well as the ability to adapt and change predictions and maintenance planning based on ongoing operational data and field-inspected data.
Regarding improved functionality, Examiner submits that no improvement in functionality of the system itself (computer system) that implements the method appears evident. Instead, the process appears fundamentally characterized by using data interfaces to receive input data via various input sources and using processing resources to implement steps to perform processing functions that fall within the judicial exception.
Regarding advantages cited in Applicant’s specification, Examiner notes that such advantages are described in a generalized manner and appear largely derived from the steps falling within the judicial exception without any significant contribution by the combination of the additional elements. While as noted by Applicant on page 5, use of automated sensor data acquisition and acquisition of input via GUI may have utility in terms of implementation of the overall method, the acquisition of data via a sensor and additional information via GUI entry even in combination with the other elements of the claim do not appear to result in an improvement to a technical field or use of a particular machine for implementing the judicial exception.
Regarding Step 2B, Applicant contends on page 6 of the response that the amendments to claims 1 and 21 capture aspects of an inventive concept.
Examiner submits that, as explained in the grounds for rejecting claims 1 and 21 under 103, neither of claims 1 and 21 include an inventive concept, such that the “inventive concept” consideration for Step 2B is inapplicable in this case.
Regarding dependent claims 9-12, Examiner has reconsidered the grounds for rejecting claims 9-12 under 101 based on the entirety of the content of the claims including the content modified by amendment to claim 1. Specifically, Examiner finds that the method as characterized by the combined elements of amended claim 1 and as further modified by the limitation in claim 9 that the “equipment,” with respect to which the operational data and field inspection data are gathered in the manner recited and in which the data is processed according the recited method, “comprises a slurry pump and the item comprises at least one component of the slurry pump” results in the claim overall integrating the judicial exception into a practical application in terms of improvement in the field of slurry pump condition monitoring.
Therefore, the rejections of claims 9-12 under 101 are withdrawn.
Regarding the rejections of independent claims 1 and 21 under 103, Examiner respectfully disagrees with Applicant’s arguments on page 8 of the Remarks, that the amendments overcome the prior art references applied in the 103 rejections.
On page 8 of the Remarks, Applicant contends that Ni is silent regarding and therefore does not teach a maintenance recommendation that “is optimized for a plurality of interconnected equipment including the item.”
Examiner submits, as set forth in the current grounds of rejections, that Ni teaches wherein the maintenance recommendation is optimized (FIG. 9 blocks 904 and 906, [0140] maintenance determination is based on a determined remaining useful life and is therefore “optimized” with respect to for example pre-scheduled maintenance intervals described in the Background in [0004]) for a plurality of interconnected equipment including the item (FIG. 9 blocks 900 an 902 sensor information collected and processed for an overall “platform” that per block 904 includes at least one component for which a remaining useful life is determined and utilized for subsequent maintenance determination per block 906 and [0140] (inferring a multi-component, interconnected platform); [0050] platform information obtain for rotorcraft (multi-component, interconnected platform).
The rejections of independent claims 1 and 21 under 103 as being unpatentable over Ni in view of Horton, and in further view of McNab are therefore maintained.
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, 3-5, and 7-8, 13-19, and 21-22 are rejected under 35 U.S.C. 101 because the claimed invention in each of these claims is directed to the abstract idea judicial exception without significantly more.
Independent claim 21, substantially representative also of independent claim 1, recites:
“[a]n equipment monitoring and maintaining system, comprising:
at least one sensor device configured to automatically acquire operational data for an item comprising the equipment or a component of the equipment while the at least one sensor device is monitoring the operation of the item, wherein the operational data comprises at least one value indicative of performance of the item;
a computing device comprising an application having a graphical user interface (GUI) configured to receive entry of field inspection data for the item, wherein the field inspection data comprises at least one measurement indicative of wear of the item;
one or more processors communicatively coupled, via one or more data collection interfaces, to the at least one sensor device, and the application; and
memory, the memory storing computer executable instructions that, when executed by the one or more processors, cause the system to:
receive, via the one or more data collection interfaces, the operational data
and the field inspection data;
obtain a trained model for the item, the model having been trained using a training dataset comprising historical operational data corresponding to a type of the equipment, and historical wear data acquired by inspecting the corresponding type of the equipment and/or a type of the component;
generate, using the trained model, an end-of-run prediction for the item based on the operational data and the field inspection data received via the one or more data collection interfaces;
determine a maintenance recommendation based on the generated end-of-run prediction, wherein the maintenance recommendation is optimized for a plurality of interconnected equipment including the item; and
generate, via an output device, an output based on one or more of the generated end-of-run prediction and the determined maintenance recommendation.”
The claim limitations considered to fall within in the abstract idea are highlighted in bold font above and the remaining features are “additional elements.”
Step 1 of the subject matter eligibility analysis entails determining whether the claimed subject matter falls within one of the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: process, machine, manufacture, or composition of matter. Claim 21 recites a system, claim 1 recites a method, and claims 20 recites an apparatus, and therefore each falls within a statutory category.
Step 2A, Prong One of the analysis entails determining whether the claim recites a judicial exception such as an abstract idea. Under a broadest reasonable interpretation, the highlighted portions of claim 21 fall within the abstract idea judicial exception. Specifically, under the 2019 Revised Patent Subject Matter Eligibility Guidance, the highlighted subject matter falls within the mental processes category (including an observation, evaluation, judgment, opinion). MPEP § 2106.04(a)(2).
The recited functions, “generate” “an end-of-run prediction for the item based on the operational data and the field inspection data received via the one or more data collection interfaces,” “determine a maintenance recommendation based on the generated end-of-run prediction,” and “wherein the maintenance recommendation is optimized for a plurality of interconnected equipment including the item” may be performed as mental processes.
Generating an end-of-run prediction for an item based on operational and field inspection data for the item based on data received via data collection interfaces may be performed via mental processes (e.g., evaluate operational and inspection data to determine, via judgement an end-of-run prediction). Determining a maintenance recommendation based on the generated end-of-run prediction may also be performed via mental processes (e.g., evaluating end-of-run prediction to determine via judgment/opinion a maintenance option). Optimizing the maintenance recommendation for a plurality of interconnected equipment including the item is part of the maintenance determination and may also be performed via mental processes (e.g., evaluating end-of-run prediction for at least one component in an interconnected equipment to determine via judgment/opinion an optimized maintenance option).
Step 2A, Prong Two of the analysis entails determining whether the claim includes additional elements that integrate the recited judicial exception into a practical application. “A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception” (MPEP § 2106.04(d)).
MPEP § 2106.04(d) sets forth considerations to be applied in Step 2A, Prong Two for determining whether or not a claim integrates a judicial exception into a practical application. Based on the individual and collective limitations of claim 21 and applying a broadest reasonable interpretation, the most applicable of such considerations appear to include: improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)); applying the judicial exception with, or by use of, a particular machine (MPEP 2106.05(b)); and effecting a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)).
Regarding improvements to the functioning of a computer or other technology, none of the “additional elements” including,
“at least one sensor device configured to automatically acquire operational data for an item comprising the equipment or a component of the equipment while the at least one sensor device is monitoring the operation of the item, wherein the operational data comprises at least one value indicative of performance of the item,” “a computing device comprising an application having a graphical user interface (GUI) configured to receive entry of field inspection data for the item, wherein the field inspection data comprises at least one measurement indicative of wear of the item,” “one or more processors communicatively coupled, via one or more data collection interfaces, to the at least one sensor device, and the application,” “memory storing computer executable instructions,” “receive, via the one or more data collection interfaces, the operational data and the field inspection data,” “obtain a trained model for the item, the model having been trained using a training dataset comprising historical operational data corresponding to a type of the equipment, and historical wear data acquired by inspecting the corresponding type of the equipment and/or a type of the component,” “using the trained model” to generate an end-of-run prediction, and “generate, via the output device, an output based on one or more of the generated end-of-run prediction and the determined maintenance recommendation,” in any combination appear to integrate the abstract idea in a manner that technologically improves any aspect of a device or system that may be used to implement the highlighted step or a device for implementing the highlighted step such as a generic computer. Instead, these elements represent routine, conventional data collection and data processing functions, including receiving input data “via the one or more data collection interfaces” that may have different sources (e.g., originating from sensors and from GUI entry), data modeling, and outputting of the processing results, recited at a high level of generality, and therefore constitute insignificant extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Using a sensor device to automatically acquire operational data for an item comprising the equipment or a component of the equipment while the at least one sensor device is monitoring the operation including performance of the item represents high-level data collection using a generalized means and functional manner having no particularized functional relation to the steps falling within the judicial exception such as in a manner constituting an improvement in a technical field, such that this element constitutes insignificant extra solution activity.
Examiner notes that “a graphical user interface (GUI) configured to receive entry of field inspection data,” conveys no particularized GUI configuration – virtually any typical GUI is configured to receive any of a variety of types of user-input data such as inspection data. Regarding “the model having been trained using a training dataset comprising historical operational data corresponding to a type of the equipment, and historical wear data acquired by inspecting the corresponding type of the equipment and/or a type of the component,” Examiner notes that this element is not positively recited as structural/functional limitations of the claimed “system,” and only limits the scope of the claim in terms of the nature/source of the data and model and therefore is not, as a function, part of the “additional elements.”
Regarding application of the judicial exception with, or by use of, a particular machine, the additional elements “obtain a trained model for the item, the model having been trained using a training dataset comprising historical operational data corresponding to a type of the equipment, and historical wear data acquired by inspecting the corresponding type of the equipment and/or a type of the component,” and “generate, using the trained model, an end-of-run prediction for the item based on the operational data and the field inspection data received via the one or more data collection interfaces” are configured and implemented in a conventional (using a model trained/configured for the general application for which it has been trained (the training performed apart from the claimed “system” as noted above) using historical operations and wear data (generalized modeling configuration using facially relevant factors such as past operations/wear) rather than a particularized manner of implementing wear/health monitoring of equipment. Again, the Examiner notes that claim 21 does not appear to positively recite that the system is configured to train a model. Instead, the claim recites to “obtain” a trained model, which based on the claim language may have been trained using the historical operational data and wear data independently of the method implemented by the system. Therefore, this additional element appears to amount to simply obtaining a model that happens to have been trained using the historical operational and wear data, which does not characterize any particularized machine implementation. The feature “use the trained model” to generate an end-of-run prediction for the item using current or post service field inspection data for the item, is recited at a high-level of generality in terms of model usage such that the model merely constitutes instructions for implementing the abstract idea.
Regarding a transformation or reduction of a particular article to a different state or thing, claim 21 does not include any such transformation or reduction. Instead, claim 21 as a whole entails receiving input information (e.g., sensor-originated operational data, GUI-entered field inspection data, and trained model), applying standard processing techniques (e.g., execution of trained model) to the information to obtain and deduce equipment condition information such as “end-of-run” with the additional elements failing to provide a meaningful integration of the abstract idea (determining end-of-run based on operation data and field inspection data and determine maintenance recommendation based on the end-of-run) in an application that transforms an article to a different state. Instead, the additional elements represent extra-solution activity that does not integrate the judicial exception into a practical application. In view of the various considerations encompassed by the Step 2A, Prong Two analysis, claim 21 does not include additional elements that integrate the recited abstract idea into a practical application.
Therefore, claim 21 is directed to a judicial exception and requires further analysis under Step 2B.
Regarding Step 2B, and as explained in the Step 2A Prong Two analysis, the additional elements constitute extra solution activity and therefore fail to result in the claim as a whole amounting to significantly more than the judicial exception. Furthermore, the additional elements in claim 21 appear to be generic and well understood as evidenced by the disclosures of Ni (US 2022/0398550 A1), Zhang (US 2019/0384257 A1), and Ristovski (US 2019/0235484 A1), each of which teach virtually the same data collection and processing environment for implementing equipment monitoring and maintenance determinations.
As explained in the grounds for rejecting claim 21 under 103, Ni teaches “at least one sensor device configured to automatically acquire operational data for an item comprising the equipment or a component of the equipment while the at least one sensor device is monitoring the operation of the item, wherein the operational data comprises at least one value indicative of performance of the item,” “a computing device comprising an application having a graphical user interface (GUI),” “one or more processors communicatively coupled, via one or more data collection interfaces, to the at least one sensor device, and the application,” “memory storing computer executable instructions,” “receive, via the one or more data collection interfaces, the operational data and the field inspection data,” “obtain a trained model for the item, the model having been trained using a training dataset comprising historical operational data corresponding to a type of the equipment, and historical wear data acquired by inspecting the corresponding type of the equipment and/or a type of the component,” “using the trained model” to generate an end-of-run prediction, and “generate, via the output device, an output based on one or more of the generated end-of-run prediction and the determined maintenance recommendation.” Zhang and Ristovski teach this same data collection and processing context (Zhang: obtain model generated/trained using historical operational and failure event data (Abstract, [0036]-[0039], [0041]-[0042], [0056]); using sensors to collect data (FIG. 1 block 110, FIG. 3 block 310), using a computer system to perform training and data analysis including maintenance determinations FIGS. 8-9. Ristovski: obtain model generated/trained using historical operational and failure event data (Abstract, [0026]-[0030]); using sensors to collect data (FIG. 5 block 540, [0026] and [0028]), using a computer system to perform training and data analysis including maintenance determinations FIGS. 6-7). McNab (US 2018/0176084 A1) discloses entering field inspection data using a GUI application ([0015], [0019] and [0028]).
Therefore, the additional elements are insufficient to amount to significantly more than the judicial exception.
Independent claim 21 is therefore not patent eligible under 101.
Claim 1 includes substantially the same features constituting an abstract idea as claim 21 and does not recite additional elements that integrate the abstract idea into a practical application or result in the claim as a whole amounting to significantly more than the judicial exception.
Therefore, claim 1 also constitutes ineligible subject matter under 101.
Claims 3-5, 7-8, 13-19, and 22 depending from claim 1, provide additional features/steps which are part of an expanded algorithm that includes the abstract idea of claim 1 (Step 2A, Prong One). None of dependent claims 3-5, 7-8, 13-19, and 22 recite additional elements that integrate the abstract idea into practical application (Step 2A, Prong Two), and all fail the “significantly more” test under the step 2B for substantially similar reasons as discussed with regards to the independent claims.
For example, claims 3-4 further characterize the nature of the “maintenance recommendation” in terms of the type of data and therefore fall within the judicial exception.
Claim 5 further characterizes the “computing device” as a “mobile device,” and the “application” as a “mobile field application utilized at a site comprising the item,” each of which represent substantially generalized forms of computing means for collecting/obtaining data and therefore constitute extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 7 further characterizes the nature of the “operational data” which does not constitute an additional element, and further includes the additional element “updating the training dataset with the current field inspection data and the current operational data,” which represents routine, conventional data processing activity (updating/retraining a model using more current/temporally relevant information) to provide the instructions for implementing the step(s) falling within the judicial exception and therefore constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 8 further characterizes the “trained model” as being of multiple trained models each trained in accordance with the type of equipment which in context essentially conveys the models are trained in accordance with intended particular application, which represents routine, conventional data processing activity (training/preparing a model for intended application in a particular context) that constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 22 characterizes the acquisition of the “operational data” as occurring “continuously, over time by the at least one sensor device” which similar to claims 11-12 represents common sensor-based monitoring having no particularized functional relation to the other elements in the claim including the steps falling within the judicial exception such as may convey an improvement to a technical field such that claim 22 also fails to integrate the judicial exception into a practical application.
Claims 13 and 15-16 further characterize “the output” such as in terms of data type (being a notification or alert and indicating whether within a threshold) and therefore include no significant additional elements.
Claim 14 recites “wherein a first notification is provided to a first user device indicative of new data being provided from a site, and a second notification is provided by the first user device to a second user device and is indicative of the maintenance recommendation based on the end-of-run prediction,” which represents routine, conventional data processing activity (passing notification outputs between devices) having no particularized functional relation to the functions falling within the judicial exception and therefore represent insignificant post-solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 17 further recites that the output is viewable in a user interface displayed on the output device, which represents routine, conventional data processing activity having no particularized functional relation to the functions falling within the judicial exception and therefore constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 18 further recites that the user interface provides wear data and operational data for a plurality of items, which represents routine, conventional data processing activity having no particularized functional relation to the functions falling within the judicial exception and therefore constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
Claim 19 further recites that the user interface provides a parts view comprising data for the plurality of components of the equipment, which represents routine, conventional data processing activity having no particularized functional relation to the functions falling within the judicial exception and therefore constitutes extra solution activity that neither integrates the judicial exception into a practical application nor results in the claim as a whole amounting to significantly more than the judicial exception.
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, 3-5, 8, 13, 15, 17-18, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Ni (US 2022/0398550 A1) in view of Horton (US 2017/0206510 A1), and in further view of McNab (US 2018/0176084 A1).
As to claim 1, Ni teaches “[a] computer-implemented method for monitoring and maintaining equipment (Abstract; FIG. 9; FIG. 1 platform manager 130 and server 104; FIG. 2 depicting computer-implemented management environment), comprising:
automatically acquiring operational data for an item comprising the equipment or a component of the equipment (FIGS 1 and 2 platform manager 130/platform management 202 receives data from the interfaces (automated/automatic acquisition); FIG. 2 sensor system 214 provides sensor information 216 for monitored platform 204 including aircraft 206; [0064]-[0067] sensor data provided to platform manager may be and/or be derived from operational data; [0066]-[0071] sensor data includes operational/performance data of the platform) using at least one sensor device while the at least one sensor device is monitoring the operation of the item (automatic acquisition inherent to the sensor monitoring within monitoring platform 204 and sensor system 214 as described in [0064]-[0067]; ), wherein the operational data comprises at least one value indicative of performance of the item (FIG. 9 blocks 900 and 902, [0139] system including trained model (inherently executed by a processor) receives currently sensed data (distinct from historical data used for training model); [0066]-[0071] sensor data includes operational/performance data of the platform);
receiving entry of field inspection data for the item (FIGS 1 and 2 platform manager 130/platform management 202 receives data from the interfaces; [0066]-[0071] sensor information may be provided via in situ sensors (voltage, accelerometer, airflow, etc.) such that the information is collected onsite (in the field)),” “wherein the field inspection data comprises at least one measurement indicative of wear of the item (FIG. 2 sensor system 214 configured to collect sensor information 216 including platform health information 218. [0068]-[0071] obtained sensor information may include health information. Examiner notes that health/condition is an indication of wear; FIG. 9 blocks 900, 902, and 904 received sensor data processed by machine learning to determine remaining useful life (data in some manner indicates wear));
receiving the operational data (FIGS 1 and 2 platform manager 130/platform management 202 receives data from the interfaces; FIG. 2 sensor system 214 provides sensor information 216 for monitored platform 204 including aircraft 206; [0064]-[0067] sensor data provided to platform manager may be and/or be derived from operational data; [0066]-[0071] sensor data includes operational/performance data of the platform) and the field inspection data (FIGS 1 and 2 platform manager 130/platform management 202 receives data from the interfaces; [0066]-[0071] sensor information may be provided via in situ sensors (voltage, accelerometer, airflow, etc.) such that the information is collected onsite (in the field)) via one or more data collection interfaces of a computing system configured for communication, via a network (FIG. 1 server computer 104 communicatively coupled via depicted interfaces (communication lines between client devices 110 and network 102 and between server computer 104 and network 102) to receive sensor information from client devices 110 via network 102), with the at least one sensor device (FIG. 1 server computer 104 is connected via network 102 with client devices 110 that provide the sensor information such that the client devices are effectively sensor device(s)”
“obtaining, by a processor of the computing system, a trained model for the item, (FIG. 1 machine learning model 134 configured to processes sensor information related to equipment such as a ship 116, rotorcraft 120, [0049], [0052]-[0053] machine learning model 134 trained for determining remaining life of components of respective equipment), the model having been trained using a training dataset comprising historical operational data corresponding to a type of equipment ([0052]-[0053] machine learning model trained using historical sensor information 136 and historical context information 138 relating to the historical sensor information; FIGS. 2-3 historical sensor information 221 and historical context information 226 used to train machine learning model 212, [0062]-[0064] model trained using historical health information for the platform (corresponding) and historical context information that relates to operating conditions 228; [0066]-[0071] sensor data includes operational data; [0131] sensor data indicates operating conditions. Examiner notes that the historical sensor information and historical context information each constitute historical operational data since each relates to the operation of the equipment. [0131] sensor information used for determining operating conditions and context information are used to train machine learning models (as historical data) for different types of platforms in which the models are selected based on and therefore correspond to the platforms (equipment, components)), and historical wear data (FIG. 2 historical sensor information 221 relates to/includes historical platform health information 224 (Examiner notes equipment/component health is a measure of wear)) acquired by inspecting the corresponding type of the equipment and/or a type of the component (FIG. 2 historical sensor information collected via accumulation of sensor information 216 provided by sensor system 214 that is configured to monitor/inspect the equipment via monitoring platform 204, [0064]-[0069], [0131]);
generating, by the processor using the trained model, an end-of-run prediction for the item (FIG. 9 blocks 902 and 904, [0139]-[0140] process receives a remaining useful life (end-of-run prediction) of a component from the trained model (i.e., trained model has generated the remaining useful life)) based on the operational data and the field inspection data received via the one or more data collection interfaces (FIG. 9 blocks 900 and 902, [0139] the trained model determines remaining life using sensor data that per [0066]-[0071] may include operational data of the platform some of which may be field inspection data);
determining, by the processor, a maintenance recommendation based on the generated end-of-run prediction (FIG. 9, [0140] remaining useful life received and processed by process to perform set of actions; [0073] set of actions may include indicating need for maintenance or maintenance scheduling; FIG. 9 blocks 904 and 906, [0140] process performs actions that may include maintenance based on the remaining useful life (the process determines maintenance action constitutes formulating a maintenance recommendation)), wherein the maintenance recommendation is optimized (FIG. 9 blocks 904 and 906, [0140] maintenance determination is based on a determined remaining useful life and is therefore “optimized” with respect to for example pre-scheduled maintenance intervales described in the Background in [0004]) for a plurality of interconnected equipment including the item (FIG. 9 blocks 900 an 902 sensor information collected and processed for an overall “platform” that per block 904 includes at least one component for which a remaining useful life is determined and utilized for subsequent maintenance determination per block 906 and [0140] (inferring a multi-component, interconnected platform); [0050] platform information obtain for rotorcraft (multi-component, interconnected platform); and
generating, by the processor using an output device (FIG. 2 computer system 208 including machine learning model 212 includes input/output (I/O) interface with platform manager 210, which itself includes I/O interfaces including to Actions 234 (Examiner notes that computer processors inherently include output interfaces for outputting processing results); FIG. 17 processor unit 1704 including I/O interface]), an output based on one or more of the generated end-of-run prediction (FIG. 9 block 904 the remaining useful life is received (i.e., has been output); [0073] platform manager 210 performs actions 234 (inherently entails outputting to implement) based on remaining life may include “indicating a maintenance is needed”) and the determined maintenance recommendation ([0073] platform manager 210 performs actions 234 include indicating a maintenance is need (inherently entails outputting to implement the indication)).
As set forth above, Ni teaches receiving data from one or more interfaces that includes operational data and field inspection data. Furthermore, Ni teaches that one of the data sources coupled to the one or more interfaces may be a mobile phone (mobile phone 118 in FIG. 1), which Examiner submits inherently entails a computing device having an application and further inherently includes a graphical user interface (GUI) as the data entry means (per depiction in FIG. 1 mobile phone 118 includes a broad user interface screen). Therefore, while Ni discloses that the overall system is capable of being implemented such that the one or more data collection interfaces are configured to receive data that has been entered via a GUI into the computing device, Ni does not expressly teach that the source of the field inspection data to the one or more interfaces is field inspection information entered into a GUI application.
Using mobile devices for on-site data collecting and provisioning was known prior to the effective filing date. For example, Horton discloses a method for inspecting and maintaining infrastructure assets (Abstract) that includes using a mobile device (and hence mobile applications) to collect/receive entry of and provide on-site information (FIG. 3 field crew (depicted as mobile device 118) configured to provide information to various networked devices; [0083] mobile computers 112 used by onsite crew to report on equipment inspections; [0029] workers visual inspection (onsite inspection) may be used for supporting modeling such as for estimating remaining life).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Horton’s teaching of using an on-site mobile device/application to collect and provide equipment data to the method taught by Ni, which teaches receiving operational data and field inspection data and using the operational and field inspection data for generating end-of-run predictions and further teaches a computing device having a GUI application as the data entry means (mobile phone 118) as a source of data, such that the combined method includes the field inspection data being received from a computing device (e.g., mobile phone 118) and in which the data was initially received/entered into a GUI application (GUI of the application) of the computing device (that the field inspection data has been acquired and entered into a graphical user interface (GUI) of the application of a computing device).
The motivation would have been to leverage the inspection flexibility of on-site manual mobile collection via GUI to optimize on-site collection and provisioning as suggested by Horton.
Regarding data entry to the mobile computers (e.g., mobile phone 118 in FIG. 1 of Ni or mobile device 118 in FIG. 3 of Horton) using a GUI application, even if Ni is assumed not to implicitly teach data entry into a mobile device by entering data into a GUI of an application, such means for entering field inspection data into an application was known in the art prior to the effective filing date. For example, McNab teaches a method/system for testing control systems (Abstract) that includes field inspection in which field inspection data is entered via a GUI of a field inspection application ([0015] application renders the GUI; [0019] and [0028] field observation/inspection data entered into a GUI of an application running on mobile device).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied McNab’s teaching of entering field inspection data into a GUI of an application to the method taught by Ni as modified by Horton such that in combination the method includes receiving entry of field inspection data into a GUI of an application for collecting the field inspection data.
Such a combination would amount to selecting a known design option for field inspection data collection to achieve predicable results.
As to claim 3, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the maintenance recommendation comprises a replacement recommendation (Ni: [0073], [0140]).”
As to claim 4, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the maintenance recommendation comprises a reuse or continued use recommendation (Ni: [0073], [0140] platform determines maintenance actions including replacement based on remaining useful life information. Examiner notes that using remaining useful life to determine to replace implicitly discloses a corresponding option of not replacing (e.g., fixing via maintenance or no action required and continuing use)).”
As to claim 5, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the computing device comprises a mobile device (Ni: FIG. 1 mobile phone 118; Horton FIG. 3 mobile field computer 118) and wherein the application comprises a mobile field application utilized at a site comprising the item (Ni: FIG. 1 mobile phone 118 (Examine notes that applications inherent to mobile phone 118 are effectively mobile applications. Horton: FIG. 3 mobile field (on-site) computer 118; [0083] inspection reporting via mobile field computer 118 inherently entails use of mobile field application).
As to claim 8, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the trained model is one of a plurality of trained models, each trained model being associated with a corresponding type of the equipment or a corresponding type of the component (Ni: [0131] sensor information used for determining operating conditions and context information used to train machine learning models for different types of platforms in which the models are selected based on and therefore correspond to the platforms (equipment, components)).”
As to claim 13, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the output based on the end-of-run prediction comprises a notification (Ni: [0053] machine learning model 134 can output to (notify) platform manager 130 remaining useful life 140 for a set of components).”
As to claim 15, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the output based on the end-of-run prediction comprises an alert (Ni: [0073] actions 234 performed based on remaining life may include “indicating a maintenance is needed”).”
As to claim 17, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 13,” but the description of Ni such as in [0073] of the output actions (e.g., FIG. 2 actions 234) does not specifically characterize the manner of implementing “indicating a maintenance is needed” and therefore does not expressly teach “wherein the output based on the prediction is provided at least in part by the application and/or is viewable in a user interface displayed on the output device.”
Ni discloses that the output based on the prediction may be an output of the remaining life prediction itself via machine learning model (e.g., FIG. 1 machine learning model 134) or may be the output of platform manager (e.g., FIG. 1 platform manager 130 with output indication described in [0073]). Ni further teaches that the platform management environment within which the machine learning model and platform manager are configured may comprise a computer system (FIG. 2) that per FIG. 17 may include a display device.
It would have been obvious to one of ordinary skill in the art before the effective filing date, in view of Ni’s teaching that the platform manager may perform “indicating a maintenance is needed” and further teaching that the platform manager may include a computer display, to have configured the method such that the output based on the prediction is viewable in a user interface. In such a configuration, and referring back to the “output device” as recited in claim 1, in which the grounds for rejecting claim 1 cites I/O interfaces of the platform manager 110 and general processor I/O entailed therein as teaching the “output device,” the teachings of Ni including that the platform may perform “indicating a maintenance is needed” and further teaching that the platform manager may include a display device that is used both for generating an output based on one or more of the generated end-of-run prediction and the determined maintenance recommendation, the output based on the prediction would be viewable in a user interface displayed on an output device.
The motivation for such combination would have been to leverage the platform manager display capability to provide user readable information regarding maintenance such that maintenance decisions can be effectively considered and implemented by a user.
As to claim 18, the combination of Ni, Horton, and McNab teaches or otherwise renders obvious “[t]he method of claim 17,” and further teaches “provides wear data and operational data for a plurality of items (Ni: FIG. 1 client devices 110 including surface ship 116, rotorcraft 120, each of which comprise multiple components, [0049] maintenance management operations performed for at least one of surface ship or rotorcraft and per [0052] entails platform health and context information provided for the respective equipment).”
Ni discloses the means for providing such wear and operational data only generally as being provided by/from monitoring platform 204 and sensor system 214 (FIG. 2), and therefore does not expressly teach that a “user interface” provides the wear and operational data. However, Ni further teaches that the computer system includes an input/output unit that may be utilized for input and output of data with other devices that can be connected to the computer (FIG. 17, [0165]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, in view of Ni’s teaching of providing wear data and operational data for a plurality of items using a computer system and further that the computer system includes a user interface that is utilized to input and output data with other connected devices to having implemented the method in a manner such that a user interface (e.g., an input or output device) is used for providing such information.
Such a combination would amount to selecting a known design option for providing information to or between computer systems to achieve predictable results.
As to claim 21, Ni teaches “[a]n equipment monitoring and maintaining system (Abstract; FIGS. 1, 2, and 17 depicting computer-implemented system for monitoring and in that manner maintaining), comprising:
at least one sensor device (FIG. 1 sensor information 142 and 132 provided from client devices 110 (client devices include or are in communication with sensors); [0038]; FIG. 2 sensor system 214 communicatively coupled with platform manager 210) configured to automatically acquire operational data for an item comprising the equipment or a component of the equipment while the at least one sensor device is monitoring the operation of the item ([0066]-[0068] sensors determine operational metrics for monitored platform) , wherein the operational data comprises at least one value indicative of performance of the item ([0067] sensor metrics may includer performance metrics such as airflow, speed, voltage, etc.);
a computing device (FIG. 2 sensor system 214, [0066]-[0067] sensor system may include computers) comprising an application ([0066]-[0067] sensor system computers include hardware and software that per FIG. 2 process data from monitoring platform 204 to generate sensor information 216 includes platform health information 218 and context information 222 such that sensors system 214 requires some form of application (program) to effectuate such processing)” “configured to receive entry of field inspection data for the item (FIG. 2 sensor system 214 configured to receive monitored/sensed data from monitoring platform 204; [0066]-[0071] sensor information may be provided via in situ sensors (voltage, accelerometer, airflow, etc.) such that the information is collected onsite (in the field)) , wherein the field inspection data comprises at least one measurement indicative of wear of the item (FIG. 2 sensor system 214 configured to collect sensor information 216 including platform health information 218. [0068]-[0071] obtained sensor information may include health information. Examiner notes that health/condition is an indication of wear; FIG. 9 blocks 900, 902, and 904 received sensor data processed by machine learning to determine remaining useful life (data in some manner indicates wear));
one or more processors (FIG. 17 processor unit 1704; [0160]-[0161]) communicatively coupled, via one or more data collection interfaces (FIG. 1 server computer 104 (inherently includes processor) communicatively coupled via depicted interfaces (communication lines between client devices 110 and network 102 and between server computer 104 and network 102) to receive data from client devices 110 via network 102) , to the at least one sensor device and the application (FIG. 1 client computers 112 and 114 and mobile phone 118 coupled via network with server computer 104; [0042] devices such as mobile phone configured to exchange information over the network. Examiner notes that client computers inherently include applications (programs) and that the mobile phone 118 characterized as exchanging information with computing devices necessarily entails that the mobile phone is a computing device that therefore necessarily includes applications); and
memory ([0059], FIG. 17 memory 1706 and persistent storage 1708), the memory storing computer executable instructions ([0059] and [0161] operations implemented by program code) that, when executed by the one or more processors, cause the system to:
receive, via the one or more data collection interfaces, the operational data (FIGS 1 and 2 platform manager 130/platform management 202 receives data from the interfaces; FIG. 2 sensor system 214 provides sensor information 216 for monitored platform 204 including aircraft 206; [0064]-[0067] sensor data provided to platform manager may be and/or be derived from operational data; [0066]-[0071] sensor data includes operational/performance data of the platform) and the field inspection data (FIGS 1 and 2 platform manager 130/platform management 202 receives data from the interfaces; [0066]-[0071] sensor information may be provided via in situ sensors (voltage, accelerometer, airflow, etc.) such that the information is collected onsite (in the field));
obtain a trained model for the item, (FIG. 1 machine learning model 134 configured to processes sensor information related to equipment such as a ship 116, rotorcraft 120, [0049], [0052]-[0053] machine learning model 134 trained for determining remaining life of components of respective equipment), the model having been trained using a training dataset comprising historical operational data corresponding to a type of the equipment ([0052]-[0053] machine learning model trained using historical sensor information 136 and historical context information 138 relating to the historical sensor information; FIGS. 2-3 historical sensor information 221 and historical context information 226 used to train machine learning model 212, [0062]-[0064] model trained using historical health information for the platform (corresponding) and historical context information that relates to operating conditions 228; [0066]-[0071] sensor data includes operational data; [0131] sensor data indicates operating conditions. Examiner notes that the historical sensor information and historical context information each constitute historical operational data since each relates to the operation of the equipment. [0131] sensor information used for determining operating conditions and context information are used to train machine learning models (as historical data) for different types of platforms in which the models are selected based on and therefore correspond to the platforms (equipment, components)), and historical wear data (FIG. 2 historical sensor information 221 relates to/includes historical platform health information 224 (Examiner notes equipment/component health is a measure of wear)) acquired by inspecting the corresponding type of the equipment and/or a type of the component (FIG. 2 historical sensor information collected via accumulation of sensor information 216 provided by sensor system 214 that is configured to monitor/inspect the equipment via monitoring platform 204, [0064]-[0069], [0131]);
generate, using the trained model, an end-of-run prediction for the item (FIG. 9 blocks 902 and 904, [0139]-[0140] process receives a remaining useful life (end-of-run prediction) of a component from the trained model (i.e., trained model has generated the remaining useful life)) based on the operational data and the field inspection data received via the one or more data collection interfaces (FIG. 9 blocks 900 and 902, [0139] the trained model determines remaining life using sensor data that per [0066]-[0071] may include operational data of the platform some of which may be field inspection data);
determine a maintenance recommendation based on the generated end-of-run prediction (FIG. 9, [0140] remaining useful life received and processed by process to perform set of actions; [0073] set of actions may include indicating need for maintenance or maintenance scheduling; FIG. 9 blocks 904 and 906, [0140] process performs actions that may include maintenance based on the remaining useful life (the process determines maintenance action constitutes formulating a maintenance recommendation)), wherein the maintenance recommendation is optimized (FIG. 9 blocks 904 and 906, [0140] maintenance determination is based on a determined remaining useful life and is therefore “optimized” with respect to for example pre-scheduled maintenance intervales described in the Background in [0004]) for a plurality of interconnected equipment including the item (FIG. 9 blocks 900 an 902 sensor information collected and processed for an overall “platform” that per block 904 includes at least one component for which a remaining useful life is determined and utilized for subsequent maintenance determination per block 906 and [0140] (inferring a multi-component, interconnected platform); [0050] platform information obtain for rotorcraft (multi-component, interconnected platform); and
generate, via an output device (FIG. 2 computer system 208 including machine learning model 212 includes input/output (I/O) interface with platform manager 210, which includes I/O interfaces including to Actions 234 (Examiner notes that computer processors inherently include output interfaces for outputting processing results); FIG. 17 processor unit 1704 including I/O interface]), an output based on one or more of the generated end-of-run prediction (FIG. 9 block 904 the remaining useful life is received (i.e., has been output); [0073] platform manager 210 performs actions 234 (inherently entails outputting to implement) based on remaining life may include “indicating a maintenance is needed”) and the determined maintenance recommendation ([0073] platform manager 210 performs actions 234 include indicating a maintenance is need (inherently entails outputting to implement the indication)).”
As set forth above, Ni teaches receiving data from one or more interfaces that includes operational data and field inspection data. Furthermore, Ni teaches that one of the data sources coupled to the one or more interfaces may be a mobile phone (mobile phone 118 in FIG. 1), which Examiner submits inherently entails a computing device having an application and further inherently includes a graphical user interface (GUI) as the data entry means (per depiction in FIG. 1 mobile phone 118 includes a broad user interface screen). Therefore, while Ni discloses that the overall system is capable of being implemented such that the one or more data collection interfaces are configured to receive data that has been entered via a GUI into the computing device, Ni does not expressly teach that the source of the field inspection data to the one or more interfaces is field inspection information entered into a GUI application.
Using mobile devices for on-site data collecting and provisioning was known prior to the effective filing date. For example, Horton discloses a method for inspecting and maintaining infrastructure assets (Abstract) that includes using a mobile device (and hence mobile applications) to collect/receive entry of and provide on-site information (FIG. 3 field crew (depicted as mobile device 118) configured to provide information to various networked devices; [0083] mobile computers 112 used by onsite crew to report on equipment inspections; [0029] workers visual inspection (onsite inspection) may be used for supporting modeling such as for estimating remaining life).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Horton’s teaching of using an on-site mobile device/application to collect and provide equipment data to the method taught by Ni, which teaches receiving operational data and field inspection data and using the operational and field inspection data for generating end-of-run predictions and further teaches a computing device having a GUI application as the data entry means (mobile phone 118) as a source of data, such that the combined method includes the field inspection data being received from a computing device (e.g., mobile phone 118) and in which the data was initially received/entered into a GUI application (GUI of the application) of the computing device (that the field inspection data has been acquired and entered into a graphical user interface (GUI) of the application of a computing device).
The motivation would have been to leverage the inspection flexibility of on-site manual mobile collection via GUI to optimize on-site collection and provisioning as suggested by Horton.
Regarding data entry to the mobile computers (e.g., mobile phone 118 in FIG. 1 of Ni or mobile device 118 in FIG. 3 of Horton) using a GUI application, even if Ni is assumed not to implicitly teach data entry into a mobile device by entering data into a GUI of an application, such means for entering field inspection data into an application was known in the art prior to the effective filing date. For example, McNab teaches a method/system for testing control systems (Abstract) that includes field inspection in which field inspection data is entered via a GUI of a field inspection application ([0015] application renders the GUI; [0019] and [0028] field observation/inspection data entered into a GUI of an application running on mobile device).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied McNab’s teaching of entering field inspection data into a GUI of an application to the method taught by Ni as modified by Horton such that in combination the method includes receiving entry of field inspection data into a GUI of an application for collecting the field inspection data.
Such a combination would amount to selecting a known design option for field inspection data collection to achieve predicable results.
As to claim 22, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the operational data comprises a plurality of values acquired continuously over time by the at least one sensor device (Ni: [0065] sensor measurements used for “monitoring” (implies continuous tracking over time) that may for example includes sensing changes in platform environment (operating environment of platform). Examiner notes detecting changes requires monitoring in a somewhat continuous manner over time).”
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Ni in view of Horton and McNab as applied to claim 1 above, and in further view of Zhang (US 2022/0292074 A1), Zhang ‘074, and Entzminger (US 2021/0080941 A1).
As to claim 7, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1, wherein the operational data comprises current operational data and wherein the field inspection data comprises current field inspection data (Ni: FIG. 9 blocks 900 and 902, [0139] system including trained model (inherently executed by a processor) receives currently sensed data (distinct from historical data used for training model); [0066]-[0071] sensor data includes operational/performance data of the platform; [0066]-[0071] sensor information may be provided via in situ sensors (voltage, accelerometer, airflow, etc.) such that the information is collected onsite (in the field))” but none of Ni, Horton, or McNab expressly teaches “updating the training dataset with the current field inspection data and the current operational data to update the trained model.”
Re-training/updating prediction models such as machine learning models based on more current input data was well-known in the art prior to the effective filing date. For example, Zhang ‘074 discloses a method for implementing models to detect anomalies that including using more current data to update an already trained model (Abstract; FIG. 4 block 412, [0080]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Zhang ‘074 teaching of updating a trained model using more current data to the method taught by Ni as modified by Horton and McNab such that in combination more current versions of the historical operational and wear data that as taught by Ni include operational data that may include field inspection data used to train the model are used to update the trained model.
The motivation would have been to account for changing usage/wear/operational conditions to improve model accuracy by updating the model as disclosed by Zhang ‘074 as also by Entzminger (see [0023] teaching need for updating models for equipment monitoring but not explicitly disclosing newer input data used for such updates).
Claims 9-12 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ni in view of Horton and McNab as applied to claim 1 above, and in further view of Neal (US 2023/0151727 A1).
As to claim 9, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 1,” but does not expressly teach “wherein the equipment comprises a slurry pump and the item comprises at least one component of the slurry pump.”
Ni teaches that the monitoring and maintenance determination method/system is applicable to a wide variety of different types of equipment ([0055] and [0057]), such that the method is not dependent on the specifics of the equipment. Neal discloses a method for determining equipment maintenance based on operational data for slurry pumps including components of such pumps (Abstract; FIG. 1 pump unit 34 including pumping equipment 46; FIG. 2 pump unit 100 including main pump 106; [0022], [0024]-[0025], [0031], [0044], [0057]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Neal’s teaching of slurry pumps as equipment to be monitored and for which to make maintenance determinations to the method taught by Ni, which as disclosed by Ni is widely applicable to different varieties of equipment, such that the combined method is applied to a slurry pump.
The motivation would have been to determine wear and consequent need for maintenance of a slurry pump as disclosed by Neal.
As to claim 10, the combination of Ni, Horton, McNab, and Neal teaches “[t]he method of claim 9,” and as combined in the rejection of claim 9 the “component” would be a component of the slurry pump, which as taught by Neal may include “a casing ([0039] pump includes a housing)” and “an impeller ([0039] pump includes an impeller).”
As to claim 11, the combination of Ni, Horton, McNab, and Neal teaches “[t]he method of claim 9, wherein the operational data comprises one or more physical properties of the equipment (Ni: [0063] historical sensor/sensor information may include vibration level, high/low speed; [0067] sensor system collects airflow, speed data) or the component and/or a medium interacting with the equipment or the component.”
As to claim 12, the combination of Ni, Horton, McNab, and Neal teaches “[t]he method of claim 11,” and Neal further teaches using historical operational data (logged data) in the form of “a speed and/or a head the pump is creating” for predicting the need for maintenance ([0044] usage log includes pump usage values such as pump flowrate (speed) and pump pressure (head)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Neal’s teaching of using operational data in the form of pump speed and/or pressure head for monitoring pump usage in order to predict required maintenance with the method taught by Ni as modified by Horton, McNab, and Neal to include monitoring a slurry pump.
The motivation would have been to utilized operation metrics relevant to pump usage and wear in order to more accurately determine pump usage/wear and thus more effectively informing the maintenance decision as suggested by Neal.
As to claim 16, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 15,” but does not expressly teach “wherein the alert is indicative of the predicted end-of-run for the item being within a threshold amount of time corresponding to type of the item.”
Neal discloses a method for determining equipment maintenance based on operational data in which an alert is indicative of a predicted end-of-run for the item being within a threshold amount of time for that type (corresponding type) of item (Abstract; [0050] service personnel alerted to an approaching future maintenance event by determining whether pump life value exceeds recommended maintenance period. “The recommended maintenance period includes a pump usage value threshold indicative of at least one pumping operation before the future maintenance event.” (emphasis added)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Neal’s teaching of using an alert indicative of an end of run is within a threshold amount of time for that type of item to the method taught by Ni as modified by Horton and McNab.
The motivation would have been to alert service personnel to approaching recommended/required maintenance events in accordance with the predicted end-of-run information in order to enable coordination of the end-of-run prediction with other maintenance requirements as disclosed by Neal.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Ni in view of Horton and McNab as applied to claim 13 above, and in further view of McKinley (US 2024/0176341 A1).
As to claim 14, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 13, wherein a first notification is provided to a first user device indicative of new data being provided from a site (Ni: FIG. 2 platform manager 210 within computer system 208 receiving new data (data obtained by ongoing monitoring) from sensor system 214. Examiner notes that receiving the new data itself is a constructive notification of new data.), and a second notification is provided by the first user device” “indicative of the maintenance recommendation based on the end-of-run prediction (Ni: [0073] set of actions 34 may include indicating (some form of output) a need for maintenance based on remaining useful life).”
Ni does not explicitly teach that the second notification is provided “to a second user device.”
McKinley discloses a method for performing prognostics on vehicles (Abstract) that includes determining remaining life of equipment (FIG. 10) and providing a maintenance recommendation from one user device to another user device (FIG. 10 block 444 “send email notifications”, [0072] report including maintenance related recommendations (e.g., replacement parts, maintenance scheduling) is output via email (requires device to device communication)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied McKinley’s teaching of providing a maintenance recommendation to another device with the method taught by Ni as modified by Horton and McNab such that in combination the actions performed by the platform manager (Ni FIG. 2) further including sending the maintenance recommendation to another user device.
The motivation would have been to leverage networked communications capabilities to provide optimally efficient distribution of maintenance recommendations to parties/devices from which maintenance may be scheduled and/or performed as suggested by McKinley.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Ni in view of Horton and McNab as applied to claim 18 above, and in further view of Johnson (US 2019/0147413 A1).
As to claim 19, the combination of Ni, Horton, and McNab teaches “[t]he method of claim 18,” and “wherein the equipment includes a plurality of components (Ni: FIG. 2 sensor system 214 provides sensor information 216 for monitored platform 204 including aircraft 206 (inherently includes multiple components))” but does not expressly teach “the user interface provides a parts view comprising data for the plurality of components of the equipment.”
Johnson discloses a method for optimizing maintenance for equipment components (Abstract) that includes a user interface that provides a parts view comprising data for a plurality of equipment components (FIG. 5, [0056]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Johnson’s teaching of providing, via a user interface, a parts view comprising data for a plurality of equipment components to the method taught by Ni that teaches monitoring multi-component equipment, such that the combined method includes the user interface (e.g., display taught by Ni) providing such a view of the parts.
The motivation would have been to provide a means by which users may efficiently ascertain comprehensive maintenance information for the equipment to enable more efficient planning and execution of maintenance tasks as suggested by Johnson.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW W BACA whose telephone number is (571)272-2507. The examiner can normally be reached Monday - Friday 8:00 am - 5: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, Andrew Schechter can be reached at (571) 272-2302. 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.
/MATTHEW W. BACA/Examiner, Art Unit 2857
/ANDREW SCHECHTER/Supervisory Patent Examiner, Art Unit 2857
Prosecution Insights