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 .
Drawings
The drawings are objected to under 37 CFR 1.83(a), because the drawings must show every feature of the invention specified in the claims, and under 37 CFR 1.84(p)(5), because reference characters (e.g., “Ta”, “Tb”, “Tc”) mentioned in the description must appear in the drawings. Therefore, the repair recommendation classifier of claim 1 and the historical fault table Ta, the production batch-related fault table Tb and the model-related fault table Tc of claim 2 (which have reference characters referenced in the description) must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
INFORMATION ON HOW TO EFFECT DRAWING CHANGES
Replacement Drawing Sheets
Drawing changes must be made by presenting replacement sheets which incorporate the desired changes and which comply with 37 CFR 1.84. An explanation of the changes made must be presented either in the drawing amendments section, or remarks, section of the amendment paper. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). A replacement sheet must include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of the amended drawing(s) must not be labeled as “amended.” If the changes to the drawing figure(s) are not accepted by the examiner, applicant will be notified of any required corrective action in the next Office action. No further drawing submission will be required, unless applicant is notified.
Identifying indicia, if provided, should include the title of the invention, inventor’s name, and application number, or docket number (if any) if an application number has not been assigned to the application. If this information is provided, it must be placed on the front of each sheet and within the top margin.
Annotated Drawing Sheets
A marked-up copy of any amended drawing figure, including annotations indicating the changes made, may be submitted or required by the examiner. The annotated drawing sheet(s) must be clearly labeled as “Annotated Sheet” and must be presented in the amendment or remarks section that explains the change(s) to the drawings.
Timing of Corrections
Applicant is required to submit acceptable corrected drawings within the time period set in the Office action. See 37 CFR 1.85(a). Failure to take corrective action within the set period will result in ABANDONMENT of the application.
If corrected drawings are required in a Notice of Allowability (PTOL-37), the new drawings MUST be filed within the THREE MONTH shortened statutory period set for reply in the “Notice of Allowability.” Extensions of time may NOT be obtained under the provisions of 37 CFR 1.136 for filing the corrected drawings after the mailing of a Notice of Allowability.
Claim (Specification) Objections
Claims 1, 5, and 15 are objected to because of the following informalities: in claim 1, line 3, “a real-time operating data”1 should read, “real-time operating data”, for grammatical correctness (e.g., “data” is plural); in claim 5, lines 2ff, “a dynamic data” should apparently read, “dynamic data” (e.g., data is plural); and in claim 15, line 1, “a user feedback” should apparently read, “user feedback” for grammatical correctness.. Appropriate correction, or reasoned traversal, is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
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 to 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 1, applicant has apparently not described, in sufficient detail, by what algorithm(s)2, or by what steps or procedure3, he [conjunctively] categorized the comprehensive repair recommendation into an operational guidance recommendation, a hardware repair recommendation and a software/hardware improvement recommendation using a repair recommendation classifier. Accordingly, the examiner believes that applicant has not evidenced, to those skilled in the art, possession of the claimed invention, but has only (if anything) described a desired result.
In particular, if the comprehensive repair recommendation is (e.g., for one example out of millions) “change oil and replace oil filter”, then by what algorithm(s) did applicant classify the comprehensive repair recommendation into “an operational guidance recommendation” and “a software/hardware improvement recommendation” e.g., if the driver need not change his operation of the vehicle and if oil and filter are the same as that used previously (e.g., OEM equipment), and are thus not improved?
In this respect, published paragraph [0045] indicates:
This classification can be performed using a repair recommendation classifier. The repair recommendation classifier can comprise a variety of machine learning algorithms, including decision trees, K-nearest neighbor algorithms, support vector machines, logistic regression, and naive Bayes classifiers. The user feedback can be continuously collected, and the repair recommendation classifier can be updated in real-time based on the actual repair outcomes.
However, while this paragraph describes generic classification techniques, it does not apparently describe, in sufficient detail, any algorithm(s) or steps/procedure by which any or all comprehensive repair recommendation(s) was/were (conjunctively, “and”) categorized into the three claimed recommendations by any described (in sufficient detail) classifier. Accordingly, the examiner believes that applicant has not evidenced, to those skilled in the art, possession of the claimed invention, but has only (if anything) described a desired result.
In this respect, see e.g., MPEP 2161.01, I., which indicates, “[O]riginal claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV.”
See also e.g., MPEP 2163, I., A. which indicates, “However, as discussed in subsection I, supra, issues of adequate written description may arise even for original claims, for example, when an aspect of the claimed invention has not been described with sufficient particularity such that one skilled in the art would recognize that the inventor had possession of the claimed invention at the time of filing. . . . An invention described solely in terms of a method of making and/or its function may lack written descriptive support where there is no described or art-recognized correlation between the disclosed function and the structure(s) responsible for the function.”
See also MPEP 2163.03, V. which indicates, “An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved or (2) a broad genus claim is presented but the disclosure only describes a narrow species with no evidence that the genus is contemplated. See Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1349-50 (Fed. Cir. 2010) (en banc). The written description requirement is not necessarily met when the claim language appears in ipsis verbis in the specification. "Even if a claim is supported by the specification, the language of the specification, to the extent possible, must describe the claimed invention so that one skilled in the art can recognize what is claimed. The appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy that requirement." Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002).”
Claims 1 to 20 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 6ff, “a comprehensive fault diagnosis result” is indefinite, not reasonably certain4, and facially subjective in the claim context from the teachings of the specification (e.g., “comprehensive” meaning what particularly in the claim context, “comprehensive” in what particular way and by what objective standard when the comprehensive fault diagnosis is generated based on e.g., only one of the historical fault diagnosis or the real-time fault diagnosis?). In particular the claim only requires generation of the first fault diagnosis result Res1 “or”5 the second diagnosis result Res2, and then generating the comprehensive diagnosis result comprising either one of the first or second diagnosis result. What does it mean, then, that the “comprehensive fault diagnosis result” is “comprehensive”, when (by the wording of the claim) it comprises only a single one of the first or second fault diagnosis results, and how could any “comprehensive fault diagnosis result” even be/comprise only a single (first or second) fault diagnosis result, as the claim encompasses and covers? In this respect, the meaning of “comprehensive” is facially subjective, with no objective standard supplied in the specification for measuring the scope of the term. See MPEP 2173.05(b), IV.
In claim 1, lines 7ff, “a comprehensive repair recommendation” is indefinite, not reasonably certain, and facially subjective in the claim context from the teachings of the specification (e.g., “comprehensive” meaning what particularly in the claim context, “comprehensive” in what particular way and by what objective standard when the comprehensive repair recommendation might be generated to comprise e.g., only one of the first repair recommendation or the second repair recommendation?). In particular the claim only requires generation of the first repair recommendation Sug1 “or” the second repair recommendation Sug2, and then generating the comprehensive repair recommendation comprising either one of the first or second repair recommendations. What does it mean, then, that the “comprehensive repair recommendation” is “comprehensive”, when (by the wording of the claim) it comprises only a single one of the first or second repair recommendations, and how could any “comprehensive repair recommendation” even be/comprise only a single (first or second) repair recommendation, as the claim encompasses and covers? In this respect, the meaning of “comprehensive” is facially subjective, with no objective standard supplied in the specification for measuring the scope of the term. See MPEP 2173.05(b), IV.
In claim 1, lines 20ff, “wherein the comprehensive repair recommendation is categorized into an operational guidance recommendation, a hardware repair recommendation and a software/hardware improvement recommendation using a repair recommendation classifier” is indefinite and not reasonably certain in the claim context and from the teachings of the specification. For example, what does it mean that the “comprehensive repair recommendation” is “categorized into” the three recited recommendations (e.g., “categorized” meaning what, particularly, in the claim context, and “categorized into” particularly how?), what are the metes and bounds of any or all “operational guidance recommendation[s]” (e.g., would these recommendations include only recommendations to the driver/vehicle user 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 [paragraphs [0047] and [0048]], or might they also include “text guidance for repair operations” for users or mechanics at published paragraph [0041]?), what are the metes and bounds of “software/hardware improvement recommendation”, with “improvement” being facially subjective (see MPEP 2173.05(b), IV.), and what is (e.g., would or would not be) a ”repair recommendation classifier” with reasonable certainty? In this respect, the claim term “operational guidance information” apparently encompasses and covers recommendations “to alert the driver to the frequent emergency braking over the next months” (paragraph [0049]). However, because this alerting of the driver is unclearly/vaguely defined/described in the specification, the claim term (“operational guidance information”) which apparently covers and encompass this vague alerting of the driver also has unclear metes and bounds.
In claim 2, lines 1ff, “a production batch-related fault table Tb” 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. For example, might the year of a vehicle 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 2, lines 5ff, “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 2, line 3, “a production batch-related fault” 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 2 and in claim 6, lines 5ff, “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 5, “a production batch” is additionally unclear because “a production batch” has already been recited in claim 2 and it is unclear (e.g., due to the lack of a definite article before “production batch” in claim 6) whether the “a production batch” of claim 6 is the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from, etc. the production batch of claim 2.
In claim 6, line 6, and in claim 6, lines 8ff, “a fault information” is unclear because “a [] fault information” has already been recited in claim 2 and it is unclear (e.g., due to the lack of a definite article before “fault information” in claim 6) whether the “a fault information” of claim 6 is the same as, different from, permissively the same as, permissively different from, necessarily the same as, necessarily different from, etc. the fault information of claim 2.
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 an abnormal operation data, a location of fault, a possible source of fault” is unclear due to improper grammar, because it is unclear if the claim requires all three of the recited components (e.g., “an abnormal operation data, a location of fault, AND a possible source of fault”) of if it only requires one of the components as an alternative (“an abnormal operation data, a location of fault, OR a possible source of fault”). For the purpose of claim interpretation, and because an “or” is not recited, the examiner assumes all three of the recited components are required for claim interpretation purposes.
In claim 10, line 1, “a big data analytics” is indefinite and facially subjective, with no objective standard provided in the specification to determine what would or would not be big data analytics. See MPEP 2173.05(b), IV.
In claim 17, lines 2ff, “integrating. . . by a multi-source data fusion” is indefinite and unclear from the teachings of the specification (e.g., integrating particularly how, multi-source defined particularly how?)
In claim 17, line 4, “a global view” is indefinite and unclear from the teachings of the specification (e.g., global view defined particularly how?)
In claim 18, lines 2ff, “a severity and a type of current fault” is indefinite in that “severity” is facially subjective, with no objective standard supplied in the specification for measuring the scope of the term (see MPEP 2173.05(b), IV.) and with “type” being an unclear approximation (see MPEP 2173.05(b), III., E.)
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 to 20 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 to 20, 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 (S2) performing a fault diagnosis on the vehicle based on the real-time operating data to generate a comprehensive fault diagnosis result and a comprehensive repair recommendation, the step S2 comprising: (S21) performing a historical fault diagnosis on 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, and/or (S22) performing a real-time fault diagnosis on the vehicle based at least in part on the real-time operating data to generate a second fault diagnosis result Res2 and a second repair recommendation Sug1, (S23) generating the comprehensive fault diagnosis result, the comprehensive fault diagnosis result comprising the first fault diagnosis result Res1 and/or the second fault diagnosis result Res2, and (S24) generating the comprehensive repair recommendation, wherein the comprehensive repair recommendation comprising the first repair recommendation Sug1 and/or the second repair recommendation Sug2, wherein the comprehensive repair recommendation is categorized into an operational guidance recommendation, a hardware repair recommendation and a software/hardware improvement recommendation using a repair recommendation classifier; (S3) generating a customized repair plan for the vehicle and transmitting (e.g., by speaking, etc.) the customized repair plan to a requester of the fault diagnosis request, the customized repair plan comprising the comprehensive fault diagnosis result and the comprehensive repair recommendation, e.g., by a method for generating a repair recommendation for a vehicle, the method comprising: (S1) collecting a 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; (S2) the cloud server performing a fault diagnosis on the vehicle based on the real-time operating data to generate a comprehensive fault diagnosis result and a comprehensive repair recommendation, the step S2 comprising: (S21) performing a historical fault diagnosis on 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, and/or (S22) performing a real-time fault diagnosis on the vehicle based at least in part on the real-time operating data to generate a second fault diagnosis result Res2 and a second repair recommendation Sug1; (S23) generating the comprehensive fault diagnosis result, the comprehensive fault diagnosis result comprising the first fault diagnosis result Res1 and/or the second fault diagnosis result Res2; and (S24) generating the comprehensive repair recommendation, wherein the comprehensive repair recommendation comprising the first repair recommendation Sug1 and/or the second repair recommendation Sug2, wherein the comprehensive repair recommendation is categorized into an operational guidance recommendation, a hardware repair recommendation and a software/hardware improvement recommendation using a repair recommendation classifier; and (S3) the cloud server generating a customized repair plan for the vehicle and transmitting the customized repair plan to a requester of the fault diagnosis request, the customized repair plan comprising the comprehensive fault diagnosis result and the comprehensive repair recommendation; wherein a historical fault table Ta, a production batch-related fault table Tb and a model-related fault table Tc of the vehicle are stored and updated in the cloud server, and wherein in step S21, the historical fault diagnosis is performed sequentially using a historical fault information of the vehicle, a historical fault information of a production batch of the vehicle, and a historical fault information of a model of the vehicle in this order; 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, the historical fault diagnosis is performed for faults having a fault count or frequency exceeding a threshold in the historical fault table Ta, the production batch-related fault table Tb or 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 a dynamic data, the dynamic data comprising a driving behavior data and/or an 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, an 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 an abnormal operation data, a location of fault, a possible source 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 comprehensive repair recommendation is transmitted to the requester of the fault diagnosis request along with the comprehensive fault diagnosis result; wherein in step S3, the comprehensive fault diagnosis result and the operational guidance recommendation are transmitted to a user of the vehicle, the comprehensive fault diagnosis result and the hardware repair recommendation are transmitted to an automotive mechanic of the vehicle, and the comprehensive fault diagnosis result and the software/hardware improvement recommendation are transmitted to a manufacturer of the vehicle; further comprising utilizing a big data analytics to update the production batch-related fault table Tb and the model-related fault table Tc of the vehicle in the cloud server; 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 threshold in real time based on changes in an operating environment of the vehicle and/or an actual operating condition of the vehicle; wherein when the historical fault diagnosis in step S21 identifies a fault that is identical to a historical fault, the real-time fault diagnosis of step S22 is bypassed; wherein a decision to perform the real-time fault diagnosis in step S22 is based on a usage of the vehicle or feedback from a user of the vehicle; further comprising collecting a user feedback to dynamically update the repair recommendation classifier; wherein step S23 and/or step S24 further comprises removing duplicate or invalid data in 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 by using a data cleaning or a feature selection; 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 step S3 comprises generating the customized repair plan based on the comprehensive fault diagnosis result, a severity and a type of current fault, and a dynamic data, the dynamic data comprising a driving behavior data and/or an environmental data; wherein the dynamic data is received from a sensor system of the vehicle and/or an external data source; and a system comprising one or more computer processors and a computer readable memory, the computer readable memory comprising machine executable code, which when executed by the one or more computer processors implements the method for generating repair recommendations for a vehicle of claim 1;
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 it could be practically performed in the human mind by a vehicle repair person (e.g., working from memory/experience and seeing live vehicle data/conditions and speaking his/her mind to a co-worker) and it includes recited mathematical concepts6 (e.g., tables, counts, frequencies, machine learning algorithm, etc.)
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 as a tool (one or more computer processors, memory, code, algorithms) 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, possibly transmitting the customized repair plan to a requester, 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 significantly more than the judicial exception because the elements/limitations/steps are recited at a high level of generality (e.g., transmitting the customized repair plan to the requester, etc.) so as to not favor eligibility (MPEP § 2106.05(d)) and/or are used e.g., for data/information gathering only (collecting real-time operating data) 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 moreover, the generically recited computer elements (e.g., one or more computer processors, computer readable memory, 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 (e.g., receiving or transmitting data over a network); 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., repair recommendations for a vehicle) is not enough to transform the abstract idea into a patent-eligible invention (Flook[7]) e.g., because the preemptive effect of the claims on the idea within the field of use would be broad.
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 to 6, 8, 10, 11, 13 to 15, and 17 to 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gutlein et al. (2023/0252829) in view of Bell (2015/0094903).
Gutlein et al. (‘829) reveals:
per claim 1, a method for generating a repair recommendation for a vehicle, the method comprising:
(S1) collecting a real-time operating data of the vehicle [e.g., the sensor measurement values from the vehicle requested (e.g., by the server 30 in FIG. 4; paragraph [0089]) at S25/S15 in FIG. 4 and received/collected at S16/S26 for evaluation/processing, and the fault codes requested at S23/S13 in FIG. 4 and received/collected at S14/S24 for analysis/evaluation, wherein the sensor measurement values (and the fault codes) are obviously “up-to-date” [and satisfy “real-time” accordingly] as taught at paragraph [0080] and are obviously “current” [and satisfy “real-time” accordingly] as taught at paragraph [0119]; wherein sensor measurement values include ambient temperature and ambient air pressure (e.g., paragraph [0071])] in response to a fault diagnosis request [e.g., the request from the vehicle diagnostic tool 20 at S11/S21, S13/S23, or S15/S25 in FIG. 4] and transmitting the real-time operating data to a cloud server [e.g., to the server 30 at S24, S26 in FIG. 4];
(S2) the cloud server performing a fault diagnosis on the vehicle based on the real-time operating data to generate a comprehensive fault diagnosis result [e.g., paragraph [0089], “On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing”] and a comprehensive repair recommendation [e.g., paragraph [0089], “On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing”; see also paragraphs [0048] to [0051], “creating and/or displaying a list of potentially defective components, creating and/or displaying context-based component information, creating and/or displaying required repair steps. In a further step, the diagnostic results can be displayed on the display device, the display device preferably being part of a diagnostic tool or the above-mentioned user interface”], the step S2 comprising:
(S21) performing a historical fault diagnosis on the vehicle based at least in part on the real-time operating data to generate a first fault diagnosis result Res1 [e.g., paragraph [0019], “historical data relate[d] to data which have been determined or measured and stored in the database in the past. Vehicle data from the vehicle can therefore be compared with the historical vehicle data, in particular also from vehicles from other vehicle manufacturers, in order to be able to draw a conclusion as to the vehicle state or the vehicle fault state. The historical vehicle data preferably include the vehicle identification means, vehicle manufacturer, vehicle type, vehicle equipment, fault codes, mileage, vehicle age, sensor measurement values, and/or sensor measurement variables.”] and a first repair recommendation Sug1 [e.g., paragraph [0031], “The historical logging data preferably include retrieved repair information and/or retrieved vehicle component information which have been retrieved during earlier (historical) vehicle diagnostics, for example. Therefore, if the mechanic is often or always retrieving particular repair information and/or vehicle component information after reading out/receiving a particular fault code, this is an indication that a particular component is defective when this particular fault code occurs.”], and/or (S22) performing a real-time fault diagnosis on the vehicle based at least in part on the real-time operating data to generate a second fault diagnosis result Res2 and a second repair recommendation Sug1 [e.g., paragraph [0089], “For more accurate diagnostics, the server 30 can additionally request from the vehicle 10 sensor measurement values. This is carried out by a request, for example, which is relayed (S25, S15) from the diagnostic tool 20 to the vehicle 10. The vehicle 10 retrieves the requested sensor measurement values from the vehicle-side memory or activates corresponding vehicle sensors to return or capture the sensor measurement values. The sensor measurement values are then sent (S16) from the vehicle 10 to the diagnostic tool 20 and sent (S26) from the diagnostic tool 20 to the server 30 for further evaluation or processing. On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing.”; with the sensor measurement values obviously being “up-to-date” as at paragraph [0080] and including ambient temperature and air pressure (e.g., paragraph [0071])];
(S23) generating the comprehensive fault diagnosis result, the comprehensive fault diagnosis result comprising the first fault diagnosis result Res1 and/or the second fault diagnosis result Res2 [e.g., paragraph [0072]..[0074], “The aim of the vehicle diagnostics is to be able to establish which component in the vehicle 10 is defective and how this component can be repaired. In order to be able to establish which component in the vehicle is defective, the vehicle diagnostic tool 20 (or the server 30; see below) evaluates the fault codes which are generated during operation of the vehicle 10 by evaluating the sensor measurement values by means of the at least one vehicle controller 11, 12 and are stored in a vehicle-side memory . . . in order to diagnose whether and which vehicle components need to be repaired or replaced in order to resolve the problem”; see also paragraphs [0046] to [0050], “Optionally, the fault codes are evaluated on the basis of the measured sensor measurement variables. By means of this evaluation, the at least one potentially defective component can be determined. The at least one potentially defective component can then be determined on the basis of the fault codes and the measured sensor measurement variables. Optionally, the method comprises at least one, a plurality of, or all the following steps: creating and/or displaying a list of potentially defective components, creating and/or displaying context-based component information, creating and/or displaying required repair steps.”]; and
(S24) generating the comprehensive repair recommendation [e.g., paragraph [0089], “On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing”; see also paragraph [0116], “In a further variant, the method can comprise the following step: determining context-based repair information on the basis of the fault codes and/or the sensor measurement variables and/or the potentially defective components. Context-based repair information for example includes circuit diagrams, operate values, or component test values which the user needs for repairing the vehicle or resolving the fault. The context-based repair information can be determined by means of the historical logging data”; see also paragraphs [0120] to [0123], “Optionally, the method comprises at least one of the following steps: creating and displaying a list of potentially defective components, creating and displaying context-based component information for the defective components, and/or creating and displaying required repair steps.], wherein the comprehensive repair recommendation comprising the first repair recommendation Sug1 [e.g., the repair information determined on the basis of the fault codes in paragraph [0116]] and/or the second repair recommendation Sug2 [e.g., the repair information determined on the basis of the sensor measurement variables/values e.g., in paragraph [0116]], wherein the comprehensive repair recommendation is categorized into an operational guidance recommendation [e.g., the required repair steps displayed (on the diagnostic tool 20 at paragraph [0051])], a hardware repair recommendation [e.g., the component to be repaired (e.g., paragraphs [0074], [0080], etc.)] and a software/hardware improvement recommendation [e.g., the (faulty) component to be replaced (e.g., paragraph [0074]; see also paragraph [0093], “The vehicle 10 can also receive new software components or updates, which the server 30 sends to the vehicle 10 via the diagnostic tool 20.”] using a repair recommendation classifier [e.g., i) when the diagnostic tool 120 displays repair steps, in order to display the steps, ii) when the diagnostic tool displays the component information of the defective component (to be repaired), at paragraphs [0046] to [0050], [0120] to [0123], etc., and iii) when the diagnostic tool 120 sends to the vehicle the new software components or updates (paragraph [0093]), where the diagnostic tool obviously distinguishes repair steps from component information of the defective component from new software components or updates, to properly handle what to do with each type of such information]; and
(S3) the cloud server generating a customized repair plan for the vehicle and transmitting the customized repair plan to a requester of the fault diagnosis request [e.g., a repair plan including the list of potentially defective (faulty) components, the component(s) to be repaired or replaced, and the repair steps ([0046] to [0050], [0120] to [0123], etc.), as well as the sensor measurement values, are obviously transmitted (FIG. 4) to the diagnostic tool 120 for display as diagnostic results (e.g., paragraphs [0051], [0119] to [0123], etc.)], the customized repair plan comprising the comprehensive fault diagnosis result [e.g., for establishing which component in the vehicle is defective from the list of potentially defective components, paragraphs [0072] and the comprehensive repair recommendation [e.g., for establishing the repair steps, etc. in paragraphs [0072], etc.];
Gutlein et al. (‘829) may not reveal that the server 30 is a “cloud server”, or the medium of claim 20. It may also be alleged that Gutlein et al. (‘829) does not reveal that the operating data is “real-time operating data”, although this would have been obvious, to one having ordinary skill in this art, from the teachings of Gutlein et al. (‘829) even without further teaching, e.g., when the operating data (sensor measurement values) were “up-to-date” and current, as desired by Gutlein et al. (‘829). Regarding the dependent claims, Gutlein et al. (‘829) may not reveal details of the fault counts.
However, in the context/field of an improved vehicle diagnostic and prognostic systems and methods, Bell (‘903) teaches that a vehicular diagnostic system that utilizes a remote server (214, 614) may be implemented in a non-transitory computer-readable storage medium (claim 8) in such a manner that the vehicle communicates (e.g., diagnostic codes; e.g., paragraph [0069]) with the remote server, wherein the remote server may be an OEM cloud-based secure server helping to ensure security when the remote device has communication access with the VCS (paragraph [0066]). Moreover, as shown in FIGS. 4 and 4 at 420, 520, variables from the vehicle may be monitored/streamed in real time, where the variables include e.g., position(s) such as throttle blade position, accelerator pedal position, etc. (e.g., paragraph [0061]), and that the monitored variables may include “diagnostic error counters, timers, diagnostic fault counters” (e.g., paragraph [0053]), such as a “position sensor out of range counter” (e.g., paragraph [0062]).
It would have been obvious before the effective filing date of the claimed invention to implement or modify the Gutlein et al. (‘829) method for performing vehicle diagnostics so that the method was implemented with a non-transitory computer-readable storage medium as taught at claim 8 of Bell (‘903), and so that the server 30 would have been implemented as an OEM cloud-based secure server, as taught by Bell (‘903), so that the sensor measurement values (as variables) would have been monitored/streamed to the server in real-time, as taught by Bell (‘903), and so that a vehicle’s diagnostic error/fault counter values (that were obviously updated each time a fault occurred in the vehicle), as taught by Bell (‘903), would have also been logged/stored in the database, in order to help to ensure security when the server (30) device has communication access with the vehicle 10 and diagnostic tool 20, in order to allow a remote engineer to access the vehicle and monitor current conditions and run tests as required or to root cause one or more customer complaints on a vehicle, and in order to keep count of faults, as taught by Bell (‘903), with conventional computer components (e.g., a medium) and with a reasonable expectation of success, and e.g., as a use of a known technique to improve similar devices (methods, or products) in the same way.
As such, the implemented or modified Gutlein et al. (‘829) method for performing vehicle diagnostics would have rendered obvious:
per claim 1, a method for generating a repair recommendation for a vehicle, the method comprising:
(S1) collecting a real-time operating data of the vehicle [e.g., in Gutlein et al. (‘829), the sensor measurement values from the vehicle requested (e.g., by the server 30 in FIG. 4; paragraph [0089]) at S25/S15 in FIG. 4 and received/collected at S16/S26 for evaluation/processing, and the fault codes requested at S23/S13 in FIG. 4 and received/collected at S14/S24 for analysis/evaluation, wherein the sensor measurement values (and the fault codes) are obviously “up-to-date” [and satisfy “real-time” accordingly] as taught at paragraph [0080] and are obviously “current” [and satisfy “real-time” accordingly] as taught at paragraph [0119]; wherein sensor measurement values include ambient temperature and ambient air pressure (e.g., paragraph [0071]); and implemented as the real-time monitoring/streaming of variables (at 420, 422, 520, 522) in FIGS. 4 and 5 of Bell (‘903)] in response to a fault diagnosis request [e.g., in Gutlein et al. (‘829), the request from the vehicle diagnostic tool 20 at S11/S21, S13/S23, or S15/S25 in FIG. 4] and transmitting the real-time operating data to a cloud server [e.g., in Gutlein et al. (‘829), to the server 30 at S24, S26 in FIG. 4; and implemented as the OEM cloud-based secure server, as taught by Bell (‘903)];
(S2) the cloud server performing a fault diagnosis on the vehicle based on the real-time operating data to generate a comprehensive fault diagnosis result [e.g., paragraph [0089] in Gutlein et al. (‘829), “On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing”] and a comprehensive repair recommendation [e.g., paragraph [0089] in Gutlein et al. (‘829), “On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing”; see also paragraphs [0048] to [0051], “creating and/or displaying a list of potentially defective components, creating and/or displaying context-based component information, creating and/or displaying required repair steps. In a further step, the diagnostic results can be displayed on the display device, the display device preferably being part of a diagnostic tool or the above-mentioned user interface”], the step S2 comprising:
(S21) performing a historical fault diagnosis on the vehicle based at least in part on the real-time operating data to generate a first fault diagnosis result Res1 [e.g., paragraph [0019] in Gutlein et al. (‘829), “historical data relate[d] to data which have been determined or measured and stored in the database in the past. Vehicle data from the vehicle can therefore be compared with the historical vehicle data, in particular also from vehicles from other vehicle manufacturers, in order to be able to draw a conclusion as to the vehicle state or the vehicle fault state. The historical vehicle data preferably include the vehicle identification means, vehicle manufacturer, vehicle type, vehicle equipment, fault codes, mileage, vehicle age, sensor measurement values, and/or sensor measurement variables.”] and a first repair recommendation Sug1 [e.g., paragraph [0031] in Gutlein et al. (‘829), “The historical logging data preferably include retrieved repair information and/or retrieved vehicle component information which have been retrieved during earlier (historical) vehicle diagnostics, for example. Therefore, if the mechanic is often or always retrieving particular repair information and/or vehicle component information after reading out/receiving a particular fault code, this is an indication that a particular component is defective when this particular fault code occurs.”], and/or (S22) performing a real-time fault diagnosis on the vehicle based at least in part on the real-time operating data to generate a second fault diagnosis result Res2 and a second repair recommendation Sug1 [e.g., paragraph [0089] in Gutlein et al. (‘829), “For more accurate diagnostics, the server 30 can additionally request from the vehicle 10 sensor measurement values. This is carried out by a request, for example, which is relayed (S25, S15) from the diagnostic tool 20 to the vehicle 10. The vehicle 10 retrieves the requested sensor measurement values from the vehicle-side memory or activates corresponding vehicle sensors to return or capture the sensor measurement values. The sensor measurement values are then sent (S16) from the vehicle 10 to the diagnostic tool 20 and sent (S26) from the diagnostic tool 20 to the server 30 for further evaluation or processing. On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing.”; with the sensor measurement values obviously being “up-to-date” as at paragraph [0080] and including ambient temperature and air pressure (e.g., paragraph [0071])];
(S23) generating the comprehensive fault diagnosis result, the comprehensive fault diagnosis result comprising the first fault diagnosis result Res1 and/or the second fault diagnosis result Res2 [e.g., paragraph [0072] to [0074] in Gutlein et al. (‘829), “The aim of the vehicle diagnostics is to be able to establish which component in the vehicle 10 is defective and how this component can be repaired. In order to be able to establish which component in the vehicle is defective, the vehicle diagnostic tool 20 (or the server 30; see below) evaluates the fault codes which are generated during operation of the vehicle 10 by evaluating the sensor measurement values by means of the at least one vehicle controller 11, 12 and are stored in a vehicle-side memory . . . in order to diagnose whether and which vehicle components need to be repaired or replaced in order to resolve the problem”; see also paragraphs [0046] to [0050], “Optionally, the fault codes are evaluated on the basis of the measured sensor measurement variables. By means of this evaluation, the at least one potentially defective component can be determined. The at least one potentially defective component can then be determined on the basis of the fault codes and the measured sensor measurement variables. Optionally, the method comprises at least one, a plurality of, or all the following steps: creating and/or displaying a list of potentially defective components, creating and/or displaying context-based component information, creating and/or displaying required repair steps.”]; and
(S24) generating the comprehensive repair recommendation [e.g., paragraph [0089] in Gutlein et al. (‘829), “On the basis of the fault codes, the identification means, and the sensor measurement values, the server 30 can establish which component in the vehicle 10 is defective and needs repairing”; see also paragraph [0116], “In a further variant, the method can comprise the following step: determining context-based repair information on the basis of the fault codes and/or the sensor measurement variables and/or the potentially defective components. Context-based repair information for example includes circuit diagrams, operate values, or component test values which the user needs for repairing the vehicle or resolving the fault. The context-based repair information can be determined by means of the historical logging data”; see also paragraphs [0120] to [0123], “Optionally, the method comprises at least one of the following steps: creating and displaying a list of potentially defective components, creating and displaying context-based component information for the defective components, and/or creating and displaying required repair steps.], wherein the comprehensive repair recommendation comprising the first repair recommendation Sug1 [e.g., in Gutlein et al. (‘829), the repair information determined on the basis of the fault codes in paragraph [0116]] and/or the second repair recommendation Sug2 [e.g., in Gutlein et al. (‘829), the repair information determined on the basis of the sensor measurement variables/values e.g., in paragraph [0116]], wherein the comprehensive repair recommendation is categorized into an operational guidance recommendation [e.g., in Gutlein et al. (‘829), the required repair steps displayed (on the diagnostic tool 20 at paragraph [0051])], a hardware repair recommendation [e.g., in Gutlein et al. (‘829), the component to be repaired (e.g., paragraphs [0074], [0080], etc.)] and a software/hardware improvement recommendation [e.g., in Gutlein et al. (‘829), the (faulty) component to be replaced (e.g., paragraph [0074]; see also paragraph [0093], “The vehicle 10 can also receive new software components or updates, which the server 30 sends to the vehicle 10 via the diagnostic tool 20.”] using a repair recommendation classifier [e.g., as categories in Gutlein et al. (‘829), i) when the diagnostic tool 120 displays repair steps, in order to display the steps, ii) when the diagnostic tool displays the component information of the defective component (to be repaired), at paragraphs [0046] to [0050], [0120] to [0123], etc., and iii) when the diagnostic tool 120 sends to the vehicle the new software components or updates (paragraph [0093]), where the diagnostic tool obviously distinguishes (as a hardware classifier) repair steps from component information of the defective component from new software components or updates, to properly handle what it should do with each type (i.e., i, ii, or iii, above) of such information]; and
(S3) the cloud server generating a customized repair plan for the vehicle and transmitting the customized repair plan to a requester of the fault diagnosis request [e.g., in Gutlein et al. (‘829), a repair plan including the list of potentially defective (faulty) components, the component(s) to be repaired or replaced, and the repair steps ([0046] to [0050], [0120] to [0123], etc.), as well as the sensor measurement values, are obviously transmitted (FIG. 4) to the diagnostic tool 120 for display as diagnostic results (e.g., paragraphs [0051], [0119] to [0123], etc.)], the customized repair plan comprising the comprehensive fault diagnosis result [e.g., in Gutlein et al. (‘829), for establishing which component in the vehicle is defective from the list of potentially defective components, paragraphs [0072] and the comprehensive repair recommendation [e.g., in Gutlein et al. (‘829), for establishing the repair steps, etc. in paragraphs [0072], etc.];
per claim 2, depending from claim 1, wherein a historical fault table Ta [e.g., the historical vehicle data database (in the server 20, paragraph [0020] and e.g., formed as a “matrix” in paragraph [0019]) in Gutlein et al. (‘829) including the historical fault codes; e.g., paragraph [0019]; where the database would have obviously been a “table”8 of data, when interpreted by one having ordinary skill in the art], a production batch-related fault table Tb [e.g., the historical vehicle data database “assigned to . . . a vehicle group” (paragraph [0019]) and including historical fault codes (e.g., paragraph [0019]) in Gutlein et al. (‘829, where the database data is arranged to include “vehicle age”, with the production batches obviously being e.g., different years] and a model-related fault table Tc of the vehicle [e.g., the historical vehicle data database “assigned to a particular vehicle” (paragraph [0019]) and including historical fault codes (e.g., paragraph [0019]) in Gutlein et al. (‘829, where the database data is arranged to include “vehicle type”, with the vehicle-type obviously being model-related] are stored and updated in the cloud server [e.g., paragraph [0020], [0105], [0114] in Gutlein et al. (‘829); and the OEM cloud-based secure server, as taught by Bell (‘903)], and
wherein in step S21, the historical fault diagnosis is performed sequentially using a historical fault information of the vehicle, a historical fault information of a production batch of the vehicle, and a historical fault information of a model of the vehicle in this order [e.g., it would have been obvious to use any historical vehicle data in the database(s) in Gutlein et al. (‘829), in any order, in order to compare with the current vehicle data and then draw a conclusion about the fault state of the vehicle and determine the at least one potentially defective component, etc.,; see e.g., paragraphs [0019], [0031], etc. in Gutlein et al. (‘829); see also e.g., MPEP 2144.04, IV., C. for legal precedents supporting obviousness (“See also In re Burhans, 154 F.2d 690, 69 USPQ 330 (CCPA 1946) (selection of *any order* of performing process steps is prima facie obvious in the absence of new or unexpected results)”];
per claim 3, depending from claim 2, wherein in step S21, when a historical fault is determined to have reoccurred, a fault count9 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 [e.g., paragraph [0113] in Gutlein et al. (‘829), “[0113] Preferably, retrievals of technical information, such as repair information or vehicle component information, by the mechanic on the diagnostic tool 20 are stored in a record, which is also called logging. The logging data are preferably also stored in the database, The logging data can be taken into consideration when determining the potentially defective component.”; see also paragraphs [0019] (which describes the aspects of the historical database/matrix as related to a) diagnostic codes, b) vehicle groups/vehicle age, and c) vehicle type/particular vehicles, respectively, for the three claimed fault tables in claim 3) and paragraph [0031] (which describes historical logging of data from the diagnostic tools which is stored in the database); and with the updated “fault count[s]” from the vehicle as taught by Bell (‘903) also being logged in the database of Gutlein et al. (‘829) to obviously keep a historical record of the fault counts, in order to assist in diagnosing as described at paragraph [0031] of Gutlein et al. (‘829), “Therefore, if the mechanic is often or always retrieving particular repair information and/or vehicle component information after reading out/receiving a particular fault code, this is an indication that a particular component is defective when this particular fault code occurs.”];
per claim 4, depending from claim 2, wherein in step S21, the historical fault diagnosis is performed for faults having a fault count or frequency exceeding a threshold [e.g., the threshold for the logging of the historical vehicle data in the database of Gutlein et al. (‘829) obviously being zero, in paragraphs [0019], [0031], etc.; and for the diagnostic error/fault counts provided in Bell (‘903)] in the historical fault table Ta, the production batch-related fault table Tb or the model-related fault table Tc [e.g., all as described (previously) in conjunction with claim 2];
per claim 5, depending from claim 2, wherein in step S21 and/or S22, the historical fault diagnosis and/or the real-time fault diagnosis is further performed based on a dynamic data, the dynamic data comprising a driving behavior data and/or an environmental data [e.g., “Conceivable sensor measurement variables include, for example, a coolant temperature, an engine temperature, a vehicle speed, an engine speed, an engine torque, an ambient temperature, an ambient air pressure, a boost pressure of an exhaust turbocharger of the drive engine, an engaged gear of a gearbox of the vehicle 10, etc.” at paragraph [0071] in Gutlein et al. (‘829)];
per claim 6, depending from claim 2, wherein the historical fault table Ta stores therein a license plate number10 [e.g., the VIN and “at least one further vehicle identification means can be used” (paragraph [0041]) for the database in Gutlein et al. (‘829), wherein a license plate number would have obviously been a further vehicle identification means, besides the VIN, for identifying vehicles, as was conventional; see also paragraph [0041], “The vehicle identification means can, for example, include a vehicle-specific number, such as a vehicle identification number (VIN), using which a vehicle can be uniquely identifiable.”], wherein a license plate number [e.g., the VIN and “at least one further vehicle identification means can be used” (paragraph [0041]) for the database in Gutlein et al. (‘829), wherein a license plate number would have obviously been a further vehicle identification means, besides the VIN, for identifying vehicles, as was well-known and conventional, for one having ordinary skill in the art], a production batch [e.g., paragraph [0019] in Gutlein et al. (‘829), “Said vehicle data are preferably combined in at least one matrix and in particular assigned to a particular vehicle or vehicle group”; and/or the vehicle age at paragraph [0019]], a model [e.g., “vehicle type” or “particular vehicle” at paragraph [0019] in Gutlein et al. (‘829)], a fault information [e.g., the fault codes, sensor measurement values, etc. in the database of Gutlein et al. (‘829) at paragraphs [0019], etc.], a fault count [e.g., the diagnostic error and fault counts taught by Bell (‘903)], an abnormal operation data [e.g., the “context-based repair information” at paragraph [0044] and the “fault codes” at paragraph [0074] in Gutlein et al. (‘829), and/or the list of potentially defective components at paragraph [0047]], a location of fault [e.g., “which component in the vehicle is defective and needs repairing” at paragraph [0080] in Gutlein et al. (‘829)], a source of fault [e.g., the “the exact cause of the fault message “ determined at paragraph [0017] in Gutlein et al. (‘829); and/or “creating and/or displaying a list of potentially defective components” at paragraph [0048] in Gutlein et al. (‘829)] and a repair recommendation [e.g., the context-based component information and/or the required repair steps at paragraphs [0049], [0050], etc. in Gutlein et al. (‘829)] corresponding to the fault information,
wherein the production batch-related fault table Tb [e.g., the historical vehicle data database “assigned to . . . a vehicle group” (paragraph [0019]) and including historical fault codes (e.g., paragraph [0019]) in Gutlein et al. (‘829, where the database data is arranged to include “vehicle age”, with the production batches obviously being e.g., different years] stores therein a production batch [e.g., paragraph [0019] in Gutlein et al. (‘829), “Said vehicle data are preferably combined in at least one matrix and in particular assigned to a particular vehicle or vehicle group”; and/or the vehicle age at paragraph [0019]], a fault information [e.g., the fault codes, sensor measurement values, etc. in the database of Gutlein et al. (‘829) at paragraphs [0019], etc.], a fault count [e.g., the diagnostic error and fault counts taught by Bell (‘903)], an abnormal performance [e.g., the “context-based repair information” at paragraph [0044] and the “fault codes” at paragraph [0074] in Gutlein et al. (‘829), and/or the list of potentially defective components at paragraph [0047]], a source of fault [e.g., the “the exact cause of the fault message “ determined at paragraph [0017] in Gutlein et al. (‘829); and/or “creating and/or displaying a list of potentially defective components” at paragraph [0048] in Gutlein et al. (‘829)] and a repair recommendation [e.g., the context-based component information and/or the required repair steps at paragraphs [0049], [0050], etc. in Gutlein et al. (‘829)], and
wherein the model-related fault table Tc [e.g., the historical vehicle data database “assigned to a particular vehicle” (paragraph [0019]) and including historical fault codes (e.g., paragraph [0019]) in Gutlein et al. (‘829, where the database data is arranged to include “vehicle type”, with the vehicle-type obviously being model-related] stores therein a model [e.g., “vehicle type” or “particular vehicle” at paragraph [0019] in Gutlein et al. (‘829)], a fault information [e.g., the fault codes, sensor measurement values, etc. in the database of Gutlein et al. (‘829) at paragraphs [0019], etc.], a fault count [e.g., the diagnostic error and fault counts taught by Bell (‘903)], an abnormal performance [e.g., the “context-based repair information” at paragraph [0044] and the “fault codes” at paragraph [0074] in Gutlein et al. (‘829), and/or the list of potentially defective components at paragraph [0047]], a source of fault [e.g., the “the exact cause of the fault message “ determined at paragraph [0017] in Gutlein et al. (‘829); and/or “creating and/or displaying a list of potentially defective components” at paragraph [0048] in Gutlein et al. (‘829)] and a repair recommendation [e.g., the context-based component information and/or the required repair steps at paragraphs [0049], [0050], etc. in Gutlein et al. (‘829)];
per claim 8, depending from claim 1, wherein in step S3, the comprehensive repair recommendation is transmitted [e.g., as shown by the dashed line in FIG. 2 of Gutlein et al. (‘829) between the server 30 and the diagnostic tool 20, wherein the defective component needing repairing and the context-based component information/repair steps are obviously established/created by the server 30, and displayed as diagnostic results at the diagnostic tool 20 after transmission] to the requester of the fault diagnosis request [e.g., to the user of the diagnostic tool 20 in Gutlein et al. (‘829) who requests the vehicle diagnostics] along with the comprehensive fault diagnosis result [e.g., the defective component needing repairing and/or the list of potentially defective components, in Gutlein et al. (‘829) at paragraphs [0048], [0089], etc.];
per claim 10, depending from claim 2, further comprising utilizing a big data analytics to update the production batch-related fault table Tb and the model-related fault table Tc of the vehicle in the cloud server [e.g., paragraph [0019] in Gutlein et al. (‘829), “Vehicle data from the vehicle can therefore be compared with the historical vehicle data, in particular also from vehicles from other vehicle manufacturers, in order to be able to draw a conclusion as to the vehicle state or the vehicle fault state”; see also paragraphs [0031], etc.];
per claim 11, depending from claim 2, 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 [e.g., as described by Gutlein et al. (‘829) in e.g., paragraphs [0019], [0020], [0031], etc.; see the examiner’s mapping for claim 2 for the manner in which the tables are being interpreted and mapped];
per claim 13, depending from claim 1, wherein when the historical fault diagnosis in step S21 identifies a fault that is identical to a historical fault, the real-time fault diagnosis of step S22 is bypassed [e.g., as would have been obvious in Gutlein et al. (‘829), e.g., to not use sensor measurement values for temperature, air pressure, etc. when the cause/location of the fault was already determined from the historical analysis (e.g., paragraphs [0019], [0031], etc.)];
per claim 14, depending from claim 1, wherein a decision to perform the real-time fault diagnosis in step S22 is based on a usage of the vehicle or feedback from a user of the vehicle [e.g., the real-time fault diagnosis, based on current sensor measurement values, is only performed in Gutlein et al. (‘829) when the vehicle is turned “on” and used];
per claim 15, depending from claim 1, further comprising collecting a user feedback to dynamically update the repair recommendation classifier [e.g., when the user uses the diagnostic tool 20 in Gutlein et al. (‘829) to display new diagnostic results or repair steps, or to receive “new software components or updates”, at paragraphs [0050], [0051], [0093], etc.];
per claim 17, depending from claim 1, 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 [e.g., by displaying all diagnostic results and all repair steps, etc. on a single display of the diagnostic tool 20, in Gutlein et al. (‘829), where the displayed data is thus obviously “fused” on the single display (e.g., regardless of whether on one or more screens or not)];
per claim 18 depending from claim 1, wherein step S3 comprises generating the customized repair plan based on the comprehensive fault diagnosis result [e.g., the diagnostic results, etc. in Gutlein et al. (‘829); see e.g., paragraphs [0050], etc.], a severity and a type of current fault [e.g., fault code(s) in Gutlein et al. (‘829)], and a dynamic data [e.g., sensor measurement values for ambient temperature or air pressure, as at paragraph [0071] in Gutlein et al. (‘829)], the dynamic data comprising a driving behavior data and/or an environmental data [e.g., ambient temperature or air pressure, in Gutlein et al. (‘829)];
per claim 19, depending from claim 18, wherein the dynamic data is received from a sensor system of the vehicle and/or an external data source [e.g., from vehicle sensors, in Gutlein et al. (‘829)];
per claim 20, a system comprising one or more computer processors and a computer readable memory [e.g., the computer-readable medium as taught at claim 8 of Bell (‘903), obviously implementing the controller/processor in Gutlein et al. (‘829)], the computer readable memory comprising machine executable code, which when executed by the one or more computer processors implements the method for generating repair recommendations for a vehicle of claim 1 [e.g., as mapped above with reference to claim 1];
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Gutlein et al. (2023/0252829) in view of Bell (2015/0094903) as applied to claim 1 above, and further in view of Fish et al. (2016/0314627).
Gutlein et al. (‘829) as implemented or modified in view of Bell (‘903) has been described above.
The implemented or modified Gutlein et al. (‘829) method for performing vehicle diagnostics may not reveal the repair recommendation includes a video of the repair approach, although he teaches that, in the historical data database (paragraph [0019]) which includes the “retrieved repair information” for automatic vehicle diagnostics, if the mechanic is often or always retrieving particular repair information and/or vehicle component information after reading out/receiving a particular fault code, this is an indication that a particular component is defective when this particular fault code occurs.
However, in the context/field of an improved system and method for facilitating collaboration between vehicle mechanics, Fish et al. (‘627) teaches at paragraphs [0016], [0021], etc. that the diagnostic history database 108 may optionally include digital “video” for providing a user with automated (and/or manual) assistance during the diagnosis and repair of an issue with a vehicle.
It would have been obvious before the effective filing date of the claimed invention to implement or further modify the Gutlein et al. (‘829) method for performing vehicle diagnostics so that digital video would have been stored in the historical data database, as taught by Fish et al. (‘627) for retrieval as repair information, in order to provide the user/mechanic with automated (and/or manual) assistance during the diagnosis and repair of an issue with a vehicle, as taught by Fish et al. (‘627), with a reasonable expectation of success, and e.g., as a use of a known technique to improve similar devices (methods, or products) in the same way.
As such, the implemented or modified Gutlein et al. (‘829) method for performing vehicle diagnostics would have rendered obvious:
per claim 7, depending from claim 1, wherein the second fault diagnosis result Res2 comprises an abnormal operation data [e.g., the “context-based repair information” at paragraph [0044] and the “fault codes” at paragraph [0074] in Gutlein et al. (‘829)], a location of fault [e.g., “which component in the vehicle is defective and needs repairing” at paragraph [0080] in Gutlein et al. (‘829)], a possible source of fault [e.g., “creating and/or displaying a list of potentially defective components” at paragraph [0048] in Gutlein et al. (‘829)], and wherein the second repair recommendation Sug2 comprises a description of fault symptom, an image of faulty component [e.g., “circuit diagrams” obviously including a schematic image/representation of the component, at paragraph [0044] in Gutlein et al. (‘829)], a description of repair approach [e.g., “repair steps” at paragraph [0050] in Gutlein et al. (‘829)], a video of repair approach [e.g., as taught at paragraphs [0016], [0021], etc. in Fish et al. (‘627), for obviously showing the repair steps taught by Gutlein et al. (‘829)] and any combination thereof;
Conclusion
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.
[This part of the page intentionally left blank.]
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 Since “data” is plural, and since the indefinite article “a” is used only for countable singular nouns, this phrase is apparently internally inconsistent.
2 See the 2019 35 U.S.C. 112 Compliance Federal Register Notice (Federal Register, Vol. 84, No. 4, Monday, January 7, 2019, pages 57 to 63). See also http://ptoweb.uspto.gov/patents/exTrain/documents/2019-112-guidance-initiative.pptx . Quoting the FR Notice at pages 61 and 62, "The Federal Circuit emphasized that ‘‘[t]he written description requirement is not met if the specification merely describes a ‘desired result.’ ’’ Vasudevan, 782 F.3d at 682 (quoting Ariad, 598 F.3d at 1349). . . . When examining computer-implemented, software-related claims, examiners should determine whether the specification discloses the computer and the algorithm(s) that achieve the claimed function in sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as 'a finite sequence of steps for solving a logical or mathematical problem or performing a task.' Microsoft Computer Dictionary (5th ed., 2002). Applicant may 'express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure.' Finisar, 523 F.3d at 1340 (internal citation omitted). It is not enough that one skilled in the art could theoretically write a program to achieve the claimed function, rather the specification itself must explain how the claimed function is achieved to demonstrate that the applicant had possession of it. See, e.g., Vasudevan, 782 F.3d at 682–83. If the specification does not provide a disclosure of the computer and algorithm(s) in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention that achieves the claimed result, a rejection under 35 U.S.C. 112(a) for lack of written description must be made. See MPEP § 2161.01, subsection I."
3 See http://www.uspto.gov/sites/default/files/documents/fnctnllnggcmptr.pptx at page 29.
4 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.”)
5 The term “and/or” in a claim has been held to be definite in Ex Parte Gross, Appeal No. 2011-004811, Application 11/565,411, 2013 WL 6907805 (PTAB Jan. 3, 2014), where the PTAB held, “We agree with Appellant that "[A] and/or [B]" covers embodiments having element A alone, element B alone, or elements A and B taken together (App. Br. 16).”
6 See, e.g., 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")
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.")
8 ta·ble (tā′bəl) n.
. . .
9. An orderly arrangement of data, especially one in which the data are arranged in columns and rows in an essentially rectangular form.
10. An abbreviated list, as of contents; a synopsis.
. . .
[From: American Heritage® Dictionary of the English Language, Fifth Edition. Copyright © 2016 by Houghton Mifflin Harcourt Publishing Company. Published by Houghton Mifflin Harcourt Publishing Company. All rights reserved. Retrieved 27 March 2026.]
9 To the extent that the/any particularly recited data in the claim/claim set is merely stored/provided and is not functionally utilized by the method of the claim, then it is considered by the examiner to be “nonfunctional descriptive material” that is given/owed no patentable weight in patentability determination. See MPEP 2111.05.
10 To the extent that the/any particularly recited data in the claim/claim set is merely stored/provided and is not functionally utilized by the method of the claim, then it is considered by the examiner to be “nonfunctional descriptive material” that is given/owed no patentable weight in patentability determination. See MPEP 2111.05.
Prosecution Insights