DETAILED ACTION
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
The amendment filed May 18, 2026 has been entered. Claims 1, 18, 19, 27, 28, 30, and 31have been amended. Claim 17 is presently canceled. Claim 33 is new. The remaining claims are in original or previously presented form. Therefore, claims 1-16 and 18-33 are pending in the application.
The Remarks filed May 18, 2026 have been fully considered. The applicant states under the heading “Disposition of Claims” on page 7 of the Remarks that “Claims 1, 27, 28, 30, and 31 are independent.” The applicant further states under the heading “Rejections under 35 U.S.C. § 112” that “claims 24 and 26 are proper dependent claims of claim 1 and are not indefinite.” In the last detailed action, which was the Non-Final Rejection dated December 18, 2025, the examiner argued that beginning a claim with, “A system comprising,” as in claims 24 and 26 of the last set of claims, sure makes the claims appear to be independent claims. And yet the claims also recited “…of claim 1”—language which generally signals a dependent claim.
The applicant in the Remarks cites MPEP 608.01(n) which states that a proper dependent claim “shall include every limitation of the claim from which it depends and specify a further limitation of the subject matter claimed.” Furthermore, “The fact that the independent and dependent claims are in different statutory classes does not, in itself, render the latter improper.”
The MPEP section does not provide specific examples, but states generally that “if claim 1 recites a specific product, a claim for the method of making the product of claim 1 in a particular manner would be a proper dependent claim since it further specifies limitations relating to the method of making the product of claim 1.” The present application does not involve mixing product and method claims in the examiner’s view because claim 1 is for a tangible “product” with material structure.
It seems to the examiner that in this case, the dependent claim might begin something like: The product of claim 1, wherein the product is made us a method comprising…” In this example, the dependency is clear. In the present application, in contrast, claims 24 and 26—both of which the applicant argues in the Remarks are dependent claims—begin by reciting: “A system comprising…” Why doesn’t the applicant simply change that to something like: The computer program product of claim 1, further comprising: a system comprising the computer program product; and a scan tool…? It is possible that the applicant might view this as potentially suggesting to some that the dependent claim is broader than the independent claim. In the examiner’s view, that is not the case; the “computer program product of claim 1” is broader than that same computer program product further narrowed by being part of a system including a scan tool.
The examiner has discussed this issue with a technical quality assurance specialist (TQAS) at the USPTO. The conclusion from the discussion was that the applicant is permitted by rule to use the claim language as written. The claim is a dependent claim, as the applicant acknowledges. In the examiner’s view, the claim means the same thing as what the examiner suggests above. The examiner withdraws the rejection.
The applicant further states under the heading “Amendments to the Claims” that “Claims 1, 27, 28, 30, and 31 have been amended to incorporate the feature of claim 17, which is now canceled.” The applicant then argues under the heading “Rejections under 35 U.S.C. § 103” on page 9 of the Remarks that claim 17 was rejected using Wes (Watch Wes Work, Youtube video clip entitled, “Can ChatGPT Diagnose this Car?,” uploaded on June 17, 2023, https://www.youtube.com/watch?v=BrpBQcqSbx0,). But according to the applicant, the portions of Wes cited “refer to troubleshooting, i.e., diagnostics. Nothing in Wes suggests ‘repair instructions for the user to perform a repair on the vehicle’ as claimed.” Italics in original.
The examiner respectfully does not find this argument persuasive. The line between troubleshooting instructions and repair instructions is significantly blurred. The applicant may interpret troubleshooting instructions as involving instructions to determine what is wrong while interpretating repair instructions as involving the steps to fix what is wrong. But, in the examiner’s mind, troubleshooting instructions also implies steps to fix the problem, i.e., to shoot the trouble, not just finding out what is wrong. This is also the definition Wes uses. For example, the screen shot at 2:35, which was cited in the rejection of claim 17 in the last detailed action, there is a heading entitled “Potential troubleshooting steps;” and then a bullet point reading “clean or replace clogged fuel injectors”. Isn’t that a repair instruction? Another bullet point reads: “Test the MAF sensor for proper function or consider cleaning it if applicable.” At the bottom of the screen shot the system provide a natural language instruction to obtain a code that may indicate that the MAF sensor is outside its expected range. This “could be caused by a faulty sensor, dirty or contaminated sensor element, or an issue with the sensor’s wiring or connector.” If the system merely instructed the user to obtain diagnostic codes, then it would lack the “repair instructions” aspect taught in original claim 17. But the system disclosed by Wes goes beyond that to actually instructing to the user to make repairs.
Thus, the system of Wes not only tells the user in natural language how to know if the MAF sensor needs cleaning, but also tells the user to clean the sensor. So the user requests some kind of repair instructions or troubleshooting instructions of the system by describing the general problem with the vehicle. Then the system replies to the user in natural language that the user should check the code related to the MAF sensor, and if the code is out of range, then the MAF sensor may need to be cleaned or replaced. The system also tells the user to clean or replace that sensor.
The examiner also thinks that other previously cited art teaches the limitations of original claim 17. Should it be found that Wes does not teach the limitations cited as being taught by Wes in the rejection of present claim 1 and original claim 17, the examiner might rely on Saini (US20200410781). Saini teaches a system in paragraph 0023 in which a user makes a “request for content related to fixing a flat tire, including how to patch a flat tire and how to replace a flat tire with a spare time.” Paragraph 0051 teaches that the reply to such an inquiry can be in the form of a video or “a how-to document.” Paragraph 0042 teaches providing “repair instructions” to a user. Paragraph 0015 teaches that the system may “quickly provide instructions for repairing or replacing damaged vehicle components”.
Saini, paragraph 0065, teaches that the system will “provide an instruction video for replace the side mirror.” Does the video contain only visual material? That seems to the examiner to be an unreasonable supposition. Paragraph 00706 teaches that, once a system identifies a problem, such as with low fuel, the system can provide step-by-step instructions to add fuel to the vehicle. The paragraph characterizes these instructions as “content”. Claim 9 teaches that “the content includes at least one of audio data, video data, or text data.” See also Fig. 10, step 1016 for “user receives interactive guide for troubleshooting the scenario.” So Saini teaches an AI-system that provides step-by-step interactive how-to repair instructions in audio, video, and text forms. It seems to the examiner that this teaches the limitations of original claim 17 above a preponderance of the evidence standard.
The examiner also notes that Saini uses the term troubleshoot to at least include repair instructions. See Fig. 10, step 1010 for “Provide step-by-step guide to identify and troubleshoot the source of leakage”. This strongly implies that troubleshoot include repairing the problem.
The applicant further states under the heading “Rejections under 35 U.S.C. § 103” on page 10 of the Remarks that clarification of the rejection of claim 19 is requested. In the heading above the rejection of claim 19 the examiner correctly cited Huynh (U.S. 12,112,587), filed June 2, 2023, hereinafter Huynh. The examiner clarifies that Huynh, col. 10, lines 32-54, teaches an AI-based diagnostic and repair system which can recommend replacement of a component. “The component is then replaced, and then a validation is conducted.” The system can provide a “repair validation” that can include “any validation procedure performed after a fix has been facilitated[d].” This validation can “confirm the passed status.” The motivation to combine Brunda in view of Wes with Huynh is that to make sure that the repair was successful, as recognized by Huynh (see col. 10, lines 48-54).
Due to the applicant’s amendments the grounds for rejection have changed. Please see the rejections below.
Claims 1-8, 10, 11, 14, 16, and 20-32 are rejected under 35 U.S.C. 103 as being unpatentable over Brunda et al. (U.S. 11,455,841) in view of Watch Wes Work, Youtube video clip entitled, “Can ChatGPT Diagnose this Car?,” uploaded on June 17, 2023, https://www.youtube.com/watch?v=BrpBQcqSbx0, hereinafter Wes.
Regarding claim 1, Brunda teaches:
A computer program product comprising one or more non-transitory program storage media on which are stored instructions executable by one or more processors or programmable circuits to perform operations for providing vehicle diagnostics, the operations comprising (see Fig. 1 for a cellphone 101. See also col. 25, lines 26-48 for the app 100 running on the phone that includes storage, instructions, and a processor):
receiving a request for AI-assisted diagnostics (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data.);
receiving diagnostic data obtained from a vehicle (see Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.);
prompting a user to describe one or more symptoms exhibited by the vehicle (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.”);
processing the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model (see col. 23, lines 40-50 for the teaching that “the app may prompt the vehicle owner with a series of questions (e.g. does the car start? is there smoke coming out of the engine?)”. See col. 28, lines 2-12 for a machine learning model tailored for diagnosing the exact same noise using the vehicle’s year, make, and model.).
Yet Brunda does not explicitly further teach:
providing natural language guidance to the user based on a result of the processing,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle.
However, Wes teaches:
providing natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language.),
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle (see Wes, screen shot at time 2:35 in which ChatGPT provides step-by-step instructions to follow. See “Potential troubleshooting steps” at the bottom of the screen. At 2:42 Wes interprets the “steps” this way, by stating “First step is to check for any exhaust leaks for the catalytic converter.” See also the screen shot at 3:42 that recites “if the exhaust leak repair doesn’t resolve the issue,” then “further diagnostics may be needed”. ChatGPT expands on the “potential trouble shooting steps” at 4:07 with a specific list of steps to take. See also 4:41 for the instruction to “follow these steps”. See also the screen shot at 2:35, for the heading entitled “Potential troubleshooting steps;” and then a bullet point reading: “clean or replace clogged fuel injectors”. Another bullet point reads: “Test the MAF sensor for proper function or consider cleaning it if applicable.” At the bottom of the screen shot at that time point the system provides a natural language instruction to obtain a code that may indicate that the MAF sensor is outside its expected range. This “could be caused by a faulty sensor, dirty or contaminated sensor element, or an issue with the sensor’s wiring or connector.” If the system merely instructed the user to obtain diagnostic codes, then it would lack the “repair instructions” aspect taught in original claim 17. But the system disclosed by Wes goes beyond that to actually instructing to the user to make repairs. Thus, the system of Wes not only tells the user in natural language how to know if the MAF sensor needs cleaning, but also tells the user to clean the sensor. So the user requests some kind of repair instructions or troubleshooting instructions of the system by describing the general problem with the vehicle. Then the system replies to the user in natural language that the user should check the code related to the MAF sensor, and if the code is out of range, then the MAF sensor may need to be cleaned or replace, and the system also tells the user to clean or replace that sensor.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda, to add the additional features of providing natural language guidance to the user based on a result of the processing, wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle, as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
This combination is particularly obvious in Brunda at least strongly teaches toward what Wes more explicitly teaches. See Brunda, col. 28, lines 24-26 for “guidance” being “for example, written or spoken,” and lines 31-45, for providing “guidance” to the user, such as “ ‘back up’ or ‘move closer’”. These phrases are natural language, but Wes expands on this and demonstrates the guidance more explicitly using longer examples of natural language.
Note that this obvious combination is not one in which the first reference does not use AI and the second reference does. Rather, both references feature AI, making them very compatible. Brunda explicitly uses “machine learning” coupled with a cellphone with an app through which the user can input diagnostic data. The system of Wes does not have the ability to receive diagnostic data directly, such as from the OBD port of the vehicle, but Brunda cures that deficiency.
Overall, it seems to the examiner that the present claim 1 involves disclosing a wrapper around an existing AI tool, like ChatGPT, that permits a user to enter diagnostic data and receive natural language response. Brunda largely teaches this, with Wes adding that the AI tool replies with extensive natural language, including with repair instructions.
Regarding claim 2, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
the diagnostic data is obtained from the vehicle in response to the request being received (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data. See Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102. See also col. 24, lines 4-19 for the vehicle owners having a DAT 102 themselves and performing what the “diagnostic service provider 300” might otherwise perform. Thus, anything taught related to the diagnostic service provider 300 in relation to obtaining information from the DAT 102 or OBD port of the vehicle can be performed by a user. Thus, col. 24, lines 38-42 teaches that “the app 100 may instead retrieve diagnostic data including the VIN directly from the vehicle 30 via the DAT 102 in response to the scan instruction receiving in step 420.” This information is then sent to a server.).
Regarding claim 4, Brunda and Wes teach the computer program product of claim 2.
Brunda further teaches:
The computer program product of claim 2, wherein
the request is derived from text entered by the user (see col. 27, lines 38-45 for the teaching that the app “may allow the user to input to the mobile communication device 101 information identifying at least one symptom associated with the vehicle 30. For instance, the app may prompt the user to input information on the mobile communication device 101, for example, in the form of answers to a series of questions.” See also col. 27, lines 45-49 for the user inputting information regarding the vehicle.).
Regarding claim 5, Brunda and Wes teach the computer program product of claim 2.
Brunda further teaches:
The computer program product of claim 2, wherein
the diagnostic data is obtained autonomously in response to the request being received (see col. 24, lines 20-53 for the app “autonomously” detecting the DAT, obtaining information from the vehicle. This occurs in response to the vehicle owner tapping the scan button 110, as described in col. 23, lines 27-28).
Regarding claim 6, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
the diagnostic data is obtained from the vehicle at predefined intervals (see col. 25, lines 5-10), and
the request is generated in response to an evaluation of the diagnostic data (note that the antecedent to the present clause’s recitation of “the request” is found in claim 1 which recites “a request for AI-assisted diagnostics”. Claim 1 teaches that a user makes a request via the app for the system to perform a diagnostic check on the user’s vehicle, while claim 6 teaches that it is the reverse; the request is made in response to the diagnostic data. This can make sense if the diagnostic data is performed at predefined intervals. Then, an evaluation of the data could be requested to be performed. With that in mind, see Brunda, col. 25, lines 5-10 for a system that performs a diagnostic check periodically, such as once a week. Then see col. 29, lines 44 to col. 30, line 4, for a system that observers “trends” that are noticeable “over time” and uses that to predict when maintenance on the vehicle needs to be performed. The example in the disclosure of Brunda is tire wear. A broad reasonable interpretation of this is that the system collects tire wear data over time, including how the driver drives the vehicle and how many miles are on the vehicle. The system then compares this data to manufacturer data, vehicle make and model data, crowdsourced data of when others (with similar driving habits and the same vehicle) needed to replace their tires, and then generates alerts. This means that the system requests an evaluation of the data after the diagnostic data has accumulated over time.).
Regarding claim 7, Brunda and Wes teach the computer program product of claim 6.
Brunda further teaches:
The computer program product of claim 6, wherein
the request is generated by a scan tool (in the present disclosure, see Fig. 1 and paragraph 0044 for the statement “a dongle that plugs into the OBD port or a scanner or scan tool that connects to the OBD port via a cable, for example” collects diagnostic data from the on-board computer of the vehicle 10. The mobile device 110 can communicate with the dongle 110. In one broad reasonable interpretation, a “scan tool” and a “mobile device” as recited in other claims are largely interchangeable. A scan tool could plug directly into the OBD port, while a mobile device needs the dongle 120 to do that, but the scan tool and the mobile device are both capable of being communicatively coupled to the on-board vehicle computer and can obtain diagnostic data from it.
With that in mind, see Brunda, col. 25, lines 5-10 for a system that performs a diagnostic check periodically, such as once a week. Then see col. 29, lines 44 to col. 30, line 4, for a system that observers “trends” that are noticeable “over time” and uses that to predict when maintenance on the vehicle needs to be performed. The example in the disclosure of Brunda is tire wear. A broad reasonable interpretation of this is that the system collects tire wear data over time, including how the driver drives the vehicle and how many miles are on the vehicle. The system then compares this data to manufacturer data, vehicle make and model data, crowdsourced data of when others (with similar driving habits and the same vehicle) needed to replace their tires, and then generates alerts. This means that the system requests an evaluation of the data after the diagnostic data has accumulated over time.).
Regarding claim 8, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
the diagnostic data includes identification information of the vehicle (col. 24, lines 38-42 which teaches that “the app 100 may…retrieve diagnostic data including the VIN directly from the vehicle 30 via the DAT 102 in response to the scan instruction receiving in step 420.” See also col. 23, lines 43-48.).
Regarding claim 10, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
the one or more symptoms are derived from text entered by the user (see col. 27, lines 38-45 for the teaching that the app “may allow the user to input to the mobile communication device 101 information identifying at least one symptom associated with the vehicle 30. For instance, the app may prompt the user to input information on the mobile communication device 101, for example, in the form of answers to a series of questions.” See also col. 27, lines 45-49 for the user inputting information regarding the vehicle. See also col. 23, lines 43-48.).
Regarding claim 11, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
the natural language guidance includes testing instructions for the user to perform a step-by-step procedure to diagnose the vehicle (see, col. 28, lines 24-26 for “guidance” being “for example, written or spoken,” and lines 31-45, for providing “guidance” to the user, such as “‘back up’ or ‘move closer’”. These phrases are natural language. While Wes expands on this and demonstrates the guidance more explicitly using longer examples of natural language, Brunda’s guidance are step-by-step instructions).
Regarding claim 14, Brunda and Wes teach the computer program product of claim 11.
Brunda further teaches:
The computer program product of claim 11 wherein
the testing instructions include an expected range value (see col. 30, lines 25-30 for presenting tire pressure information to the user, including the recommended range.).
Regarding claim 16, Brunda and Wes teach the computer program product of claim 1.
Yet Brunda does not further teach:
The computer program product of claim 1, wherein
the operations further comprise initiating an automated diagnostic routine based on the result of the processing,
wherein the natural language guidance is provided to the user further based on a result of the automated diagnostic routine.
However, Wes teaches:
the operations further comprise initiating an automated diagnostic routine based on the result of the processing (the antecedent to “the result of the processing” in the present claim is found in claim 1. In claim 1, the user is prompted to “describe one or more symptoms exhibited by the vehicle” and the computer engages in “processing the one or more symptoms”. Claim 1 then recites “providing natural language guidance to the user based on a result of the processing”. The present claim recites that the computer is configured for “initiating an automated diagnostic routine based on the result of the processing”. In one broad reasonable interpretation, the present claim, in the context of claim 1, can mean that the user inputs symptoms and then the system provides natural language guidance as a result of processing those symptoms, and that this natural language guidance may not provide the immediate fix for the symptoms but may initiate a diagnostic routine, which could reasonably include follow-up questions, or follow-up requests for information or user input, such as asking additional questions or requesting the user answer Y/N questions or input a value, such as a voltage or other measurement.
With that in mind, see Wes, screen shot at time 2:35 in which ChatGPT provides step-by-step instructions to follow. See “Potential troubleshooting steps” at the bottom of the screen. See also the screen shot at 3:42 that recites “if the exhaust leak repair doesn’t resolve the issue,” then “further diagnostics may be needed”. ChatGPT expands on the “potential trouble shooting steps” at 4:07 with a specific list of steps to take. See also 4:41 for the instruction to “follow these steps”.),
wherein the natural language guidance is provided to the user further based on a result of the automated diagnostic routine (see the rejection of the above bullet point.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of the operations further comprise initiating an automated diagnostic routine based on the result of the processing, wherein the natural language guidance is provided to the user further based on a result of the automated diagnostic routine, as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 20, Brunda and Wes teach the computer program product of claim 1.
Yet Brunda does not further teach:
The computer program product of claim 1, wherein
said processing and said providing the natural language guidance proceed autonomously in response to receipt of the one or more symptoms.
However, Wes teaches:
said processing and said providing the natural language guidance proceed autonomously in response to receipt of the one or more symptoms (for processing to proceed autonomously (or automatically, as the word implies in this context) seems inherent in AI systems, like ChatGPT. So does providing the response. The AI system receives an input from the user, such as a symptom, and then the AI system processes the input and returns a response without further need of the user to do anything, thus the processing and providing “proceed autonomously”. With that in mind, see Wes at time 2:23 for the user entering error codes and then the system processing them and providing a natural language response automatically.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of: said processing and said providing the natural language guidance proceed autonomously in response to receipt of the one or more symptoms, as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 21, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
said processing includes
uploading the one or more symptoms and the diagnostic data to one or more servers (see Fig. 1, item 200 and Fig. 7, step 730) and
receiving the result from the one or more servers (see Fig. 4, step 450; and Fig. 7 step 740).
Regarding claim 22, Brunda and Wes teach the computer program product of claim 1.
Brunda further teaches:
The computer program product of claim 1, wherein
said processing includes inputting the one or more symptoms and the diagnostic data to a machine learning model (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” See also col. 8, lines 20-32).
Regarding claim 23, Brunda and Wes teach the computer program product of claim 22.
Brunda further teaches:
The computer program product of claim 22, wherein
said processing includes generating instructions to collect additional data based on an output of the machine learning model (see col. 23, lines 27-62. The system receives at least one symptom, and then, after processing that, further obtain VIN info, derive diagnostic data, and then receive past vehicle condition information and then derive more diagnostic data “further taking into account” this information to obtain a “more targeted” diagnosis with “increased value for the vehicle owner.”).
Regarding claim 24, Brunda teaches:
A system comprising (see Fig. 1):
the computer program product of claim 1 (see the rejection of claim 1).
Yet Brunda does not explicitly further teach:
providing natural language guidance to the user based on a result of the processing.
However, Wes teaches:
providing natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda, to add the additional features of providing natural language guidance to the user based on a result of the processing, as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 25, Brunda and Wes teach the system of claim 24.
Brunda further teaches:
The system of claim 24, wherein
the diagnostic data is obtained from the vehicle by a dongle communicatively coupled with the mobile device (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data. See Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102. See also col. 24, lines 4-19 for the vehicle owners having a DAT 102 themselves and performing what the “diagnostic service provider 300” might otherwise perform. Thus, anything taught related to the diagnostic service provider 300 in relation to obtaining information from the DAT 102 or OBD port of the vehicle can be performed by a user. Thus, col. 24, lines 38-42 teaches that “the app 100 may instead retrieve diagnostic data including the VIN directly from the vehicle 30 via the DAT 102 in response to the scan instruction receiving in step 420.” This information is then sent to a server.).
Regarding claim 26, Brunda teaches:
A system comprising:
the computer program product of claim 1 (see the rejection of claim 1.):
receiving a request for AI-assisted diagnostics (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data.);
receiving diagnostic data obtained from a vehicle (see Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.);
prompting a user to describe one or more symptoms exhibited by the vehicle (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.”);
processing the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model (see col. 23, lines 40-50 for the teaching that “the app may prompt the vehicle owner with a series of questions (e.g. does the car start? is there smoke coming out of the engine?)”. See col. 28, lines 2-12 for a machine learning model tailored for diagnosing the exact same noise using the vehicle’s year, make, and model.); and
a scan tool (see col. 16, lines 35-39. This teaches a scan tool and that the scan tool and a phone with app. 100 and a dongle are essentially identical in function. See Fig. 1, item 101 with a dongle, and item 102, a DAT.),
wherein the scan tool includes the one or more processors or programmable circuits and is operable to obtain the diagnostic data from the vehicle (a scan tool that functions as a phone with an app inherently has processors and programs that meet the limitations of this clause.).
Yet Brunda does not explicitly further teach:
providing natural language guidance to the user based on a result of the processing.
However, Wes teaches:
providing natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda, to add the additional features of providing natural language guidance to the user based on a result of the processing, as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 27, Brunda teaches:
A method of providing vehicle diagnostics, the method comprising (see the title of Brunda for teaching a system and method):
receiving a request for AI-assisted diagnostics (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data.);
receiving diagnostic data obtained from a vehicle (see Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.);
prompting a user to describe one or more symptoms exhibited by the vehicle (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.”);
processing the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model (see col. 23, lines 40-50 for the teaching that “the app may prompt the vehicle owner with a series of questions (e.g. does the car start? is there smoke coming out of the engine?)”. See col. 28, lines 2-12 for a machine learning model tailored for diagnosing the exact same noise using the vehicle’s year, make, and model.).
Yet Brunda does not explicitly further teach:
providing natural language guidance to the user based on a result of the processing,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle.
However, Wes teaches:
providing natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language.),
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language.),
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle (see Wes, screen shot at time 2:35 in which ChatGPT provides step-by-step instructions to follow. See “Potential troubleshooting steps” at the bottom of the screen. At 2:42 Wes interprets the “steps” this way, by stating “First step is to check for any exhaust leaks for the catalytic converter.” See also the screen shot at 3:42 that recites “if the exhaust leak repair doesn’t resolve the issue,” then “further diagnostics may be needed”. ChatGPT expands on the “potential trouble shooting steps” at 4:07 with a specific list of steps to take. See also 4:41 for the instruction to “follow these steps”. See also the screen shot at 2:35, for the heading entitled “Potential troubleshooting steps;” and then a bullet point reading: “clean or replace clogged fuel injectors”. Another bullet point reads: “Test the MAF sensor for proper function or consider cleaning it if applicable.” At the bottom of the screen shot at that time point the system provides a natural language instruction to obtain a code that may indicate that the MAF sensor is outside its expected range. This “could be caused by a faulty sensor, dirty or contaminated sensor element, or an issue with the sensor’s wiring or connector.” If the system merely instructed the user to obtain diagnostic codes, then it would lack the “repair instructions” aspect taught in original claim 17. But the system disclosed by Wes goes beyond that to actually instructing to the user to make repairs. Thus, the system of Wes not only tells the user in natural language how to know if the MAF sensor needs cleaning, but also tells the user to clean the sensor. So the user requests some kind of repair instructions or troubleshooting instructions of the system by describing the general problem with the vehicle. Then the system replies to the user in natural language that the user should check the code related to the MAF sensor, and if the code is out of range, then the MAF sensor may need to be cleaned or replace, and the system also tells the user to clean or replace that sensor.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method, as taught by Brunda, to add the additional features taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 28, Brunda teaches:
A system for providing vehicle diagnostics, the system comprising (see Fig. 1):
a mobile device operable to (see Fig. 1 for a cellphone 101. See also col. 25, lines 26-48 for the app 100 running on the phone that includes storage, instructions, and a processor)
receive a request for AI-assisted diagnostics (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data.),
receive diagnostic data obtained from a vehicle (see Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.), and
prompt a user to describe one or more symptoms exhibited by the vehicle (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.”); and
one or more servers in communication with the mobile device (see Fig. 1 for the phone 101 and server 200 being in communication.),
the one or more servers being operable to process the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model (see Fig. 4, step 450; and Fig. 7 steps 730 and 740),
Yet Brunda does not further teach:
wherein the mobile device is further operable to provide natural language guidance to the user based on a result of the processing,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle.
However, Wes teaches:
wherein the mobile device is further operable to provide natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language. This is done on a laptop, which is a mobile device. Furthermore, accessing ChatGPT and other such AI models on a laptop can be a done on a smartphone.),
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle (see Wes, screen shot at time 2:35 in which ChatGPT provides step-by-step instructions to follow. See “Potential troubleshooting steps” at the bottom of the screen. At 2:42 Wes interprets the “steps” this way, by stating “First step is to check for any exhaust leaks for the catalytic converter.” See also the screen shot at 3:42 that recites “if the exhaust leak repair doesn’t resolve the issue,” then “further diagnostics may be needed”. ChatGPT expands on the “potential trouble shooting steps” at 4:07 with a specific list of steps to take. See also 4:41 for the instruction to “follow these steps”. See also the screen shot at 2:35, for the heading entitled “Potential troubleshooting steps;” and then a bullet point reading: “clean or replace clogged fuel injectors”. Another bullet point reads: “Test the MAF sensor for proper function or consider cleaning it if applicable.” At the bottom of the screen shot at that time point the system provides a natural language instruction to obtain a code that may indicate that the MAF sensor is outside its expected range. This “could be caused by a faulty sensor, dirty or contaminated sensor element, or an issue with the sensor’s wiring or connector.” If the system merely instructed the user to obtain diagnostic codes, then it would lack the “repair instructions” aspect taught in original claim 17. But the system disclosed by Wes goes beyond that to actually instructing to the user to make repairs. Thus, the system of Wes not only tells the user in natural language how to know if the MAF sensor needs cleaning, but also tells the user to clean the sensor. So the user requests some kind of repair instructions or troubleshooting instructions of the system by describing the general problem with the vehicle. Then the system replies to the user in natural language that the user should check the code related to the MAF sensor, and if the code is out of range, then the MAF sensor may need to be cleaned or replace, and the system also tells the user to clean or replace that sensor.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda, to add the additional features indicated as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 29, Brunda and Wes teach the system of claim 28.
Brunda further teaches:
The system of claim 28, further comprising
a data acquisition and transfer device (DAT) in communication with the mobile device and connected to an OBD port of the vehicle, the DAT being operable to obtain the diagnostic data from the vehicle (see col. 16, lines 35-39. This teaches a scan tool and that the scan tool and a phone with app. 100 and a dongle are essentially identical in function. See also col. 25, lines 4-53).
Regarding claim 30, Brunda teaches:
A system for providing vehicle diagnostics, the system comprising (see Fig. 1):
a scan tool operable to (see Fig. 1, item 101 and item 102. See col. 16, lines 35-39. This teaches a scan tool and that the scan tool and a phone with app. 100 and a dongle are essentially identical in function. See Fig. 1, item 101 with a dongle, and item 102, a DAT.)
receive a request for AI-assisted diagnostics (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.” Tapping the scan button 110 is the app receiving a request from the user to begin the process of entering the diagnostic data.),
receive diagnostic data obtained from a vehicle (see Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.), and
prompt a user to describe one or more symptoms exhibited by the vehicle (see col. 23, lines 27-62 for the teaching that “upon tapping the scan button 110, the app 100 may….allow the user to input to the mobile communication device at least one symptom associated with the vehicle 30.”); and
one or more servers in communication with the scan tool (see Fig. 1 for the phone 101 with dongle, item 102 for the DAT, and server 200 all being in communication.),
the one or more servers being operable to process the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model (see Fig. 4, step 450; and Fig. 7 steps 730 and 740);
Yet Brunda does not further teach:
wherein the scan tool is further operable to provide natural language guidance to the user based on a result of the processing,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle.
However, Wes teaches:
wherein the scan tool is further operable to provide natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language. This is done on a laptop, which is a mobile device. Furthermore, accessing ChatGPT and other such AI models on a laptop can be a done on a smartphone.) ,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle (see Wes, screen shot at time 2:35 in which ChatGPT provides step-by-step instructions to follow. See “Potential troubleshooting steps” at the bottom of the screen. At 2:42 Wes interprets the “steps” this way, by stating “First step is to check for any exhaust leaks for the catalytic converter.” See also the screen shot at 3:42 that recites “if the exhaust leak repair doesn’t resolve the issue,” then “further diagnostics may be needed”. ChatGPT expands on the “potential trouble shooting steps” at 4:07 with a specific list of steps to take. See also 4:41 for the instruction to “follow these steps”. See also the screen shot at 2:35, for the heading entitled “Potential troubleshooting steps;” and then a bullet point reading: “clean or replace clogged fuel injectors”. Another bullet point reads: “Test the MAF sensor for proper function or consider cleaning it if applicable.” At the bottom of the screen shot at that time point the system provides a natural language instruction to obtain a code that may indicate that the MAF sensor is outside its expected range. This “could be caused by a faulty sensor, dirty or contaminated sensor element, or an issue with the sensor’s wiring or connector.” If the system merely instructed the user to obtain diagnostic codes, then it would lack the “repair instructions” aspect taught in original claim 17. But the system disclosed by Wes goes beyond that to actually instructing to the user to make repairs. Thus, the system of Wes not only tells the user in natural language how to know if the MAF sensor needs cleaning, but also tells the user to clean the sensor. So the user requests some kind of repair instructions or troubleshooting instructions of the system by describing the general problem with the vehicle. Then the system replies to the user in natural language that the user should check the code related to the MAF sensor, and if the code is out of range, then the MAF sensor may need to be cleaned or replace, and the system also tells the user to clean or replace that sensor.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda, to add the additional features as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 31, Brunda teaches:
A computer program product comprising one or more non-transitory program storage media on which are stored instructions executable by one or more processors or programmable circuits to perform operations for providing vehicle diagnostics, the operations comprising (see Fig. 1 for a cellphone 101. See also col. 25, lines 26-48 for the app 100 running on the phone that includes storage, instructions, and a processor):
receiving diagnostic data obtained from a vehicle (see Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.);
receiving symptomatic data obtained from one or more sensors within the vehicle (see col. 7, lines 1-4. See Fig. 1 and col. 24, lines 4-5, noting that a DAT 102 functions as a diagnostic tool. See lines 36-41 for the app 100 receiving “diagnostic data” from the DAT 102.);
inputting the diagnostic data and the symptomatic data to a machine learning model (see col. 7, lines 5-25, and col. 28, lines 2-12).
Yet Brunda does not explicitly further teach:
providing natural language guidance to the user based on a result of the processing,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle.
However, Wes teaches:
providing natural language guidance to the user based on a result of the processing (see Wes, especially the screen at 3:36 in which ChatGPT provides step-by-step instructions to the user, Wes, in natural language.) ,
wherein the natural language guidance includes repair instructions for the user to perform a repair on the vehicle (see Wes, screen shot at time 2:35 in which ChatGPT provides step-by-step instructions to follow. See “Potential troubleshooting steps” at the bottom of the screen. At 2:42 Wes interprets the “steps” this way, by stating “First step is to check for any exhaust leaks for the catalytic converter.” See also the screen shot at 3:42 that recites “if the exhaust leak repair doesn’t resolve the issue,” then “further diagnostics may be needed”. ChatGPT expands on the “potential trouble shooting steps” at 4:07 with a specific list of steps to take. See also 4:41 for the instruction to “follow these steps”. See also the screen shot at 2:35, for the heading entitled “Potential troubleshooting steps;” and then a bullet point reading: “clean or replace clogged fuel injectors”. Another bullet point reads: “Test the MAF sensor for proper function or consider cleaning it if applicable.” At the bottom of the screen shot at that time point the system provides a natural language instruction to obtain a code that may indicate that the MAF sensor is outside its expected range. This “could be caused by a faulty sensor, dirty or contaminated sensor element, or an issue with the sensor’s wiring or connector.” If the system merely instructed the user to obtain diagnostic codes, then it would lack the “repair instructions” aspect taught in original claim 17. But the system disclosed by Wes goes beyond that to actually instructing to the user to make repairs. Thus, the system of Wes not only tells the user in natural language how to know if the MAF sensor needs cleaning, but also tells the user to clean the sensor. So the user requests some kind of repair instructions or troubleshooting instructions of the system by describing the general problem with the vehicle. Then the system replies to the user in natural language that the user should check the code related to the MAF sensor, and if the code is out of range, then the MAF sensor may need to be cleaned or replace, and the system also tells the user to clean or replace that sensor.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the product, as taught by Brunda, to add the additional features as taught by Wes. The motivation for doing so would be to provide customized instructions in plain English, as recognized by Wes (see the video at 22:10 in which Wes states receiving a “simple plain text answer” which can be seen at 2:35 and other times.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 32, Brunda and Wes teach the computer program product of claim 31.
Brunda further teaches:
The computer program product of claim 31, wherein
the operations further comprise building a training data set based on the diagnostic data, the symptomatic data, and the output of the machine learning model (see col. 27, line 57-col. 28, line 12. See also col. 12, lines 31-34).
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Brunda in view of Wes in further view of Poluri et al. (US2021/0248732).
Regarding claim 12, Brunda and Wes teach the computer program product of claim 11.
Yet Brunda and Wes do not further teach:
The computer program product of claim 11, wherein
the testing instructions include a wire color.
However, Poluri teaches:
the testing instructions include a wire color (see paragraph 0048 for a user being instructed regarding a correct wire and color and “whether the connection is correct”. See paragraph 0046 for providing audible instructions in natural language. See paragraph 0030 for identifying wiring errors.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the product, as taught by Brunda and Wes, to add the additional features of the testing instructions include a wire color, as taught by Poluri. The motivation for doing so would be to find wiring errors and fix them, as recognized by Poluri (see paragraph 0004.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 13, Brunda and Wes teach the computer program product of claim 11.
Yet Brunda and Wes do not further teach:
The computer program product of claim 11, wherein
the testing instructions include a pin number.
However, Poluri teaches:
the testing instructions include a pin number (see Fig. 13 and paragraph 0053 for item 180 being pin numbers. Wire colors associated with them are seen at items 180 and the pins to the right. See paragraph 0048 for a user being instructed regarding a correct wire and color and “whether the connection is correct”. See paragraph 0046 for providing audible instructions in natural language. See paragraph 0030 for identifying wiring errors.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the product, as taught by Brunda and Wes, to add the additional features of testing instructions include a pin number, as taught by Poluri. The motivation for doing so would be to find wiring errors and fix them, as recognized by Poluri (see paragraph 0004.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Claims 3 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Brunda in view of Wes in further view of Chen et al. (US2019/0304213).
Regarding claim 3, Brunda and Wes teach the computer program product of claim 2.
Yet Brunda and Wes do not explicitly further teach:
The computer program product of claim 2, wherein
the request is derived from speech of the user.
However, Chen teaches:
the request is derived from speech of the user (see paragraphs 0047-0048 for a voice conversation tool).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of: the request is derived from speech of the user, as taught by Chen. The motivation for doing so would be to facilitate communication between the mobile device and the user, as recognized by Chen (see paragraph 0047.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
This combination is particularly obvious in Brunda at least strongly teaches towards it: see col. 27, lines 24-45 for the teaching that the app “may prompt the user into input information on the mobile communication device 101, for example, in the form of answers to a series of questions.” The app can also analyze “noise or vibration of the engine” for example, using a microphone 103. See col. 23, lines 41-43 for the “app may prompt the vehicle owner with a series of questions”. It is widely known that phones and ChatGPT as taught by Brunda and Wes can recognize speech input and provide speech output. Chen just makes that explicit.
Regarding claim 9, Brunda and Wes teach the computer program product of claim 1.
Yet Brunda and Wes do not explicitly further teach:
The computer program product of claim 1, wherein
the one or more symptoms are derived from speech of the user.
However, Chen teaches:
the one or more symptoms are derived from speech of the user (in the present disclosure, see at least paragraph 0082 which states that in Fig. 10, step 1030 a user can tell the system what symptoms the vehicle is exhibiting. See paragraph 0045 for examples such as “the car won’t start,” “What’s going on with my brakes?” or “What’s that clicking sound?”
With that in mind, see Chen, paragraphs 0047-0048, for a voice conversation tool).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of: the one or more symptoms are derived from speech of the user, as taught by Chen. The motivation for doing so would be to facilitate communication between the mobile device and the user, as recognized by Chen (see paragraph 0047.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Brunda in view of Wes in further view of Chen et al. (US2014/0195101), hereinafter Chen ‘101.
Regarding claim 15, Brunda and Wes teach the computer program product of claim 11.
Yet Brunda and Wes do not further teach:
The computer program product of claim 11, wherein
the testing instructions include prompting the user to input a measurement value, and
the operations further comprise comparing the measurement value to an expected range value.
However, Chen ‘101 teaches:
the testing instructions include prompting the user to input a measurement value (see paragraph 0059 for prompting the user to enter a mileage of the vehicle), and
the operations further comprise comparing the measurement value to an expected range value (see paragraphs 0056-0057 for using the mileage information to a mileage at which failures occur or repairs are needed.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of: the testing instructions include prompting the user to input a measurement value, and the operations further comprise comparing the measurement value to an expected range value, as taught by Chen ‘101. The motivation for doing so would be to predict component failure, as recognized by Chen ‘101 (see paragraph 0057.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Inputting information is strongly taught towards by Brunda, col. 27, lines 34-39 for the app 100 asking the user “to input information on the mobile communication device 101, for example, in the form of answers to a series of questions.” Brunda also teaches a system which gathered tread depth, mileage, and tire pressure information.
Claim 18 and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Brunda in view of Wes in further view of Saini (US20200410781).
Regarding claim 18, Brunda and Wes teach the computer program product of claim [[17]] 1, .
Yet Brunda and Wes do not further teach:
The computer program product of claim [[17]] 1, wherein
the repair instructions include identification information of a replacement part.
However, Saini teaches:
the repair instructions include identification information of a replacement part (in the present filed specification, see paragraph 0051 for teaching that a system that can provide a “repair solution as well as vehicle-specific replacement parts, are described in…Innova Electronics Corporation…U.S. Pat. 6,807,469” and 17 other patents. Yet note that the present claim does not recite “vehicle-specific replacement parts” but rather “identification information of a replacement part”. This could mean identifying a part such as an airflow sensor or oil filter.
With that in mind, see Saini Fig. 10, box 1010 for using an AI system (see Fig. 1, item 220) to detect leaks, provide a “step-by-step guide to identify and troubleshoot” the leak…provide options to replace [the] part…suggest sources to buy [the part] from”. See paragraph 0065 for providing options to order a specific part from Amazon after determining that that part is broken. See also paragraph 0081.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of: the repair instructions include identification information of a replacement part, as taught by Saini. The motivation for doing so would be to make diagnosing and repair vehicle components less difficult, as recognized by Saini (see paragraphs 0002-0003).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
This combination is especially obvious because Wes at least strongly teaches toward it by telling the user that particular sensors or the catalytic converter may be faulty. The implication is that, if they are faulty, they need to be replaced. But the examiner has relied on Saini for more explicitly teaching the present claim.
Regarding claim 33, Brunda and Wes teach the computer program product of claim 1.
Yet Brunda and Wes do not further teach:
The computer program product of claim 1, wherein
the repair instructions include removal and replacement instructions for a vehicle component.
However, Saini teaches:
the repair instructions include removal and replacement instructions for a vehicle component (see Saini paragraph 0023 for a system in which a user makes a “request for content related to fixing a flat tire, including how to patch a flat tire and how to replace a flat tire with a spare time.” Paragraph 0051 teaches that this can be in the form of a video or “a how-to document.” This reasonably means how to remove and replace ad flat tire, which meets the limitations of the present claim. See Saini paragraph 0042 teaches providing “repair instructions” to a user. Paragraph 0015 teaches that the system may “quickly provide instructions for repairing or replacing damaged vehicle components”. Saini, paragraph 0065, teaches that the system will “provide an instruction video for replace the side mirror.” Does the video contain only visual material? That seems to the examiner to be an unreasonable supposition. Paragraph 00706 teaches that, once a system identifies a problem, such as with low fuel, the system can provide step-by-step instructions to add fuel to the vehicle. The paragraph characterizes these instructions as “content”. Claim 9 teaches that “the content includes at least one of audio data, video data, or text data.” See also Fig. 10, step 1016 for “user receives interactive guide for troubleshooting the scenario.” So Saini teaches an AI-system that provides step-by-step interactive how-to repair instructions in audio, video, and text forms. It seems to the examiner that this teaches the limitations of original claim 17 above a preponderance of the evidence standard.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features as indicated as taught by Saini. The motivation for doing so would be to make removing and replacing vehicle components less difficult, as recognized by Saini (see paragraphs 0002-0003).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
This combination is especially obvious because Wes at least strongly teaches toward it in at least the screenshot from 2:35 which teaches instructions to “replace clogged fuel injectors”. But the examiner has relied on Saini for more explicitly teaching the present claim.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Brunda in view of Wes in further view of Huynh (U.S. 12,112,587), filed June 2, 2023.
Regarding claim 19, Brunda and Wes teach the computer program product of claim [[17]] 1.
Yet Brunda and Wes do not further teach:
The computer program product of claim [[17]] 1, wherein
the repair instructions include a verification procedure for confirming that the repair was successful.
However, Huynh discloses:
the repair instructions include a verification procedure for confirming that the repair was successful (the provisional disclosure of the present disclosure does not teach this claim. Therefore, the priority date for this claim is Oct. 9, 2024. With that in mind, see Huynh, col. 10, lines 32-54, which teaches an AI-based diagnostic and repair system which can recommend replacement of a component. “The component is then replaced, and then a validation is conducted.” The system can provide a “repair validation” that can include “any validation procedure performed after a fix has been facilitated[d].” This validation can “confirm the passed status.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Brunda and Wes, to add the additional features of: the repair instructions include a verification procedure for confirming that the repair was successful, as taught by Huynh. The motivation for doing so would be to make sure the repair was successful, as recognized by Huynh (see col. 10, lines 48-54).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Conclusion
THIS ACTION IS MADE FINAL. 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 DANIEL M. ROBERT whose telephone number is (571)270-5841. The examiner can normally be reached M-F 7:30-4:30 EST.
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, Hunter Lonsberry can be reached at 571-272-7298. 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.
/DANIEL M. ROBERT/Primary Examiner, Art Unit 3665
Prosecution Insights