DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is the First Office Action on the merits.
Claims 1-28 are currently pending and addressed below.
Information Disclosure Statement
The information disclosure statement (IDS) filed on 09/13/2023 has been considered. An initialed copy of the IDS is enclosed herewith.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3 and 7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claim 3, the claim recites the limitation "the group consisting of" in line 2. There is insufficient antecedent basis for this limitation in the claim.
As to claim 7, the claim recites the limitation "the group consisting of" in line 3. There is insufficient antecedent basis for this limitation in the claim.
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-28 are rejected under 35 U.S.C. 101
Regarding claim 1:
Step 1: Statutory Category - Yes
The claim is directed toward a method which falls within one of the four statutory categories. MPEP 2106.3.
Step 2A Prong 1: Judicial Exception – Yes
Independent claim 1 includes limitations that recite an abstract idea. The claim recites “deriving, from the at least one fault indication and the identification information, one or more simulated output parameters for simulating an output of the component” and “deriving vehicle condition information from the at least one fault indication and the live data”, which given their broadest reasonable interpretation, the claim covers performance of the limitations in the human mind. For example, a human mind could reasonably diagnose a problem associating with the vehicle or a vehicle component based on a fault indication (e.g. oil leaks) and given data. As such, the claim recites at least one abstract idea.
Step 2A Prong 2: Practical Application – No
Claim 1 is evaluated whether as a whole it integrates the recited judicial exception into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial except ion to a particular technological environment or field of use do not integrate a judicial exception into a “practical application”.
The claim does not include additional elements that are sufficient enough to amount to integrating the judicial exception into a practical application, for example, the claimed elements “receiving diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle”, and “receiving live data collected from the OBD port of the vehicle based on a simulated output of the component generated according to the one or more simulated output parameters” are recited at a high-level of generality and are directed to insignificant extra-solution activity of data gathering.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B:
Claim 1 is evaluated as to whether the claim as a whole amounts to significantly more
than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim.
The claim does not include additional elements that are sufficient enough to provide an
inventive concept in Step 2B, for example, the claimed elements “receiving diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle”, and “receiving live data collected from the OBD port of the vehicle based on a simulated output of the component generated according to the one or more simulated output parameters” are well-understood, routine and conventional activity in the art. See MPEP 2106.05(d), II, “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information);”.
Accordingly, the claim is not patent eligible.
Regarding claim 9:
Step 1: Statutory Category - Yes
The claim is directed toward a method which falls within one of the four statutory categories. MPEP 2106.3.
Step 2A Prong 1: Judicial Exception – Yes
Independent claim 9 includes limitations that recites an abstract idea. The claim recites “the diagnostic tool being further operable to derive, from the at least one fault indication and the identification information, one or more simulated output parameters for simulating an output of the component”, which given their broadest reasonable interpretation, the claim covers performance of the limitations in the human mind. For example, a human mind could reasonably determine an appropriate parameter (e.g. range of voltage or a voltage value) corresponding to a vehicle component for testing purposes. As such, the claim recites at least one abstract idea.
Step 2A Prong 2: Practical Application – No
Claim 9 is evaluated whether as a whole it integrates the recited judicial exception into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial except ion to a particular technological environment or field of use do not integrate a judicial exception into a “practical application”.
The claim does not include additional elements that are sufficient enough to amount to integrating the judicial exception into a practical application, for example, the claimed elements “a diagnostic tool operable to receive diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle” is recited at a high-level of generality and are directed to insignificant extra solution activity of data gathering. The claimed invention further reads “a simulator operable to generate a simulated output of the component according to the one or more simulated output parameters”, appears to be “apply it" limitation. Additionally, claim 9 recites the additional elements of “a diagnostic tool”, and “a simulator” are merely describe how to generally “apply” the otherwise mental judgements in a generic or general purpose computing environment. The claim is recited at a high-level of generality and merely automate the deriving steps.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B:
Claim 9 is evaluated as to whether the claim as a whole amounts to significantly more
than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim.
The claim does not include additional elements that are sufficient enough to provide an
inventive concept in Step 2B, for example, the claimed elements “a diagnostic tool operable to receive diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle” are well-understood, routine and conventional activity in the art. See MPEP 2106.05(d), II, “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information);”.
As to the limitation “a simulator operable to generate a simulated output of the component according to the one or more simulated output parameters”, appears to be “apply it" limitation, since the limitation invokes computers or other machinery merely as a tool to performing an existing process – simply adding a general purpose computer or computer components after the fact to an abstract idea. Section 2106.05(f) [R-10.2019] of the MPEP states the following: “(2) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity… or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more". These limitations amount to computer implementation of mental processes including an evaluation, judgment, opinion Therefore, the claim does not amount to significantly more than the abstract idea itself.
As discussed with respect to Step 2A Prong 2, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer/components. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Accordingly, the claim is not patent eligible.
Regarding claim 17:
Step 1: Statutory Category - Yes
The claim is directed toward a method which falls within one of the four statutory categories. MPEP 2106.3.
Step 2A Prong 1: Judicial Exception – Yes
Independent claim 17 includes limitation that recites an abstract idea. The claim recites “the one or more servers being further operable to derive, from the at least one fault indication and the identification information, one or more simulated output parameters for simulating an output of the component”, which given their broadest reasonable interpretation, the claim covers performance of the limitations in the human mind. For example, a human mind could reasonably determine an appropriate parameter (e.g. range of voltage or a voltage value) corresponding to a vehicle component for testing purposes. As such, the claim recites at least one abstract idea.
Step 2A Prong 2: Practical Application – No
Claim 17 is evaluated whether as a whole it integrates the recited judicial exception into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial except ion to a particular technological environment or field of use do not integrate a judicial exception into a “practical application”.
The claim does not include additional elements that are sufficient enough to amount to integrating the judicial exception into a practical application, for example, the claimed elements “one or more servers operable to receive diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle” are recited at a high-level of generality and directed to insignificant pre-solution and post-solution activity, which is a form of insignificant extra-solution activity. The claimed invention further reads “a simulator operable to generate a simulated output of the component according to the one or more simulated output parameters”, appears to be “apply it" limitation. Additionally, claim 17 recites the additional elements of “one or more servers”, and “a simulator” are merely describe how to generally “apply” the otherwise mental judgements in a generic or general purpose computing environment. The claim is recited at a high-level of generality and merely automate the deriving steps.
Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B:
Claim 17 is evaluated as to whether the claim as a whole amounts to significantly more
than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim.
The claim does not include additional elements that are sufficient enough to provide an
inventive concept in Step 2B, for example, the claimed elements “one or more servers operable to receive diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle”, are well-understood, routine and conventional activity in the art. See MPEP 2106.05(d), II, “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information);”.
As to the limitation “a simulator operable to generate a simulated output of the component according to the one or more simulated output parameters”, appears to be “apply it" limitation, since the limitation invokes computers or other machinery merely as a tool to performing an existing process – simply adding a general purpose computer or computer components after the fact to an abstract idea. Section 2106.05(f) [R-10.2019] of the MPEP states the following: “(2) Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity… or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more". These limitations amount to computer implementation of mental processes including an evaluation, judgment, opinion Therefore, the claim does not amount to significantly more than the abstract idea itself.
As discussed with respect to Step 2A Prong 2, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer/components. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Accordingly, the claim is not patent eligible.
Claims 2-4, 6-8, 10-16, 18-20 and 22-28 are also rejected under 35 U.S.C. 101 by virtue of their dependency to the independent claims.
Claims 2-4, 6-8, 10-16, 18-20 and 22-28 do not recite additional elements that integrate the judicial exception into a practical application, because the additional elements are directed toward additional aspects of judicial exception and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. For example, claim 10 recites the limitation “wherein the at least one fault indication comprises at least one diagnostic trouble code (DTC)” is recited at a high-level of generality and is directed to insignificant extra-solution activity of data gathering.
The dependent claims are rejected under 35 U.S.C. 101 under similar rationale as their independent claims.
Regarding claims 5 and 21, claim 5 recites a non-transitory program storage media and claim 21 recites a system which falls within at least one of the four statutory categories. Claims 5 and 21 recites similar limitations as indicated above with respect to claims 1, 9, and 17. Hence, the claim is not eligible for the same reasons as discussed above with respect to claims 1, 9, and 17. All other limitations not discussed are the same as those discussed above with to claims 1, 9, and 17. Discussion is omitted for brevity.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-7, and 9-28 are rejected under 35 U.S.C. 103 as being unpatentable over Hardesty (US 20160171795 A1) in view of Keane et al. (US 20160328890 A1).
Regarding claim 1, and similarly with respect to claims 5, 9, and 21 Hardesty discloses
A method of providing vehicle diagnostics, the method comprising: receiving diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including component of the vehicle; ([0052] “a separate diagnostic scanner or analyzer (e.g., a Snap-On scanner) not shown) or the OBD2 Cable 252 of the ADS 200/250 may be plugged into an OBD2 port of the vehicle computer 102 in order to monitor the response of the vehicle computer 102 during the sensor simulation of the staircase sweep output 512E. Then, if the vehicle computer 102 fails to provide an appropriate response to each step of the staircase waveform output from the ADS 200/250, the user may be led to conclude that the vehicle computer 102, or that particular sensor input provided by the vehicle sensor wiring harness 110, or the vehicle sensor wiring harness 110 has failed.”)
deriving, from the at least one fault indication and the identification information, one or more simulated output parameters for simulating an output of the component; receiving live data collected from the OBD port of the vehicle based on a simulated output of the component generated according to the one or more simulated output parameters; and ([0044] “the external computer 102 adapted to provide user inputs to the external computer 301, and a memory 230 coupled to the external computer 301, the memory 230 adapted to store user input data associated with a range of vehicle manufacturers makes, models, years, sensor function types, and one or more of a voltage, current, and resistance operational range values of the selected sensor (e.g., 131) to be simulated.”, [0049] “sensor output vs. time diagrams, comprising operational ranges of voltages resistances or milliamperes, for example, wherein the range values of known good sensors will remain between exemplary High and Low limits, such as may be simulated by the sensor simulator of the automotive diagnostic systems”, and [0051] “sensor output plot 512A, illustrates an exemplary simulated output of a known good sensor which provides an output level transition, from an initial high output level at time “0” 506 through time “4”, transitioning between times “4-7”, down to a final sensor output level at time “7” 508 through time “9”. The sensor simulator 302 of ADS 200/250, for example, may be used to simulate this and all the following sensor outputs discussed herein. Sensor output plots 5128 and 512C may illustrate sensor outputs of a failed sensor that is unable to remain between exemplary High limit HL 504 and Low limit LL 502. Sensor output plot 512D illustrates another possible sensor output which remains steady at a low level, and remains between exemplary high and low limits, HL 504 and LL 502 respectively.”)
deriving vehicle condition information from the at least one fault indication and the live data. (960-982, Figure 9A, [0010] The present invention is directed to an automotive diagnostic system (ADS) for testing the integrity of a sensor or other such detector used in the automotive electrical system of a vehicle, in which the automotive diagnostic system simulates the typical operations of a functional sensor, but without any connection to the suspect sensor (independent of the suspect sensor. The automotive diagnostic system or ADS comprises a sensor simulator that is electrically connected into the automotive electrical system to simulate a functional sensor and therefore directly replaces the suspect sensor (or any user selected sensor). During normal vehicle operations, the vehicle computer or Electronic Control Module (ECM) is typically coupled to a vehicle sensor wiring harness which is coupled to the sensor. During a diagnostic mode of the automotive diagnostic system, the vehicle computer or (ECM) is coupled to the vehicle sensor wiring harness which is coupled to the sensor simulator. Connected at this point in the automotive electrical system, the automotive diagnostic system is therefore configured to diagnose and determine whether problems exist with the sensor, the vehicle computer, or the vehicle sensor wiring harness, or in a combination thereof., and [0052] “a separate diagnostic scanner or analyzer (e.g., a Snap-On scanner) not shown) or the OBD2 Cable 252 of the ADS 200/250 may be plugged into an OBD2 port of the vehicle computer 102 in order to monitor the response of the vehicle computer 102 during the sensor simulation of the staircase sweep output 512E. Then, if the vehicle computer 102 fails to provide an appropriate response to each step of the staircase waveform output from the ADS 200/250, the user may be led to conclude that the vehicle computer 102, or that particular sensor input provided by the vehicle sensor wiring harness 110, or the vehicle sensor wiring harness 110 has failed.”)
However, Hardesty fails to explicitly disclose receiving diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle
Keane et al. teaches receiving diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle; ([0025] “the diagnostic tools are connected to the ECUs in vehicles to retrieve vehicle information, trouble codes, sensor data from in-vehicle sensors, and to test the operation of one or more systems in the vehicle by generating commands for the ECU. When a diagnostic tool is connected to the ECU in a vehicle, the diagnostic tool retrieves the VIN or other identification information for the vehicle that enables automatic identification of the make and model of the vehicle under test. The diagnostic tool also records a data stream from sensors in the vehicle and any trouble codes from the ECU in the vehicle. Some diagnostic tool embodiments retrieve the diagnostic data in the OBD-II or other industry standard format that enables the diagnostic tool to be operatively connected to a wide range of vehicles.”, and [0037] “the diagnostic tool records error codes, such as the diagnostic trouble codes, operating condition information, and other diagnostic data from the ECU in the vehicle (block 212).”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty to incorporate collecting vehicle identification information as taught by Keane et al. for the purpose of enabling “automatic identification of the make and model of the vehicle under test” (Keane, [0025]).
With the additional limitation of claim 21, Hardesty discloses a data acquisition and transfer device configured to be plugged into an on-board diagnostics (OBD) port of a vehicle; ([0062] “the automotive diagnostic system 200/250, the vehicle sensor wiring harness 110 comprises a computer-side connector 112 for connection to the vehicle computer 102”, and [0072] “the automotive diagnostic system 200/250 is configured and operable to digitally and wirelessly communicate with one or more or a combination of wireless accessory modules, an RF transceiver, a router, a diagnostic scanner, a remote display, an alarm, an OBD2 compatible connector (e.g., at the vehicle computer 102), an OBD2 compatible cable 252, and a sensor 131”)
With the additional limitation of claim 9, Hardesty discloses a simulator operable to generate a simulated output of the component according to the one or more simulated output parameters. ([0029] “The ADS further comprises a memory coupled to the external computer, adapted to store user input data associated with a range of vehicle manufacturer's makes, models, years, sensor function types, and one or more of a voltage, current and resistance operational range values of the selected sensor to be simulated…automotive diagnostic system may also include a user interface having a display for viewing various vehicle status conditions and sensor preset values, and may include pushbuttons for selecting various modes or for entering the sensor preset values.”, [0030] “the automotive diagnostic system, the external computer, keypad and memory are adapted to receive and store user input data associated with a selected manufacturers' make, model, year vehicle, and the function type of the selected sensor to be simulated by the sensor simulator. The keypad also enables the user to enter, select or adjust a typical operational value or range of values, or one or more High/Low limits of the selected sensor. The automotive diagnostic system is also adapted to determine whether a problem exists in one or more of the sensor or sensor system, the vehicle computer, and the vehicle sensor wiring harness, and to diagnose a likely problem therein”, and [0051] “sensor output plot 512A, illustrates an exemplary simulated output of a known good sensor which provides an output level transition, from an initial high output level at time “0” 506 through time “4”, transitioning between times “4-7”, down to a final sensor output level at time “7” 508 through time “9”. The sensor simulator 302 of ADS 200/250, for example, may be used to simulate this and all the following sensor outputs discussed herein. Sensor output plots 5128 and 512C may illustrate sensor outputs of a failed sensor that is unable to remain between exemplary High limit HL 504 and Low limit LL 502.”)
Regarding claim 2, and similarly with respect to claims 6, 10, 18, and 22 Hardesty in view of
Keane et al. discloses The method of claim 1,
Keane et al. teaches wherein the at least one fault indication comprises at least one diagnostic trouble code (DTC). ([0037] “the diagnostic tool records error codes, such as the diagnostic trouble codes, operating condition information, and other diagnostic data from the ECU in the vehicle (block 212)… during a service visit the diagnostic tool 116C retrieves diagnostic data at multiple times and sends multiple test commands to the ECU 166 in the vehicle. The mechanic 160 performs one or more service procedures in response to receiving DTCs and other diagnostic data from the diagnostic tool 116C.”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty to incorporate the teachings of Keane et al. for the same reasons stated in the motivation of claim 1.
Regarding claim 3, and similarly with respect to claim 7, Hardesty in view of Keane et al.
discloses The method of claim 1,
Hardesty discloses wherein the one or more simulated output parameters includes at least one parameter for generating a simulated output selected from the group consisting of a simulated resistance, a simulated voltage, a simulated sine wave, a simulated square wave, a simulated temperature coefficient sensor output, a simulated throttle and pedal sensor output, a simulated oxygen sensor output, a simulated exhaust gas pressure sensor output, a simulated camshaft position (CMP) sensor output, a simulated crankshaft position (CKP) sensor output, a simulated common rail pressure sensor output, a simulated knock sensor output, a simulated manifold absolute pressure (MAP) sensor output, a simulated anti-lock braking system (ABS) sensor output, a simulated mass airflow (MAF) sensor output, a simulated heating, ventilation, and air conditioning (HVAC) pressure sensor output, a simulated signal for controlling an injector pulse of the vehicle, a simulated signal for controlling an ignitor pulse of the vehicle, and a simulated signal for controlling a solenoid pulse of the vehicle. ([0014] “the simulated operation of the selected sensor comprises one or more of the voltage, current or resistance operational range values as presented to the vehicle computer.” and [0026] “sensor output vs time diagrams, comprising operational ranges of voltages, resistances or milliamperes, for example, wherein the range values of known good sensors will remain between exemplary High and Low limits, such as may be simulated by the sensor simulator of the automotive diagnostic systems”)
Regarding claim 11, and similarly with respect to claims 14, 23, and 26 Hardesty in view of
Keane et al. discloses The system of claim 10,
Hardesty discloses wherein the diagnostic tool is further operable to receive live data collected from the OBD port of the vehicle based on the simulated output ([0052] “a separate diagnostic scanner or analyzer (e.g., a Snap-On scanner) not shown) or the OBD2 Cable 252 of the ADS 200/250 may be plugged into an OBD2 port of the vehicle computer 102 in order to monitor the response of the vehicle computer 102 during the sensor simulation of the staircase sweep output 512E. Then, if the vehicle computer 102 fails to provide an appropriate response to each step of the staircase waveform output from the ADS 200/250, the user may be led to conclude that the vehicle computer 102, or that particular sensor input provided by the vehicle sensor wiring harness 110, or the vehicle sensor wiring harness 110 has failed.”)
Keane et al. teaches and derive vehicle condition information from the at least on DTC and live data. ([0037] “the diagnostic tool records error codes, such as the diagnostic trouble codes, operating condition information, and other diagnostic data from the ECU in the vehicle (block 212)… during a service visit the diagnostic tool 116C retrieves diagnostic data at multiple times and sends multiple test commands to the ECU 166 in the vehicle. The mechanic 160 performs one or more service procedures in response to receiving DTCs and other diagnostic data from the diagnostic tool 116C.”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty in combination with Keane et al. to incorporate diagnostic trouble code as taught by Keane et al. for the purpose of identifying a specific problem corresponding to a vehicle component.
Regarding claim 12, and similarly with respect to claims 15, 24, and 27, Hardesty in view of
Keane et al. discloses The system of claim 11,
Keane et al. teaches wherein the deriving of the vehicle condition information by the diagnostic tool includes uploading the at least one DTC and the live data to one or more servers and receiving the vehicle condition information from the one or more servers. (Abstract “receiving with the diagnostic tool a component identifier corresponding to a component in the vehicle that is replaced in a service procedure in response to the diagnostic data from the diagnostic tool, transmitting with the diagnostic tool the diagnostic data and the component identifier to a server”, [0025] “the diagnostic tools are connected to the ECUs in vehicles to retrieve vehicle information, trouble codes, sensor data from in-vehicle sensors, and to test the operation of one or more systems in the vehicle by generating commands for the ECU. When a diagnostic tool is connected to the ECU in a vehicle, the diagnostic tool retrieves the VIN or other identification information for the vehicle that enables automatic identification of the make and model of the vehicle under test. The diagnostic tool also records a data stream from sensors in the vehicle and any trouble codes from the ECU in the vehicle. Some diagnostic tool embodiments retrieve the diagnostic data in the OBD-II or other industry standard format that enables the diagnostic tool to be operatively connected to a wide range of vehicles.”, and [0033] “The diagnostic query listeners 156 receive search queries and diagnostic data, such as DTCs and the VIN information, from the diagnostic tool 116”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty in combination with Keane et al. to incorporate uploading diagnostic trouble code to a server as taught by Keane et al. for the purpose of identifying a specific problem corresponding to a vehicle component.
Regarding claim 13, and similarly with respect to claims 16, 25, and 28, Hardesty in view of Keane et al. discloses The system of claim 9,
Hardesty teaches wherein the deriving of the one or more simulated output parameters includes parameters from the one or more servers. ([0060] “The ADS 200/250 further comprises an external computer 301 (non-vehicular computer 301) coupled to the sensor simulator 302 and adapted for controlling the sensor simulator 302 to selectively couple to the vehicle computer 102 and to simulate (e.g., 512A, 512D, 512E, 612A/D, 712, 812) the operation of the (user) selected sensor 130.”, and [0061] “ADS 200/250 may also comprise a user keypad 220 coupled to the external computer 301 adapted to provide user inputs to the external computer 301; and a memory 230 coupled to the external computer 301, the memory 230 is adapted to store user input data associated with a range of vehicle manufacturer's makes, models, years, sensor 130 function types, and one or more of a voltage, current, and resistance operational range values (e.g., 502, 504, 510) of the selected sensor 130 to be simulated (e.g., 512A, 512D, 512E, 612A/D, 712, 812) (e.g., by sensor simulator 302).”)
Keane et al. teaches uploading the at least one fault indication and the identification information to one or more servers (Abstract “receiving with the diagnostic tool a component identifier corresponding to a component in the vehicle that is replaced in a service procedure in response to the diagnostic data from the diagnostic tool, transmitting with the diagnostic tool the diagnostic data and the component identifier to a server”, [0025] “the diagnostic tools are connected to the ECUs in vehicles to retrieve vehicle information, trouble codes, sensor data from in-vehicle sensors, and to test the operation of one or more systems in the vehicle by generating commands for the ECU. When a diagnostic tool is connected to the ECU in a vehicle, the diagnostic tool retrieves the VIN or other identification information for the vehicle that enables automatic identification of the make and model of the vehicle under test. The diagnostic tool also records a data stream from sensors in the vehicle and any trouble codes from the ECU in the vehicle. Some diagnostic tool embodiments retrieve the diagnostic data in the OBD-II or other industry standard format that enables the diagnostic tool to be operatively connected to a wide range of vehicles.”, and [0033] “The diagnostic query listeners 156 receive search queries and diagnostic data, such as DTCs and the VIN information, from the diagnostic tool 116”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty in combination with Keane et al. to incorporate uploading diagnostic data to a server as taught by Keane et al. for the purpose of identifying a specific problem corresponding to a vehicle component.
Regarding claim 17, Hardesty discloses A system for providing vehicle diagnostics, the
system comprising: ([0060] “The ADS 200/250 further comprises an external computer 301 (non-vehicular computer 301) coupled to the sensor simulator 302 and adapted for controlling the sensor simulator 302 to selectively couple to the vehicle computer 102 and to simulate (e.g., 512A, 512D, 512E, 612A/D, 712, 812) the operation of the (user) selected sensor 130.”, and [0061] “ADS 200/250 may also comprise a user keypad 220 coupled to the external computer 301 adapted to provide user inputs to the external computer 301; and a memory 230 coupled to the external computer 301, the memory 230 is adapted to store user input data associated with a range of vehicle manufacturer's makes, models, years, sensor 130 function types, and one or more of a voltage, current, and resistance operational range values (e.g., 502, 504, 510) of the selected sensor 130 to be simulated (e.g., 512A, 512D, 512E, 612A/D, 712, 812) (e.g., by sensor simulator 302).”) a simulator (Fig. 3A, 302) operable to generate a simulated output of the component according to the one or more simulated output parameters. ([0043] “The automotive diagnostic system 200 comprises a sensor simulator 302 configured to be selectively coupled to the vehicle computer 102 having the vehicle sensor wiring harness 110 coupled therebetween during a diagnostic mode. The sensor simulator 302 is adapted to simulate an operation of a selected sensor (such as a user selected sensor or a suspect sensor 131 of sensor system 130) to the vehicle computer 102 independent of the selected sensor or a connection means between the sensor and the automotive diagnostic system 200.”, [0044] “the external computer 102 adapted to provide user inputs to the external computer 301, and a memory 230 coupled to the external computer 301, the memory 230 adapted to store user input data associated with a range of vehicle manufacturers makes, models, years, sensor function types, and one or more of a voltage, current, and resistance operational range values of the selected sensor (e.g., 131) to be simulated.”, [0049] “sensor output vs. time diagrams, comprising operational ranges of voltages resistances or milliamperes, for example, wherein the range values of known good sensors will remain between exemplary High and Low limits, such as may be simulated by the sensor simulator of the automotive diagnostic systems”, and [0051] “sensor output plot 512A, illustrates an exemplary simulated output of a known good sensor which provides an output level transition, from an initial high output level at time “0” 506 through time “4”, transitioning between times “4-7”, down to a final sensor output level at time “7” 508 through time “9”. The sensor simulator 302 of ADS 200/250, for example, may be used to simulate this and all the following sensor outputs discussed herein. Sensor output plots 5128 and 512C may illustrate sensor outputs of a failed sensor that is unable to remain between exemplary High limit HL 504 and Low limit LL 502. Sensor output plot 512D illustrates another possible sensor output which remains steady at a low level, and remains between exemplary high and low limits, HL 504 and LL 502 respectively.”)
However, Hardesty fails to explicitly disclose one or more servers, and one or more servers operable to receive diagnostic data collected from an on- board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle,
Keane et al. teaches one or more servers operable to receive diagnostic data collected from an on-board diagnostics (OBD) port of a vehicle, the diagnostic data including identification information of the vehicle and at least one fault indication associated with a component of the vehicle (Abstract “receiving with the diagnostic tool a component identifier corresponding to a component in the vehicle that is replaced in a service procedure in response to the diagnostic data from the diagnostic tool, transmitting with the diagnostic tool the diagnostic data and the component identifier to a server”, [0025] “the diagnostic tools are connected to the ECUs in vehicles to retrieve vehicle information, trouble codes, sensor data from in-vehicle sensors, and to test the operation of one or more systems in the vehicle by generating commands for the ECU. When a diagnostic tool is connected to the ECU in a vehicle, the diagnostic tool retrieves the VIN or other identification information for the vehicle that enables automatic identification of the make and model of the vehicle under test. The diagnostic tool also records a data stream from sensors in the vehicle and any trouble codes from the ECU in the vehicle. Some diagnostic tool embodiments retrieve the diagnostic data in the OBD-II or other industry standard format that enables the diagnostic tool to be operatively connected to a wide range of vehicles.”, and [0033] “The diagnostic query listeners 156 receive search queries and diagnostic data, such as DTCs and the VIN information, from the diagnostic tool 116”)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty in combination with Keane et al. to incorporate uploading diagnostic data to a server as taught by Keane et al. for the purpose of identifying a specific problem corresponding to a vehicle component.
Regarding claim 19, and similarly with respect to claim 20, Hardesty in view of Keane et al.
discloses The system of claim 18,
Hardesty discloses (([0052] “a separate diagnostic scanner or analyzer (e.g., a Snap-On scanner) not shown) or the OBD2 Cable 252 of the ADS 200/250 may be plugged into an OBD2 port of the vehicle computer 102 in order to monitor the response of the vehicle computer 102 during the sensor simulation of the staircase sweep output 512E. Then, if the vehicle computer 102 fails to provide an appropriate response to each step of the staircase waveform output from the ADS 200/250, the user may be led to conclude that the vehicle computer 102, or that particular sensor input provided by the vehicle sensor wiring harness 110, or the vehicle sensor wiring harness 110 has failed.”)
Keane et al. teaches wherein the one or more servers is further operable to receive live data collected from the OBD port of the vehicle (Abstract “receiving with the diagnostic tool a component identifier corresponding to a component in the vehicle that is replaced in a service procedure in response to the diagnostic data from the diagnostic tool, transmitting with the diagnostic tool the diagnostic data and the component identifier to a server”, [0025] “the diagnostic tools are connected to the ECUs in vehicles to retrieve vehicle information, trouble codes, sensor data from in-vehicle sensors, and to test the operation of one or more systems in the vehicle by generating commands for the ECU. When a diagnostic tool is connected to the ECU in a vehicle, the diagnostic tool retrieves the VIN or other identification information for the vehicle that enables automatic identification of the make and model of the vehicle under test. The diagnostic tool also records a data stream from sensors in the vehicle and any trouble codes from the ECU in the vehicle. Some diagnostic tool embodiments retrieve the diagnostic data in the OBD-II or other industry standard format that enables the diagnostic tool to be operatively connected to a wide range of vehicles.”, and [0033] “The diagnostic query listeners 156 receive search queries and diagnostic data, such as DTCs and the VIN information, from the diagnostic tool 116”).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention with reasonable expectations of success to modify the diagnostic system of Hardesty in combination with Keane et al. to incorporate uploading diagnostic trouble code to a server as taught by Keane et al. for the purpose of identifying a specific problem corresponding to a vehicle component.
Claims 4 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Hardesty (US 20160171795 A1) in view of Keane et al. (US 20160328890 A1) and further in view of Shibi (US 20100023203 A1).
Regarding claim 4, and similarly with respect to claim 8, Hardesty in view of Keane et al.
discloses The method of claim 1,
Hardesty discloses wherein the one or more simulated output parameters includes ([0029] “The ADS further comprises a memory coupled to the external computer, adapted to store user input data associated with a range of vehicle manufacturer's makes, models, years, sensor function types, and one or more of a voltage, current and resistance operational range values of the selected sensor to be simulated…automotive diagnostic system may also include a user interface having a display for viewing various vehicle status conditions and sensor preset values, and may include pushbuttons for selecting various modes or for entering the sensor preset values.”, [0030] “the automotive diagnostic system, the external computer, keypad and memory are adapted to receive and store user input data associated with a selected manufacturers' make, model, year vehicle, and the function type of the selected sensor to be simulated by the sensor simulator. The keypad also enables the user to enter, select or adjust a typical operational value or range of values, or one or more High/Low limits of the selected sensor. The automotive diagnostic system is also adapted to determine whether a problem exists in one or more of the sensor or sensor system, the vehicle computer, and the vehicle sensor wiring harness, and to diagnose a likely problem therein”, and [0051] “sensor output plot 512A, illustrates an exemplary simulated output of a known good sensor which provides an output level transition, from an initial high output level at time “0” 506 through time “4”, transitioning between times “4-7”, down to a final sensor output level at time “7” 508 through time “9”. The sensor simulator 302 of ADS 200/250, for example, may be used to simulate this and all the following sensor outputs discussed herein. Sensor output plots 5128 and 512C may illustrate sensor outputs of a failed sensor that is unable to remain between exemplary High limit HL 504 and Low limit LL 502.”)
However, Hardesty in combination with Keane et al. fails to explicitly disclose user instructions for connecting a simulator to the vehicle
Shibi teaches user instructions for connecting a simulator to the vehicle ([0037] “screen shots are shown to better illustrate how the set of predeter