DETAILED CORRESPONDENCE
This action is in response to the filing of the Amendments on 07/20/2026. Claim 20 is cancelled.
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 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 a method comprising: receiving a query specifying a vehicle issue via a user interface; identifying a vehicle corresponding to the query; obtaining a vehicle history describing a part purchase history for the vehicle; [see p0006, p0076 - 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; 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.];
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 the user interface [ see p0007 – 0010, p0013, p0017,p0045- p0048 and Fig 2, 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 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; 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];
displaying a plurality of options of a possible cause of the vehicle issue via the user interface. the plurality of options generated using the one or more machine-learning models based on the query; [see p0013 – p0016, Figs 5A – 5C, p0051 (referring to Patent 8909416, incorporated by reference – scan tool with display for inputs and outputs); “Here are some options to detect where the problem is: Read Generic Diagnostic Trouble Code (DTC), Read Engine Control Module (ECM) Diagnostic Trouble Code (DTC);
receiving a selection of an option from the plurality of options via the user interface [see p0049 - p0056 and Response to Arguments below – in flow chart of FIG. 5B continues with the presentation to the user of options for further processing (which may be retrieved from the server(s)/database(s) 140, 150 as described above); In response to a second communication 12 from the user selecting one of the proposed scan tool functions, “I want to check the engine” (which may entail a simple selection from an enumerated menu of options or involve further natural language processing as described above), the system 100 (e.g., the app) may initiate the scan tool function];
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 p0045 – p0048 and Fig 2 - 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];
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 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].
Huyhn does not specifically teach responsive to the selection, obtaining data describing parts identified as associated with the vehicle issue using a retrieval-augmented generation model, the data describing the parts maintained as a vector database as an embedding space for parts and related symptoms.
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, Smith teaches 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 [see Fig. 1, p0013]. The VHR system 100 performs a normalization and weighting of the historical information: this includes, but is not limited to, parts, 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 can offer stronger insights into the vehicle history, its current health, and offer predictions on needed repairs and recommended maintenance for each vehicle. Using a predictive insight technology, the system 100 can generate a forecast of potential repairs on a particular vehicle given its use. The VHR system 100 takes the additional steps of utilizing a graph database 112 to build connection points between the different data records, tables, models, and vector databases 113 to empower the machine learning models 114 and web applications 116 to provide AI-based Health services 115 [see p0012 – p0020].
Smith discloses the AI Augmentation layer 204 includes vector databases 113 that store vector embeddings for fast data retrieval, enabling new AI models 114. The vector database 113 is a specialized type of database designed to store and manage high-dimensional data, such as embeddings, vectors, or data points from machine learning models. The vector databases 113 enable fast and efficient retrieval of similar data points for AI and ML applications; the model enables the machine learning (ML) algorithm to learn what type of data matters and by how much. This helps the Large Language Model (LLM) 114 to know how to respond or act when the same diagnostics code shows up for different vehicles. For example, the same diagnostics code might mean one thing for a Ford vehicle but something different for a Chevrolet. The VHR system 100 performs a normalization and weighting of the historical information [see p0016 – p0023].
Therefore, 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 Huyhn to include responsive to the selection, obtaining data describing parts identified as associated with the vehicle issue using a retrieval-augmented generation model, the data describing the parts maintained as a vector database as an embedding space for parts and related symptoms, as suggested and taught by Smith, with a reasonable expectation of success, for the purpose of providing improved accuracy, relevance, and improved history of a vehicle, thus resulting in better diagnoses proper valuation and correct part purchases.
Claim 15 is similarly rejected as Claim 1, see above.
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 the 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 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; [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];
receiving a selection of an option from the plurality of options [see p0049 - p0056 and Response to Arguments below – in flow chart of FIG. 5B continues with the presentation to the user of options for further processing (which may be retrieved from the server(s)/database(s) 140, 150 as described above); In response to a second communication 12 from the user selecting one of the proposed scan tool functions, “I want to check the engine” (which may entail a simple selection from an enumerated menu of options or involve further natural language processing as described above), the system 100 (e.g., the app) may initiate the scan tool function];
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 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 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
Amendments made have overcome the prior 101 rejection.
Applicants’ arguments filed 07/20/2026 with respect to all claims have been fully considered but they are not persuasive.
Applicant argues that Huynh does not disclose “displaying a plurality of options of a possible cause of the vehicle issue” and “receiving a selection of an option from the plurality of options.”
The Examiner respectfully disagrees. First, the Examiner notes that 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. In Huynh, the user may receive diagnostic information on a smartphone or tables (see 110 – Fig 1 and p0044).
For the recitation, “displaying a plurality of options of a possible cause of the vehicle issue” Huynh discloses in at least p0049, p0054, p0055 – p0056 and Fig 5B teaching: the diagnostic system 100 continues with a presentation to the user of options for further processing (which may be retrieved from the server(s)/database(s) 140, 150 as described above): “Here are some options to solve in case of replacing the oxygen sensor: Oxygen Sensor Explanation, Active Test: Oxygen Sensor1, Oxygen Sensor Part Number.” Also Huyn teaches, see p0013 – p0016, Figs 5A – 5C, p0051 (referring to Patent 8909416, incorporated by reference – scan tool with display for inputs and outputs); “Here are some options to detect where the problem is: Read Generic Diagnostic Trouble Code (DTC), Read Engine Control Module (ECM) Diagnostic Trouble Code (DTC);
In a relatively simple embodiment, the second communication 12 may include a selection from an enumerated menu of options (e.g., by making a selection on screen or repeating a specific word or phrase in the case of spoken communication with the app), such that there is little or no possibility of misunderstanding the user's intent.
From the user's perspective, the system 100 (e.g., the app) may reply verbally to the user, “Your Check Engine light is ON, which means a potential problem with the engine or emissions system,” followed by “Here are some options to detect where the problem is: Read Generic Diagnostic Trouble Code (DTC), Read Engine Control Module (ECM) Diagnostic Trouble Code (DTC), Scan All Systems,” at which point the system 100 may wait for further input from the user.
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.
Suggest Assistance [see p0072]:
the AI assistant may utilize inputs like DTC, Live Data, symptoms, and big data to suggest possible failure components/systems (1), providing a list of top verified fixes based on specific big data (2). This quickly informs the user of the faulty area.
For the recitation “receiving a selection of an option from the plurality of options” Huynh discloses: FIG. 5B continues with the presentation to the user of options for further processing (which may be retrieved from the server(s)/database(s) 140, 150 as described above); In response to a second communication 12 from the user selecting one of the proposed scan tool functions, “I want to check the engine” (which may entail a simple selection from an enumerated menu of options or involve further natural language processing as described above), the system 100 (e.g., the app) may initiate the scan tool function [see p0049 - p0056]; Also teaching,
…in a relatively simple embodiment, the second communication 12 may include a selection from an enumerated menu of options (e.g., by making a selection on screen or repeating a specific word or phrase in the case of spoken communication with the app), such that there is little or no possibility of misunderstanding the user's intent [p0049].
second communication 12 from the user selecting one of the proposed scan tool functions, “I want to check the engine” (which may entail a simple selection from an enumerated menu of options or involve further natural language processing as described above), the system 100 (e.g., the app) may initiate the scan tool function [see p0059].
The Applicant further argues that “responsive to the selection, obtaining data describing identified as associated with the vehicle issue and additional data describing a purchase history of parts for a vehicle identified via a user interaction” is not cured by Smith.
The Examiner respectfully disagrees. Smith discloses the VHR system and method 100 include continuous analytics methods and processes that take the normalized and weighted vehicle data from the data warehouse 206 to train machine learning (ML) models 208 and uncover new insights. The trained AI/ML models 114 are utilized to augment the vehicle data with newly generated insights. This process is used to generate various AI/ML-based derivative products and services 124, such as PredictaFix™ 202, Autolingo 204, Parts Predictor 206, and others 208; the VHR system and method 100 described herein can be used for a number of applications. For example, the VHR system 100 can offer stronger insights into the vehicle history, its current health, and offer predictions on needed repairs and recommended maintenance for each vehicle. Using a predictive insight technology, the system 100 can generate a forecast of potential repairs on a particular vehicle given its use. PredictaFix™ 202 evaluates codes alongside vehicle information, symptoms, history, recalls and other related data. Further teaching, API and embedded delivery. 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. Smith discloses the use of a vehicle health intelligence that connects live and historical information [see Smith at least at Fig 2, p0016 – p0033].
Conclusion
Applicants’ amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicants are reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RENEE MARIE LAROSE whose telephone number is (313)446-4856. The examiner can normally be reached M- F 8:30 am - 5 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abby Lin can be reached at 313-446-4821. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Renee LaRose/Examiner, Art Unit 3657 /ABBY LIN/Supervisory Patent Examiner, Art Unit 3657
