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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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, 3-4, and 8, “fault processing module” in claims 1 and 5, “operation analysis module” in claims 1 and 6, and “maintenance report module” in claims 1 and 8.
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. As set forth below, claims 1-8 are rejected under 112(b) because the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the “perform fault maintenance” function recited in claim 1 or the “maintenance function” recited in claim 5.
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 Objections
Claims 1 and 5 are objected to because of the following informalities:
In claim 1 line 6, “the engine” lacks antecedent basis and therefore should read “an engine.”
In claim 5 line 9, “and” should be inserted between “replacement;” and “the intake.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-8 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
In claim 1 lines 11-12, “the recognition result” lack sufficiently clear antecedent basis with reference to “identify a fault location” in line 6. While the “recognition result” appears to refer to a result of “identify a fault location,” line 8 recites “identification results” that also appear to refer to “identify a fault location” rendering the use of different terminology (identify versus recognize) potentially confusing. For the purpose of examination, “the recognition result” is interpreted as “the identification results.”
Claims 2-8 depend from claim 1 and are likewise rejected for the same reasons.
In claim 3 line 2, “retrieves images of the same engines stored in the data repository” renders claim 3 indefinite because the meaning of “the same engines” in this context is unclear. Based on apparent intent, and for purposes of examination, “retrieves images of the same engines stored in the data repository” is interpreted as “retrieves images of engines that are the same as the matched engine model.”
Claim limitation “fault processing module” invokes 35 U.S.C. 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the “perform fault maintenance” function recited in claim 1 or the “maintenance function” recited in claim 5. Specifically, the written description does not appear to disclose a manner in which computer program instructions are able to “perform fault maintenance” as recited in claim 1 and/or to directly implement the various maintenance functions set forth in claim 5. Therefore, claims 1 and 5 are indefinite and are rejected under 35 U.S.C. 112(b). Claims 2-4 and 6-8 depend from claim 1 and are likewise rejected for the same reasons.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
In claim 6 line 2, “three-dimensional modeling and meshing of the engine” renders claim 6 indefinite because the meaning of what may encompass “meshing” of the engine (e.g., potentially relating to a characteristic of the manner of modeling) is entirely unclear from the claim language itself and as interpreted in view of the specification. For the purpose of examination, “meshing” is interpreted as a function related to the modeling in which multiple aspects of the engine are determined/considered in combination (meshed) as part of the modeling.
In claim 6 line 5, “an upper and lower computer system” renders claim 6 indefinite because the meaning of what may encompass “an upper” computer system and a “lower” computer system, individually and in combination, is entirely unclear from the claim language itself and as interpreted in view of the specification. Given that Applicant’s disclosure provides no basis for reasonably speculating about what may be encompassed by an “upper and lower computer system,” and for the purpose of examination, “an upper and lower computer system” is interpreted as a computer system performing multiple different (upper and lower) functions.
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-8 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;
the information input module is used to input information of several types of engines;
the information matching module is used to match an engine model according to engine information and identify a fault location of the engine;
the fault processing module is used to perform fault maintenance according to matching results and identification results of the information matching module;
the operation analysis module is used to analyze a normal operation state of the engine after maintenance, generate and display an analysis report;
the data repository is used to store the engine information, the matching result, the recognition result and the analysis report, the data repository also stores appearance images of different types of engines;
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, 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 engine information and identify a fault location of the engine,”
“analyze a normal operation state of the engine after maintenance, generate” “an analysis report,”
“summarize, regulate” “fault causes and fault parts of different types of engines according to stored data in the data repository, and optimize the information matching module according to a regulated result,”
may be performed as mental processes.
Matching an engine model according to engine information and identify a fault location of the engine maybe performed via mental processes (e.g., evaluation and judgment). Analyzing a normal operation state of the engine after maintenance and generating an analysis report may be performed via mental processes (e.g., evaluation of operation state information and judgment in ascertaining conclusions). Summarizing and regulating fault causes and fault parts of different types of engines according to stored data in the data repository may be performed via mental processes (e.g., evaluation of stored data and judgement in categorizing (summarized and regulated) fault causes/parts. 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).
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,” and 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,” 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 is unclear in scope as set forth in the grounds for rejecting claim 1 under 112(b), but nevertheless appears to represent 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.
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. 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), 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.
Independent claim 1 is therefore not patent eligible.
Claims 2-8, 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 2-8 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.
For example, claim 8 further characterizes the nature/type of the data without specifying an additional elements indicating some manner of collection or processing and therefore falls within the same judicial exception.
Claim 3 recites “performs a similarity matching between the images of the same engines and the engine images in the engine information; the information matching module determines a system part of an engine failure according to a fault state representation and a fault occurrence scene in the engine information, and judges an influence degree of a fault according to a use time, maintenance history, and fault occurrence time,” which falls within the mental processes exception because these steps may be performed via mental processes (e.g., evaluation and judgment). Claim 3 further recites the additional element “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,” which 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.
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 6 recites “three-dimensional modeling and meshing of the engine under normal operating conditions to obtain the engine model,” which appears to fall 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.
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.
Claim 6, as best understood and interpreted in view of the grounds for rejecting claim 6 under 112(b), further recites “an engine operation mechanism is analyzed according to the engine model, system components of the engine are simulated, and” “analyze and correct wear of engine system components, and a life prediction of each system component is carried out according to the engine operation mechanism, and the analysis report is generated” the steps of which may individually and in combination be performed via mental processes (e.g., evaluation and judgment including analyzing and correcting wear via evaluation condition data to ascertain necessary correction). The use of a multifunction computer to implement the functions falling within the abstract idea constitutes 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.
Claim 8 recites “preferentially identify the components that are prone to failure of the engines according to the summary results” and “an operation stability of different types of engines is evaluated according to a life prediction result of the same type of components in the analysis report,” which fall within the mental processes exception because these steps may be performed via mental processes (e.g., evaluation and judgment). Claim 8 further recites the additional elements “wherein the maintenance report module summarizes 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, and generates summary results,” “the same component analysis report of different types of engines in the data repository is extracted,” and “generate evaluation results,” which represents a form of substantially ordinary data processing functions including collection, organization, and output having no particularized functional relation to the steps falling within the judicial exception and therefore constitute insignificant extra solution activity.
Dependent claims 2-8 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 and 6-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 and Mylaraswamy (US 7,337,058 B1).
As to claim 1, as best understood in view of the grounds for rejecting claim 1 under 112(b), 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);
the information input module is used to input 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);
the information matching module is used to match an engine model according to 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]) and identify a fault location of the 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);
the fault processing module is used to” [determine] “fault maintenance 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) ;
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))”
“the data repository is used to store the engine information, the matching result, the recognition result and 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),”
“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 also stores 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.
As to claim 6, as best understood in view of the grounds for rejecting claim 6 under 112(b), the combination of Chinnadurai, Kuschke, and Mylaraswamy teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1, wherein the operation analysis module carries out three-dimensional modeling and meshing 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]);
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), system components of the engine are simulated (Chinnadurai: [0085] parameter spaces represent operating conditions that per [0037]-[0065] represent modeled (simulated) engine components), and an upper and lower computer system (Chinnadurai: [0009]-[0010] method is computer-implemented; FIG. 1 data collector/analyzer includes computer 12 (inherently includes multiple functional levels)) is used 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),” “and the analysis report is generated (Chinnadurai renders obvious generating the analysis report as set forth in the grounds for rejecting claim 1) .”
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 and Mylaraswamy 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.
As to claim 7, the combination of Chinnadurai, Kuschke, and Mylaraswamy 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.
Claims 2-3 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai in view of Kuschke and Mylaraswamy as applied to claim 1 above, and further in view of Charbonnel (US 2022/0155772 A1).
As to claim 2, the combination of Chinnadurai, Kuschke, and Mylaraswamy teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1, 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.
As to claim 3, as best understood in view of the grounds for rejecting claim 3 under 112(b), the combination of Chinnadurai, Kuschke, and Mylaraswamy teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1,”
“the information matching module determines 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 and Mylaraswamy 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.
As to claim 8, the combination of Chinnadurai, Kuschke, and Mylaraswamy teaches “[t]he multi-engine synchronous detection and analysis system according to claim 1, wherein the maintenance report module 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), the information matching module is used to preferentially identify the components that are prone to failure of the engines according to the summary results (Chinnadurai: [0037]-[0066] historical data stored in database summarize components subject/prone to failure), and the same component analysis report of different types of engines in the data repository is extracted (Chinnadurai: processing of historical operational data for different types of engines (e.g., [0073]-[0076]) entails extracting/retrieving the data from the database 24), an operation stability of different types of engines is evaluated” [comparatively with respect to] “the same type of 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 as set forth in the grounds for rejecting claim 1).”
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.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai in view of Kuschke and Mylaraswamy 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 do 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, 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.”
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, 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.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Chinnadurai in view of Kuschke and Mylaraswamy as applied to claim 1 above, and further in view of Rich (US 2022/0306050 A1).
As to claim 5, as best understood in view of the grounds for rejecting claim 5 under 112(b), the combination of Chinnadurai, Kuschke, and Mylaraswamy 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 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 “wherein a maintenance function [of the fault processing module] comprises ignition system maintenance, fuel injector maintenance, fuel pump maintenance, cylinder maintenance, and intake system maintenance;
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;
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Analogous devices and methods for engine diagnostics are represented by KR20010095904A (attached).
Conclusion
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
/ALEXANDER SATANOVSKY/Primary Examiner, Art Unit 2857
Prosecution Insights