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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Drawings
The drawings are objected to because the second instances of S510 and S520 at the bottom of Figure 5 should be amended to be S570 and S580 respectively. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 3 is objected to because of the following informalities: claim 3 should be amended to recite “determining an update pending status of a prestored diagnostic script file in a local database …” for grammatical correctness. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “diagnostic client” in claim 9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. See [0116] of the as-filed specification (e.g. TBox).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
Claim 1 is directed to a method, claim 9 is directed to a system and claim 10 is directed to a device. Therefore, claims 1, 9 and 10 are within at least one of the four statutory categories.
101 Analysis – Step 2A, Prong I
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claim 1 and claim 9 include limitations that recite an abstract idea (emphasized below) and will be used as a representative claim for the remainder of the 101 rejection. The other analogous claims 10 are rejected for the same reasons as the representative claim 1 as discussed here.
Claim 1 recites:
A fault diagnosis method, the method being applied by a remote diagnostic client and comprising:
receiving a vehicle diagnostic push message sent by a remote diagnostic server, wherein the vehicle diagnostic push message comprises at least one of a diagnostic task type or diagnostic script information;
acquiring a target diagnostic script file and a target diagnostic condition based on the at least one of the diagnostic task type or the diagnostic script information, wherein the target diagnostic script file is obtained from conversion of a diagnostic database and a diagnostic sequence, and the target diagnostic script file is an interpreted language file; and
performing a fault diagnosis on a target vehicle according to the target diagnostic condition and the target diagnostic script file.
Claim 9 recites:
A fault diagnosis system, comprising a remote diagnostic server and a remote diagnostic client, wherein the remote diagnostic server comprises a diagnostic management platform, a push server, and a content delivery network, and the remote diagnostic client comprises a diagnostic client and a diagnostic script engine, wherein
the diagnostic management platform is configured to merge a diagnostic database and a diagnostic sequence into a diagnostic script file; and
the diagnostic client is configured to, in response to receiving a vehicle diagnostic push message that is sent by the push server and that carries at least one of a diagnostic task type or diagnostic script information, receive, based on the at least one of the diagnostic task type or the diagnostic script information, a target diagnostic script file and a target diagnostic condition sent by the content delivery network; and send the target diagnostic script file to the diagnostic script engine to enable the diagnostic script engine to parse the target diagnostic script file and perform a fault diagnosis on a target vehicle according to the target diagnostic condition and the target diagnostic script file,
wherein the target diagnostic script file is obtained from conversion of the diagnostic database and the diagnostic sequence by the diagnostic management platform, and the target diagnostic script file is an interpreted language file.
The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. For example, performing … in the context of this claim encompasses a person looking at data collected (received, detected, etc.) and forming a simple judgement (determination, analysis, comparison, etc.) either mentally or using a pen and paper. Accordingly, the claim recites at least one abstract idea. The Examiner notes that under MPEP 2106.04(a)(2)(III), the courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 ("‘[M]ental processes[] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same).
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract 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 exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
Claim 1 recites:
A fault diagnosis method, the method being applied by a remote diagnostic client and comprising:
receiving a vehicle diagnostic push message sent by a remote diagnostic server, wherein the vehicle diagnostic push message comprises at least one of a diagnostic task type or diagnostic script information;
acquiring a target diagnostic script file and a target diagnostic condition based on the at least one of the diagnostic task type or the diagnostic script information, wherein the target diagnostic script file is obtained from conversion of a diagnostic database and a diagnostic sequence, and the target diagnostic script file is an interpreted language file; and
performing a fault diagnosis on a target vehicle according to the target diagnostic condition and the target diagnostic script file.
Claim 9 recites:
A fault diagnosis system, comprising a remote diagnostic server and a remote diagnostic client, wherein the remote diagnostic server comprises a diagnostic management platform, a push server, and a content delivery network, and the remote diagnostic client comprises a diagnostic client and a diagnostic script engine, wherein
the diagnostic management platform is configured to merge a diagnostic database and a diagnostic sequence into a diagnostic script file; and
the diagnostic client is configured to, in response to receiving a vehicle diagnostic push message that is sent by the push server and that carries at least one of a diagnostic task type or diagnostic script information, receive, based on the at least one of the diagnostic task type or the diagnostic script information, a target diagnostic script file and a target diagnostic condition sent by the content delivery network; and send the target diagnostic script file to the diagnostic script engine to enable the diagnostic script engine to parse the target diagnostic script file and perform a fault diagnosis on a target vehicle according to the target diagnostic condition and the target diagnostic script file,
wherein the target diagnostic script file is obtained from conversion of the diagnostic database and the diagnostic sequence by the diagnostic management platform, and the target diagnostic script file is an interpreted language file.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitations of acquiring ..., receiving …, merging …, and sending … the examiner submits that these limitations are insignificant extra-solution activities that merely use a computer (processor) to perform the process. In particular, the acquiring ..., and receiving … step is recited at a high level of generality (i.e. as a general means of acquiring data for use in the next steps), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. The sending … and merging …. step is also recited at a high level of generality (i.e. as a general means of displaying information from some of the previous steps), and amounts to mere post solution action, which is a form of insignificant extra-solution activity. Lastly, claims 1, 9 and 10 further recite the “A fault diagnosis method, the method being applied by a remote diagnostic client and comprising: … by a remote diagnostic server, …” (claim 1), “A fault diagnosis system, comprising a remote diagnostic server and a remote diagnostic client, wherein the remote diagnostic server comprises a diagnostic management platform, a push server, and a content delivery network, and the remote diagnostic client comprises a diagnostic client and a diagnostic script engine, wherein the diagnostic management platform is configured to …, and the diagnostic client is configured to ...” (claim 9) and “A fault diagnosis device, comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program executable by the at least one processor to cause the at least one processor to perform the following steps: … by a remote diagnostic server …” (claim 10), which merely describes how to generally “apply” the otherwise mental judgements and/or additional limitations in a generic or general purpose vehicle control environment. See Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. at 223 (“[T]he mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention.”). The device(s) and processor(s) are recited at a high level of generality and merely automates the steps.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the 2019 PEG, representative independent claims 1 and 9 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor to perform the steps amounts to nothing more than applying the exception using a generic computer component. Generally applying an exception using a generic computer component cannot provide an inventive concept. And as discussed above, the additional limitations discussed above are insignificant extra-solution activities.
The additional limitations of acquiring … and receiving … is well-understood, routine and conventional activities because the background recites that the sensors are all conventional sensors, and the specification does not provide any indication that the processor is anything other than a conventional computer. MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner. The additional limitation of sending … and merging … is a well-understood, routine, and conventional activity because the Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere performances are well understood, routine, and conventional function. Hence, the claim is not patent eligible.
Dependent claims 2-8 and 11-20 do not recite any further limitations that cause the claims to be patent eligible. Rather, the limitations of dependent claims are directed toward additional aspects of the judicial exception and/or additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 2-8 and 11-20 are not patent eligible under the same rationale as provided for in the rejection of claim 1 and 9.
Therefore, claims 1-20 are ineligible under 35 USC §101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-2, 5-6, 8, 10, 12, 15, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haap (US 20140100737 A1) in view of Zoppelt (US 20180182184 A1).
Regarding claim 1, Haap discloses a fault diagnosis method, the method being applied by a remote diagnostic client (See at least abstract, [0007] A system for the diagnosis of a component of a vehicle, in particular a motor vehicle, provides a server that is configured and provided for the provision of at least one test sequence that is independent of the platform and that can be executed outside the diagnostic device, which sequence is for the diagnosis of the component, and at least one execution parameter allocated to the test sequence, as well as a diagnostic device that is configured and provided for the reception of at least one executable test sequence …) and comprising: acquiring a target diagnostic script file and a target diagnostic condition based on the at least one of the diagnostic task type or the diagnostic script information, wherein the target diagnostic script file is obtained from conversion of a diagnostic database and a diagnostic sequence, and the target diagnostic script file is an interpreted language file (See at least abstract, [0007], [0011-0015], [0017-0018], and [0044] A server that is configured and provided for the provision of at least one test sequence that is independent of the platform and that can be executed outside the diagnostic device, which sequence is for the diagnosis of the component, and at least one execution parameter allocated to the test sequence, as well as a diagnostic device that is configured and provided for the reception of at least one executable test sequence and the at least one execution parameter and for the conversion to a file format or runtime script that is executable or implementable in the environment of the diagnostic device and the runtime thereof, with a script interpreter or a script compiler. It is even more advantageous for the script generation device to be configured to be used for the generation of the test sequence information from a database. This is preferably information present in a description language, in particular in ODX. Generate test sequences from an output script compiled in a script language, in particular in Open Test sequence data eXchange (OTX). The pre-compiled test sequences are preferably a combination of OTX scripts and ODX control device diagnostic data, wherein the diagnostic possibilities of control devices are described in ODX. The script execution device is preferably a script compiler, which converts the OTX test sequences or the ETX scripts into the diagnostic target format, e.g. LUA, Java, Python, Pearl etc., which is applied in the respective vehicle. The execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed); and performing a fault diagnosis on a target vehicle according to the target diagnostic condition and the target diagnostic script file (See at least abstract, [0011-0015], [0023] The execution parameter are received by a server through a diagnostic device and the diagnostic device generates the runtime script and executes the execution parameter accordingly).
Haap does not explicitly disclose receiving a vehicle diagnostic push message sent by a remote diagnostic server, wherein the vehicle diagnostic push message comprises at least one of a diagnostic task type or diagnostic script information. However, Zoppelt teaches receiving a vehicle diagnostic push message sent by a remote diagnostic server, wherein the vehicle diagnostic push message comprises at least one of a diagnostic task type or diagnostic script information (See at least abstract, [0007], [0013-0014] Sending, by a back end unit via an air interface to a vehicle unit, a data packet which comprises an order for the diagnosis and/or configuration of the vehicle. The data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. Thus, the data packet contains, on the one hand, information with respect to the order to be carried out such as, e.g., diagnosis and/or configuration of the vehicle and, on the other hand, the corresponding scripts for performing the diagnosis and/or configuration of the vehicle). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches receiving a vehicle diagnostic push message sent by a remote diagnostic server, wherein the vehicle diagnostic push message comprises at least one of a diagnostic task type or diagnostic script information since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic efficiency and reduce network overhead.
Regarding claim 2, Haap does not explicitly disclose wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type comprises: in response to the diagnostic task type being a basic diagnosis, retrieving a prestored diagnostic script file and a diagnostic condition corresponding to the prestored diagnostic script file from a local database of the remote diagnostic client; and using the prestored diagnostic script file as the target diagnostic script file and using the diagnostic condition corresponding to the prestored diagnostic script file as the target diagnostic condition.
However, Zoppelt teaches wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type comprises: in response to the diagnostic task type being a basic diagnosis (See at least abstract, [0011-0017], [0030] The precondition test sequence executes scripts for testing preconditions which are relevant for the execution sequence), retrieving a prestored diagnostic script file and a diagnostic condition corresponding to the prestored diagnostic script file from a local database of the remote diagnostic client (See at least abstract, [0011-0017], [0042-0043] In the vehicle, executable scripts for the diagnosis and/or the configuration of the vehicle are stored. In this context, scripts either already previously stored in the script database 215 in the vehicle); and using the prestored diagnostic script file as the target diagnostic script file and using the diagnostic condition corresponding to the prestored diagnostic script file as the target diagnostic condition (See at least abstract, [0042] In this context, scripts either already previously stored in the script database 215 in the vehicle or contained in the OTA packet can be executed. Alternatively, the corresponding script can also already be stored in the script database 215 in the vehicle unit 200.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type comprises: in response to the diagnostic task type being a basic diagnosis, retrieving a prestored diagnostic script file and a diagnostic condition corresponding to the prestored diagnostic script file from a local database of the remote diagnostic client; and using the prestored diagnostic script file as the target diagnostic script file and using the diagnostic condition corresponding to the prestored diagnostic script file as the target diagnostic condition since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would enhance diagnostic speed and reduce network overhead.
Regarding claim 5, Haap does not explicitly disclose wherein performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file comprises: calling a corresponding target diagnostic protocol stack according to a diagnostic script logic of the target diagnostic script file; and in response to current operating status of the target vehicle satisfying the target diagnostic condition, performing the fault diagnosis on the target vehicle according to the target diagnostic script file by using the target diagnostic protocol stack.
However, Zoppelt teaches wherein performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file comprises: calling a corresponding target diagnostic protocol stack according to a diagnostic script logic of the target diagnostic script file (See at least abstract, Fig. 1, [0025], [0043-0047], [0052] The diagnostic interface 217 represents the interface between the script execution unit 214, the diagnostic data and the bus API 219. In the fourteenth step S14, in consequence, the diagnostic interface 217 enables the diagnostic data which are needed for executing the scripts for the diagnosis and/or the configuration of the vehicle to be accessed. After execution of the script in the script execution unit 214, an interface call up with identifiers (so-called short names) and parameters for determining machine-readable request PDUs (PDU=Protocol Data Unit) via the diagnostic interface 217); and in response to current operating status of the target vehicle satisfying the target diagnostic condition, performing the fault diagnosis on the target vehicle according to the target diagnostic script file by using the target diagnostic protocol stack (See at least abstract, [0013], [0028-0029], [0031-0033], [0042] The periodicity can describe whether the OTA order is to be executed cyclically (periodically at a particular time interval) or only once. Trigger conditions define the criteria which must be met for starting the OTA order. For example, there can be a temporal triggering (e.g. clock time/timer) or an event-based triggering (e.g. terminal 15=off) of the OTA order. The diagnosis and/or configuration of a vehicle, is characterized in that a data packet which comprises an order for the diagnosis and/or configuration of the vehicle is sent by a back end unit via an air interface to a vehicle unit, the vehicle unit evaluates whether a diagnosis and/or a configuration of the vehicle is to be undertaken, and the vehicle unit initiates a diagnosis and/or a configuration of the vehicle. In an eleventh step S11, the call up of the scripts for the diagnosis and/or the configuration of the vehicle and of any scripts needed for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle is sent to the script execution unit 214.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file comprises: calling a corresponding target diagnostic protocol stack according to a diagnostic script logic of the target diagnostic script file; and in response to current operating status of the target vehicle satisfying the target diagnostic condition, performing the fault diagnosis on the target vehicle according to the target diagnostic script file by using the target diagnostic protocol stack since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce network overhead.
Regarding claim 6, Haap discloses after performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file (See at least abstract, [0011-0015], [0023]), the method further comprising: parsing the execution result based on a data parsing format that is comprised in the target diagnostic script file and that matches the diagnostic instruction to obtain a diagnostic result (See at least abstract, [0017], [0024] During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner notes a “data parsing format” is a set of rules for interpreting result data. Haap’s “calculations and evaluations” necessarily require the script to know the format of the result data. Thus, the script file contains a data parsing format).
Haap does not explicitly disclose for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server. However, Zoppelt teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction (See at least abstract, [0017], [0043] During the execution of a script for the diagnosis and/or the configuration of the vehicle, logging files for the back documentation to the back end unit are generated and stored. With the aid of the sequence protocol, the back end unit can be informed whether the script for the diagnosis or the configuration of the vehicle has been executed correctly and in the case of a faulty execution, suitable measures can be initiated such as, e.g., a repeated execution of the script or the output of an error message.); and reporting the diagnostic result and the execution result to the remote diagnostic server (See at least abstract, [0017-0018], [0043], [0047-0049] Logging files for the back documentation to the back end unit are generated and stored. By means of the back documentation, both the actual useful data in the form of a useful data protocol and also a sequence protocol for fault analysis can be transmitted to the back end unit and deposited there. By means of the back documentation via the air interface, the back end unit can be informed immediately whether the diagnosis or the configuration of the vehicle has been executed correctly and suitable measures can be taken immediately). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would enhance diagnostic reporting and reliability.
Regarding claim 8, Haap discloses wherein the diagnostic script file comprises diagnostic communication information and diagnostic data information, wherein the diagnostic communication information comprises at least access information of a to-be-diagnosed electronic control unit (ECU); and the diagnostic data information comprises at least an instruction execution sequence, diagnostic data, and execution result processing (See at least abstract, [0014-0017], [0024] The pre-compiled test sequences are preferably a combination of OTX scripts and ODX control device diagnostic data, wherein the diagnostic possibilities of control devices are described in ODX. The pre-compiled test sequences are preferably denoted with the file extension “ETX” (for Executable Test sequence exchange). These test sequences preferably contain all necessary information to be able to execute them independent of their platform. During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner notes ODX (Open Diagnostic Data Exchange) provides diagnostic communication information, including access information (logical addresses) of ECUs. OTX (Open Test Sequence Exchange) provides the instruction execution sequence).
Regarding claim 10, Zoppelt discloses a fault diagnosis device, comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program executable by the at least one processor to cause the at least one processor to perform the following steps (See at least abstract, [0019-0020]). The rest of claim 10 is commensurate in scope with claim 1. See rejection for claim 1 above.
Regarding claim 12, Haap discloses after performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file (See at least abstract, [0011-0015], [0023]), the method further comprising: parsing the execution result based on a data parsing format that is comprised in the target diagnostic script file and that matches the diagnostic instruction to obtain a diagnostic result (See at least abstract, [0017], [0024] During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner notes a “data parsing format” is a set of rules for interpreting result data. Haap’s “calculations and evaluations” necessarily require the script to know the format of the result data. Thus, the script file contains a data parsing format).
Haap does not explicitly disclose for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server. However, Zoppelt teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction (See at least abstract, [0017], [0043] During the execution of a script for the diagnosis and/or the configuration of the vehicle, logging files for the back documentation to the back end unit are generated and stored. With the aid of the sequence protocol, the back end unit can be informed whether the script for the diagnosis or the configuration of the vehicle has been executed correctly and in the case of a faulty execution, suitable measures can be initiated such as, e.g., a repeated execution of the script or the output of an error message.); and reporting the diagnostic result and the execution result to the remote diagnostic server (See at least abstract, [0017-0018], [0043], [0047-0049] Logging files for the back documentation to the back end unit are generated and stored. By means of the back documentation, both the actual useful data in the form of a useful data protocol and also a sequence protocol for fault analysis can be transmitted to the back end unit and deposited there. By means of the back documentation via the air interface, the back end unit can be informed immediately whether the diagnosis or the configuration of the vehicle has been executed correctly and suitable measures can be taken immediately). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Regarding claim 15, Haap discloses after performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file (See at least abstract, [0011-0015], [0023]), the method further comprising: parsing the execution result based on a data parsing format that is comprised in the target diagnostic script file and that matches the diagnostic instruction to obtain a diagnostic result (See at least abstract, [0017], [0024] During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner notes a “data parsing format” is a set of rules for interpreting raw result data. Haap’s “calculations and evaluations” necessarily require the script to know the format of the result data. Thus, the script file contains a data parsing format).
Haap does not explicitly disclose for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server. However, Zoppelt teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction (See at least abstract, [0017], [0043] During the execution of a script for the diagnosis and/or the configuration of the vehicle, logging files for the back documentation to the back end unit are generated and stored. With the aid of the sequence protocol, the back end unit can be informed whether the script for the diagnosis or the configuration of the vehicle has been executed correctly and in the case of a faulty execution, suitable measures can be initiated such as, e.g., a repeated execution of the script or the output of an error message.); and reporting the diagnostic result and the execution result to the remote diagnostic server (See at least abstract, [0017-0018], [0043], [0047-0049] Logging files for the back documentation to the back end unit are generated and stored. By means of the back documentation, both the actual useful data in the form of a useful data protocol and also a sequence protocol for fault analysis can be transmitted to the back end unit and deposited there. By means of the back documentation via the air interface, the back end unit can be informed immediately whether the diagnosis or the configuration of the vehicle has been executed correctly and suitable measures can be taken immediately). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Regarding claim 20, Haap as modified by Zoppelt discloses wherein the diagnostic script file comprises diagnostic communication information and diagnostic data information, wherein the diagnostic communication information comprises at least access information of a to-be-diagnosed electronic control unit (ECU); and the diagnostic data information comprises at least an instruction execution sequence, diagnostic data, and execution result processing (See at least Haap abstract, [0014-0017], [0024] The pre-compiled test sequences are preferably a combination of OTX scripts and ODX control device diagnostic data, wherein the diagnostic possibilities of control devices are described in ODX. The pre-compiled test sequences are preferably denoted with the file extension “ETX” (for Executable Test sequence exchange). These test sequences preferably contain all necessary information to be able to execute them independent of their platform. During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner notes ODX (Open Diagnostic Data Exchange) provides diagnostic communication information, including access information (logical addresses) of ECUs. OTX (Open Test Sequence Exchange) provides the instruction execution sequence).
Claim(s) 3, 4, 7, 11, 13-14, 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haap (US 20140100737 A1) in view of Zoppelt (US 20180182184 A1), and further in view of Bolt (US 12190654 B2).
Regarding claim 3, Haap does not explicitly disclose wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type and the diagnostic script information comprises: in response to the diagnostic task type being a basic diagnosis. However, Zoppelt teaches wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type and the diagnostic script information comprises: in response to the diagnostic task type being a basic diagnosis (See at least abstract, [0011-0015], [0017-0018], [0030] Parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence executes scripts for testing preconditions which are relevant for the execution sequence). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type and the diagnostic script information comprises: in response to the diagnostic task type being a basic diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose determining update pending status of a prestored diagnostic script file in a local database of the remote diagnostic client based on the diagnostic script information; in response to the update pending status being that an update is required, reporting vehicle attribute information of the target vehicle to the remote diagnostic server; and receiving a latest diagnostic script file and a corresponding latest diagnostic condition that are sent by the remote diagnostic server and that match the vehicle attribute information; and using the latest diagnostic script file as the target diagnostic script file and using the corresponding latest diagnostic condition as the target diagnostic condition. However, Bolt teaches determining update pending status of a prestored diagnostic script file in a local database of the remote diagnostic client based on the diagnostic script information (See at least abstract, [0016-0018], [0021-0023], [0032-0033] Replacing the first VEC file stored on the one or more storage devices with a second VEC file distinct from the first VEC file, in response to detection of a new VIN. [0017] In particular implementations, replacing the first VEC file stored on the one or more storage devices with the second VEC file in response to at least one of a change in the VIN. Examiner notes the detection of a new VIN necessarily requires a comparison that an update is pending. The diagnostic script information includes the VIN); in response to the update pending status being that an update is required, reporting vehicle attribute information of the target vehicle to the remote diagnostic server (See at least abstract, [0008-0009], [0023], [0034-0038], The operations include causing a request including the VIN to be transmitted to a remote server system. The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number); and receiving a latest diagnostic script file and a corresponding latest diagnostic condition that are sent by the remote diagnostic server and that match the vehicle attribute information; and using the latest diagnostic script file as the target diagnostic script file and using the corresponding latest diagnostic condition as the target diagnostic condition (See at least abstract, [0008-0009], [0016-0022], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. Replacing the first VEC file stored on the one or more storage devices with a second VEC file distinct from the first VEC file, in response to detection of a new VIN). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches determining update pending status of a prestored diagnostic script file in a local database of the remote diagnostic client based on the diagnostic script information; in response to the update pending status being that an update is required, reporting vehicle attribute information of the target vehicle to the remote diagnostic server; and receiving a latest diagnostic script file and a corresponding latest diagnostic condition that are sent by the remote diagnostic server and that match the vehicle attribute information; and using the latest diagnostic script file as the target diagnostic script file and using the corresponding latest diagnostic condition as the target diagnostic condition since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve update efficiency and vehicle reporting.
Regarding claim 4, Haap does not explicitly disclose wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type and the diagnostic script information comprises: in response to the diagnostic task type being a script diagnosis. However, Zoppelt teaches wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type and the diagnostic script information comprises: in response to the diagnostic task type being a script diagnosis (See at least abstract, [0011-0015], [0017-0018], [0030] Parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence executes scripts for testing preconditions which are relevant for the execution sequence. The execution sequence describes the actual task which is to be executed by the OTA order). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein acquiring the target diagnostic script file and the target diagnostic condition based on the diagnostic task type and the diagnostic script information comprises: in response to the diagnostic task type being a basic diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose reporting vehicle attribute information of the target vehicle to the remote diagnostic server; and receiving a latest diagnostic script file and a corresponding latest diagnostic condition that are sent by the remote diagnostic server and that match the vehicle attribute information; and using the latest diagnostic script file as the target diagnostic script file and using the corresponding latest diagnostic condition as the target diagnostic condition. However, Bolt teaches reporting vehicle attribute information of the target vehicle to the remote diagnostic server (See at least abstract, [0008], [0022], [0038] Causing a request including the VIN to be transmitted from the vehicle diagnostic system to a remote server system. The methods include receiving, at the vehicle diagnostic system in response to transmission of the request, a vehicle electronic configuration (VEC) file based, at least in part, on the VIN); and receiving a latest diagnostic script file and a corresponding latest diagnostic condition that are sent by the remote diagnostic server and that match the vehicle attribute information; and using the latest diagnostic script file as the target diagnostic script file and using the corresponding latest diagnostic condition as the target diagnostic condition (See at least abstract, [0008-0009], [0016-0022], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. Replacing the first VEC file stored on the one or more storage devices with a second VEC file distinct from the first VEC file, in response to detection of a new VIN). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches reporting vehicle attribute information of the target vehicle to the remote diagnostic server; and receiving a latest diagnostic script file and a corresponding latest diagnostic condition that are sent by the remote diagnostic server and that match the vehicle attribute information; and using the latest diagnostic script file as the target diagnostic script file and using the corresponding latest diagnostic condition as the target diagnostic condition since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would enhance script matching accuracy and improve diagnostic reliability.
Regarding claim 7, Haap does not explicitly disclose teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis. However, Zoppelt teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis (See at least abstract, [0014-0015], [0028-0030], [0042] the data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. The processing instructions are used for sequentially grading and parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence (basic diagnosis) executes scripts for testing preconditions which are relevant for the execution sequence), or the diagnostic task type is determined as a script diagnosis (See at least abstract, Fig. 1 & 2, [0028-0030], [0042] The execution sequence describes the actual task which is to be executed by the OTA order. The scripts listed in this context are processed (e.g. reading the error store entries). ).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose in response to the diagnostic script information being non-empty. However, Bolt teaches in response to the diagnostic script information being non-empty (See at least abstract, [0008], [0038], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. The operations include identifying, via the VEC file, a parameter identification (PID) code, in response to receiving a generic request for vehicle operational data. The VEC file comprises strings and logic for a plurality of parameter identification (PID) codes). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches in response to the diagnostic script information being non-empty since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve the system’s diagnostic operation and reduce network overhead.
Regarding claim 11, Haap as modified by Zoppelt does not explicitly disclose a non-transitory computer-readable storage medium storing computer instructions which, when executed by a processor, cause the processor to perform the fault diagnosis method of claim 1. However, Bolt teaches a non-transitory computer-readable storage medium storing computer instructions which, when executed by a processor, cause the processor to perform the fault diagnosis method of claim 1 (See at least abstract, [0064-0065]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches a non-transitory computer-readable storage medium storing computer instructions which, when executed by a processor, cause the processor to perform the fault diagnosis method of claim 1 since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve the diagnostic system’s efficiency.
Regarding claim 13, Haap discloses after performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file (See at least abstract, [0011-0015], [0023]), the method further comprising: parsing the execution result based on a data parsing format that is comprised in the target diagnostic script file and that matches the diagnostic instruction to obtain a diagnostic result (See at least abstract, [0017], [0024] During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner note a “data parsing format” is a set of rules for interpreting result data. Haap’s “calculations and evaluations” necessarily require the script to know the format of the result data. Thus, the script file contains a data parsing format).
Haap does not explicitly disclose for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server. However, Zoppelt teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction (See at least abstract, [0017], [0043] During the execution of a script for the diagnosis and/or the configuration of the vehicle, logging files for the back documentation to the back end unit are generated and stored. With the aid of the sequence protocol, the back end unit can be informed whether the script for the diagnosis or the configuration of the vehicle has been executed correctly and in the case of a faulty execution, suitable measures can be initiated such as, e.g., a repeated execution of the script or the output of an error message.); and reporting the diagnostic result and the execution result to the remote diagnostic server (See at least abstract, [0017-0018], [0043], [0047-0049] Logging files for the back documentation to the back end unit are generated and stored. By means of the back documentation, both the actual useful data in the form of a useful data protocol and also a sequence protocol for fault analysis can be transmitted to the back end unit and deposited there. By means of the back documentation via the air interface, the back end unit can be informed immediately whether the diagnosis or the configuration of the vehicle has been executed correctly and suitable measures can be taken immediately). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve and enhance diagnostic reporting and reliability.
Regarding claim 14, Haap discloses after performing the fault diagnosis on the target vehicle according to the target diagnostic condition and the target diagnostic script file (See at least abstract, [0011-0015], [0023]), the method further comprising: parsing the execution result based on a data parsing format that is comprised in the target diagnostic script file and that matches the diagnostic instruction to obtain a diagnostic result (See at least abstract, [0017], [0024] During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. Examiner notes a “data parsing format” is a set of rules for interpreting result data. Haap’s “calculations and evaluations” necessarily require the script to know the format of the result data. Thus, the script file contains a data parsing format).
Haap does not explicitly disclose for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server. However, Zoppelt teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction (See at least abstract, [0017], [0043] During the execution of a script for the diagnosis and/or the configuration of the vehicle, logging files for the back documentation to the back end unit are generated and stored. With the aid of the sequence protocol, the back end unit can be informed whether the script for the diagnosis or the configuration of the vehicle has been executed correctly and in the case of a faulty execution, suitable measures can be initiated such as, e.g., a repeated execution of the script or the output of an error message.); and reporting the diagnostic result and the execution result to the remote diagnostic server (See at least abstract, [0017-0018], [0043], [0047-0049] Logging files for the back documentation to the back end unit are generated and stored. By means of the back documentation, both the actual useful data in the form of a useful data protocol and also a sequence protocol for fault analysis can be transmitted to the back end unit and deposited there. By means of the back documentation via the air interface, the back end unit can be informed immediately whether the diagnosis or the configuration of the vehicle has been executed correctly and suitable measures can be taken immediately). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches for each diagnostic instruction in the target diagnostic script file, acquiring an execution result of the diagnostic instruction; and reporting the diagnostic result and the execution result to the remote diagnostic server since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve and enhance diagnostic reporting and reliability.
Regarding claim 16, Haap does not explicitly disclose teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis. However, Zoppelt teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis (See at least abstract, [0014-0015], [0028-0030], [0042] the data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. The processing instructions are used for sequentially grading and parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence (basic diagnosis) executes scripts for testing preconditions which are relevant for the execution sequence), or the diagnostic task type is determined as a script diagnosis (See at least abstract, Fig. 1 & 2, [0028-0030], [0042] The execution sequence describes the actual task which is to be executed by the OTA order. The scripts listed in this context are processed (e.g. reading the error store entries). ).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose in response to the diagnostic script information being non-empty. However, Bolt teaches in response to the diagnostic script information being non-empty (See at least abstract, [0008], [0038], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. The operations include identifying, via the VEC file, a parameter identification (PID) code, in response to receiving a generic request for vehicle operational data. The VEC file comprises strings and logic for a plurality of parameter identification (PID) codes). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches in response to the diagnostic script information being non-empty since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve the system’s diagnostic operation and reduce network overhead.
Regarding claim 17, Haap does not explicitly disclose teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis. However, Zoppelt teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis (See at least abstract, [0014-0015], [0028-0030], [0042] the data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. The processing instructions are used for sequentially grading and parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence (basic diagnosis) executes scripts for testing preconditions which are relevant for the execution sequence), or the diagnostic task type is determined as a script diagnosis (See at least abstract, Fig. 1 & 2, [0028-0030], [0042] The execution sequence describes the actual task which is to be executed by the OTA order. The scripts listed in this context are processed (e.g. reading the error store entries). ).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose in response to the diagnostic script information being non-empty. However, Bolt teaches in response to the diagnostic script information being non-empty (See at least abstract, [0008], [0038], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. The operations include identifying, via the VEC file, a parameter identification (PID) code, in response to receiving a generic request for vehicle operational data. The VEC file comprises strings and logic for a plurality of parameter identification (PID) codes). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches in response to the diagnostic script information being non-empty since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve the system’s diagnostic operation and reduce network overhead.
Regarding claim 18, HHHaap does not explicitly disclose teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis. However, Zoppelt teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis (See at least abstract, [0014-0015], [0028-0030], [0042] the data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. The processing instructions are used for sequentially grading and parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence (basic diagnosis) executes scripts for testing preconditions which are relevant for the execution sequence), or the diagnostic task type is determined as a script diagnosis (See at least abstract, Fig. 1 & 2, [0028-0030], [0042] The execution sequence describes the actual task which is to be executed by the OTA order. The scripts listed in this context are processed (e.g. reading the error store entries). ).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose in response to the diagnostic script information being non-empty. However, Bolt teaches in response to the diagnostic script information being non-empty (See at least abstract, [0008], [0038], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. The operations include identifying, via the VEC file, a parameter identification (PID) code, in response to receiving a generic request for vehicle operational data. The VEC file comprises strings and logic for a plurality of parameter identification (PID) codes). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches in response to the diagnostic script information being non-empty since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve the system’s diagnostic operation and reduce network overhead.
Regarding claim 19, Haap does not explicitly disclose teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis. However, Zoppelt teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis (See at least abstract, [0014-0015], [0028-0030], [0042] the data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. The processing instructions are used for sequentially grading and parametrizing the diagnosis/configuration scripts to be executed, which can contain precondition test sequences, execution sequences and post-processing sequences. The precondition test sequence (basic diagnosis) executes scripts for testing preconditions which are relevant for the execution sequence), or the diagnostic task type is determined as a script diagnosis (See at least abstract, Fig. 1 & 2, [0028-0030], [0042] The execution sequence describes the actual task which is to be executed by the OTA order. The scripts listed in this context are processed (e.g. reading the error store entries). ).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches wherein in response to the diagnostic script information being empty, the diagnostic task type is determined as a basic diagnosis, or the diagnostic task type is determined as a script diagnosis since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic reliability and reduce overhead.
Haap as modified by Zoppelt does not explicitly disclose in response to the diagnostic script information being non-empty. However, Bolt teaches in response to the diagnostic script information being non-empty (See at least abstract, [0008], [0038], [0055] The operations include receiving, at the one or more storage devices and in response to transmission of the request to the remote server system, a vehicle electronic configuration (VEC) file generated or obtained based, at least in part, on the vehicle identification number. The operations include identifying, via the VEC file, a parameter identification (PID) code, in response to receiving a generic request for vehicle operational data. The VEC file comprises strings and logic for a plurality of parameter identification (PID) codes). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Bolt which teaches in response to the diagnostic script information being non-empty since they are all directed to vehicle diagnostics and configuration, and incorporation of Bolt would improve the system’s diagnostic operation and reduce network overhead.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haap (US 20140100737 A1) in view of Zoppelt (US 20180182184 A1) and further in view of Ingerman (US 20210344604 A1).
Regarding claim 9, Haap discloses a fault diagnosis system, comprising a remote diagnostic server and a remote diagnostic client (See at least abstract [0007] A server that is configured and provided for the provision of at least one test sequence that is independent of the platform and that can be executed outside the diagnostic device, which sequence is for the diagnosis of the component, and at least one execution parameter allocated to the test sequence, as well as a diagnostic device that is configured and provided for the reception of at least one executable test sequence), wherein the remote diagnostic server comprises a diagnostic management platform (See at least abstract, [0007] A system for the diagnosis of a component of a vehicle, in particular a motor vehicle, provides a server that is configured and provided for the provision of at least one test sequence that is independent of the platform and that can be executed outside the diagnostic device, which sequence is for the diagnosis of the component, and at least one execution parameter allocated to the test sequence, as well as a diagnostic device that is configured and provided for the reception of at least one executable test sequence), and the remote diagnostic client comprises a diagnostic client and a diagnostic script engine, wherein the diagnostic management platform is configured to merge a diagnostic database and a diagnostic sequence into a diagnostic script file (See at least abstract, [0007], [0014-0017] [0044-0045] A diagnostic device that is configured and provided for the reception of at least one executable test sequence and the at least one execution parameter and for the conversion to a file format or runtime script that is executable or implementable in the environment of the diagnostic device and the runtime thereof, with a script interpreter or a script compiler. The script execution device 22 can advantageously be a so-called “script interpreter”, so a computer program that reads, analyzes and executes a program source code. The script execution device is preferably a script compiler, which converts the OTX test sequences or the ETX scripts into the diagnostic target format, e.g. LUA, Java, Python, Pearl etc., which is applied in the respective vehicle. The pre-compiled test sequences are preferably a combination of OTX scripts and ODX control device diagnostic data, wherein the diagnostic possibilities of control devices are described in ODX); and send the target diagnostic script file to the diagnostic script engine to enable the diagnostic script engine to parse the target diagnostic script file and perform a fault diagnosis on a target vehicle according to the target diagnostic condition and the target diagnostic script file, wherein the target diagnostic script file is obtained from conversion of the diagnostic database and the diagnostic sequence by the diagnostic management platform, and the target diagnostic script file is an interpreted language file (See at least abstract, [0007], [0011-0015], [0017-0018], [0023-0024], and [0044] The execution parameter are received by a server through a diagnostic device and the diagnostic device generates the runtime script and executes the execution parameter accordingly. During the test sequences, the execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed. A server that is configured and provided for the provision of at least one test sequence that is independent of the platform and that can be executed outside the diagnostic device, which sequence is for the diagnosis of the component, and at least one execution parameter allocated to the test sequence, as well as a diagnostic device that is configured and provided for the reception of at least one executable test sequence and the at least one execution parameter and for the conversion to a file format or runtime script that is executable or implementable in the environment of the diagnostic device and the runtime thereof, with a script interpreter or a script compiler. It is even more advantageous for the script generation device to be configured to be used for the generation of the test sequence information from a database. This is preferably information present in a description language, in particular in ODX. Generate test sequences from an output script compiled in a script language, in particular in Open Test sequence data eXchange (OTX). The pre-compiled test sequences are preferably a combination of OTX scripts and ODX control device diagnostic data, wherein the diagnostic possibilities of control devices are described in ODX. The script execution device is preferably a script compiler, which converts the OTX test sequences or the ETX scripts into the diagnostic target format, e.g. LUA, Java, Python, Pearl etc., which is applied in the respective vehicle. The execution parameters preferably define the performance during the script execution, e.g. vehicle data to be compiled, the calculations and evaluations thereof and defining the further course of the script depending on the results, preferably under which conditions the runtime scripts are executed).
Haap does not explicitly disclose a push server, a content delivery network, and the diagnostic client is configured to, in response to receiving a vehicle diagnostic push message that is sent by the push server and that carries at least one of a diagnostic task type or diagnostic script information, receive, based on the at least one of the diagnostic task type or the diagnostic script information, a target diagnostic script file and a target diagnostic condition, and a target diagnostic script file and a target diagnostic condition sent by the content delivery network. Zoppelt teaches a push server (See at least abstract, [0007] The method includes sending, by a back end unit via an air interface to a vehicle unit, a data packet which comprises an order for the diagnosis and/or configuration of the vehicle; evaluating, by the vehicle unit, whether the diagnosis and/or a configuration of the vehicle is to be undertaken; and initiating, by the vehicle unit, the diagnosis and/or a configuration of the vehicle), and the diagnostic client is configured to, in response to receiving a vehicle diagnostic push message that is sent by the push server and that carries at least one of a diagnostic task type or diagnostic script information, receive, based on the at least one of the diagnostic task type or the diagnostic script information, a target diagnostic script file and a target diagnostic condition (See at least [0007], [0014-0015] Sending, by a back end unit via an air interface to a vehicle unit, a data packet which comprises an order for the diagnosis and/or configuration of the vehicle; evaluating, by the vehicle unit, whether the diagnosis and/or a configuration of the vehicle is to be undertaken; and initiating, by the vehicle unit, the diagnosis and/or a configuration of the vehicle. [0014-0015] According to a preferred development of the present invention, it is provided that the data packet contains an executable script for the diagnosis and/or the configuration of the vehicle and/or software for the configuration of the vehicle. Thus, the data packet contains, on the one hand, information with respect to the order to be carried out such as, e.g., diagnosis and/or configuration of the vehicle and, on the other hand, the corresponding scripts for performing the diagnosis and/or configuration of the vehicle). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap to incorporate the teachings of Zoppelt which teaches a push server, and the diagnostic client is configured to, in response to receiving a vehicle diagnostic push message that is sent by the push server and that carries at least one of a diagnostic task type or diagnostic script information, receive, based on the at least one of the diagnostic task type or the diagnostic script information, a target diagnostic script file and a target diagnostic condition since they are both directed to vehicle diagnostics and configuration, and incorporation of Zoppelt would improve diagnostic efficiency and reduce overhead.
Haap as modified by Zoppelt doesn’t explicitly disclose a content delivery network and a target diagnostic script file and a target diagnostic condition sent by the content delivery network. However, Ingerman teaches a content delivery network (See at least [0004], [0015], [00360-0035] FIG. 6 is a high-level diagram of an embodiment of the content delivery network (CDN) in which the teachings hereof may be implemented), and a target diagnostic script file and a target diagnostic condition sent by the content delivery network (See at least abstract, [0030-0033], [0132-0135] However, in modem systems, the vehicle manufacturer can use a CDN to deliver the data. It was stated above that either or both of the edge server 102 and data storage 104 may be provided by a content delivery network (CDN) service provider as a service to the vehicle manufacturer. The CDN server checks its configuration file to determine whether the content domain or sub-domain requested is actually being handled by the CDN. If so, the CDN server applies its content handling rules and directives for that domain or sub-domain as specified in the configuration). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, with a reasonable expectation of success, to have modified Haap as modified by Zoppelt to incorporate the teachings of Ingerman which teaches a content delivery network, and a target diagnostic script file and a target diagnostic condition sent by the content delivery network since they are all directed to vehicle data delivery, and incorporation of Ingerman would improve diagnostic efficiency and scalability for sending diagnostic information to the vehicle client.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LABIBAH I. ALI whose telephone number is (571)272-6738. The examiner can normally be reached M-F 8:00-5:00.
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, Faris Almatrahi 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.
/LABIBAH ILMA ALI/Examiner, Art Unit 3667
/SAHAR MOTAZEDI/Primary Examiner, Art Unit 3667
Prosecution Insights