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 .
Response to Amendment
Claims 1, 4-5, and 7 are amended and claims 2-3, 6, and 8 are cancelled. Claims 1, 4-5, and 7 are pending.
Response to Arguments
Applicant's arguments filed 8/27/2026 have been fully considered.
Regarding the objections to claims 1 and 5, and as noted by Applicant on page 5 of the response, the amendments to claims 1 and 5 overcome the objections, which are withdrawn.
Regarding the rejections of claims 1-8 under 112(b), and as noted by Applicant on pages 6-9, the amendments to the claims overcome the rejections, which are withdrawn.
Regarding the rejection of claim 1 under 101 as directed to an abstract idea without significantly more, Examiner respectfully disagrees with Applicant’s arguments that the amendments to claim 1 overcome the rejection for the following reasons.
Regarding Step 2A Prong One, Applicant contends on page 10 of the response that the steps of image similarity matching, three-dimensional modeling, simulation of system components, wear analysis, and life prediction do not fall within the mental processes exception and instead “… are concrete technical operations that require a computer system.”
Examiner submits that image similarity matching, simulation of system components, wear analysis, and life prediction fall within the mental processes exception because these steps, individually and in combination, may be performed via mental processes (e.g., evaluation and judgment). As explained in the grounds for rejecting claim 1, the step of three-dimensional modeling falls within the mathematical relationships subcategory of the mathematical concepts exception. As explained in the grounds for rejecting claim 1, computer implementation of these steps does not disqualify the functions themselves as falling within either the mental processes or mathematical concepts exception.
Regarding Step 2A Prong Two, Applicant contends on pages 10-11 of the response that claim 1 integrates any potential abstract idea into a practical application via improvement to a technical field, application with a particular machine, and transformation of a particular article.
In support, regarding improvement to a technical field, Applicant cites paragraph [0002] of the specification asserting that the prior art cannot effectively realize the synchronous detection of multiple engines and the accurate evaluation of the state of each component of the engine, and that the invention accomplishes these goals via image similarity matching, three-dimensional modeling, simulation, wear analysis, life prediction, and feedback optimization.
Examiner submits that, as set forth in the grounds for rejecting claim 1 under 103, synchronous detection of multiple engines is achieved via Chinnadurai’s disclosed system/method in terms of identifying faults for different types of engines using data collected for different types of engines ([0072]-[0077], [0099] and [0109]) and accuracy of state evaluation is a generalized and universal goal, such that these functions/results do not themselves represent technology improvements. As set forth in the grounds of rejection, the functions including image similarity matching, three-dimensional modeling, simulation, wear analysis, and life prediction constitute known functions for determining engine/component state and therefore also do not represent improvements in the technical field. Moreover, Examiner submits that the goals of synchronous detection and evaluation accuracy are achieved by the functions of the steps falling within the abstract idea without significant involvement (particularized functional relation) of the additional elements.
Regarding application with a particular machine, Applicant asserts on page 11 that the claimed invention is implemented on a particular machine with the multi-engine synchronous detection and analysis system comprising sequentially connected module resulting in a specialized engine diagnostic system.
Examiner submits that, as characterized by claim 1 interpreted in view of Applicant’s specification, the machine constitutes computer processing functions for merely implementing the steps via program execution including storing data, which constitutes insignificant extra solution activity. In a more particularized aspect, claim 1 recites some of the functions performed via “a system comprising a host computer and a slave computer,” which was known prior to the effective filing date, and furthermore does not appear to have any particularized functional relation to the steps falling within the abstract idea such that it does not constitute a particular machine for implementing the processing steps.
Regarding transformation of a particular article, Applicant asserts that such transformation is achieved via generation of actionable technical outputs such as analysis reports, maintenance plans, life predictions, stability evaluations, and an optimized information matching module via the processing of engine data.
Examiner submits that deriving information based on other information does not constitute transformation of a particular article. Moreover, any arguable informational transformation that occurs is confined to the elements falling within the judicial exception.
Regarding Step 2B, Applicant contends on page 11 that the additional elements are not well-understood, routine, conventional in the field. In support, Applicant asserts that no prior art system combines sequential system architecture with image similarity matching, multi-parameter fault determination, three-dimensional modeling, simulation, wear analysis, life prediction, and feedback optimization including summarizing components prone to failure, preferentially identifying them, and evaluating operation stability.
Examiner submits that the “additional elements” identified in the grounds of rejection as being well-understood, routine, conventional in the field do not include several of the foregoing paraphrased functions, which fall within the judicial exception. Moreover, while Examiner acknowledges that no single reference teaches the combination of all of the functions/structures recited in claim 1, the claim does not appear to include any combination of elements (additional elements combined with elements falling within the judicial exception) that results in the claim as a whole amounting to significantly more than the abstract idea because as explained in the grounds of rejection, the additional elements (e.g., “the information input module” “used to input information of several types of engines,” “the fault processing module” “used to perform fault maintenance according to matching results and identification results of the information matching module,” “the data repository” “used to store the engine information, the matching result, the recognition result and the analysis report, and “appearance images of different types of engines,” the processing functions falling within the abstract idea being implemented by “an information matching module,” “an operation analysis module,” and “a maintenance report module connected in turn,” “retrieve images of engines stored in the data repository according to the engine model in the engine information,” “use a system comprising a host computer and a slave computer” to analyze and correct wear of engine system components, carry out a life prediction of each engine component according to the engine operation mechanism, and generate and “display” an analysis report) constitute insignificant extra solution activity and therefore do not result in the claim as a whole amounting to significantly more than the judicial exception.
Regarding the rejection of claim 1 under 103, and as noted by Applicant on page 12 of the response, claim 1 is amended to include the new (via clarification) element “a system comprising a host computer and a slave computer,” which overcomes the previous grounds for rejecting under 103. Upon further search and analysis, new grounds for rejecting amended claim 1 under 103 as being unpatentable over Chinnadurai (US 2008/0004764 A1) in view of Kuschke (US 2015/0094931 A1) and in further view of Mylaraswamy (US 7,337,058 B1), Charbonnel (US 2022/0155772 A1), Rich (US 2022/0306050 A1), and Battista (US 2007/0210905 A1) are set forth herein.
On page 12 of the response, Applicant contends that the Chinnadurai reference does not disclose the combined elements of claim 1. In support, Applicant provides a list of generalized, paraphrased features and contends that Chinnadurai fails to disclose these features. However, “Applicant’s response:” in the table provided under “B. Chinnadurai does not disclose these features,” fails to accurately map the citations from Chinnadurai used in the previous rejection of claim 1 to corresponding claim elements. For example, in row 1 the table correctly indicates Chinnadurai [0022], [0025]-[0026], and [0029] as being applied in the rejection as disclosing “analyze a normal operation.” However, Applicant’s response does not address the correctness of this application, instead asserting that Chinnadurai does not disclose three-dimensional modeling, operation mechanism analysis, etc.. The other rows in the table similarly mismatch what is presented in the actual grounds of rejection. One recurring contention in the table is that Chinnadurai fails to disclose three-dimensional modeling. As set forth in the previous and current grounds of rejection, Chinnadurai teaches three-dimensional modeling ([0037], [0066], and [0072]-[0077] historical vehicle operational data for normal operating conditions collected and associated with respective types of engines to form respective models from which parameter ranges are determined; FIG. 4 and [0080]-[0085] depicting and describing multi-dimensional modeling (e.g., parameter space including failure operating conditions spaces P that include normal operation PN (one dimension) and at least two other condition spaces (dimensions) as explained in [0084] which describes the depicted 2-D parameter space actually representing a higher-dimensionality; [0106] historical data represented in multi-dimensional vector space having dimensionality equal to the number of measured parameters (three or more measured parameters as disclosed in [0037]-[0065]).
On pages 13-14 of the response, Applicant generally contends that the rejection of claim 1 relies on impermissible hindsight and that the references are from different technical fields and address different problems. Examiner respectfully disagrees because the Chinnardurai, Kuschke, Mylaraswamy, Charbonnel, Rich, (and currently) Battista recite methods/systems applicable to the same field of endeavor, i.e., monitoring and diagnosing vehicular condition. Regarding impermissible hindsight, the grounds of rejection provide adequate explanation of why the respective combinations of teachings from different references would have been recognized by one of ordinary skill as readily combinable
On page 14 of the response, Applicant contends that the combinations set forth in the rejections lack adequate motivation to combine. However, Applicant does not directly address any of the provided reasons set forth in the rejections. Instead, Applicant contends that that the references are directed to different problems and therefore one of ordinary skill in the art would not have been motivated to combine these disparate references because they address different technical problems and use different technical approaches. Applicant’s argument on this point is overly generalized and does not directly address whether any of the specific combinations of prior art references for teaching combinations of recited elements are improper. As stated above, Examiner contends that the individual prior art references address issues/problems in the same field of endeavor and, for at least that reason, are properly applied to the various aspects of data collection and processing (including modeling) of vehicle condition information.
On page 15 of the response, Applicant contends that the invention exhibits unexpected advantages over the prior art including synchronous detection of different types of engines, improved fault identification accuracy via engine model matching, image similarity matching, and multi-parameter analysis, predictive maintenance through life prediction based on three dimensional modeling, simulation, and operational mechanism analysis, and self-optimization via the “feedback mechanism.”
Examiner submits that Applicant’s argument in this regard is unclear, paraphrasing functions/results in a manner such that the Examiner cannot discern what particular outcome is “unexpected” by a specific combination of elements recited in claim 1.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “information input module” in claim 1, “information matching module” in claims 1 and 4, “fault processing module” in claims 1 and 5, “operation analysis module” in claim 1, and “maintenance report module” in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
For example, paragraphs [0025] and [0042]-[0045] describes the embodiments of the invention, which would include the foregoing limitations, except “fault processing module,” may be implemented via program instructions executed by a computer processor.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
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, 4-5, and 7 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.
Claim 1 recites:
“[a] multi-engine synchronous detection and analysis system, comprising an information input module, an information matching module, a fault processing module, an operation analysis module, a data repository, and a maintenance report module connected in turn;
wherein the information input module is used to input engine information of several types of engines; wherein the engine information comprises several different engine models, engine images, a duration of use, a maintenance history, a fault state characterization, a fault occurrence time, and fault occurrence scenarios;
wherein the information matching module is used to match an engine model according to the engine information, retrieve images of engines stored in the data repository according to the engine model in the engine information, perform a similarity matching between images of the engines and the engine images in the engine information, wherein the engines are same as a matched engine model, identify a fault location of an engine, determine a system part of an engine failure according to a fault state representation and a fault occurrence scene in the engine information, and judge an influence degree of a fault according to a use time, the maintenance history, and the fault occurrence time;
wherein the fault processing module is used to determine a fault maintenance plan according to matching results and identification results of the information matching module; wherein the fault maintenance plan comprises one or more of ignition system maintenance, fuel injector maintenance, fuel pump maintenance, cylinder maintenance, and intake system maintenance;
wherein the operation analysis module is used to analyze a normal operation state of the engine after maintenance, carry out three-dimensional modeling of the engine under normal operating conditions to obtain the engine model, analyze an engine operation mechanism according to the engine model, simulate system components of the engine, use a system comprising a host computer and a slave computer to analyze and correct wear of engine system components, carry out a life prediction of each engine component according to the engine operation mechanism, and generate and display an analysis report;
wherein the data repository is used to store the engine information, the matching results, the identification results, the analysis report, and appearance images of different types of engines; and
wherein the maintenance report module is used to summarize, regulate, and display fault causes and fault parts of different types of engines according to stored data in the data repository, summarize components that are prone to failure of different types of engines according to the identification results and analysis reports classified and stored by the data repository, generate summary results, use the information matching module to preferentially identify components that are prone to failure of different types of engines according to the summary results, extract analysis reports of a same component of different types of engines in the data repository, evaluate an operation stability of different types of engines according to a life prediction result of components in the analysis report to generate evaluation results, and optimize the information matching module according to a regulated result.”
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 1 recites a system and therefore 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 1 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:
“match an engine model according to the engine information,” “perform a similarity matching between images of the engines and the engine images in the engine information, wherein the engines are same as a matched engine model, identify a fault location of an engine, determine a system part of an engine failure according to a fault state representation and a fault occurrence scene in the engine information, and judge an influence degree of a fault according to a use time, the maintenance history, and the fault occurrence time;
“determine a fault maintenance plan according to matching results and identification results of the information matching module; wherein the fault maintenance plan comprises one or more of ignition system maintenance, fuel injector maintenance, fuel pump maintenance, cylinder maintenance, and intake system maintenance,”
“analyze a normal operation state of the engine after maintenance,” “analyze an engine operation mechanism according to the engine model, simulate system components of the engine,” “analyze and correct wear of engine system components, carry out a life prediction of each engine component according to the engine operation mechanism, and generate” “an analysis report,”
“summarize, regulate” “fault causes and fault parts of different types of engines according to stored data in the data repository,” “preferentially identify components that are prone to failure of different types of engines according to the summary results,” “evaluate an operation stability of different types of engines according to a life prediction result of components in the analysis report to generate evaluation results, and optimize the information matching” “according to a regulated result,”
may be performed as mental processes.
Matching an engine model according to engine information, performing a similarity matching between images of the engines and the engine images in the engine information, identifying a fault location of the engine, determining a system part of an engine failure according to a fault state representation and a fault occurrence scene in the engine information, judging an influence degree of a fault according to a use time, the maintenance history, and the fault occurrence time, determining a fault maintenance plan according to matching results and identification results in which the fault maintenance plan includes various aspects of engine maintenance, analyze a normal operation state of the engine after maintenance, analyze an engine operation mechanism according to the engine model, simulate system components of the engine, analyzing and correcting (determining correction) wear of engine system components, performing life prediction of each engine component according to the engine operation mechanism, generating an analysis report, summarizing/regulating fault causes and fault parts of different types of engines according to stored data in the data repository, identifying components that are prone to failure according to summary results, and evaluating an operation stability of different types of engines according to a life prediction result of components in the analysis report to generate evaluation results, may individually and/or in combination be performed via mental processes (e.g., evaluation and judgment). Optimizing the information matching module according to a regulated result may also be performed via mental processes (e.g., ascertaining improvements to program code as a preliminary step to changing the code in accordance with observed results).
The step “carry out three-dimensional modeling of the engine under normal operating conditions to obtain the engine model,” falls within the mathematical relations sub-category of the mathematical concepts judicial exception because three-dimensional data modeling entails vector processing (spatial or otherwise) which is fundamentally characterized by mathematical relations/calculations.
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 1 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, for example, “the information input module” “used to input information of several types of engines,” “the fault processing module” “used to perform fault maintenance according to matching results and identification results of the information matching module,” “the data repository” “used to store the engine information, the matching result, the recognition result and the analysis report, and “appearance images of different types of engines,” the processing functions falling within the abstract idea being implemented by “an information matching module,” “an operation analysis module,” and “a maintenance report module connected in turn,” “retrieve images of engines stored in the data repository according to the engine model in the engine information,” “use a system comprising a host computer and a slave computer” to analyze and correct wear of engine system components, carry out a life prediction of each engine component according to the engine operation mechanism, and generate and “display” an analysis report 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 steps or a device for implementing the highlighted step such as a signal processing device or a generic computer. Instead, the information input module and the data repository represent high-level and ordinary computing functionalities (inputting and storing data) having no particularized functional relation to the steps falling within the judicial exception 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. The fault processing module used to perform fault maintenance represents high level post-solution activity (repairing/replacing engine components as a high level result of the processing steps) 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.
The modules for implementing the processing functions falling within the judicial exception constitute program code execution for implementing the judicial exception and therefore also 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.
Retrieving images of engines stored in the data repository according to the engine model in the engine information represents high-level and ordinary computer processing functionality (retrieving database information via an identifier/key) having no particularized functional relation to the steps falling within the judicial exception and therefore constitutes insignificant extra solution activity.
Using a system comprising “a host computer and a slave computer” to analyze and correct wear of engine system components, carry out a life prediction of each engine component according to the engine operation mechanism, and generate and display an analysis report represents using known computer functionality to implement processing steps in a manner having no particularized functional relation to the steps falling within the judicial exception and therefore also constitutes insignificant extra solution activity.
Regarding application of the judicial exception with, or by use of, a particular machine, the additional elements are not configured or otherwise implemented a particularized manner of implementing condition monitoring of engines.
Regarding a transformation or reduction of a particular article to a different state or thing, claim 1 does not include any such transformation or reduction. Instead, claim 1 as a whole entails receiving input information (e.g., engine information), applying standard processing techniques (program execution via computer) to the information to determine engine condition information with the additional elements failing to provide a meaningful integration of the abstract idea 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.
Examiner notes that even if three-dimensional modeling is interpreted to fall outside the abstract idea and therefore constitute an additional element, this function has no apparent particularized functional relation to the steps falling within the judicial exception and would therefore constitute insignificant extra solution activity. Specifically, the modeling process is recited at a high-level of generality (3-D) such that the use of such modeling to obtain “the engine model” represents well-known computer processing instructions (modelling) for generating a data representation of the engine.
In view of the various considerations encompassed by the Step 2A, Prong Two analysis, claim 1 does not include additional elements that integrate the recited abstract idea into a practical application.
Therefore, claim 1 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 in claim 1 constitute insignificant extra solution activity and therefore do not result in the claim as a whole amounting to significantly more than the judicial exception as well as failing to integrate the judicial exception into a practical application. Furthermore, most of the additional elements appear to be generic and well understood as evidenced by the disclosures of Chinnadurai (US 2008/0004764 A1) and Charbonnel (US 2022/0155772 A1), each of which teach a substantially similar data collection/storage and processing platform for implementing engine diagnostics.
As explained in the grounds for rejecting claim 1 under 103, Chinnadurai teaches an information input module for inputting/collecting engine information, a data repository for storing the engine information including engine information derived via processing, and computer program execution means for implementing the processing steps as does Charbonnel (see FIG. 1 depicting remoting monitoring system 106 receiving (and therefore storing) engine information from engine monitoring systems 104, [0015], [0020]-[0023] describing data processing for diagnostics; [0008] and claim 15 method implemented by execution of program instructions).
Performing engine maintenance in connection with diagnostics is also generic and well understood as evidenced by Charbonnel (FIG. 3 step 360, [0015]; [0026]-[0027]) and Kuschke (US 2015/0094931 A1) (Abstract; claim 10).
Therefore, the additional elements are insufficient to amount to significantly more than the judicial exception.
Claim 1 is therefore not patent eligible under 101.
Claims 4-5 and 7, 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 4-5 and 7 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 claim 1.
In claim 4, the operation “when there is no engine image matching with the engine model in the data repository, carrying out a search online according to the engine model by the information matching module” entails a mental step of determining the “no engine matching” condition, and the additional element “carrying out a search online according to the engine model by the information matching module” itself represents high-level data collection using ordinary computer processing having no particularized functional relation to the steps falling within the judicial exception and therefore constitutes insignificant extra solution activity. The step of “setting a similarity threshold according to a corresponding engine image” falls within the mental processes exception because it may be performed via mental processes (e.g., evaluation and judgment). The step “when a similarity between an image obtained by a search result and an image uploaded in the engine information reaches the similarity threshold, storing an image obtained by the search result as the engine image” entails a mental step of determining the “similarity … reaches a similarity threshold” condition, and the additional element “storing an image obtained by the search result as the engine image” itself represents high-level and ordinary computer processing (data storage) having no particularized functional relation to the steps falling within the judicial exception and therefore constitutes insignificant extra solution activity.
Claim 5 recites a list of maintenance functions performed in which there appears to be no significant functional relation between any individual or combination of the functions and the steps falling within the judicial exception such that these functions constitute insignificant extra solution activity.
Claim 7 recites “wherein the data repository is classified” “respectively according to the identification results and the analysis reports of the engine model at different times,” which falls within the mental processes exception because these functions are largely abstract and can be performed via mental processes (e.g., ascertain classification of data repository via evaluation of identification results and analysis report that were collected at various times. Claim 7 further recites storing the repository according to the results/reports and unifying the analysis reports of the same component of different types of engines, which represents a form of substantially ordinary data collection and organization having no particularized functional relation to the steps falling within the judicial exception and therefore constitute insignificant extra solution activity.
Dependent claims 4-5 and 7 therefore also constitute ineligible subject matter under 101.
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, 5, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai (US 2008/0004764 A1) in view of Kuschke (US 2015/0094931 A1) and in further view of Mylaraswamy (US 7,337,058 B1), Charbonnel (US 2022/0155772 A1), Rich (US 2022/0306050 A1), and Battista (US 2007/0210905 A1).
As to claim 1, Chinnadurai teaches “[a] multi-engine synchronous detection and analysis system (Abstract describing diagnostic data collector/analyzer for different vehicles; FIG. 1 data collector/analyzer 10), comprising an information input module (FIG. 1 PC 12 and/or diagnostic scan tool 14), an information matching module (FIG. 2 depicting processing functions within diagnostic data collector/analyzer 10), a fault processing module (FIG. 2 depicting processing functions within diagnostic data collector/analyzer 10), an operation analysis module (FIG. 2 depicting processing functions within diagnostic data collector/analyzer 10), a data repository (FIG. 1 database 24 within diagnostic data collector/analyzer 10; FIG. 2 memory 32 within diagnostic data collector/analyzer 10), and a maintenance report module (FIG. 2 data compiler 36 and data analyzer 38) connected in turn (FIGS. 1 and 2 depicting processing functions interconnected);
wherein the information input module is used to input engine information of several types of engines (FIG. 1 PC 12 and/or diagnostic scan tool 14 configured to provide information from vehicle 16 including from onboard computer 18; Abstract explaining that the input information may be from any of different vehicles; [0025] data collected for multiple different vehicle types; [0034], [0039], [0041], [0046]-[0053], [0059], and [0063]-[0065] vehicle information includes engine information; [0073]-[0076] engine information includes information for different types of engines)”
“wherein the information matching module is used to match an engine model according to the engine information ([0072]-[0077] historical data collected for different types of engines for analysis to determine established operating ranges; [0094], [0096]-[0098], and [0108] measurements obtained for test-subject vehicle and compared with corresponding established operating ranges (inherently requires identifying/matching test-subject vehicle engine for operating ranges categorized per [0072]-[0076])” “identify a fault location of an engine ([0099] and [0109] comparison may result in determining failure condition including component failure; FIG. 3 components may be engine components (represented as nodes under engine node N11)”
“wherein the fault processing module is used to determine a fault plan according to matching results and identification results of the information matching module ([0036] repairs are associated with respective failure modes that per the categorical engine type association with operational ranges depicted described in FIG. 3 (node N11 is a particular engine of the various possible engine types per [0073]-[0076]) and [0035] are also associated with engine type);”
“wherein the operation analysis module is used to analyze a normal operation state of” [an] “engine ([0022], [0025]-[0026], [0029] and [0037] operating parameters of test-subject vehicle compared with established ranges corresponding to normal operating conditions and failure conditions (test subject vehicle engine may or may not be operating normally))”
“wherein the data repository is used to store the engine information, the matching results, the identification results, the analysis report (FIG. 1 database 24 within diagnostic data collector/analyzer 10; FIG. 2 memory 32 within diagnostic data collector/analyzer 10 inherently stores the processing results)”
“wherein the maintenance report module is used to summarize, regulate,” “fault causes and fault parts of different types of engines according to stored data in the data repository (FIG. 2 data compiler 36 and data analyzer 38; [0025]-[0026], [0029] and [0066] gather and compile (summarize and regulate) historical diagnostic (fault causes) data for engine components; [0037], [0040], [0047], [0059], [0073]-[0077] data includes data for engine parts/components for different types of engines),” “and optimize the information matching module according to a regulated result ([0077] data analyzer 38 optimizes information matching by analyzing historical data (regulated result) to determine ranges for normal and failure conditions).
As set forth above, Chinnadurai teaches determining fault maintenance, and therefore suggests but does not appear to expressly teach performing/implementing the determined maintenance, and furthermore does not appear to expressly teach analyzing a normal operation state of the engine “after maintenance.”
Kuschke discloses a system/method for performing maintenance on an engine based on engine analysis information (Abstract; claim 10) and further teaches analyzing an operation state of the engine after maintenance (Abstract and claim 10 describing the process for determining potentially required maintenance includes providing a second performance parameter characterizing engine performance after engine maintenance. Examiner notes that providing the performance parameter characterizing engine performance after maintenance inherently requires a determination/analysis to derive the performance parameter as disclosed in claim 11 disclosing the second performance parameter as determined using a monitoring system).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Kuschke’s teaching of performing maintenance and monitoring engine performance after maintenance (which would likely entail at least incidentally on some occasions the engine performance being relatively normal) to the system taught by Chinnadurai, which is configured to monitor ongoing engine performance including normal performance, such that in combination the system is configured to perform the determined maintenance, and to analyze a normal operation state of the engine “after maintenance.”
The motivation would have been to implement maintenance and in a process that uses post-maintenance information that may be helpful for optimizing further maintenance as disclosed by Kuschke.
Regarding the operation analysis module used to “generate and display an analysis report” and the maintenance report module being used to “display” fault causes and fault parts of different types of engines,” Chinnadurai teaches that the diagnostic data collector/analyzer may directly or indirectly control a display function (FIG. 2 computer Input/Output 34; [0033] data processing involving diagnostic data collector/analyzer 10 may be visually displayed). Furthermore, Chinnadurai discloses that it was known in the art that graphical displays may be generated and used to display (report) analyzer/diagnostic data (analyzer data that is reported falling within a broadest reasonable interpretation in view of Applicant’s specification of an analysis report) ([0005]-[0006]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, have applied Chinnadurai’s disclosed generation and display of an analysis report to Chinnadurai’s disclosed embodiments that teaches generating the analysis data such that in combination the system is configured such that the operation analysis module used to generate and display an analysis report and is further configured to display fault causes and fault parts of different types of engines.
The motivation would have been to provide a user-readable format for a user (e.g., technician or personnel in communication with a technician) to comprehend and address vehicle engine conditions including diagnostic/fault cause conditions in accordance with generated analysis data that may include engine components.
Neither Chinnadurai nor Kuschke appears to teach “the data repository is used to store” “appearance images of different types of engines.”
Mylaraswamy discloses a system/method for characterizing engine wear (Abstract) that includes collecting/storing engine information that include engine appearance images for diagnostics (Abstract; col. 4 lines 21-35 describing collection of engine images reflecting operational conditions (relative appearance)).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mylaraswamy’s teaching of collecting/storing engine appearance images for engine diagnostics to the system taught by Chinnadurai as modified by Kuschke and Charbonnel such that engine images data is included in the collected engine information stored in the data repository.
Such a combination would amount to using a known design option in the form of engine image data as useful diagnostic/maintenance information to achieve predictable results.
The combination of Chinnadurai, Kuschke, and Mylaraswamy further teaches “wherein the engine information comprises several different engine models (Chinnadurai: [0034], [0039], [0041], [0046]-[0053], [0059], and [0063]-[0065] information about different vehicles includes engine information; [0073]-[0076] engine information includes information for different models of engines), engine images (Mylaraswamy: (Abstract; col. 4 lines 21-35),” “fault state characterization (Chinnadurai: [0008] and [0025]-[0026] collected operational/diagnostic data includes failure conditions),” “and fault occurrence scenarios (Chinnadurai: [0037] and [0066] failure conditions associated with ambient and operating conditions).”
Kuschke further teaches collecting maintenance history data for engine diagnostics and maintenance ([0009] historical data of previous maintenance may be used for determining maintenance).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Kuschke’s teaching of collecting and using maintenance history data for engine diagnostics/maintenance to the system taught by Chinnadurai such that maintenance history data is included in the collected engine information.
Such a combination would amount to using a known design option in the form of maintenance history as useful diagnostic/maintenance information to achieve predictable results.
Chinnadurai further discloses the significance of duration of use and fault timing ([0037] failure conditions associated with time in terms of a period and/or point in time; [0066] historical data associated with vehicle information and ambient/operating conditions during which the data was recorded) but neither Chinnadurai nor Kuschke appear to expressly teach duration of use and fault occurrence time as being collected.
Charbonnel discloses a system/method for implementing diagnostic engine monitoring (Abstract) that includes collecting fault occurrence times ([0015] and [0023] histogram data associated with time that operating parameters were measured to indicate when operating parameters exceed threshold) and duration of use ([0023] timestamp data indicating duration of engine operation).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Charbonnel’s teaching of collecting fault occurrence time and duration of use data for engine diagnostics/maintenance to the system taught by Chinnadurai as modified by Kuschke such that fault occurrence time and duration of use data is included in the collected engine information.
Such a combination would amount to using a known design option in the form of fault occurrence time and duration of use data as useful diagnostic/maintenance information to achieve predictable results.
The combination of Chinnadurai, Kuschke, Mylaraswamy, and Charbonnel further teaches “the information matching module is used to” “determine a system part of an engine failure (Chinnadurai: [0099] and [0109] comparison may result in determining failure condition including component failure; FIG. 3 components may be engine components (represented as nodes under engine node N11)) according to a fault state representation (Chinnadurai: [0008] and [0025]-[0026] collected data for diagnostics includes failure conditions) and a fault occurrence scene in the engine information (Chinnadurai: [0037] and [0066] failure conditions associated with ambient and operating conditions).”
Kuschke further teaches using maintenance history data for engine diagnostics and maintenance determinations that reflect an influence degree of a fault ([0009] historical data of previous maintenance may be used for determining scope of maintenance. Examiner notes that scope of maintenance corresponds to and is reflective of an influence degree of fault; claim 10 describing maintenance history data directly in terms of maintenance parameter and indirectly in terms of post-maintenance performance data used in assessing influence of maintenance on further maintenance requirements).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Kuschke’s teaching of using maintenance history data for engine diagnostics and maintenance determinations that reflect an influence degree of a fault to the system taught by Chinnadurai as modified by Kuschke, Mylaraswamy, and Charbonnel such that maintenance history data is used for judging an influence degree of a fault.
Such a combination would amount to using a known design option in the form of maintenance history as useful diagnostic/maintenance information to achieve predictable results.
Chinnadurai further discloses the significance of duration of use and fault timing ([0037] failure conditions associated with time in terms of a period and/or point in time; [0066] historical data associated with vehicle information and ambient/operating conditions during which the data was recorded) but none of Chinnadurai, Kuschke, and Mylaraswamy appear to expressly teach judging an influence degree of a fault according to a “use time” and “fault occurrence time.”
Charbonnel discloses a system/method for implementing diagnostic engine monitoring (Abstract) that includes using fault occurrence times ([0015] and [0023] histogram data associated with time that operating parameters were measured to indicate when operating parameters exceed threshold) and usage times for fault diagnostics ([0023] timestamp data indicating duration of engine operation).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Charbonnel’s teaching of collecting fault occurrence time and duration of use data for engine diagnostics/maintenance to the system taught by Chinnadurai as modified by Kuschke and Mylaraswamy such that the system is configured to use fault occurrence times and usage times for engine diagnostics and maintenance determinations that reflect an influence degree of a fault.
Such a combination would amount to using a known design option in the form of fault occurrence time and duration of use data as useful diagnostic/maintenance information to achieve predictable results.
Chinnadurai further teaches that the information matching module associates and retrieves engine information according to the engine model ([0072]-[0076] engine data such as mileage, usage, fault code, etc., associated within database by respective engine models), but none of Chinnadurai, Kuschke, and Charbonnel appear to teach “wherein the information matching module retrieves images of the same engines stored in the data repository according to the engine model in the engine information, and performs a similarity matching between the images of the same engines and the engine images in the engine information.”
Mylaraswamy discloses a system/method for characterizing engine wear (Abstract) that includes retrieving images of the same engines stored in the data repository (Abstract baseline images compared to images obtained following operation (requires retrieval of the baseline images); FIG. 1 blocks 144 and 146 depicting retrieval of baseline images from image library, col. 4 lines 43-56) according to an engine model (col. 7 lines 47-54 CAD model selected based on engine type), and performs a similarity matching between the images of the same engines and the engine images in the engine information (FIG. 1 blocks 148 and 152 depicting retrieval of baseline images from image library for comparison, col. 4 lines 60-67).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mylaraswamy’s teaching of retrieving images of the same engines stored in the data repository and performing a similarity matching between the images of the same engines and the engine images in the engine information to the system taught by Chinnadurai, as modified by Kuschke, Mylaraswamy, and Charbonnel in which engine model information is used for database association with other engine information (to retrieve engine information according to engine model) such that in combination the system is configured such that the information matching module retrieves images of the same engines stored in the data repository according to the engine model in the engine information, and performs a similarity matching between the images of the same engines and the engine images in the engine information.
Such a combination would amount to using a known design option in the form of engine image data as useful diagnostic/maintenance information and retrieving such data using a known design operation to achieve predictable results.
Regarding “wherein the fault maintenance plan comprises one or more of ignition system maintenance, fuel injector maintenance, fuel pump maintenance, cylinder maintenance, and intake system maintenance,” Chinnadurai teaches a wide variety of the engine systems/components analyzed for potential indication of failure and need of maintenance include an ignition system ([0038], [0063], [0064]), cylinder ([0065]), and intake system ([0046]) and the other systems/components specified for example in [0038]-[0065]. Kuschke discloses a system/method for performing maintenance on an engine based on engine analysis information (Abstract; claim 10) and Kuschke’s method for determining maintenance requirements are not limited to any particular type or category of engine maintenance ([0007] describing a variety of operational parameter used for determining performance; [0025] explaining that maintenance/repair performed is a function of engine performance metrics).
Furthermore, the particular maintenance activities recited by claim 1 were well known in the prior art prior to the effective filing data as was centralized means/systems for implementing a variety of types of repair/replacement maintenance as discloses by Rich (Abstract, [0028]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have combined Rich’s teaching of implementing various replacement/repair processes as directed by a centralized system with the system taught by Chinnadurai as modified by Kuschke and Mylaraswamy which teaches performing repair/maintenance with respect to a variety of engine systems/components such that in combination the system is configured such that the fault maintenance plan [of the fault processing module] comprises one or more of ignition system maintenance, fuel injector maintenance, fuel pump maintenance, cylinder maintenance, and intake system maintenance.
The motivation would have been to remediate any of a variety of potential faults that may be recognized by the diagnostics procedures.
The combination of Chinnadurai, Kuschke, Mylaraswamy, Charbonnel, and Rich further teaches “wherein the operation analysis module is used to” “carry out three-dimensional modeling of the engine under normal operating conditions to obtain the engine model (Chinnadurai: [0037], [0066], and [0072]-[0077] historical vehicle operational data for normal operating conditions collected and associated with respective types of engines to form respective models from which parameter ranges are determined; FIG. 4 and [0080]-[0085] depicting and describing multi-dimensional modeling (e.g., parameter space including failure operating conditions spaces P that include normal operation PN (one dimension) and at least two other condition spaces (dimensions) as explained in [0084] which describes the depicted 2-D parameter space actually representing a higher-dimensionality; [0106] historical data represented in multi-dimensional vector space having dimensionality equal to the number of measured parameters (three or more measured parameters as disclosed in [0037]-[0065]), analyze an engine operation mechanism is analyzed according to the engine model (Chinnadurai: [0085] parameter spaces represent operating conditions that per [0037]-[0065] represent operation mechanisms), simulate system components of the engine (Chinnadurai: [0085] parameter spaces represent operating conditions that per [0037]-[0065] represent modeled (simulated) engine components), use a system comprising a” [computer] (Chinnadurai: [0009]-[0010] method is computer-implemented; FIG. 1 data collector/analyzer includes computer 12) “to analyze and correct” [failure] “of engine system components (Chinnadurai: [0026] and [0097]-[0098] and [0100]-[0101] diagnose potential abnormal/failure conditions related to operation (wear); Kuschke: Abstract; claim 10 perform maintenance).”
Kuschke further teaches that the failure of the engine component(s) may be a “wear” of the engine system components ([0036]-[0037] formula for determining deterioration (wear) of components) and carrying out a life prediction of system components according to engine operation ([0037]-[0038] need for maintenance (life prediction) determined in accordance with component deterioration data).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Kuschke’s teaching of that the failure of the engine component(s) may be a “wear” of the engine system components and carrying out a life prediction of system components according to engine operation to the system taught by Chinnadurai as modified by Kuschke, Mylaraswamy, Charbonnel, and Rich such that in combination the system is configured to analyze and correct “wear” of engine system components,” and to carry out a life prediction of each system according to the engine operation mechanism.
Such a combination would amount to implementing a known design option in terms of a component analytic metric (wear) and a known design option in terms of engine health monitoring (life prediction) to achieve predictable results.
None of Chinnadurai, Kuschke, Mylaraswamy, Charbonnel, and Rich appear to expressly teach that the computer is configured as a host computer and a slave computer.
Using host/slave computer configuration for implementing vehicle monitoring by collecting and analyzing vehicle data that is in turn used in an overall computing system for determining maintenance requirements was known prior to the effective filing date. For example Battista discloses a method/system for monitoring vehicles to collect/analyze information for making maintenance determinations ([0012]-[0013], [0024], and[0030]) in which the computer platform is implemented as a master (host) and slave configuration ([0020] claim 2 wireless devices that include processors configured as master-slave).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Battista’s teaching of using a master/slave computing configuration for monitoring vehicles to collect/analyze information for making maintenance determinations to the system disclosed by Chinnadurai as modified by Kuschke, Mylaraswamy, Charbonnel, and Rich, which teaches a computer system for analyzing and correcting wear, carrying out a life prediction, and generating an displaying an analysis report, such that in combination the system is configured to include/use a system comprising a host computer and a slave computer as part of an overall computer configuration for implementing such functions.
The motivation would have been to enable centralized coordination/control of multiple otherwise independent computing devices that may be assigned for respective collection/processing tasks as suggested by Battista.
The combination of Chinnadurai, Kuschke, Mylaraswamy, Charbonnel, Rich, and Battista further teaches “wherein the maintenance report module is used to” “summarizes components that are prone to failure of different types of engines according to” [failure location data] and “analysis reports classified and stored by the data repository, and generates summary results (Chinnadurai: [0037]-[0066] historical data stored in database summarize components subject/prone to failure), use the information matching module to preferentially identify the components that are prone to failure of different types of engines according to the summary results (Chinnadurai: [0037]-[0066] historical data stored in database summarize components subject/prone to failure), extract analysis reports of a same component of different types of engines in the data repository (Chinnadurai: processing of historical operational data for different types of engines (e.g., [0073]-[0076]) entails extracting/retrieving the data from the database 24), evaluate an operation stability of different types of engines” [comparatively with respect to] “components (Chinnadurai: FIG. 5 blocks 66 and 68, [0108]-[0109] measurements (associated with particular components per [0101]) for target vehicle which may have any one of a variety of different engines ([0073]-[0076]) and for which the method is implemented for different target vehicles (Abstract) are comparatively processed with respect to ranges established via historical data. Comparison of same components generally inferred and more specifically conveyed in [0100] and [0109]) in the analysis report to generate evaluation results (Chinnadurai renders obvious generating the analysis report/results as set forth above).”
Chinnadurai does not appear to expressly disclose summarizing components that are prone to failure of different types of engines according to “the identification results.” However, Chinnadurai discloses an open-ended manner of collecting failure condition data for the historical database such that it would have been obvious to one of ordinary skill in the art before the effective filing date, to have recognized each new failure condition determination for each target vehicle to be a readily available source for summarizing components that are prone to failure with the motivation being to utilize each new failure condition determination to further enhance failure diagnostics.
Chinnadurai does not appear to expressly teach an operation stability of different types of engines is evaluated “according to a life prediction result of” the same type of components.
Charbonnel discloses a system/method for implementing diagnostic engine monitoring (Abstract) that includes determining a life prediction as a metric of engine condition (Abstract determine period within which engine likely to fail; FIG. 3 block 350, [0046]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Charbonnel’s teaching of determining a life prediction as a metric of engine condition to the system taught by Chinnadurai as modified by Kuschke and Mylaraswamy in which operation stability of different types of engines is evaluated comparative with respect to the same type of components based on other condition metrics such that in combination the system is configured to evaluate the operation stability of different types of engines according to a life prediction result of the same type of components.
Such a combination would amount to utilizing a known design option for ascertaining engine health/stability to achieve predictable results.
As to claim 5, the combination of Chinnadurai, Kuschke, Mylaraswamy, Charbonnel, Rich, and Battista teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1,” and Chinnadurai teaches a wide variety of the engine systems/components analyzed for potential indication of failure and need of maintenance include an ignition system ([0038], [0063], [0064]), cylinder ([0065]), and intake system ([0046]) and the other systems/components specified for example in [0038]-[0065]. Kuschke discloses a system/method for performing maintenance on an engine based on engine analysis information (Abstract; claim 10) and Kuschke’s method for determining maintenance requirements are not limited to any particular type or category of engine maintenance ([0007] describing a variety of operational parameter used for determining performance; [0025] explaining that maintenance/repair performed is a function of engine performance metrics).
Furthermore, the particular maintenance activities recited by claim 5 were well known in the prior art prior to the effective filing data as was centralized means/systems for implementing a variety of types of repair/replacement maintenance as discloses by Rich (Abstract, [0028]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have combined Rich’s teaching of implementing various replacement/repair processes as directed by a centralized system with the system taught by Chinnadurai as modified by Kuschke, Mylaraswamy, Charbonnel, Rich, and Battista which teaches performing repair/maintenance with respect to a variety of engine systems/components such that in combination the system is configured such that “the ignition system maintenance comprises high voltage line replacement, spark plug replacement, spark plug cleaning, and distributor maintenance; the fuel injector maintenance comprises injector cleaning, injector replacement, and injector line maintenance; the fuel pump maintenance comprises fuel pump diaphragm replacement and relay replacement; the cylinder maintenance comprises cylinder leakage repair and cylinder replacement; and the intake system maintenance comprises sensor replacement, one-way valve replacement, and piston cleaning.”
The motivation would have been to remediate any of a variety of potential faults that may be recognized by the diagnostics procedures.
As to claim 7, the combination of Chinnadurai, Kuschke, Mylaraswamy, Charbonnel, Rich, and Battista teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1, wherein the data repository is classified and stored respectively according to” [failure location data] “and the analysis reports of the engine model at different times (Chinnadurai: [0028] database 24 part of/processed by diagnostic data collector/analyzer 10; [0029] stored historical operational data including failure condition data is stored and associated/classified with various vehicles and with test subject vehicle; [0037] data is associated with respective times), and the analysis reports of the same component of different types of engines are unified (Chinnadurai: [0073]-[0076] same component of difference vehicles associated with analysis are unified in the collected historical data).”
Chinnadurai does not appear to expressly disclose that the data repository is classified and stored according to “the identification results.” However, Chinnadurai discloses an open-ended manner of collecting failure condition data for the historical database such that it would have been obvious to one of ordinary skill in the art before the effective filing date, to have recognized each new failure condition determination for each target vehicle to be a readily available source for supplementing the historical database with the motivation being to utilize each new failure condition determination to further enhance the database.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai in view of Kuschke, Mylaraswamy, Charbonnel, Rich, and Battista as applied to claim 1 above, and further in view of Lairsey (US 2020/0252276 A1) and Wu (US 2020/0410280 A1).
As to claim 4, the combination of Chinnadurai, Kuschke, and Mylaraswamy teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1,” but does not appear to teach using engine images for engine diagnostics and therefore do not teach “wherein when there is no engine image matching with the engine model in the data repository, carrying out a search online according to the engine model by the information matching module, and setting a similarity threshold according to a corresponding engine image, and when a similarity between an image obtained by a search result and an image uploaded in the engine information reaches the similarity threshold, storing an image obtained by the search result as an engine image.”
Mylaraswamy discloses a system/method for characterizing engine wear (Abstract) that includes retrieving images of the same engines stored in the data repository (Abstract baseline images compared to images obtained following operation (requires retrieval of the baseline images); FIG. 1 blocks 144 and 146 depicting retrieval of baseline images from image library, col. 4 lines 43-56), and performs a similarity matching between the images of the same engines and the engine images in the engine information (FIG. 1 blocks 148 and 152 depicting retrieval of baseline images from image library for comparison, col. 4 lines 60-67 (Examiner notes that such retrieval will or will not result in a matching)) in which the retrieval of the baseline images itself entails similarity matching of the baseline images is based on a similarity matching for selecting the baseline images that correspond to the operational images and therefore to be used for the diagnostic comparison (col. 7 lines 47-67 performing a template match for selecting a baseline images according to a best fit with the data image of the engine). In this manner Mylaraswamy teaches maintaining a repository of reference engine images that are similarity matched with respect to the target engine for the purpose of engine diagnostics.
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Mylaraswamy’s teaching of maintaining a repository of images corresponding in terms of similarity to the target engines under analysis and in which matching is performed to retrieve the template/baseline images to the system taught by Chinnadurai as modified by Kuschke in which engine model information is used for database association with other engine information (to retrieve engine information according to engine model) such that in combination the system is configured such that engine image matching or no matching occurs for the data repository.
Such a combination would amount to using a known design option in the form of engine image data as useful diagnostic/maintenance information and retrieving such data using a known design operation to achieve predictable results.
Mylaraswamy appears largely silent regarding the manner in which the image repository is updated to add engine image data for processing and therefore does not teach the combination of steps including when there is no engine image matching with the engine model in the data repository, “carrying out a search online according to the engine model by the information matching module, and setting a similarity threshold according to a corresponding engine image, when a similarity between an image obtained by a search result and an image uploaded in the engine information reaches the similarity threshold, storing an image obtained by the search result as the engine image.”
Lairsey discloses a system/method for hardware management that uses image recognition for locating/identifying equipment (Abstract) and further discloses that it is necessary to update an image database/library to accommodate imaging analysis of newly added equipment (i.e., updating the image library to add matching image). Wu discloses a system/method for updating image databases (Abstract; [0034], [0053]-[0054]) that includes when there is a lack of matching image(s) for a target object carrying out a search” “according to the targe image (FIG. 2 blocks 210 and 220 searching for images corresponding to an acquired image of a target object (need for obtain the matching images)) and setting a similarity threshold according to a corresponding object image ([0026] and [0028] threshold used for determining similarity between image templates and target object), when a similarity between an image obtained by a search result and a target image reaches the similarity threshold, updating the image database (FIG. 1 block 120, [0034], [0052]-[0053], [0133]).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Lairsey’s teaching of adding new images to update an image database to account for new equipment to the system taught by Chinnadurai as modified by Kuschke such that in combination the system is configured to store an image obtained by some form of search.
The motivation would have been to enable the image database to comprehensively cover the equipment as new equipment is added as disclosed by Lairsey.
It would further have been obvious to one of ordinary skill in the art before the effective filing date, to have applied Wu’s teaching of when there is a lack of matching image(s) for a target object carrying out a search according to the targe image and setting a similarity threshold according to a corresponding object image, updating the image database when a similarity between an image obtained by a search result and a target image reaches the similarity threshold to the system taught by Chinnadurai as modified by Kuschke, Mylaraswamy, and Lairsey, which teaches storing new images corresponding to a new target in the database, such that in combination the system is configured for carrying out a search according to the engine model by the information matching module, and setting a similarity threshold according to a corresponding engine image, when a similarity between an image obtained by a search result and an image uploaded in the engine information reaches the similarity threshold, storing an image obtained by the search result as the engine image.
The motivation would have been to leverage database image repositories to identify a correctly matching image for a new target object to enhance the image database (taught by Chinnadurai in combination with Lairsey).
The combination of Chinnadurai, Kuschke, Mylaraswamy, Chabonnel, Rich, Battista, Lairsey, and Wu does not expressly teach that the search is an “online” (e.g., over a network) search. Wu teaches server-based network acquisition of data ([0021] method (includes search) performed by server; [0158] network acquisition).
It would have been obvious to one of ordinary skill in the art before the effective filing date, to have combined Wu’s teaching of server based network acquisition with the system taught by Chinnadurai as modified by Kuschke, Mylaraswamy, Lairsey, and Wu such that the system implements online searching for accessing image data with which to match a target image.
Such a combination would amount to selecting a known design option for accessing distributed data to achieve predictable results.
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
/LINA CORDERO/Primary Examiner, Art Unit 2857
