DETAILED CORRESPONDENCE
This action is in response to the filing of the Amendment on 03/17/2026. Claim 20 is cancelled. Claim 21 is new. The prior art reference of Sipe, III is under common ownership of the Applicant, and is not used for this rejection.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined
under the first inventor to file provisions of the AIA .
Claim Objections
Claim 3 is objected to because of the following informalities: Claim 1 was amended to include Claim 3, the recitation of “…describing a part purchase history for the vehicle…” However, Claim 3 recites wherein “the vehicle history describes a part purchase history for the vehicle…” it is unclear whether the part purchase history is the same history in both Claim 1 and 3, or if Claim 3 should recite “the vehicle history describes the part purchase for the vehicle…” Appropriate correction is required.
Claim 17 appears to have a grammatical error in that it recites “…wherein the prompt specifies a level of expertise to be used a level of detail for the result.” Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8 and 15-19, 21 are rejected under 35 U.S.C. 101:
Claim 1 recites a method and is therefore directed to a statutory category of invention.
Claim 1 recites abstract limitations including those identified in bold below:
Claim 1, A method comprising: receiving a query specifying a vehicle issue; identifying a vehicle corresponding to the query;
obtaining a vehicle history describing a part purchase history for the vehicle; generating a user question using one or more machine-learning models based on the query, the vehicle, and the vehicle history;
receiving a response to the user question via a user interface;
generating a prompt for processing by the one or more machine-learning models, the prompt based on the query, the vehicle, the vehicle history, the user question, and the response;
receiving a result of the processing of the prompt by the one or more machine-learning models as an answer to the vehicle issue;
and outputting the result for display in the user interface.
These limitations, as drafted, are a process that, under its broadest reasonable interpretation, cover performance of the limitations in the mind, or by a human using pen and paper, and therefore recite mental processes. More specifically, other than reciting
the computing elements, nothing in the claim element precludes the aforementioned steps from practically being performed in the human mind, or by a human using pen and paper. The mere recitation of a generic computer does not take the claim out of the mental process grouping. Thus, the claim recites an abstract idea.
If the claim recites a judicial exception in step 2A Prong One , the claim requires further analysis in step 2A Prong Two. In step 2A Prong Two, examiners evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
Claim 1, A method comprising: receiving a query specifying a vehicle issue; identifying a vehicle corresponding to the query;
obtaining a vehicle history describing a part purchase history for the vehicle; generating a user question using one or more machine-learning models based on the query, the vehicle, and the vehicle history;
receiving a response to the user question via a user interface;
generating a prompt for processing by the one or more machine-learning models, the prompt based on the query, the vehicle, the vehicle history, the user question, and the response;
receiving a result of the processing of the prompt by the one or more machine-learning models as an answer to the vehicle issue; and outputting the result for display in the user interface.
As recited, the functions of the computing device (comprising: a processing device; and a computer-readable storage medium storing instructions) is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component.
As recited, the receiving and presenting steps amount to extra-solution activity (sending and receiving information, displaying information).
The functions of the computing device amount to mere instructions to apply the exception using generic computer components (i.e., computing device). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
With respect to the receiving steps, the Symantec, TLI, OIP Techs. and buySAFE court decisions cited in MPEP 2106.05(d)(II) indicate that mere receiving or transmitting data over a network is a well-understood, routine, conventional function when it is claimed in a merely generic manner (as it is here).
As discussed, with respect to the presenting step, MPEP 2106.05(d)(II), and the cases cited therein, including in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying of data is a well understood, routine, and conventional function.
Thus, even when viewed as an ordered combination, nothing in the claims add significantly more (i.e. an inventive concept) to the abstract idea.
Claims 2-5 are more information about the vehicle history, which is part of the data obtained and fits under mental process due to information observed.
Claim 6-8 describe information presented, which would be information mentally determined, and the display of the information is extrasolutionary activity.
Claim 15 recites a system and is therefore directed to a statutory category of invention.
Claim 15 recites abstract limitations including those identified in bold below:
Claim 15, A computing device comprising: a processing device; and a computer-readable storage medium storing instructions that, responsive to execution by the processing device, causes the processing device to perform operations including:
receiving a query specifying a vehicle issue;
obtaining data describing a vehicle history of the vehicle, a vehicle history of a make and model of the vehicle including a part purchase history for a plurality of instances of the make and model of the vehicle via a digital service implemented via a digital platform, and a response to a user question posed about the vehicle issue;
generating a prompt including the query and the data for processing by a machine-learning model to identify a corrective action to the vehicle issue;
receiving a result of the processing of the prompt by the machine- learning model; and presenting the result for output in a user interface.
These limitations, as drafted, are a process that, under its broadest reasonable interpretation, cover performance of the limitations in the mind, or by a human using pen and paper, and therefore recite mental processes. More specifically, other than reciting the computing elements, nothing in the claim element precludes the aforementioned steps from practically being performed in the human mind, or by a human using pen and paper. The mere recitation of a generic computer does not take the claim out of the mental process grouping. Thus, the claim recites an abstract idea.
Claim 15 recites additional elements including those underlined below:
15. A computing device comprising: a processing device; and a computer-readable storage medium storing instructions that, responsive to execution by the processing device, causes the processing device to perform operations including:
receiving a query specifying a vehicle issue;
obtaining data describing a vehicle history of the vehicle, a vehicle history of a make and model of the vehicle, and a response to a user question posed about the vehicle issue;
generating a prompt including the query and the data for processing by a machine-learning model to identify a corrective action to the vehicle issue;
receiving a result of the processing of the prompt by the machine-learning model; and presenting the result for output in a user interface.
As recited, the functions of the computing device (comprising: a processing device; and a computer-readable storage medium storing instructions) is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component.
As recited, the receiving and presenting steps amount to extra-solution activity (sending and receiving information, displaying information).
The functions of the computing device amount to mere instructions to apply the exception using generic computer components (i.e., computing device). Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
As discussed above, with respect to the receiving steps, the Symantec, TLI, OIP Techs. and buySAFE court decisions cited in MPEP 2106.05(d)(II) indicate that mere receiving or transmitting data over a network is a well-understood, routine, conventional function when it is claimed in a merely generic manner (as it is here).
With respect to the presenting step, MPEP 2106.05(d)(II), and the cases cited therein, including in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying of data is a well understood, routine, and conventional function.
Thus, even when viewed as an ordered combination, nothing in the claims add significantly more (i.e. an inventive concept) to the abstract idea.
Claim 16-17 describe information presented, which would be information mentally determined, and the display of the information is extrasolutionary activity.
Claims 18-19, 20 are more information about the vehicle history, which is part of the data obtained and fits under mental process due to information observed.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 – 11, 13 – 19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Huynh (US 20250273026) in view of Smith (US 20240362956).
Claim 1, Huynh discloses: receiving a query specifying a vehicle issue; identifying a vehicle corresponding to the query [see p0006 - a vehicle owner, technician, or other user of the disclosed subject matter may engage in ordinary conversation with the vehicle or with an application (e.g., a mobile app) associated with the vehicle that acts as a gateway connection between the user and the vehicle; By processing the user's spoken (or typed) commands, questions, and concerns using a natural language processing (NLP) model, the disclosed app is able to derive appropriate scan tool feature functions to efficiently address the situation,];
generating a user question using one or more machine-learning models based on the query, the vehicle, and the vehicle history [see p0011, p0013, p0017,p0045- p0048, see Figs 7, 10 - a pretrained machine learning model such as a general purpose chatbot or virtual assistant (e.g., OpenAI's ChatGPT) may serve as the natural language processing model (NLP) model 130. The diagnostic condition may be derived based on a historical database of vehicle-specific diagnostic data and associated diagnostic conditions and/or using artificial intelligence (AI).The user's communication 12 may be uploaded or otherwise provided by the mobile device 110 as input to the NLP model 130, and the NLP model 130 may create NLP model output including a sequence of words, typically in the form of a human-readable response to the communication 12 that attempts to answer the user's question or otherwise address the user's need];
receiving a response to the user question via a user interface [p0007 – 0010, p0044 – p0049, Figs, 2 and 10 - mobile device 110 such as a smartphone or tablet having an installed application (e.g., a mobile app), the application may enable the mobile device 110 to receive the user's communication 12 via a microphone thereof (in the case of a spoken communication 12) or via a wireless communication interface thereof (in the case of a communication 12 in the form of a text message); in the operational flow of FIG. 2 may continue with extracting one or more keywords from the sequence of words included in the NLP model output (step 230). For example, in the above scenario where the user said, “The car won't start,” it was envisioned that the NLP model output might be something like, “Here is a list of possible reasons that a vehicle won't start];
generating a prompt for processing by the one or more machine-learning models, the prompt based on the query, the vehicle, the vehicle history, the user question, and the response [see – the prompt based on the query p0049 and Figs 3 – 4 - processing of the second communication 12 may in this case be straightforward (i.e., selecting the scan tool function that is unambiguously identified/confirmed by the user), though it may still involve an automatic speech recognition or speech to text algorithm, for example. Alternatively, natural language processing may be used to interpret the second communication 12, allowing the user more flexibility with his/her wording. A flow chart describing an example application of the operational flow of FIG. 2 including the sub-operational flow of FIG. 3 is shown in FIG. 4, in which the user confirms one of three proposed functions (“Function A,” “Function B,” and “Function C”) for instructing the DAT 120 (i.e., receiving a second communication which indicates a selection)].
receiving a result of the processing of the prompt by the one or more machine-learning models as an answer to the vehicle issue; and outputting the result for display in the user interface [see Fig. 10, p0044, p0067 – p0072 receive request, retrieve vehicle data (result) and suggest assistance and possible issues, suggest fixes along with step by step repair instruction…; or example, in a case where the diagnostic methodology is performed by a mobile device 110 such as a smartphone or tablet having an installed application (e.g., a mobile app), the application may enable the mobile device 110 to receive the user's communication 12 via a microphone thereof (in the case of a spoken communication 12) or via a wireless communication interface thereof (in the case of a communication 12 in the form of a text message)].
Huynh does not specifically teach obtaining a vehicle history describing a part purchase history for the vehicle.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others (covering digital – computer technology) [see p0002].
Further disclosing, the vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. The VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events. The weighting of the value of the different data records may focus on the reliability of the data which is dependent on where the data record came from (e.g., a First Notice of Loss event, Motor Vehicle Department, an Aftermarket tool provider, or an Original Equipment Manufacturer). The VHR system 100 is also capable of identifying missing elements, such as maintenance or replacement of vehicle parts and components that have not been performed, and generate a market or trade-in value for each vehicle based on a number of different vehicle data points. For example, if oil changes in a vehicle's maintenance history is always significantly late or have gaps, the value of the vehicle may be adversely impacted. Therefore, the market value of any vehicle can be scientifically and comprehensively based on the actual use, maintenance, repair, and performance history of the vehicle [see p0016 – p0018].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh, to include obtaining a vehicle history describing a part purchase history for the vehicle, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing repair shops and vehicle owners with a complete picture of the history of a vehicle, avoiding misdiagnoses, undervaluation, a longer key to key cycles, and incorrect part purchases, thus allowing a onetime scan tool which provides the same data in the same format and uses the same nomenclature [see Smith Background].
Claim 2, Huynh discloses the method as described in claim 1, wherein the vehicle history describes a service history for the vehicle [see p0006, p0076, Fig. 11 - the contemplated method may search for useful information like feedback, tips, etc., compare a current fix with verified fixes based on feedback history, find issues related to a similar family of vehicles, etc. The search may be specific to the user's vehicle, as may be derived from a VIN included in the diagnostic data, for example].
Claim 3, Huynh discloses the method as described in claim 2, but is silent to wherein the vehicle history describes a part purchase history for the vehicle obtained via a digital service implemented via a digital platform.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others (covering digital – computer technology) [see p0002].
Further disclosing, the vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. The VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events [see p0016 – p0018].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh to include wherein the vehicle history describes a part purchase history for the vehicle obtained via a digital service implemented via a digital platform, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing improved diagnostic services with a focused vehicle inspection process that is specific to both the make and model of the vehicle as well as the vehicle history specific to the selected vehicle. Inspection and arbitration data as well as part and failure rate data that is specific to vehicle make and models may be stored and analyzed. The data may be accessed to provide focused and personalized inspection based on the specific failure rates and vehicle reconditioning estimates.
Claim 18 is similarly rejected as Claim 3, see above.
Claim 4, Huynh discloses the method as described in claim 1, wherein the vehicle history is collected for a plurality of instances of a make and model of the vehicle [see p0046, p0076, More specific contexts are also contemplated, such as where the context includes identifying information of the particular vehicle 10 in question. Identifying information of the vehicle 10 may include, for example, year/make/model/engine/trim information, which may be stored in a user profile associated with the app (e.g., locally or on a server), derived from a VIN retrieved from the vehicle 10 by the DAT 120, or, in some cases, deduced by the system 100 from other diagnostic data of the vehicle 10].
Claim 5, Huynh discloses the method as described in claim 4, but is silent to wherein the vehicle history describes the part purchase history for the plurality of instances of a make and model of the vehicle via a digital service implemented via a digital platform.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others (covering digital – computer technology) [see p0002].
Further disclosing, the vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. The system 100 is seamlessly integrated or interfaced with shop management systems, OEM (Original Equipment Manufacturer) databases, and other vehicle data sources, so that vehicle data may be automatically accessed or pulled on a periodic and/or real-time basis. The VHR system 100 automatically ingests vehicle data from these various sources 102 via, for example, one or more data ingestion pipelines 104 and stores the data in one or more raw vehicle data databases (i.e., data lakes) 106. The use of a data lake allows for the storage of unstructured data without requiring pre-processing or transformation of the data into specific formats or structures. The VHR system 100 then performs data processing on the vehicle data (108), including removing personally identifiable information (PII) from the vehicle data in the database 106 for privacy concerns and normalizing the data [see p0013 – p0018, Figs 1 – 3].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh to include wherein the vehicle history describes a part purchase history for the vehicle obtained via a digital service implemented via a digital platform, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing improved diagnostic services with a focused vehicle inspection process that is specific to both the make and model of the vehicle as well as the vehicle history specific to the selected vehicle. Inspection and arbitration data as well as part and failure rate data that is specific to vehicle make and models may be stored and analyzed. The data may be accessed to provide focused and personalized inspection based on the specific failure rates and vehicle reconditioning estimates.
Claim 6, Huynh discloses the method as described in claim 1, wherein the result specifies a probable source of the vehicle issue [p0006 - By employing NLP to expand upon the user's utterances and introduce related technical terminology, the system is able to derive keywords or other inputs for determining the most relevant scan tool feature functions and, ultimately, the diagnostic condition of the vehicle including the root cause of a problem, repair solutions, and/or replacement parts].
Claim 7, Huynh discloses the method as described in claim 1, wherein the result specifies a probable fix for the vehicle issue [see p0055, Fig 10 - user may then select from these options (“DTC Details (Severity, Effect on Vehicle), Fix for DTC, Repair Tips”) as shown (“Let me know the fix”), and the system 100 may retrieve the fix from the server(s)/database(s) 140, 150 and announce or otherwise present it to the user (“The Primary Fix for P0141 is to replace the oxygen sensor”)].
Claim 8, Huynh discloses the method as described in claim 1, wherein the prompt specifies a level of expertise to be used and a level of detail for the result [see Summary p0006, Figs 8A – 8B and Fig 10, - The user can benefit from the full range of capabilities found in professional scan tools without any level of expertise or even a working knowledge of correct vehicle terminology. By employing NLP to expand upon the user's utterances and introduce related technical terminology, the system is able to derive keywords or other inputs for determining the most relevant scan tool feature functions and, ultimately, the diagnostic condition of the vehicle including the root cause of a problem, repair solutions, and/or replacement parts].
Claim 9, Huynh discloses a method comprising: receiving a query via a display of a user interface including an option to specify a vehicle issue [see p0044 – p0046, in a case where the diagnostic methodology is performed by a mobile device 110 such as a smartphone or tablet having an installed application (e.g., a mobile app), the application may enable the mobile device 110 to receive the user's communication 12 via a microphone thereof (in the case of a spoken communication 12) or via a wireless communication interface thereof (in the case of a communication 12 in the form of a text message); Figs 1 – 2 - a diagnostic methodology using the system 100 may begin with receiving a first communication 12 from the vehicle owner or other user (step 210)].
displaying a plurality of options of a possible cause of the vehicle issue, the plurality of options generated using a large language model based on the query; receiving a selection of an option from the plurality of options [see p0045 - in response to the user's communication 12 of “The car won't start,” for example, the NLP model output may be something like, “Here is a list of possible reasons that a vehicle won't start];
presenting a result of the processing of the prompt by the large language model for display in the user interface [see Figs 2 – 3, The proposed functions may be presented to the user by the system 100 (e.g., via the app), on screen or preferably by verbal communication with the user (e.g., using a speaker of the mobile device 110). In addition to the names of the proposed functions, the system 100 may provide the user with an explanation of each proposed function so that the user can make an informed choice].
Huynh discloses forming a prompt for processing by the large language model, the prompt including the query, the data, [see p0045 - after the first communication 12 is received from the user, the diagnostic methodology of FIG. 2 may proceed with processing the communication 12 using a natural language processing (NLP) model 130 to produce NLP model output (step 220). In a readily deployable embodiment of the disclosed subject matter, it is envisioned that a pretrained machine learning model such as a general purpose chatbot or virtual assistant (e.g., OpenAI's ChatGPT) may serve as the NLP model 130].
However, Huynh does not specifically teach the “additional data” which is reciting additional data, describing a purchase history of parts for a vehicle identified via a user interaction, or specifically teach responsive to the selection, obtaining data describing parts identified as associated with the vehicle issue and additional data describing a purchase history of parts for a vehicle identified via a user interaction.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others. The VHR system 100 also includes AI/machine learning (ML) modeling technology to generate additional derivative products and services, such as PredictaFix that provide predictive repair recommendations based on diagnostic trouble codes, connected car data, mechanical and collision repair estimates, registration data, and other touch point data related to the vehicle lifecycle. The vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. Also, the VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events. The weighting of the value of the different data records may focus on the reliability of the data which is dependent on where the data record came from (e.g., a First Notice of Loss event, Motor Vehicle Department, an Aftermarket tool provider, or an Original Equipment Manufacturer) [see p0002, p0012 - p0016 and Figs 1 – 3].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh to include additional data, describing a purchase history of parts for a vehicle identified via a user interaction, or specifically teach responsive to the selection, obtaining data describing parts identified as associated with the vehicle issue and additional data describing a purchase history of parts for a vehicle identified via a user interaction, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing improved diagnostic services for a vehicle owner that allows for accurate diagnosis of systems surrounding certain codes in automation which will increase efficiency, and human-like interaction to ease operations of diagnostic devices.
Claim 10, Huynh discloses the method as described in claim 9, wherein the obtaining includes obtaining additional data describing a list of the parts identified as associated with the vehicle issue for a vehicle identified via the user interface as associated with the vehicle issue and the prompt includes the additional data [see Fig 1, p0006 and p0044 -by employing NLP to expand upon the user's utterances and introduce related technical terminology, the system is able to derive keywords or other inputs for determining the most relevant scan tool feature functions and, ultimately, the diagnostic condition of the vehicle including the root cause of a problem, repair solutions, and/or replacement parts; where the diagnostic methodology is performed by a mobile device 110 such as a smartphone or tablet having an installed application (e.g., a mobile app), the application may enable the mobile device 110 to receive the user's communication 12 via a microphone thereof (in the case of a spoken communication 12) or via a wireless communication interface thereof (in the case of a communication 12 in the form of a text message)].
Claim 11, Huynh discloses the method as described in claim 9, but is silent to wherein the obtaining includes obtaining additional data describing the purchase history of parts for the vehicle identified via the user interface as associated with the vehicle issue via a digital service implemented via a digital platform and the prompt includes the additional data.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others. The VHR system 100 also includes AI/machine learning (ML) modeling technology to generate additional derivative products and services, such as PredictaFix that provide predictive repair recommendations based on diagnostic trouble codes, connected car data, mechanical and collision repair estimates, registration data, and other touch point data related to the vehicle lifecycle. The vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. Also, the VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events. The weighting of the value of the different data records may focus on the reliability of the data which is dependent on where the data record came from (e.g., a First Notice of Loss event, Motor Vehicle Department, an Aftermarket tool provider, or an Original Equipment Manufacturer); including other vehicle data sources (102 – the interfaces [see p0002, p0012 - p0016 and Figs 1 – 3].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh to include wherein the obtaining includes obtaining additional data describing the purchase history of parts for the vehicle identified via the user interface as associated with the vehicle issue via a digital service implemented via a digital platform and the prompt includes the additional data, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing improved diagnostic services for a vehicle owner that allows for accurate diagnosis of systems surrounding certain codes in automation which will increase efficiency, and human-like interaction to ease operations of diagnostic devices.
Claim 13, Huynh discloses the method as described in claim 9, wherein the obtaining includes obtaining additional data describing diagnostic data from a vehicle identified via the user interface as associated with the vehicle issue and the prompt includes the additional data [see p0044 – p0046, Figs 1 – 2 - a pretrained machine learning model such as a general purpose chatbot or virtual assistant (e.g., OpenAI's ChatGPT) may serve as the NLP model 130. The user's communication 12 may be uploaded or otherwise provided by the mobile device 110 as input to the NLP model 130, and the NLP model 130 may create NLP model output including a sequence of words, typically in the form of a human-readable response to the communication 12 that attempts to answer the user's question or otherwise address the user's needs].
Claim 14, Huynh discloses the method as described in claim 9, but not specifically wherein the obtaining includes obtaining additional data describing one or more repairs made to a vehicle identified via the user interface as associated with the vehicle issue and the prompt includes the additional data.
However, Smith discloses the VHR system 100 also includes AI/machine learning (ML) modeling technology to generate additional derivative products and services, such as PredictaFix that provide predictive repair recommendations based on diagnostic trouble codes, connected car data, mechanical and collision repair estimates, registration data, and other touch point data related to the vehicle lifecycle. The vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. Also, the VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events.
Also Smith teaching, the VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events. The weighting of the value of the different data records may focus on the reliability of the data which is dependent on where the data record came from (e.g., a First Notice of Loss event, Motor Vehicle Department, an Aftermarket tool provider, or an Original Equipment Manufacturer); including other vehicle data sources (102 – the interfaces [see p0002, p0012 - p0016 and Figs 1 – 3].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh, to include wherein the obtaining includes obtaining additional data describing one or more repairs made to a vehicle identified via the user interface as associated with the vehicle issue and the prompt includes the additional data, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing repair shops and vehicle owners with a complete picture of the history of a vehicle, avoiding misdiagnoses, undervaluation, a longer key to key cycles, and incorrect part purchases, thus allowing a onetime scan tool which provides the same data in the same format and uses the same nomenclature [see Smith Background].
Claim 15, Huynh discloses a computing device comprising: a processing device; and a computer-readable storage medium storing instructions that, responsive to execution by the processing device, causes the processing device to perform operations including: receiving a query specifying a vehicle issue; obtaining data describing a vehicle history of the vehicle [see p0006, p0057 - a vehicle owner, technician, or other user of the disclosed subject matter may engage in ordinary conversation with the vehicle or with an application (e.g., a mobile app) associated with the vehicle that acts as a gateway connection between the user and the vehicle; By processing the user's spoken (or typed) commands, questions, and concerns using a natural language processing (NLP) model, the disclosed app is able to derive appropriate scan tool feature functions to efficiently address the situation; It is contemplated that the operations performed by the system 100 (e.g., by the app and/or server(s) 140) may include deriving a reliability index associated with the presumed diagnostic condition of the vehicle. The reliability index may be a score (e.g., a numerical score) that quantifies a confidence in the diagnostic condition (or any other result) that is determined by the system 100 and may be based on, for example, historical data indicative of how often the same diagnostic condition (or other result) was found to be accurate in the same or similar vehicles under the same or similar circumstances in the past];
and a response to a user question posed about the vehicle issue [see p0060, Fig. 7 - Tracking of the function process may be done automatically by virtue of the connection between the DAT 120 and the vehicle 10. As conditions remain unmet for completing the function, the app may inform the user of unmet conditions, finally confirming that the function has been done properly. The app may then respond with the result and any further options as described above. In this way, the user may be in communication with the system 100 at all times, to a degree suitable for each particular user, while setting up and performing complex scan tool functions];
generating a prompt including the query and the data for processing by a machine-learning model to identify a corrective action to the vehicle issue [see Fig. 10, p0067 – p0072 receive request, retrieve vehicle data and suggest assistance and possible issues, suggest fixes along with step by step repair instructions…];
receiving a result of the processing of the prompt by the machine- learning model; and presenting the result for output in a user interface [see Fig. 10, p0044, p0067 – p0072 in a case where the diagnostic methodology is performed by a mobile device 110 such as a smartphone or tablet having an installed application (e.g., a mobile app), the application may enable the mobile device 110 to receive the user's communication 12 via a microphone thereof (in the case of a spoken communication 12) or via a wireless communication interface thereof (in the case of a communication 12 in the form of a text message); receive request, retrieve vehicle data (result) and suggest assistance and possible issues, suggest fixes along with step by step repair instructions…];
Huynh does not specifically teach a vehicle history of a make and model of the vehicle including a part purchase history for a plurality of instances of the make and model of the vehicle via a digital service implemented via a digital platform.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others (covering digital – computer technology) [see p0002].
Further disclosing, the vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. The VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events. The weighting of the value of the different data records may focus on the reliability of the data which is dependent on where the data record came from (e.g., a First Notice of Loss event, Motor Vehicle Department, an Aftermarket tool provider, or an Original Equipment Manufacturer). The VHR system 100 is also capable of identifying missing elements, such as maintenance or replacement of vehicle parts and components that have not been performed, and generate a market or trade-in value for each vehicle based on a number of different vehicle data points. For example, if oil changes in a vehicle's maintenance history is always significantly late or have gaps, the value of the vehicle may be adversely impacted. Therefore, the market value of any vehicle can be scientifically and comprehensively based on the actual use, maintenance, repair, and performance history of the vehicle [see p0016 – p0018].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh, to include a vehicle history of a make and model of the vehicle including a part purchase history for a plurality of instances of the make and model of the vehicle via a digital service implemented via a digital platform, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing repair shops and vehicle owners with a complete picture of the history of a vehicle, avoiding misdiagnoses, undervaluation, a longer key to key cycles, and incorrect part purchases, thus allowing a onetime scan tool which provides the same data in the same format and uses the same nomenclature [see Smith Background].
Claim 16, Huynh discloses the computing device as described in claim 15, wherein the result specifies a probable fix for the vehicle issue [p0055 - user may then select from these options (“DTC Details (Severity, Effect on Vehicle), Fix for DTC, Repair Tips”) as shown (“Let me know the fix”), and the system 100 may retrieve the fix from the server(s)/database(s) 140, 150 and announce or otherwise present it to the user (“The Primary Fix for P0141 is to replace the oxygen sensor”)].
Claim 17, Huynh discloses the computing device as described in claim 15, wherein the prompt specifies a level of expertise to be used a level of detail for the result [see Summary p0006 - The user can benefit from the full range of capabilities found in professional scan tools without any level of expertise or even a working knowledge of correct vehicle terminology. By employing NLP to expand upon the user's utterances and introduce related technical terminology, the system is able to derive keywords or other inputs for determining the most relevant scan tool feature functions and, ultimately, the diagnostic condition of the vehicle including the root cause of a problem, repair solutions, and/or replacement parts].
Claim 19, Huynh discloses the computing device as described in claim 15, wherein the vehicle history of a make and model of a vehicle is collected for a plurality of instances of the vehicle [see p0046, p0076, More specific contexts are also contemplated, such as where the context includes identifying information of the particular vehicle 10 in question. Identifying information of the vehicle 10 may include, for example, year/make/model/engine/trim information, which may be stored in a user profile associated with the app (e.g., locally or on a server), derived from a VIN retrieved from the vehicle 10 by the DAT 120, or, in some cases, deduced by the system 100 from other diagnostic data of the vehicle 10].
Claim 21, Hyunh discloses the computing device as described in claim 15, but is silent to wherein the vehicle history describes the part purchase history for the vehicle as accessible via an application programming interface.
However, Smith discloses an AI and blockchain-based vehicle health record (VHR) system, and more particularly to a decentralized, secure, and transparent platform for storing, managing, and accessing vehicle repair information, build information, OEM and aftermarket diagnostic scans, recall information, diagnostics information, connected car information, DMV history, accident information, insurance claim information, and others (covering digital – computer technology) [see p0002].
Further disclosing, the vehicle data and derivative products/services are associated with a specific YMME (year/make/model/engine) combination, normalized AutoLingo (nomenclature) of specific vehicle modules, parts, structures and other data points. It also includes vehicle history specifically associated with the VIN (Vehicle Identification Number) and associated to YMME. The VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, part names, module names, repairs, registration locations, purchase events, and accident events. The weighting of the value of the different data records may focus on the reliability of the data which is dependent on where the data record came from (e.g., a First Notice of Loss event, Motor Vehicle Department, an Aftermarket tool provider, or an Original Equipment Manufacturer).
Also disclosing, under the control of the app, the mobile device 110 may then, as described in more detail below, initiate one or more functions of a data acquisition and transfer device (DAT) 120 that may be connected to an on-board diagnostics (OBD) port of the vehicle 10, e.g., a data link connector (DLC) port. The DAT 120 may be 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, to collect diagnostic data from an onboard computer (e.g., an electronic control unit or ECU) of the vehicle 10 for diagnostic analysis. The mobile device 110 may communicate with the DAT 120 using a shortrange wireless communication protocol (e.g., Bluetooth) or a wired connection, for example (teaching programming interface DAT 120 connected to vehicle and performs the functions to check vehicle status [see Fig 1, p0044, p0016 – p0018].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh to include wherein the vehicle history describes the part purchase history for the vehicle as accessible via an application programming interface, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing improved diagnostic services for a vehicle owner that allows for accurate diagnosis of systems surrounding certain codes in automation which will increase efficiency, and human-like interaction to ease operations of diagnostic devices.
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Huynh (US 20250273026) in view of Smith (US 20240362956) and Gronsbell (US 20200234515).
Claim 12, Huynh discloses the method as described in claim 9, but is silent to wherein the obtaining includes obtaining additional data describing one or more service bulletins associated with a vehicle identified via the user interface as associated with the vehicle issue and the prompt includes the additional data.
However, Gronsbell discloses a method of providing vehicle diagnostics and maintenance is provided. The method includes receiving vehicle data from an on-board vehicle computing system on a first vehicle. The method also includes generating a vehicle diagnostic data object based on the vehicle data. The vehicle diagnostic data object includes one or more maintenance actions associated with the first vehicle [see p0036].
Further disclosing, the system may be configured to render a maintenance interface to the user configured to provide vehicle-specific diagnostic and maintenance information [see p0279, and Fig 32]. The apparatus 200 includes means, such as the processor 240, the communication interface 280, or the like, for determining whether a diagnostic triggering event has occurred. Some examples of diagnostic triggering events include reading events off the vehicle, such as tire pressure indicator is low (e.g., a notification or promotion may be sent to a consumer apparatus), DTC codes, etc. Additionally, there could be time based maintenance, such as a trigger when the vehicle hasn't been serviced in 6 months, or it is at a 36 month service date. In an instance in which the diagnostic trigger event has occurred, the apparatus may proceed to Block 3200, while if the diagnostic trigger event the apparatus may await a user input (e.g., entering a standby state until a user input is received at Block 3260 or a diagnostic trigger event is detected at Block 3200). The diagnostic triggering event may provide information that a service bulletin would supply, such as the oil needs to be changed, therefore service is needed. the malfunction indicator may comprise an indication that scheduled maintenance may be needed (e.g., the vehicle, user device, and/or network may report regular service intervals via the malfunction indicator). For example, the apparatus may, based on the vitals of the vehicle, such as miles, and the policy information, be required to get check-ups during certain intervals as to not jeopardize the vehicle's health or as a condition for a policy, such as a warranty [see p0212].
It would have been obvious before the effective date of the claimed invention to one of ordinary skill in the art to modify the device in Huynh to include wherein the obtaining includes obtaining additional data describing one or more service bulletins associated with a vehicle identified via the user interface as associated with the vehicle issue and the prompt includes the additional data, as suggested and taught by Gronsbell with a reasonable expectation of success, for the purpose of providing improved diagnostic services for a vehicle owner to have fast and efficient information concerning the monitoring and tracking as well as associated onboarding, diagnostic, and repair activities of the vehicle. This allows for the owner to be more prepared for vehicle items such as an insurance policy, a manufacturer warranty, an extended vehicle protection plan, a GAP insurance plan, a tire and wheel coverage plan, or a prepaid maintenance plan.
Response to Arguments
Applicant’s arguments with respect to claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Also, it is understood that the prior art reference of Sipe, III is under common ownership of the Applicant, and is not used for this rejection.
This Action is NON-FINAL.
Conclusion
The examiner has pointed out particular references contained in the prior art of record in the body of this action for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. Applicant should consider the entire prior art as applicable as to the limitations of the claims. It is respectfully requested from the applicant, in preparing the response, to consider fully the entire references as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RENEE LAROSE whose telephone number is (313)446-4856. The examiner can normally be reached on Monday - Friday 8:30am - 5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abby Lin can be reached on (571) 270-3976. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Renee LaRose/Examiner, Art Unit 3657
/ABBY LIN/Supervisory Patent Examiner, Art Unit 3657
Prosecution Insights