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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR
1.17(e) has been timely paid, the finality of the previous Office action has been
withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 3rd, 2026 has been entered.
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.
Claims 1, 2, 3, 7, 8, 11, 13, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Elizalde et al. (US20180113702, Elizalde hereinafter), in view of Patra et al. (US20230289500, Patra hereinafter), Boling et al. (US20220374415, Boling hereinafter) and Miyake et al. (US20190278588, Miyaki hereinafter).
Regarding claim 1, Elizalde discloses: A non-transitory computer-readable medium having instructions recorded thereon that, in response to execution by one or more processors (see Elizalde et al., paragraph [0064], “…The computer program product comprises a non-transitory computer-readable medium encoded with a reprogramming file comprising computer executable instructions and computer readable data that when executed by a processor disposed within the target vehicle executes the method…”), cause performance of operations comprising:
(extract… convert… compile… segment… assemble… reprogramming… the target ECU) according to at least one testing script included in the equipment software assembly (see Elizalde, paragraph [0017], “Open Test sequence data eXchange (OTX) script file… extract commands from said OTX script file… convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image… assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU”);
producing an equipment package (“reprogramming file”) from the equipment software assembly (extract… convert… compile… segment… assemble… into a reprogramming file),
wherein the produced equipment package is executable to install (“re-flashing”) and validate (“verify success”) software on a target hardware element (“ECU”) of a vehicle architecture specification included in the equipment software assembly (see Elizalde, paragraph [0016], “…the reprogramming file may comprise steps to create a re-flashing scenario for reprogramming the target ECU… The reprogramming file may further comprise steps to verify success…”), (see Elizalde, paragraph [0017], “Test sequence data eXchange (OTX) script file... extract commands from said OTX script file... convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image... assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU…”), (See Elizalde, paragraph [0016], “…The reprogramming file may further comprise steps to verify success of said reprogramming…”), the produced equipment package including:
a plurality of binaries (“binary memory images”), each binary corresponding to a program package among a plurality of program packages included in the equipment software assembly (see Elizalde, paragraph [0032], “…a plurality of binary memory images... segmenting a binary image of the target ECU into a plurality of data blocks; compiling the plurality of data blocks… assembling the plurality of UDS stages and the handling routines into the reprogramming file.”), (see Elizalde, paragraph [0078], “…a binary file to be transmitted to a target vehicle… Reprogramming file 200 contains both control software and new program(s) to replace the corresponding program(s) in one or more electronic module(s) or electronic control units (ECU) in the vehicle…”)
metadata including (see Elizalde, paragraph [0013], “…the reprograming file comprises a header comprising general parameters, general execution conditions, and the number of the plurality of UDS stages.”), (see Elizalde, paragraph [0079], “…the reprogramming file is referred to as a “FOTA package.”... various embodiments shown utilize a wireless link to transmit the reprogramming file or FOTA package 200 to the target vehicle…”), (see Elizalde, paragraph [0096], “…The FOTA package comprises… a common header… FOTA header 201A may typically comprise FOTA identification information…”).
Elizalde does not appear to distinctly disclose:
testing
and
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Patra discloses:
testing (see Patra, paragraph [0016], “This disclosed methods and systems provide a simplified tool flow that automatically supplements the heterogeneous design with inferred connectivity, generates programming model-specific compiler scripts and a build script to generate configuration data for making a hardware implementation, and generates a test bench, along with hardware compatible input test vectors and expected result data”), (see Patra, paragraph [0062], “…The simulation tool creates simulation models and simulates the application, logging input simulation vectors and output result data from the simulation as captured simulation data...”),
a building script included in the equipment software assembly (see Patra, paragraph [0063], “…the system can, without designer intervention or further efforts, automatically generate compiler scripts for the different blocks, a build script (e.g., a makefile) to execute the compiler scripts… from the compiled binary object files…”), (see Patra, paragraph [0070], “…the script generation logic specifies in the build script the linking of the binary object files generated by the compilers…”), (see Patra, paragraph [0086], “…The build script can be run at block 428 to compile the design and link the binary objects…”),
metadata including (see Patra, paragraph [0063], “According to the disclosed methods and systems, once simulation results are satisfactory…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include testing to obtain test results and a build script as taught by Patra, for the result of ensuring that binaries are generated and verified prior to deployment.
Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Boling discloses:
(operating system utilizing operating system policies) (see Boling, paragraph [0055], “…the host processor 110 may have different operating modes, such as a user mode for user applications and a privileged mode for an operating system. Policy-related code (e.g., tagging, evaluating policies, etc.) may run in the same privileged mode as the operating system…”), at least one middleware package (“software libraries”) (Middleware is defined as a software component that is used between applications, systems, or services. Boling’s software libraries are not only used by one or more application programs but also distinctly separate from the applications, see Boling, paragraph [0194], “…The storage 1005 may also store one or more application programs and/or resources used by application programs (e.g., software libraries), which may be loaded into the memory 1002.”), and at least one application package (data and instructions used by one or more applications) (see Boling, paragraph [0026], “…It should be appreciated that application data may include data manipulated by an operating system (OS), instructions of the OS, data manipulated by one or more user applications, and/or instructions of the one or more user applications.”) and
metadata including debugging information, a description of the produced equipment package, and the test result information (see Boling, paragraph [0068], “…the debugger 230 may be programmed to display assembly code annotated with metadata labels… During debugging, the debugger 230 may halt a program during execution, and allow inspection of entities and/or metadata tags associated with the entities…”), (see Boling, paragraph [0064], “…the target description may include descriptions of a plurality of named entities. A named entity may represent a component of a target system. As one example, a named entity may represent a hardware component…”), (see Boling, paragraph [0046], “…the policy processor 150 may compute an output metadata tag for a register for storing a result of executing the arithmetic instruction…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an operating system package, middleware package, and application package, as well as metadata including debugging information as taught by Boling, for the result of providing modular and layered software consistent with modern automotive software architecture and facilitating troubleshooting and diagnosis of software.
Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Miyake discloses:
wherein the vehicle architecture specification includes an acceptable (“allowable versions”) version range of the at least one operating system package (“software for operating… respective pieces of software”) (Miyake, see paragraph [0034], “…In each compatibility table, a combination of software versions of all of the in-vehicle devices A to D that constitute the vehicle control system 100 is defined… each of the compatibility tables Ta_cur and Ta_old may include a system number that specifies a version of the vehicle control system 100, and respective software versions of the in-vehicle devices A to D… a range of versions of each in-vehicle device, which can be combined with those of the other in-vehicle devices, may be defined. Also, in the compatibility table, two or more sets or combinations of versions (or version ranges) allowed to be executed at the same time may be defined. In the case where one in-vehicle device holds two or more pieces of software, allowable versions of the respective pieces of software may be defined in the compatibility table.”), (Miyake, see paragraph [0033], “The software storing unit 10 stores software for operating the representative in-vehicle device A. The representative in-vehicle device A executes the software stored in the software storing unit 10, so as to fulfill a predetermined function for controlling operation of the vehicle.”), (Miyake, see paragraph [0034], “…In the case where one in-vehicle device holds two or more pieces of software, allowable versions of the respective pieces of software may be defined in the compatibility table.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an acceptable version range of the at least one operating system package as taught by Miyake, for the result of avoiding a version mismatch causing unexpected vehicle behavior.
Regarding claim 2, Elizalde teaches: (see Elizalde, paragraph [0075], “Embodiments of the invention are described that provide for reprogramming electronic modules in vehicles…”);
Elizalde does not appear to distinctly disclose: wherein the at least one testing script is configured to interact with
However, Patra teaches: wherein the at least one testing script is configured to interact with (see Patra, paragraph [0062], “The simulation tool creates simulation models and simulates the application…), (see Patra, paragraph [0063], “…the system can automatically generate compiler scripts for the different blocks, a build script (e.g., a makefile) to execute the compiler scripts, a test bench application and data, and a hardware image from the compiled binary object files and the test bench application.”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include a testing script as taught by Patra, for the result of evaluating vehicle-related software.
Regarding claim 3, Elizalde teaches: wherein the target hardware element is an Electronic Control Unit (ECU) of the vehicle architecture specification (see Elizalde, paragraph [0078], “…Reprogramming file 200 contains both control software and new program(s) to replace the corresponding program(s) in one or more electronic module(s) or electronic control units (ECU) in the vehicle…”);
Regarding claim 7, Elizalde teaches: (see Elizalde, paragraph [0017], “Open Test sequence data eXchange (OTX) script file... extract commands from said OTX script file… convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image... assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU”);
Elizalde does not appear to distinctly disclose: testing
However, Patra teaches: testing (see Patra, paragraph [0016], “This disclosed methods and systems provide a simplified tool flow that automatically supplements the heterogeneous design with inferred connectivity, generates programming model-specific compiler scripts and a build script to generate configuration data for making a hardware implementation, and generates a test bench, along with hardware compatible input test vectors and expected result data”), (see Patra, paragraph [0062], “The simulation tool creates simulation models and simulates the application, logging input simulation vectors and output result data from the simulation as captured simulation data...”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include testing to produce test result information as taught by Patra, for the result of verifying and improving functionality.
Regarding claim 8, Elizalde teaches: producing a vehicle package from the vehicle software assembly, wherein the vehicle package is executable to install (“re-flashing”) and validate (“verify success”) software on each of a plurality of hardware elements (see Elizalde, paragraph [0078], “…Reprogramming file 200 contains both control software and new program(s) to replace the corresponding program(s) in one or more electronic module(s) or electronic control units (ECU) in the vehicle…”), including the target element, of the vehicle architecture specification (see Elizalde, paragraph [0016], “…the reprogramming file may comprise steps to create a re-flashing scenario for reprogramming the target ECU… The reprogramming file may further comprise steps to verify success of said reprogramming...), (see Elizalde, paragraph [0017], “Open Test sequence data eXchange (OTX) script file… extract commands from said OTX script file... convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image... assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU”).
Regarding claim 11, Elizalde teaches: wherein the vehicle architecture specification includes a LAN (Local Area Network) communication specification (see Elizalde, paragraph [0091], “…transmit the FOTA package to a target vehicle 131 (or vehicles) via a wireless link 129. Wireless link 129 may comprise… local area network);
Regarding claim 13, Elizalde discloses: A method comprising:
(extract… convert… compile… segment… assemble… reprogramming… the target ECU) according to at least one testing script included in the equipment software assembly (see Elizalde, paragraph [0017], “Open Test sequence data eXchange (OTX) script file… extract commands from said OTX script file… convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image… assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU”);
producing an equipment package (“reprogramming file”) from the equipment software assembly (extract… convert… compile… segment… assemble… into a reprogramming file), wherein the produced equipment package is executable to install (“re-flashing”) and validate (“verify success”) software on a target hardware element (“ECU”) of a vehicle architecture specification included in the equipment software assembly (see Elizalde, paragraph [0016], “…the reprogramming file may comprise steps to create a re-flashing scenario for reprogramming the target ECU… The reprogramming file may further comprise steps to verify success…”), (see Elizalde, paragraph [0017], “Test sequence data eXchange (OTX) script file... extract commands from said OTX script file... convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image... assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU…”), (See Elizalde, paragraph [0016], “…The reprogramming file may further comprise steps to verify success of said reprogramming…”), the produced equipment package including:
a plurality of binaries (“binary memory images”), each binary corresponding to a program package among a plurality of program packages included in the equipment software assembly (see Elizalde, paragraph [0032], “…a plurality of binary memory images... segmenting a binary image of the target ECU into a plurality of data blocks; compiling the plurality of data blocks… assembling the plurality of UDS stages and the handling routines into the reprogramming file.”), (see Elizalde, paragraph [0078], “…a binary file to be transmitted to a target vehicle… Reprogramming file 200 contains both control software and new program(s) to replace the corresponding program(s) in one or more electronic module(s) or electronic control units (ECU) in the vehicle…”)
metadata including (see Elizalde, paragraph [0013], “…the reprograming file comprises a header comprising general parameters, general execution conditions, and the number of the plurality of UDS stages.”), (see Elizalde, paragraph [0079], “…the reprogramming file is referred to as a “FOTA package.”... various embodiments shown utilize a wireless link to transmit the reprogramming file or FOTA package 200 to the target vehicle…”), (see Elizalde, paragraph [0096], “…The FOTA package comprises… a common header… FOTA header 201A may typically comprise FOTA identification information…”).
Elizalde does not appear to distinctly disclose:
testing
and
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Patra discloses:
testing (see Patra, paragraph [0016], “This disclosed methods and systems provide a simplified tool flow that automatically supplements the heterogeneous design with inferred connectivity, generates programming model-specific compiler scripts and a build script to generate configuration data for making a hardware implementation, and generates a test bench, along with hardware compatible input test vectors and expected result data”), (see Patra, paragraph [0062], “…The simulation tool creates simulation models and simulates the application, logging input simulation vectors and output result data from the simulation as captured simulation data...”),
a building script included in the equipment software assembly (see Patra, paragraph [0063], “…the system can, without designer intervention or further efforts, automatically generate compiler scripts for the different blocks, a build script (e.g., a makefile) to execute the compiler scripts… from the compiled binary object files…”), (see Patra, paragraph [0070], “…the script generation logic specifies in the build script the linking of the binary object files generated by the compilers…”), (see Patra, paragraph [0086], “…The build script can be run at block 428 to compile the design and link the binary objects…”),
metadata including (see Patra, paragraph [0063], “According to the disclosed methods and systems, once simulation results are satisfactory…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include testing to obtain test results and a build script as taught by Patra, for the result of ensuring that binaries are generated and verified prior to deployment.
Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Boling discloses:
(operating system utilizing operating system policies) (see Boling, paragraph [0055], “…the host processor 110 may have different operating modes, such as a user mode for user applications and a privileged mode for an operating system. Policy-related code (e.g., tagging, evaluating policies, etc.) may run in the same privileged mode as the operating system…”), at least one middleware package (“software libraries”) (Middleware is defined as a software component that is used between applications, systems, or services. Boling’s software libraries are not only used by one or more application programs but also distinctly separate from the applications, see Boling, paragraph [0194], “…The storage 1005 may also store one or more application programs and/or resources used by application programs (e.g., software libraries), which may be loaded into the memory 1002.”), and at least one application package (data and instructions used by one or more applications) (see Boling, paragraph [0026], “…It should be appreciated that application data may include data manipulated by an operating system (OS), instructions of the OS, data manipulated by one or more user applications, and/or instructions of the one or more user applications.”) and
metadata including debugging information, a description of the produced equipment package, and the test result information (see Boling, paragraph [0068], “…the debugger 230 may be programmed to display assembly code annotated with metadata labels… During debugging, the debugger 230 may halt a program during execution, and allow inspection of entities and/or metadata tags associated with the entities…”), (see Boling, paragraph [0064], “…the target description may include descriptions of a plurality of named entities. A named entity may represent a component of a target system. As one example, a named entity may represent a hardware component…”), (see Boling, paragraph [0046], “…the policy processor 150 may compute an output metadata tag for a register for storing a result of executing the arithmetic instruction…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an operating system package, middleware package, and application package, as well as metadata including debugging information as taught by Boling, for the result of providing modular and layered software consistent with modern automotive software architecture and facilitating troubleshooting and diagnosis of software.
Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Miyake discloses:
wherein the vehicle architecture specification includes an acceptable (“allowable versions”) version range of the at least one operating system package (“software for operating… respective pieces of software”) (Miyake, see paragraph [0034], “…In each compatibility table, a combination of software versions of all of the in-vehicle devices A to D that constitute the vehicle control system 100 is defined… each of the compatibility tables Ta_cur and Ta_old may include a system number that specifies a version of the vehicle control system 100, and respective software versions of the in-vehicle devices A to D… a range of versions of each in-vehicle device, which can be combined with those of the other in-vehicle devices, may be defined. Also, in the compatibility table, two or more sets or combinations of versions (or version ranges) allowed to be executed at the same time may be defined. In the case where one in-vehicle device holds two or more pieces of software, allowable versions of the respective pieces of software may be defined in the compatibility table.”), (Miyake, see paragraph [0033], “The software storing unit 10 stores software for operating the representative in-vehicle device A. The representative in-vehicle device A executes the software stored in the software storing unit 10, so as to fulfill a predetermined function for controlling operation of the vehicle.”), (Miyake, see paragraph [0034], “…In the case where one in-vehicle device holds two or more pieces of software, allowable versions of the respective pieces of software may be defined in the compatibility table.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an acceptable version range of the at least one operating system package as taught by Miyake, for the result of avoiding a version mismatch causing unexpected vehicle behavior.
Regarding claim 14, Elizalde teaches: (see Elizalde, paragraph [0075], “Embodiments of the invention are described that provide for reprogramming electronic modules in vehicles…”);
Elizalde does not appear to distinctly disclose: wherein the at least one testing script is configured to interact with
However, Patra teaches: wherein the at least one testing script is configured to interact with (see Patra, paragraph [0062], “The simulation tool creates simulation models and simulates the application…), (see Patra, paragraph [0063], “…the system can automatically generate compiler scripts for the different blocks, a build script (e.g., a makefile) to execute the compiler scripts, a test bench application and data, and a hardware image from the compiled binary object files and the test bench application.”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include a testing script as taught by Patra, for the result of evaluating vehicle-related software.
Regarding claim 15, Elizalde teaches: wherein the target hardware element is an Electronic Control Unit (ECU) of the vehicle architecture specification (see Elizalde, paragraph [0078], “…Reprogramming file 200 contains both control software and new program(s) to replace the corresponding program(s) in one or more electronic module(s) or electronic control units (ECU) in the vehicle…”).
Regarding claim 19, Elizalde teaches: (see Elizalde, paragraph [0017], “Open Test sequence data eXchange (OTX) script file... extract commands from said OTX script file... convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image... assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU”);
Elizalde does not appear to distinctly disclose: testing
However, Patra teaches: testing information (see Patra, paragraph [0003], “The application can then be simulated across different simulators, such as Simulink, X86 simulator and DPE simulator, using input test vectors and verifying the results”), (see Patra, paragraph [0062], “The simulation tool creates simulation models and simulates the application, logging input simulation vectors and output result data from the simulation as captured simulation data...”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include testing to produce test result information as taught by Patra, for the result of verifying and improving functionality.
Regarding claim 20, Elizalde discloses:
(extract… convert… compile… segment… assemble… reprogramming… the target ECU) according to at least one testing script included in the equipment software assembly (see Elizalde, paragraph [0017], “Open Test sequence data eXchange (OTX) script file… extract commands from said OTX script file… convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image… assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU”);
producing an equipment package (“reprogramming file”) from the equipment software assembly (extract… convert… compile… segment… assemble… into a reprogramming file),
wherein the produced equipment package is executable to install (“re-flashing”) and validate (“verify success”) software on a target hardware element (“ECU”) of a vehicle architecture specification included in the equipment software assembly (see Elizalde, paragraph [0016], “…the reprogramming file may comprise steps to create a re-flashing scenario for reprogramming the target ECU… The reprogramming file may further comprise steps to verify success…”), (see Elizalde, paragraph [0017], “Test sequence data eXchange (OTX) script file... extract commands from said OTX script file... convert the high-level language diagnostics... compile the imperative language instructions… segment the binary image... assemble the plurality of UDS stages and the handling routines into a reprogramming file for reprogramming the target ECU…”), (See Elizalde, paragraph [0016], “…The reprogramming file may further comprise steps to verify success of said reprogramming…”), the produced equipment package including:
a plurality of binaries (“binary memory images”), each binary corresponding to a program package among a plurality of program packages included in the equipment software assembly (see Elizalde, paragraph [0032], “…a plurality of binary memory images... segmenting a binary image of the target ECU into a plurality of data blocks; compiling the plurality of data blocks… assembling the plurality of UDS stages and the handling routines into the reprogramming file.”), (see Elizalde, paragraph [0078], “…a binary file to be transmitted to a target vehicle… Reprogramming file 200 contains both control software and new program(s) to replace the corresponding program(s) in one or more electronic module(s) or electronic control units (ECU) in the vehicle…”)
metadata including (see Elizalde, paragraph [0013], “…the reprograming file comprises a header comprising general parameters, general execution conditions, and the number of the plurality of UDS stages.”), (see Elizalde, paragraph [0079], “…the reprogramming file is referred to as a “FOTA package.”... various embodiments shown utilize a wireless link to transmit the reprogramming file or FOTA package 200 to the target vehicle…”), (see Elizalde, paragraph [0096], “…The FOTA package comprises… a common header… FOTA header 201A may typically comprise FOTA identification information…”).
Elizalde does not appear to distinctly disclose: A device comprising: a controller including circuitry configured to perform
testing
and
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Patra discloses: A device comprising: a controller including circuitry configured to perform operations (see Patra, paragraph [0026], “Computer 102 may include one or more Input/Output (I/O) interfaces 128 communicatively linked to bus 110. I/O interface(s) 128 allow computer 102 to communicate with external devices, couple to external devices that allow user(s) to interact with computer 102, couple to external devices that allow computer 102 to communicate with other computing devices, and the like… Computer 102 may be coupled to other external devices such as a keyboard (not shown) via I/O interface(s) 128. Examples of I/O interfaces 128 may include, but are not limited to, network cards, modems, network adapters, hardware controllers, etc.”) including
testing (see Patra, paragraph [0016], “This disclosed methods and systems provide a simplified tool flow that automatically supplements the heterogeneous design with inferred connectivity, generates programming model-specific compiler scripts and a build script to generate configuration data for making a hardware implementation, and generates a test bench, along with hardware compatible input test vectors and expected result data”), (see Patra, paragraph [0062], “…The simulation tool creates simulation models and simulates the application, logging input simulation vectors and output result data from the simulation as captured simulation data...”),
a building script included in the equipment software assembly (see Patra, paragraph [0063], “…the system can, without designer intervention or further efforts, automatically generate compiler scripts for the different blocks, a build script (e.g., a makefile) to execute the compiler scripts… from the compiled binary object files…”), (see Patra, paragraph [0070], “…the script generation logic specifies in the build script the linking of the binary object files generated by the compilers…”), (see Patra, paragraph [0086], “…The build script can be run at block 428 to compile the design and link the binary objects…”),
metadata including (see Patra, paragraph [0063], “According to the disclosed methods and systems, once simulation results are satisfactory…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include testing to obtain test results and a build script as taught by Patra, for the result of ensuring that binaries are generated and verified prior to deployment.
Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Boling discloses:
operating system package (operating system utilizing operating system policies) (see Boling, paragraph [0055], “…the host processor 110 may have different operating modes, such as a user mode for user applications and a privileged mode for an operating system. Policy-related code (e.g., tagging, evaluating policies, etc.) may run in the same privileged mode as the operating system…”), at least one middleware package (“software libraries”) (Middleware is defined as a software component that is used between applications, systems, or services. Boling’s software libraries are not only used by one or more application programs but also distinctly separate from the applications, see Boling, paragraph [0194], “…The storage 1005 may also store one or more application programs and/or resources used by application programs (e.g., software libraries), which may be loaded into the memory 1002.”), and at least one application package (data and instructions used by one or more applications) (see Boling, paragraph [0026], “…It should be appreciated that application data may include data manipulated by an operating system (OS), instructions of the OS, data manipulated by one or more user applications, and/or instructions of the one or more user applications.”) and
metadata including debugging information, a description of the produced equipment package, and the test result information (see Boling, paragraph [0068], “…the debugger 230 may be programmed to display assembly code annotated with metadata labels… During debugging, the debugger 230 may halt a program during execution, and allow inspection of entities and/or metadata tags associated with the entities…”), (see Boling, paragraph [0064], “…the target description may include descriptions of a plurality of named entities. A named entity may represent a component of a target system. As one example, a named entity may represent a hardware component…”), (see Boling, paragraph [0046], “…the policy processor 150 may compute an output metadata tag for a register for storing a result of executing the arithmetic instruction…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an operating system package, middleware package, and application package, as well as metadata including debugging information as taught by Boling, for the result of providing modular and layered software consistent with modern automotive software architecture and facilitating troubleshooting and diagnosis of software.
Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification includes an acceptable version range of the at least one operating system package.
However, Miyake discloses:
wherein the vehicle architecture specification includes an acceptable (“allowable versions”) version range of the at least one operating system package (“software for operating… respective pieces of software”) (Miyake, see paragraph [0034], “…In each compatibility table, a combination of software versions of all of the in-vehicle devices A to D that constitute the vehicle control system 100 is defined… each of the compatibility tables Ta_cur and Ta_old may include a system number that specifies a version of the vehicle control system 100, and respective software versions of the in-vehicle devices A to D… a range of versions of each in-vehicle device, which can be combined with those of the other in-vehicle devices, may be defined. Also, in the compatibility table, two or more sets or combinations of versions (or version ranges) allowed to be executed at the same time may be defined. In the case where one in-vehicle device holds two or more pieces of software, allowable versions of the respective pieces of software may be defined in the compatibility table.”), (Miyake, see paragraph [0033], “The software storing unit 10 stores software for operating the representative in-vehicle device A. The representative in-vehicle device A executes the software stored in the software storing unit 10, so as to fulfill a predetermined function for controlling operation of the vehicle.”), (Miyake, see paragraph [0034], “…In the case where one in-vehicle device holds two or more pieces of software, allowable versions of the respective pieces of software may be defined in the compatibility table.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an acceptable version range of the at least one operating system package as taught by Miyake, for the result of avoiding a version mismatch causing unexpected vehicle behavior.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Elizalde, Patra, Boling, and Miyaki as applied to claims 3 and 15 above, and further in view of Drew et al. (US20140172397, Drew hereinafter).
Regarding claim 4, Elizalde as modified does not appear to distinctly disclose: wherein the equipment software assembly further includes a model configured for emulating a neighboring ECU.
However, Drew teaches: wherein the equipment software assembly further includes a model configured for emulating a neighboring ECU (see Drew, paragraph [0023], “…Individual multiple vehicle profiles may include a plurality of engine control units or Electronic Control Units (ECU)…”), (see Drew, paragraph [0026], “… the vehicle simulator device 12 is able to mimic a number of PIDs and corresponding response codes so as to test the emissions testing device across a wide array of different ECU's commonly found on a variety of different vehicles…”), (see Drew, paragraph [0028], “…the processor 14 is configured to perform a variety of different simulations. For example, the processor 14 is configured to simulate a plurality of different ECU's simultaneously…”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include a model configured for emulating a neighboring ECU as taught by Drew, for the result of evaluating the functionality of the software in the context of a system involving other ECUs.
Regarding claim 16, Elizalde as modified does not appear to distinctly disclose: wherein the equipment software assembly further includes a model configured for emulating a neighboring ECU.
However, Drew teaches: wherein the equipment software assembly further includes a model configured for emulating a neighboring ECU (see Drew, paragraph [0023], “…Individual multiple vehicle profiles may include a plurality of engine control units or Electronic Control Units (ECU)…”), (see Drew, paragraph [0026], “… the vehicle simulator device 12 is able to mimic a number of PIDs and corresponding response codes so as to test the emissions testing device across a wide array of different ECU's commonly found on a variety of different vehicles…”), (see Drew, paragraph [0028], “…the processor 14 is configured to perform a variety of different simulations. For example, the processor 14 is configured to simulate a plurality of different ECU's simultaneously…”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include a model configured for emulating a neighboring ECU as taught by Drew, for the result of evaluating the functionality of the software in the context of a system involving other ECUs.
Claim 5, 6, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Elizalde, Patra, Boling, and Miyaki as applied to claim 1 and 13 above, and further in view of Tzeng (US20060190933).
Regarding claim 5, Elizalde as modified does not appear to distinctly disclose: wherein the producing includes building the plurality of binaries.
However, Tzeng teaches: wherein the producing includes building the plurality of binaries (see Tzeng, paragraph [0038], “…Utilize the automated building framework to automatically read the utility source code and to compile the utility source code to generate a plurality of utility binary programs…”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include the building of binaries as taught by Tzeng, for the result of generating executable software components required for deployment on the hardware.
Regarding claim 6, Elizalde teaches: wherein the equipment software assembly further includes a model (“providing access… utilizing… converts… compiles”) configured for generating binary code (see Elizalde, paragraph [0032], “An embodiment of a method for generating a reprogramming file… providing access… to a plurality of binary memory images…utilizing high-to-low level command conversions… converting high-to-low language… compiling the imperative language instructions into binary code”);
Regarding claim 17, Elizalde as modified does not appear to distinctly disclose: wherein the producing includes building the plurality of binaries.
However, Tzeng teaches: wherein the producing includes building the plurality of binaries (see Tzeng, paragraph [0038], “…Utilize the automated building framework to automatically read the utility source code and to compile the utility source code to generate a plurality of utility binary programs…”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include the building of binaries as taught by Tzeng, for the result of generating executable software components required for deployment on the hardware.
Regarding claim 18, Elizalde teaches: wherein the equipment software assembly further includes a model (“providing access… utilizing… converts… compiles”) configured for generating binary code (see Elizalde, paragraph [0032], “An embodiment of a method for generating a reprogramming file… providing access… to a plurality of binary memory images…utilizing high-to-low level command conversions… converting high-to-low language… compiling the imperative language instructions into binary code”);
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Elizalde, Patra, Boling, and Miyaki as applied to claim 1 above, and further in view of Poulin et al. (US20210061273, Poulin hereinafter).
Regarding claim 10, Elizalde as modified does not appear to distinctly disclose: wherein the vehicle architecture specification includes a CAN (Controller Area Network) communication specification.
However, Poulin teaches: wherein the vehicle architecture specification includes a CAN (Controller Area Network) communication specification (see Poulin, paragraph [0013]. “…the ISA system comprises a number of modules defining nodes of the controller area network including: a user identification device 12 for identifying a driver of the vehicle; a navigation device 14, such as a navigation device including global positioning system (GPS) capabilities for determining a position of the vehicle on a road…”);
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include a controller area network as taught by Poulin, for the result of enabling communication between ECUs in a vehicle.
Claims 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Elizalde, Patra, Boling, and Miyaki as applied to claim 1 above, and further in view of Markley et al. (US20050132350, Markley hereinafter).
Regarding claim 21, Elizalde as modified does not appear to distinctly disclose:
wherein the vehicle architecture specification further includes an acceptable version range of each dependency of the at least one operating system package.
However, Miyake discloses:
wherein the vehicle architecture specification further includes an acceptable version range (see Miyake, paragraph [0034], “…While a single version is defined as a version of each in-vehicle device, in the example of the compatibility tables of FIG. 3, a range of versions of each in-vehicle device, which can be combined with those of the other in-vehicle devices, may be defined. Also, in the compatibility table, two or more sets or combinations of versions (or version ranges) allowed to be executed at the same time may be defined…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an acceptable version range of the at least one operating system package as taught by Miyake, for the result of avoiding the breaking of the operating system when a package is updated.
Elizalde as modified does not appear to distinctly disclose:
However, Markley discloses:
wherein (see Markley, paragraph [0043], “…The dependency rules for a package require that the package or packages on which a package is dependent are either at or above the version number identified in the dependency list…”), (see Markley, paragraph [0042], “Also seen in the device manifest header is a list of packages on which the current package is dependent…”), (see Markley, paragraph [0031], “…the entire operating system image is built from one or more packages, each of which may be updated individually or in combination with other packages, depending upon each package's requirements.”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include an acceptable version range of each dependency of the at least one operating system package as taught by Markley, for the result of avoiding the breaking of the operating system when a package is updated.
Regarding claim 22, Elizalde does not appear to distinctly disclose:
wherein the operations further comprise validating that each dependency on the operating system package is a version prescribed by the vehicle architecture specification.
However, Miyake discloses:
wherein the operations further comprise validating that (see Miyake, paragraph [0039], “…the determining unit 14 checks the version of the software stored in the software storing unit 10 of the representative in-vehicle device A, and the software versions obtained by the obtaining unit 12 from the other in-vehicle devices B to D, against the proper compatibility table specified by the compatibility information specifying unit 13…”), (see Miyake, paragraph [0054], “…the software version “234” of the in-vehicle device B does not match the version defined in the compatibility table Tc_cur. Accordingly, the determining unit 14 determines that the software versions of all of the in-vehicle devices A to D that constitute the vehicle control system 100 lack compatibility…”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include validating that the operating system package is a version prescribed by the vehicle architecture specification as taught by Miyake, for the result of ensuring that the operating system package is never left running with an incompatible dependency and identifying a package that needs to be updated.
Elizalde as modified does not appear to distinctly disclose:
However, Markley discloses:
wherein the operations further comprise validating that each dependency on the operating system package is a version prescribed by (see Markley, paragraph [0078], “Once the highest version number is determined, the dependencies for that node are validated... If a dependency cannot be satisfied, then the branch is abandoned and a new branch is attempted…”), (see Markley, paragraph [0043], “There can be any number of packages each uniquely described by a GUID; all versions of a package share the same GUID. The dependency rules for a package require that the package or packages on which a package is dependent are either at or above the version number identified in the dependency list…”), (see Markley, paragraph [0031], “…the entire operating system image is built from one or more packages…”), (see Markley, paragraph [0043], “…A package is at or above the specified version if such a version is already installed on the device, or the install is pending and its dependencies are satisfied (thus ensuring its install).”).
It would have been obvious to one of ordinary skill in the art before the effecting filing
date of the claimed invention to have modified a method for programming vehicle electronic control modules as taught by Elizalde, to include validating that each dependency on the operating system package is a version as taught by Markley, for the result of ensuring that the operating system package is never left running with an incompatible dependency and for the result of identifying a package that needs to be updated.
Response to Arguments
Applicant’s Argument: The prior are does not teach the newly amended subject matter.
Examiner’s Response: The applicant’s argument is moot as new art is used to teach the newly amended subject matter.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to Joshua Tran whose telephone number is (571)272-5460.
The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s
supervisor, Hyung Sough can be reached on (571)272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JOSHUA TRAN/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
