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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 24-26 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 pre-AIA the applicant regards as the invention.
Claims 24 and 26 are rejected for being indefinite about whether the claims are independent or dependent. Claim 25 is rejected due to its dependency.
Claims 24 and 26 reference another claim, namely claim 1. Yet the preamble to these claims are altered. The altered preambles appears to indicate that claims 24 and 26 are independent claims, but the refence to “of claim 1” indicates dependency. This conflicting structure makes the claims unclear regarding their dependency and therefore indefinite.
The examiner recommends cutting and pasting parts of claim 1 into claims 24 and 26 as shown below, thereby making them clearly independent.
If claims 24 and 26 are independent claims, as they partly appear, that makes claims 1, 24, 26, 27, 28, 30, and 31 independent claims. That makes 7 independent claims. But the fee worksheet dated October 18, 2024 lists only 5 independent claims. Therefore, the fees worksheet probably also needs to be recomputed.
Claim 24 recites:
A system comprising:
the computer program product of claim 1; and
a mobile device,
wherein the mobile device includes the one or more processors or programmable circuits.
For examination purposes, claim 24 will be interpreted as follows, with the examiner’s deletions in double strike-through and additions in bold underlined italics:
A system comprising:
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:
receiving a request for AI-assisted diagnostics;
receiving diagnostic data obtained from a vehicle;
prompting a user to describe one or more symptoms exhibited by the vehicle;
processing the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model; and
providing natural language guidance to the user based on a result of the processing; and
a mobile device,
wherein the mobile device includes the one or more processors or programmable circuits.
Claim 26 recites:
A system comprising:
the computer program product of claim 1; and
a scan tool,
wherein the scan tool includes the one or more processors or programmable circuits and is operable to obtain the diagnostic data from the vehicle.
For examination purposes, the claim will be interpreted as follows, with the examiner’s deletions in double strike-through and additions in bold underlined italics:
A system comprising:
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:
receiving a request for AI-assisted diagnostics;
receiving diagnostic data obtained from a vehicle;
prompting a user to describe one or more symptoms exhibited by the vehicle;
processing the one or more symptoms and the diagnostic data at least in part using a natural language processing (NLP) model; and
providing natural language guidance to the user based on a result of the processing; and
a scan tool,
wherein the scan tool includes the one or more processors or programmable circuits and is operable to obtain the diagnostic data from the vehicle.
Claims 1-8, 10, 11, 14, 16, 17, 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.
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.
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.
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 toolgle. 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, Bunda’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 17, 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 natural language guidance further includes repair instructions for the user to perform a repair on the vehicle.
However, Wes teaches:
the natural language guidance further 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”.).
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 natural language guidance further 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.
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 (as interpreted by the examiner for examination purposes, see the 35 USC 112(b) rejection), Brunda teaches:
A system comprising (see Fig. 1):
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 toolgle. 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 mobile device (see Fig. 1 for a cellphone 101. See also col. 25, lines 26-48 for the app 100 running on the phone),
wherein the mobile device includes the one or more processors or programmable circuits (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).
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 toolgle. 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 (as interpreted by the examiner for examination purposes, see the 35 USC 112(b) rejection), Brunda teaches:
A system comprising:
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 toolgle. 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 toolgle. 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.
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 method, 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 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 toolgle. 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.
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.).
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 wherein the mobile device is further operable to provide 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 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 toolgle. 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.
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.).
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 wherein the scan tool is further operable to provide 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 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 toolgle. 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.
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 product, 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 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