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 Arguments
Applicant's arguments filed 29 May 2026 have been fully considered but they are persuasive only in part.
First, the drawing objection is overcome by the claim amendments and the replacement drawing sheets.
Second, the previous claim objections are overcome by applicant’s claim amendments, but the amendment to claim 18 precipitates a new (minor) claim objection, as detailed below.
Third, the claim amendments overcome the previous rejection under 35 U.S.C. 112(a), description requirement, and most of the rejections under 35 U.S.C. 112(b), with the remaining (and new) issues under 35 U.S.C. 112(b) dealt with below.
In this respect, “a production batch” is still indefinite from the teachings of the specification, with production batch having indeterminate metes and bounds, and applicant’s arguments providing no additional clarity to this term.
Additionally, applicant now inconsistently (e.g., in claim 1) uses “real-time operating data”, “the vehicle’s real-time data”, and “the vehicle’s real-time operation data”, leading to uncertainty as to whether these are all referring to the same data or not.
Regarding the “severity” of the current fault in claim 18, the examiner (upon reconsideration and in light of the “medium” severity fault at published paragraph [0048]) now believes this term/concept would be reasonably certain to those skilled in this art. Accordingly, that aspect of the indefiniteness rejection of claim 18 is withdrawn by the examiner, with applicant’s amendments curing other indefiniteness issues in that claim.
Fourth, after consultation with a TQAS[1], applicant’s arguments regarding the 35 U.S.C. 101 rejection are not convincing. In this respect, applicant argues first:
A vehicle repair person working from memory does not practically perform this claimed ordered combination. In particular, the human mind does not store and update the claimed cloud server tables Ta, Tb, and Tc, dynamically adjust adaptive thresholds across vehicles, usage environments, and operating conditions, perform feature comparison using feature matching algorithms, weighted vector algorithms, and multidimensional data space mapping methods, and remove duplicate or invalid data by data cleaning and feature selection as recited in amended claim 1. The claim therefore is directed to a specific technological vehicle diagnostic process, not merely a mental process.
Other than the cloud server limitation, the human mind could practically perform process/action described above, even if not as efficiently as on a high-speed computer. Regarding the cloud server, this is merely a generic computer component for fault diagnosis (see e.g., the literature cited herewith), and the abstract idea is thus simply “applied” on a general-purpose computer, which is not indicative of integration into a practical application. Accordingly, applicant’s arguments are not persuasive.
Next, applicant argues:
Even if the Examiner maintains that certain calculations or comparisons involve an abstract idea, amended claim 1 integrates any such alleged abstract idea into a practical application. The claimed workflow is applied in a vehicle diagnostic system to generate vehicle repair recommendations using real-time vehicle operating data, cloud-server historical fault information, production-batch-related fault information, model-related fault information, adaptive thresholding, feature-based comparison, real-time fault diagnosis, and data cleaning/feature selection. The claimed operations are not performed for their own sake. They are applied to diagnose vehicle faults and generate a customized repair plan for a vehicle.
The examiner believes that applicant has, in the argument above, described only an improved abstract idea of e.g., diagnosing vehicle faults and generating a customized repair plan for a vehicle. See Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a *new* abstract idea is still an abstract idea") (emphasis in original). Moreover, improving an abstract idea is not an improvement to the functioning of a computer, or to any other technology or technical field - see MPEP 2106.05(a). Accordingly, applicant’s arguments are not persuasive in this respect.
Next applicant argues:
The practical application is further reflected in the claimed outputs. The comprehensive fault diagnosis result and comprehensive repair recommendation are generated from Res1/Sug1 and/or Res2/Sug2 after the claimed historical and/or real-time diagnostic processing, duplicate or invalid data are removed, and the cloud server generates and transmits a customized repair plan to the requester. Thus, amended claim 1 applies the claimed data processing to a concrete vehicle repair recommendation workflow.
The examiner believes that a human being can provide (generate/transmit) these claimed outputs, including the customized repair plan, e.g., by the human being speaking to a co-worker, and he can think before he speaks and by such thinking remove duplicate or invalid data. To have a generic cloud server provide the outputs is merely an “apply it” type limitation (e.g., applying the abstract idea to a computer).
Next applicant argues, regarding an improvement:
Amended claim 1 provides a technical improvement in vehicle fault diagnosis systems. Conventional systems that rely primarily on fault codes or current sensor measurements have limited ability to account for historical vehicle faults, production-batch fault patterns, model-related fault patterns, environmental conditions, and driving behavior. Amended claim 1 addresses these limitations by using a cloud server that stores and updates Ta, Tb, and Tc, performs historical fault diagnosis in a specified sequence, applies an adaptive threshold dynamically adjusted based on different vehicles, usage environments, and operating conditions, performs feature extraction and algorithmic comparison against data in Ta, Tb, and/or Tc, and uses real-time fault diagnosis based on road environment, climate conditions, and driving behavior when no identical historical fault has occurred.
This provides a technical improvement because the diagnostic system is not limited to static fault-code lookup or generic repair advice. Instead, the system uses structured historical fault information, adaptive thresholding, algorithmic feature comparison, and data cleaning/feature selection to improve vehicle fault diagnosis accuracy, reduce duplicate or invalid diagnostic information, and generate more targeted repair recommendations.
Again, the examiner believes that applicant has, above, described an improved abstract idea of e.g., generating more targeted repair recommendations. See Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a *new* abstract idea is still an abstract idea") (emphasis in original). The cloud server is apparently a generic computer component for fault diagnosis (see the literature cited herewith). Moreover, improving an abstract idea is not an improvement to the functioning of a computer, or to any other technology or technical field - see MPEP 2106.05(a). Accordingly, applicant’s arguments are not persuasive.
Lastly in this respect applicant argues:
The amended claims do not preempt all vehicle fault diagnosis methods or all vehicle repair recommendation techniques. The claims are limited to a specific workflow requiring, among other things, cloud-server tables Ta, Tb, and Tc, a specified historical diagnosis sequence, adaptive thresholding, feature extraction and algorithmic comparison using feature matching algorithms, weighted vector algorithms, and multidimensional data space mapping methods, real-time fault diagnosis using road environment, climate conditions, and driving behavior when no identical historical fault has occurred, and removal of duplicate or invalid data using data cleaning and feature selection.
Other vehicle diagnostic approaches remain available, including conventional OBD fault code lookup, manual mechanic diagnosis, rule-based expert systems that do not use the claimed Ta/Tb/Tc sequence, systems that use only current sensor measurements, systems that do not dynamically adjust the claimed adaptive threshold, and systems that do not perform the claimed feature comparison and data cleaning/feature selection. Accordingly, the amended claims do not preempt vehicle fault diagnosis.
In this respect, while preemption is a concern for the 35 U.S.C. 101 issue, is not dispositive as to eligibility. See MPEP 2106.04, I.:
While preemption is the concern underlying the judicial exceptions, it is not a standalone test for determining eligibility. Rapid Litig. Mgmt. v. CellzDirect, Inc., 827 F.3d 1042, 1052, 119 USPQ2d 1370, 1376 (Fed. Cir. 2016). Instead, questions of preemption are inherent in and resolved by the two-part framework from Alice Corp. and Mayo (the Alice/Mayo test referred to by the Office as Steps 2A and 2B). Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1150, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016); Ariosa Diagnostics, Inc. v. Sequenom, Inc., 788 F.3d 1371, 1379, 115 USPQ2d 1152, 1158 (Fed. Cir. 2015). It is necessary to evaluate eligibility using the Alice/Mayo test, because while a preemptive claim may be ineligible, the absence of complete preemption does not demonstrate that a claim is eligible. Diamond v. Diehr, 450 U.S. 175, 191-92 n.14, 209 USPQ 1, 10-11 n.14 (1981) ("We rejected in Flook the argument that because all possible uses of the mathematical formula were not pre-empted, the claim should be eligible for patent protection").
Accordingly, applicant’s arguments are not persuasive in this respect.
In summation, regarding 35 U.S.C. 101, upon guidance from the TQAS, the examiner believes that claimed invention is directed to the data and how it is being analyzed (e.g., as observation, evaluation, judgment, opinion) e.g., on generic computer components, followed by generating and transmitting a repair plan based on the analyzing. So this appears to be part of the abstract idea, as opposed to an improvement to the functioning of a computer or an improvement to any other technology or technical field.
Lastly, applicant’s arguments concerning the patentability of the amended claims under 35 U.S.C. 103 are convincing. Accordingly, the previous prior art rejection is withdrawn.
Accordingly, applicant’s arguments are only persuasive in part.
Drawings
The drawings were received on 29 May 2026. These drawings are accepted by the examiner.
Specification
The disclosure is objected to because of the following informalities: in filed (or published) paragraph [0029] of the specification, “perform s fault diagnosis” should apparently read, “perform fault diagnosis”.
Appropriate correction is required.
Claim (Specification) Objections
Claim 18 is objected to because of the following informalities: in claim 18, lines 2ff, “a severity of current fault” should apparently read, “a severity of a current fault”, for grammatical correctness. Appropriate correction is required.
Claim Interpretation
Regarding (“if”) contingent or conditional clauses as recited in claim 1 at (S22) and now in claim 13[2]), the examiner applies the guidance of MPEP 2111.04, II. and the PTAB Decision in Ex parte RANDAL C. SCHULHAUSER et al. (Precedential), Appeal 2013-007847, decided 28 April 2016, where the Board decided:
"A proper interpretation of claim language, under the broadest reasonable interpretation of a claim during prosecution, must construe the claim language in a way that at least encompasses the broadest interpretation of the claim language for purposes of infringement. . . . [In a method claim, if] the condition for performing a contingent step is not satisfied, the performance recited by the step need not be carried out in order for the claimed method to be performed. . . . [However, the] broadest reasonable interpretation of a system claim having structure that performs a function, which only needs to occur if a condition precedent is met, still requires structure for performing the function should the condition occur. This interpretation of the system claim differs from the method claim because the structure [] is present in the system regardless of whether the condition is met and the function is actually performed. Unlike [the method claim], which is written in a manner that does not require all of the steps to be performed should the condition precedent not be met, [the system claim] is limited to the structure capable of performing all the recited functions."
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3, 5 to 8, 11 to 13, 15, and 17 to 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 1, lines 13ff, “a production batch-related fault table Tb” is indefinite and not reasonably certain in scope3, because it is unclear (from the teachings of the specification) how the metes and bounds of any or all “production batch[es]” as are covered by the claim might possibly be defined, with reasonable certainty. For example, might the year of a vehicle be a “production batch”, might a vehicle model be a production batch, might the country or plant of manufacture be a production batch, might all red vehicles be a production batch, might all unsold or leased vehicles be a production batch? Why or why not?
In claim 1, line 15, “production batch” is indefinite and unclear, with indeterminate metes and bounds, because it is unclear (from the teachings of the specification) how the metes and bounds of any or all “production batch” might possibly be defined, with reasonable certainty.
In claim 1, line 21, “usage environments” and “operating conditions” are indefinite in the claim context and from the teachings of the specification, having indeterminate metes and bounds that are not reasonably certain (e.g., which particular usage of what particularly, with environments defined particularly how, and operating conditions of what particularly defined particularly how?). For example, it is unclear from paragraph [0034] of the published specification whether “temperature, humidity, altitude” might be/refer to usage environments, operating conditions, or both, and what a difference might be between usage environments and operating conditions (e.g., what are the metes and bounds of “usage environments” and what are the metes and bounds of “operating conditions”, particularly?)
In claim 1, lines 22ff, “that is identical to the vehicle’s real-time data” is indefinite and unclear, with “the vehicle’s real-time data” also apparently having insufficient antecedent basis (e.g., is this referring back to the “real-time operating data of the vehicle” in line 3?)
In claim 1, lines 25ff, “the vehicle’s real-time operation data” is indefinite and unclear, with insufficient antecedent basis (e.g., is this referring back to the vehicle’s real-time data as recited in lines 22ff, or to the real-time operating data as recited in line 3, or to something else?) This quoted (“real-time operation data”) phrase is similarly unclear when referred back to later in the claim set (e.g., at line 29 in claim 1, etc.)
In claim 1, lines 45ff, “[wherein the repair recommendation] comprises an operational guidance recommendation, a hardware repair recommendation and a software/hardware improvement recommendation” is indefinite and unclear from the teachings of the specification. In this respect, it is unclear what the metes and bounds of any or all “operational guidance recommendation[s]” are (e.g., what might these guidance recommendations encompass and entail, with reasonable certainty?), and what operations might be subject to of the object of guidance recommendations (e.g., would these operational guidance recommendations include only recommendations to the driver [i.e., user of the vehicle] including modifications to driving habits or the implementation of regular inspections of specific components or recommendations to reduce the frequency of fast charging, to avoid charging in high-temperature environments, and to regularly check the battery cooling system [published paragraphs [0047] and [0048]], or might they also or alternately include “text guidance for repair operations” for users or mechanics at published paragraph [0041]?). Additionally, it is unclear what the metes and bounds of “software/hardware improvement recommendation” are, with “improvement” being facially subjective (see MPEP 2173.05(b), IV.)? In this respect, from the teachings of the specification, the claim term “operational guidance information” apparently encompasses and covers recommendations “to alert the driver to the frequent emergency braking over the next months” (published paragraph [0049]). However, because this alerting to the driver is unclearly/vaguely defined/described in the specification, the claim term “operational guidance information”, which apparently MUST cover and encompass this vague alerting to the driver[4], also apparently (or even necessarily) must have unclear metes and bounds.
In claim 6, line 2 and in claim 6, line 5, “a production batch” is indefinite and unclear because it is unclear (from the teachings of the specification) how the metes and bounds of any or all “production batch” might possibly be defined, with reasonable certainty.
In claim 6, line 3, and in claim 7, line 2, “abnormal operation data” is vague and unclear, also being facially subjective (e.g., “abnormal” relative to what objective/normal standard, particularly, and “operation data” defined particularly how?) See MPEP 2173.05(b), IV.
In claim 6, line 6 and in claim 6, line 9, “an abnormal performance” is vague and unclear, also being facially subjective (e.g., “abnormal” relative to what objective/normal standard, particularly, and “performance” defined particularly how?) See MPEP 2173.05(b), IV.
In claim 7, lines 1ff, the phrase “the second fault diagnosis result Res2 comprises abnormal operation data, a location of fault, a possible cause of fault” is unclear due to improper grammar, because it is unclear if the claim requires all three of the recited components (e.g., “abnormal operation data, a location of fault, AND a possible cause of fault”) of if it only requires one of the components as an alternative (“abnormal operation data, a location of fault, OR a possible cause of fault”). For the purpose of claim interpretation, and because the disjunctive “or” is not recited, the examiner assumes all three of the recited components are (conjunctively) required for claim interpretation purposes.
Claim(s) depending from (or otherwise referencing) claims expressly noted above are also rejected under 35 U.S.C. 112 by/for reason of their dependency from a noted claim that is rejected under 35 U.S.C. 112, for the reasons given.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3, 5 to 8, 11 to 13, 15, and 17 to 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1 and Step 2A, Prong I:
Claim(s) 1, 3, 5 to 8, 11 to 13, 15, and 17 to 19, while (each) reciting a statutory category of invention defined in 35 U.S.C. 101 (a useful process, machine, manufacture, or composition of matter), is/are directed to an abstract idea, which is a judicial exception, the recited abstract idea being that of performing the fault diagnosis (at S2) for the vehicle, and generating and transmitting (at S3) the customized repair plan (including a fault diagnosis result and a repair recommendation) for the vehicle to a requester of the fault diagnosis request, e.g., by performing a method for generating a repair recommendation for a vehicle, the method comprising: (S1) collecting, by one or more processors, real-time operating data of the vehicle in response to a fault diagnosis request and transmitting the real-time operating data to a cloud server via an on-board diagnostic system (OBD) of the vehicle, wherein the real-time operating data comprises at least one of a mode, state, signal, and driving data of the vehicle; (S2) performing a fault diagnosis, by the cloud server, for the vehicle based on the real-time operating data to generate a fault diagnosis result and a repair recommendation, the step S2 comprising: (S21) performing a historical fault diagnosis for the vehicle based at least in part on the real-time operating data to generate a first fault diagnosis result Res1 and a first repair recommendation Sug1, wherein the cloud server stores and updates a historical fault table Ta, a production batch-related fault table Tb, and a model-related fault table Tc, wherein the historical fault diagnosis is performed in this sequence: first, using a historical fault information; next, using a historical fault information of a production batch; and finally, using a historical fault information of a model of the vehicle, and wherein the historical fault diagnosis is performed for faults that have a fault count or frequency exceeding an adaptive threshold in the historical fault table Ta, the production batch-related fault table Tb, and/or the model-related fault table Tc; wherein the adaptive threshold is dynamically adjusted based on different vehicles, usage environments, and operating conditions; wherein the historical fault diagnosis comprises retrieving historical fault data that is identical to the vehicle's real-time data from the historical fault table Ta, the production batch-related fault table Tb, and/or the model-related fault table Tc; wherein the historical fault diagnosis comprises extracting features from the vehicle's real-time operation data and comparing the extracted features with features of data in the historical fault table Ta, the production batch-related fault table Tb, and/or the model-related fault table Tc to find substantially identical historical fault data that is substantially identical to the vehicle's real-time operation data, wherein similarity comparison between data is performed using feature matching algorithms, weighted vector algorithms, and multidimensional data space mapping methods; (S22) if the historical fault diagnosis in step S21 determines that no identical historical fault has occurred, performing a real-time fault diagnosis on the vehicle based at least in part on the vehicle's real-time operation data and data from road environment, climate conditions, and driving behavior, to generate a second fault diagnosis result Res2 and a second repair recommendation Sug2; (S23) generating the fault diagnosis result, the fault diagnosis result comprising the first fault diagnosis result Res1 and/or the second fault diagnosis result Res2, wherein duplicate or invalid data are removed from the first fault diagnosis result Res1 and the second fault diagnosis result Res2 using data cleaning and feature selection; and (S24) generating the repair recommendation, wherein the comprehensive repair recommendation comprises the first repair recommendation Sug1 and/or the second repair recommendation Sug2, wherein the repair recommendation comprises an operational guidance recommendation, a hardware repair recommendation and a software/hardware improvement recommendation, wherein duplicate or invalid data are removed from the first repair recommendation Sug1 and the second repair recommendation Sug2 using data cleaning and feature selection; and (S3) generating, by the cloud server, a customized repair plan for the vehicle and transmitting, by the cloud server, the customized repair plan to a requester of the fault diagnosis request, the customized repair plan comprising the fault diagnosis result and the repair recommendation; wherein in step S21, when a historical fault is determined to have reoccurred, a fault count corresponding to the historical fault is updated in the historical fault table Ta; when a production batch-related fault is determined to have reoccurred, a fault count corresponding to the production batch-related fault is updated in the production batch-related fault table Tb; and/or when a model-related fault is determined to have reoccurred, a fault count corresponding to the model-related fault is updated in the model-related fault table Tc; wherein in step S21 and/or S22, the historical fault diagnosis and/or the real-time fault diagnosis is further performed based on dynamic data, the dynamic data comprising driving behavior data and/or environmental data; wherein the historical fault table Ta stores therein a license plate number, a production batch, a model, a fault information, a fault count, abnormal operation data, a location of fault, a source of fault and a repair recommendation corresponding to the fault information, wherein the production batch-related fault table Tb stores therein a production batch, a fault information, a fault count, an abnormal performance, a source of fault and a repair recommendation, and wherein the model-related fault table Tc stores therein a model, a fault information, a fault count, an abnormal performance, a source of fault and a repair recommendation; wherein the second fault diagnosis result Res2 comprises abnormal operation data, a location of fault, a possible cause of fault, and wherein the second repair recommendation Sug2 comprises a description of fault symptom, an image of faulty component, a description of repair approach, a video of repair approach and any combination thereof; wherein in step S3, the repair recommendation is transmitted along with the fault diagnosis result; wherein the production batch-related fault table Tb and the model-related fault table Tc are generated by aggregating data from the historical fault table Ta; wherein a machine learning algorithm is utilized to adjust the adaptive threshold in real time based on changes in an operating environment of the vehicle and/or an actual operating condition of the vehicle; wherein if the historical fault diagnosis in step S21 determines that a fault identical to a historical fault has occurred, the real-time fault diagnosis of step S22 is skipped; further comprising collecting a feedback on the customized repair plan to enhance accuracy of future recommendations; wherein step S23 and/or step S24 further comprises integrating the first fault diagnosis result Res1 and the second fault diagnosis result Res2 and/or the first repair recommendation Sug1 and the second repair recommendation Sug2 into a global view by a multi-source data fusion, wherein the multi-source data fusion employs weighted averaging or Bayesian reasoning; wherein step S3 comprises generating the customized repair plan based on the fault diagnosis result, a severity of current fault, and dynamic data, the dynamic data comprising driving behavior data and/or environmental data; wherein the dynamic data is derived from a sensor system of the vehicle and/or an external data source.
This abstract idea falls within the grouping(s) of mathematical concepts, mental processes, and/or certain methods of organizing human activity, distilled from case law, because the performing of the fault diagnosis and the generating and transmitting of the customized repair plan could be practically performed in the human mind of a repair technician or diagnostic expert (e.g., which stored organized/tabular historical fault knowledge of vehicles, production batches, and models as learned experience and was able to match real-time vehicle operating data with the stored historical fault knowledge, etc. in order to learn about and make fault diagnosis results and repair recommendations as a customized repair plan) as a mental process, who would also be able to, in the mental process, use his mouth or a pen/pencil and paper as an aid in order to “transmit[]” the customized repair plan to a requester. Moreover, the historical fault tables, the count or frequency exceeding the adaptive threshold and the comparing of features to find identical or substantially identical data are mathematical concepts.5
Step 2A, Prong II and Step 2B:
Additionally, applying a preponderance of the evidence standard, the abstract idea is not integrated (e.g., at Step 2A, Prong II) by the recitation of additional elements/limitations into a practical application (using the considerations set forth in MPEP §§ 2106.04(a)-(h)) because merely using a computer (e.g., one or more processors, the OBD system[6], a cloud server, a machine learning algorithm, etc.) as a tool to perform an abstract idea or adding the words "apply it" is not integrating the idea into a practical application of the idea, and e.g., looking at the claim as a whole and considering any additional elements/limitations individually and in combination, no (additional) particular machine, transformation, improvement to the functioning of a computer or an existing technological process or technical field, or meaningful application of the idea, beyond generally linking the idea to a technological environment (e.g., "implementation via computers", Alice) or adding insignificant extra-solution activity (e.g., collecting real-time operating data of the vehicle, transmitting to or by a cloud server, etc.), is recited in or encompassed by the claims. Therefore, the claim is not integrated into a practical application and is thus "directed to" the exception.
Moreover, applying a preponderance of the evidence standard, the claim(s) does/do not include additional elements/limitations/steps (e.g., at Step 2B) that are, individually or in ordered combination, sufficient to amount to an inventive concept that is significantly more than the judicial exception because the elements/limitations/steps are recited at a high level of generality (e.g., real-time operating data of a vehicle, transmitting the customized repair plan, etc.) so as to not favor eligibility (MPEP § 2106.05(d)) and/or are used e.g., for data/information gathering only or for other activities that were well-understood, routine, and conventional activity in the industry, for example as indicated in applicant's specification at published paragraphs [0003] to [0005] and as indicated in the non-patent literature cited with the examiner's Office action(s) related to OBD systems and cloud servers as used in vehicle diagnostics, etc., and moreover, the generically recited computer elements (e.g., the one or more processors, the OBD system, the cloud server, the machine learning algorithm, etc.; see e.g., Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 110 USPQ2d 1984 (2014); buySAFE, Inc. v. Google, Inc., 765 F.3d. 1350, 112 USPQ2d 1093 (Fed. Cir. 2014); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 115 USPQ2d 1090 (Fed. Cir. 2015); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1321, 120 USPQ2d 1353, 1362; Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-1355, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016); FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 1096 (Fed. Cir. 2016) (“[T]he use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent-eligible subject matter.”); Mobile Acuity, Ltd. v. Blippar Ltd., Case No. 22-2216 (Fed. Cir. Aug. 6, 2024); see also the 2019 PEG Advanced Module at pages 89, 145, etc.) do not add a meaningful limitation to the abstract idea because their use would be routine (and conventional) in any computer implementation of the idea.
Moreover, limiting or linking the use of the idea to a particular technological environment (e.g., fault diagnoses and repair recommendations for vehicles as applied on a generic computer arrangement including e.g., one or more processors, an OBD system, and a cloud server as generic computer components; see e.g., the literature cited herewith) is not enough to transform the abstract idea into a patent-eligible invention (Flook[7]) e.g., because (as a concern underlying the judicial exception) the preemptive effect of the claims on the idea within the field of use would apparently be broad.
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 David A Testardi whose telephone number is (571)270-3528. The examiner can normally be reached Monday, Tuesday, Thursday, 8:30am - 5:30pm E.T., and Friday, 8:30 am - 12:30 pm E.T.
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, Rachid Bendidi can be reached at (571) 272-4896. 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.
/DAVID A TESTARDI/Primary Examiner, Art Unit 3664
1 Training Quality Assurance Specialist
2 Note that original claim 13 apparently did not have the “if” conditional clause, and the claim has apparently been amended without appropriate markings, contrary to 37 CFR 1.121. The examiner, however, examines the claim as presented.
3 See Nautilus, Inc. v. Biosig Instruments, Inc. (U.S. Supreme Court, 2014) which held, "A patent is invalid for indefiniteness if its claims, read in light of the patent’s specification and prosecution history, fail to inform, with reasonable certainty, those skilled in the art about the scope of the invention." See also In re Packard, 751 F.3d 1307 (Fed.Cir.2014)(“[A] claim is indefinite when it contains words or phrases whose meaning is unclear,” i.e., “ambiguous, vague, incoherent, opaque, or otherwise unclear in describing and defining the claimed invention.”) and Ex Parte McAward, Appeal No. 2015-006416 (PTAB, Aug. 25, 2017, Precedential) (“Applying the broadest reasonable interpretation of a claim, then, the Office establishes a prima facie case of indefiniteness with a rejection explaining how the metes and bounds of a pending claim are not clear because the claim contains words or phrases whose meaning is unclear.”)
4 Since the specification, including its examples, should (ideally) be the glossary for the claims. See MPEP 2111.01, I. (“the greatest clarity is obtained when the specification serves as a glossary for the claim terms. Phillips v. AWH Corp., 415 F.3d 1303, 1315, 75 USPQ2d 1321, 1327 (Fed. Cir. 2005) (en banc)”).
5 See MPEP 2106.04, II., A., 2., citing RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1327, 122 USPQ2d 1377 (Fed. Cir. 2017) ("Adding one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract")
6 Since the OBD system has been required by law (e.g., per Section 202 of the Clean Air Act; see also 42 U.S.C. 7521(m) and 40 CFR 86.1806, e.g., § 86.1806-17 Onboard diagnostics) for two decades in the United States, the examiner understands this to be a generic computer component.
7 See e.g., Bilski v. Kappos, 561 U.S. 593 ("Flook established that limiting an abstract idea to one field of use . . . did not make the concept patentable.")
Prosecution Insights