DETAILED ACTION
Remarks
Applicant presents a request for continued examination dated 24 April 2026 in response to the 3 February 2026 final rejection (the “Final Office Action”) as well as the 20 April 2026 advisory action.
With the request, Applicant amends claims 1, 5, 7 and 19. Applicant has also amended paragraph [0033] of the specification.
Claim 1-20 are pending. Claims 1, 15 and 19 are the independent claims.
Applicant’s arguments are unpersuasive as set forth in the “Response to Arguments” section below.
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 24 April 2026 has been entered.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Response to Arguments
Applicant’s arguments are moot in view of the new ground(s) of rejection herein below.
Specification
The Final Office Action’s objection to the specification is withdrawn in view of Applicant’s amendments to paragraph [0033]. Note too for the record the objection appears to have erroneously referred to paragraph [0044] instead of paragraph [0033].
Claim Interpretation
In view of Applicant’s claim amendments, the claim limitations noted in the Final Office Action are no longer interpreted in accordance with 35 U.S.C 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The Previous Action’s § 112 rejections are withdrawn in view of Applicant’s claim amendments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Maeda et al. (US 2018/0152341) (art of record – hereinafter Maeda) in view of Phatak et al. (US 2018/0060456) (art of record – hereinafter Phatak) in view of Matsumura et al. (US 2012/0011097) (art of record – hereinafter Matsumura).
As to claim 1, Maeda discloses a system, comprising:
one or more computing devices, comprising one or more processors and memory storing program instructions, configured (e.g., Maeda, par. [0245]: this method may be taken to be a computer program realized by a computer. One aspect of the present disclosure may be a computer system equipped with a microprocessor and memory in which the memory records the above computer program, and the microprocessor operates according to the computer program) to implement a vehicle software test environment management system, (e.g., Maeda, par. [0047] executing a simulation of operation of the updated firmware [firmware being a type of software]. Operation verification is performed by the execution of the simulation; par. [0056]: updating firmware installed in each ECU on board a vehicle to a new, updated firmware) wherein the one or more computing devices are configured to:
receive, at the vehicle software test environment management system, a software application to be certified; (e.g., Maeda, par. [01769]: registration of updated firmware [software application to be certified, see above])
determine, by the vehicle software test environment management system, based on the information, respective configurations for virtual electronic control units (vECUs) to be used to simulate respective ones of the ECUs of the information; (e.g., Maeda, par. [0185], information for simulating various ECUs stored by the ECU information storing unit 531 may include, information to the processor and memory inside each ECU, information related to the CAN controller inside each ECU, information regarding the bus connected to each ECU or a communication link used by each ECU; par. [0116]: unit 530 references the ECU information storing unit 531 to construct an operating environment that simulates ECUs of the same type; par. [0223]: in simulator 800, each ECU is simulated by a single virtual machine. Multiple virtual machines 805 “(equal to the number of ECUs constituting the operating environment)” may be generated)
determine, by the vehicle software test environment management system, based on the information, virtual bus connectivity configuration for the vECUs based on the connectivity configuration of the ECUs indicated in the information (e.g., Maeda, par. [0185]: information for simulating various ECUs stored by the information storing unit 531 may include information regarding the bus connected to each ECU or a communication link used by each ECU; par. [0116]: unit 530 references the ECU information storing unit 531 to construct an operating environment that simulates ECUs of the same type; par. [0213]: software running on the simulator includes a virtual machine monitor 801; par. [0223]: virtual machine monitor 801 may be configured to simulate the bus-mediated communication between ECUs).
provide computing resources configured as the vECUs having the determined respective configurations that correspond to the respective ones of the ECUs of the information, wherein the computing resources are implemented using virtual compute instances that are configured based on the determined respective configurations for the vECUs, (e.g., Maeda, par. [0223]: in the simulator 800, a single ECU is simulated by a single virtual machine. For example, multiple virtual machines 805 (equal to the number of ECUs constituting the operating environment) may be generated; par. [0185]: unit 530a sets information about each ECU that should be used in the simulator 800, on the basis of information for simulating ECUs stored in the ECU information storing unit 531) and wherein the computing resources are further configured in a network configuration that implements the determined virtual bus connectivity configuration; (e.g., Maeda, par. [0185]: the information for simulating various ECUs stored by the ECU information storing unit 531 may include information regarding the bus connected to each ECU; par. [0185]: the FW operation verifying unit 530a sets information about each ECU that should be used in the operation verification in the simulator 800, on the basis of information stored in the ECU information storing unit 531; par. [0223]: the virtual machine monitor may be configured to simulate the bus-mediated communication between ECUs by communicating between the multiple virtual hardware configurations running on the virtual machine monitor 801; par. [0224]: virtual machines in the simulator 800 to perform the same operations as each of the ECUs )
deploy the software application to at least one of the provided computing resources configured as a vECU; (e.g., Maeda, par. [0187]: unit 530a uses the simulator 800 to simulate an update of setting the updated firmware in the target ECU and simulate the operation of each ECU adter updating; par. [0194]: every time on piece of updated firmware is set in one ECU in the simulator 800, unit 530a verifies whether the ECU operates correctly).
Maeda does not explicitly disclose: to receive or access, at the vehicle software test environment management system, a test plan for certifying the software application for use in a given vehicle; to receive or access, at the vehicle software test environment management system, a vehicle deployment graph of the given vehicle, wherein the vehicle deployment graph comprises respective configurations of electronic control units (ECUs) of the given vehicle and a connectivity configuration of the ECUs of the given vehicle and wherein the vehicle deployment graph comprises nodes representing the ECUs and one or more edges representing one or more communication links between the ECUs; the vehicle deployment graph; and to perform the test plan to certify the software application for use in the given vehicle, wherein the test plan is performed using the provided computing resources configured as the vECUs configured in the virtual bus configuration.
However, in an analogous art, Phatak discloses:
to receive or access, at the vehicle software test environment management system, a test plan for certifying the software application for use in a given vehicle; (e.g., Phatak; par. [0057]: a user may provide software, such as control software that is to be installed on the real ECU, execute the software on the vECU to determine whether the control software performs as intended; par. [0092]: the user may provide parameter sweep information, and the simulation platform may execute the simulation with the indicated parameters)
to perform the test plan to certify the software application for use in the given vehicle, wherein the test plan is performed using the provided computing resources configured as the vECUs configured in the virtual bus configuration (e.g., Phatak, par. [0057]: a vECU may be a processor simulator. A user may provide software, such as control software that is to be installed on the real ECU, execute the software on the vECU to determine whether the control software performs as intended; par. [0134]: simulators may execute on the virtual machines; par. [0059]: the CAN router may provide a virtual CAN bus between multiple simulators, such as multiple vECUs, by enabling communication between the virtual machines 110 par. [0092]: the user may provide parameter sweep information, and the simulation platform may execute the simulation with the indicated parameters; par. [0167]: the simulation platform may perform a sweep of more than one parameter in each model).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the vehicle software test environment management system verifying software using vECUs and a virtual bus configuration taught by Maeda, to include receiving or accessing at system, a test plan for certifying the software application for use in a given vehicle and performing the test plan to certify the software application for use in the given vehicle, wherein the test plan is performed using the provided computing resources configured as the vECUs configured in the virtual bus configuration as taught by Phatak, as Phatak would provide a means of testing the system with different sets of parameters. (See Phatak, par., [0036]).
Further, in an analogous art, Matsumura discloses to:
to receive or access a vehicle deployment graph of the given vehicle, wherein the vehicle deployment graph comprises respective configurations of electronic control units (ECUs) of the given vehicle and a connectivity configuration of the ECUs of the given vehicle and wherein the vehicle deployment graph comprises nodes representing the ECUs and one or more edges representing one or more communication links between the ECUs (e.g., Matsumura, Fig. 13 and associated text, par. [0125]: a discussion is made on assignments to an in-vehicle communication bus (BUS) of an in-vehicle software component (SWC). FIG. 13 is a diagram illustrating an example graph model 80 according to this embodiment; par. [0126]: the graph model 80 is a graph-structured system model including SWCs, BUSes and ECUs installed [deployed] in a vehicle. SWCs are connected to ECU blocks which represent ECUs and BUS1, Bus2,…are connected to ECUs [see figure, the graph includes blocks (nodes) representing ECUs and the lines (edges) connecting ECUs via BUS blocks]) and
information in the form of the vehicle deployment graph (see immediately above)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and information of Maeda by incorporating receiving or accessing a vehicle deployment graph of the given vehicle, wherein the vehicle deployment graph comprises respective configurations of one or more electronic control units (ECUs) of the given vehicle and a connectivity configuration of the ECUs of the given vehicle; wherein the vehicle deployment graph comprises nodes representing the ECUs and one or more edges representing one or more communication links between the ECU and such that the information (of Maeda) is in the form of the vehicle deployment graph, as taught by Matsumura, as Matsumura would provide the advantage of a mean of proving the information in a standard format. (See Matsumura, pars. [0125-0126], [0004]). Storing information in the form of a graph also provides a means of analyzing relationships that underlie the data, allows certain types of queries to be more easily expressed and permits easier schema changes. (See US 2020/0184026 at par. [0023]).
Claims 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Phatak (US 2018/0060456) in view of Matsumura (US 2012/0011097) in further view of Kislovskiy et al. (US 2018/0341571) (art of record – hereinafter Kislovskiy) and Wiechowski et al. (US 20118/0101472) (art of record – hereinafter Wiechowski).
As to claim 2, Maeda/Phatak/Matsumura discloses the system of claim 1 (see rejection of claim 1 above) but Maeda does not explicitly disclose wherein to perform the test plan, the one or more computing devices are further configured to: receive recorded signals of one or more ECUs of the given vehicle, or a vehicle having a similar configuration as the given vehicle; apply the recorded signals to respective ones of one or more of the vECUs via virtual hooks of the one or more of the vECUs and determine that a resulting response of the software application is within a threshold range as provided in the test plan.
However, in an analogous art, Phatak discloses:
wherein to perform the test plan, the one or more computing devices are further configured to:
apply the received recorded signals to respective ones of one or more of the vECUs via virtual hooks of the one or more of the vECUs; (e.g., Phatak, Figs. 16, 17 and associated text, par. [0125]: the virtual CAN router 1414 may receive a CAN message [recorded in the sense that it is stored] with the speed set point 1434 as a payload, and may propagate this CAN message to each of the vECU 1402 and the vECU 1404 [the bidirectional arrows shown interfacing virtual CAN bus 1412 and the vECUs being virtual hooks]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing of software set in vECUs taught by Maeda to include testing the software using a test plan, wherein to perform the test plan, the one or more computing devices are further configured to: apply the signals to respective ones of one or more of the vECUs via virtual hooks of the one or more vECUs, as taught by Phatak, as Phatak would provide the advantage of a means of emulating the vehicle-level traffic of the ECUs. (See Phatak, par. [0125]).
Further, in an analogous art, Kislovskiy discloses the one or more computing devices are further configured to:
receive recorded signals of one or more ECUs of the given vehicle, or a vehicle having a similar configuration as the given vehicle; (e.g., Kislovskiy, Fig. 5 and associated text, par. [0112]: the control system 520 [ECU, in a vehicle as shown in the figure] can transmit log data 527 to transport management system 590. The log data 527 can include sensor data stream 515, and data corresponding to control inputs made by the control system).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing ECUs in a simulation environment utilizing received signals of Maeda/Phatak/Matsumura, such that the signals are recorded signals of one or more ECUs of the given vehicle, or a vehicle having a similar configuration as the given vehicle, as taught by Kislovskiy, as Kislovskiy would provide the advantage of a means to perform the simulation using real-world data. (See Kislovskiy, par. [0136]).
Finally, in an analogous art, Wiechowski discloses to:
determine that a resulting response of the software application is within a threshold range as provided in the test plan (e.g., Wiechowski, par. [0024]: to test a piece of software, signals are used to stimulate the inputs to the software. During the simulation, the corresponding output signals are recorded an evaluated, in that the recorded values are compared with previously specified acceptance or tolerance [threshold range] criteria; par. [0013]: a simple manner permits the specification of signals, as well as acceptance or tolerance criteria; par. [0027]: a test case specification can comprise the following parameters [and see table, the parameters include “Acceptance” criterion])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing of a software application taught by Maeda/Phatak/Matsumura/Kislovskiy, by incorporating determining that a resulting response of the software application is within a threshold range as provided in the test plan, as taught by Wiechowski, as Wiechowski would provide the advantages of a simple means of specifying the test plan and a means determining whether the application responds acceptably. (See Wiechowski, par. [0013]).
As to claim 3, Maeda/Phatak/Matsumura/Kislovskiy/Wiechowski discloses the system of claim 2 (see rejection of claim 2 above), Maeda further discloses:
sensor outputs from the vECUs (e.g., Maeda, par. [0060]: the ECUs 100a to 100d are connected to equipment such as sensor 103, sensor 104, respectively, acquiring the states of the equipment and periodically transmitting the states “(data frames)” to an on-board network made up of devices such as buses 200a and 200b; par. [0224]: virtual machines in the simulator to perform the same operations as each of the ECUs).
Maeda does not explicitly disclose wherein to perform the test plan the one or more computing devices are configured to: apply a portion of the received recorded signals corresponding to a first set of moments in time to the respective ones of the one or more of the vECUs via the virtual hooks; receive outputs from the vECUs based on the application of the received recorded signals for the first set of moments in time; modify a second portion of the recorded signals corresponding to a second set of moments in time based on the received outputs from the vECUs; and apply the modified second portion of the recorded signals to the respective ones of the one or more of the vECUs via the virtual hooks for the second set of moments in time.
However, in an analogous art, Phatak discloses:
wherein to perform the test plan the one or more computing devices are configured to:
apply a portion of the received recorded signals corresponding to a first set of moments in time to the respective ones of the one or more of the vECUs via the virtual hooks (e.g., Phatak, Figs. 16, 17 and associated text, par. [0125]: the virtual CAN router 1414 may receive a CAN message [necessarily recorded in sense that it is stored] with the speed set point 1434 as a payload, and may propagate this CAN message to each of the vECU 1402 and the vECU 1404 [the bidirectional arrows shown interfacing virtual CAN bus 1412 and the vECUs being virtual hooks]);
receive outputs from the vECUs based on the application of the received recorded signals for the first set of moments in time (e.g., Phatak, Fig. 15 and associated text, par. [0123]: determining that the motor controllers 1426 and 1428 [each in a vECU, see figure] respond as intended to external control signals, and output control signals as intended)
to apply recorded signals to the respective ones of the one or more vECUs via the virtual hooks (see above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the computing devices performing software testing via vECUs and reception of sensor outputs from those vECUs such that to perform a test plan, the one or more devices apply a portion of received recorded signals corresponding to a first set of moments in time to the respective ones of the one or more of the vECUs via the virtual hooks; receive the outputs from the vECUs based on the application of the received recorded signals for the first set of moments in time and apply signals to the respective ones of the one or more vECUs via the virtual hooks, as taught by Phatak, as Phatak would provide the advantage of a means of emulating the vehicle-level traffic of the ECUs. (See Phatak, par. [0125]).
Further, in an analogous art, Wiechowski discloses to:
modify a second portion of the signals corresponding to a second set of moments in time based on the received outputs; (e.g., Wiechowski, par. [0011]: the output values generated up to the respective point in time by the test platform are taken into account in the automated change of the stimulation signals and new stimuli, are generated on this basis; par. [0050]: the new generation can be implemented in various ways. For example, specific numerical parameters are adjusted in the existing test harness) and
apply the modified second portion of the signals for the second set of moments in time (e.g., Wiechowski, Fig. 1 and associated text, par. [0025]: the signals are generated again and sent back to the execution platform)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the application of a portion of received recorded signals to respective ones of the vECUs via virtual hooks at a first moment in time during testing and received sensor outputs from vECUs taught by Maeda/Phatak/Matsumura/Kislovskiy such that a second portion of test of the signals corresponding to a second set of moments in time are modified based on the received outputs and applied for the second set of moments in time, as taught by Wiechowski, as Wiechowski would provide the advantage of a means of generating test signals that are similar to those that actually arise in the real world and a means of achieving the highest level of automation early in the development process. (See Wiechowski, pars. [0006], [0008]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Phatak (US 2018/0060456) in view of Matsumura (US 2012/0011097) in further view of Kislovskiy (US 2018/0341571) and Hwang, “Unit Testing Non Deterministic Code” (art of record – hereinafter Hwang).
As to claim 4, Maeda/Phatak/Matsumura discloses the system of claim 1 (see rejection of claim 1 above), but Maeda does not explicitly disclose wherein the one or more computing devices are further configured to: record a response of the software application during performance of the test plan; perform the test plan multiple times using the same received recorded signals, wherein the software application is non-determinists, wherein performance of the test plan multiple times indicates a range of performance levels for the non-deterministic software application, and wherein a threshold range for certification for the non-deterministic software application is based on the range of performance levels.
However, in an analogous art, Phatak discloses:
wherein the one or more computing devices are further configured to:
record a response of the software application during performance of the test plan; (e.g., Phatak, Fig. 15 and associated text, par. [0123]: to test that the motor controllers 1426 [application] respond as intended to external control signals, and output control signals as intended [the response and outputs are recorded in the sense that they are inherently stored in a computer]; par. [0126]: one example of the output of the co-simulation 1400 may be a graph showing motor speed control output).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing of Maeda to include record a response of the software application during performance of the test plan, as taught by Phatak, as Phatak would provide the advantage of a means of determining whether the application responds as intended. (See Phatak, par. [0123]).
Further, in an analogous Kislovskiy discloses to:
perform the test plan multiple times using the same received recorded signals (e.g., Kislovskiy, par. [0138]: the AV software version may be run through the precertification simulations again in steps (905) through (930); par. [0136]: the system can execute a fill forward simulation using real-world log data; par. [0138]: after running a through a series simulation tests, the AV management system can determine whether the software version is pre-certified).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the test plan performance of Maeda/Phatak, such that it is performed multiple times using the same recorded signals, as taught by Kislovskiy, as Kislovskiy would provide the advantage of a means of ensuring the application performs as desired. (See Kislovskiy, par. [0138]).
Further, in an analogous art, Hwang discloses to:
perform the received test plan multiple times, wherein the software application is non-determinist, wherein performance of the test plan multiple times indicates a range of performance levels for the non-deterministic software application, and wherein a threshold range for certification for the non-deterministic software application is based on the range of performance levels (e.g., Hwang, p. 4 par. 3: if the code has any real purpose, there must be a way to describe characteristics of the result. These may be in terms of ranges of acceptable values and distribution within the range. This may require the test code [test plan, or comprising one] run multiple passes thorough the code to collect a variety of samples. A simple check for normal distribution might use five result ranges. You might decide the high and low ranges should have 0 results, the 2nd and 4th ranges should fall within 10% of each other, and the middle ranges should have more hits than either the 2nd or 4th ranges).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the performance of a test plan multiple times using the same recorded signals of Maeda/Phatak/Matsumura/Kislovskiy such that the test plan is performed multiple times, wherein the software application is non-determinists, wherein performance of the test plan multiple times indicates a range of performance levels for the non-deterministic software application, and wherein a threshold range for certification for the non-deterministic software application is based on the range of performance levels, as taught by Hwang, as Hwang would provide the advantage of a means of successfully testing the non-deterministic code. (See Hwang, p. 1 line 1, p. 4 pars. 3-4).
Claim 5, 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097).
As to claim 5, Maeda discloses a method, comprising:
determining, based on the information, respective configurations for one or more virtual electronic control units (vECUs) to be used to simulate one or more respective ones of the ECUs of the information; (e.g., Maeda, par. [0185], information for simulating various ECUs stored by the ECU information storing unit 531 [database] may include, information to the processor and memory inside each ECU, information related to the CAN controller inside each ECU; par. [0116]: the information includes the most recent firmware being used by the various ECUs; par. [0116]: unit 530 references the ECU information storing unit 531 to construct an operating environment that simulates ECUs of the same type; par. [0223]: in simulator 800, each ECU is simulated by a single virtual machine. Multiple virtual machines 805 “(equal to the number of ECUs constituting the operating environment)” may be generated).
providing one or more vECUs having the determined respective configurations (e.g., Maeda, par. [0223]: in the simulator 800, a single ECU is simulated by a single virtual machine. For example, multiple virtual machines 805 (equal to the number of ECUs constituting the operating environment) may be generated; par. [0185]: unit 530a sets information about each ECU that should be used in the simulator 800, on the basis of information for simulating ECUs stored in the ECU information storing unit 531) for use in certifying a software application to be implemented at the given vehicle, (e.g., Maeda, par. [0047] executing a simulation of operation of the updated firmware [firmware being a type of software]. Operation verification is performed by the execution of the simulation; par. [0056]: updating firmware installed in each ECU on board a vehicle to a new, updated firmware) wherein the provided one or more vECUs are implemented on one or more virtual compute instances that are configured based on the determined respective configurations for the one or more vECUs (e.g., Maeda, par. [0185], information for simulating various ECUs stored by the ECU information storing unit 531 may include, information to the processor and memory inside each ECU, information related to the CAN controller inside each ECU, information regarding the bus connected to each ECU or a communication link used by each ECU; par. [0116]: unit 530 references the ECU information storing unit 531 to construct an operating environment that simulates ECUs of the same type; par. [0223]: in simulator 800, each ECU is simulated by a single virtual machine. Multiple virtual machines 805 “(equal to the number of ECUs constituting the operating environment)” may be generated).
Phatak does not explicitly disclose receiving or accessing a vehicle deployment graph of a given vehicle, wherein the vehicle deployment graph comprises respective configurations of electronic control units (ECUs) of the given vehicle and a connectivity configuration of the ECUs of the given vehicle and wherein the vehicle deployment graph comprises nodes representing the ECUs and one or more edges representing one or more communication links between the ECUs; or the vehicle deployment graph.
Further, in an analogous art, Matsumura discloses:
receiving or accessing a vehicle deployment graph of a given vehicle, wherein the vehicle deployment graph comprises respective configurations of electronic control units (ECUs) of the given vehicle and a connectivity configuration of the ECUs of the given vehicle and wherein the vehicle deployment graph comprises nodes representing the ECUs and one or more edges representing one or more communication links between the ECUs (e.g., Matsumura, Fig. 13 and associated text, par. [0125]: a discussion is made on assignments to an in-vehicle communication bus (BUS) of an in-vehicle software component (SWC). FIG. 13 is a diagram illustrating an example graph model 80 according to this embodiment; par. [0126]: the graph model 80 is a graph-structured system model including SWCs, BUSes and ECUs installed [deployed] in a vehicle. SWCs are connected to ECU blocks which represent ECUs and BUS1, Bus2,…are connected to ECUs [see figure, the graph includes blocks (nodes) representing ECUs and the lines (edges) connecting ECUs via BUS blocks])
information in the form of the vehicle deployment graph (see immediately above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and information of Maeda by incorporating receiving or accessing a vehicle deployment graph of the given vehicle, wherein the vehicle deployment graph comprises respective configurations of one or more electronic control units (ECUs) of the given vehicle and a connectivity configuration of the ECUs of the given vehicle; wherein the vehicle deployment graph comprises nodes representing the ECUs and one or more edges representing one or more communication links between the ECU and such that the information is in the form of the vehicle deployment graph, as taught by Matsumura, as Matsumura would provide the advantage of a mean of proving the information in a standard format. (See Matsumura, pars. [0125-0126], [0004]). Storing information in the form of a graph also provides a means of analyzing relationships that underlie the data, allows certain types of queries to be more easily expressed and permits easier schema changes. (See US 2020/0184026 at par. [0023]).
As to claim 15, Maeda/Matsumura discloses the method of claim 5 (see rejection of claim 5 above), Maeda further discloses further comprising,
deploying the software application to at least one of the provided one or more vECUs via an over-the-air (OTA) service, wherein the OTA service is configured to deploy the software application to the one or more vECUs and the ECUs of the given vehicle (e.g., Maeda, Fig. 1 and associated text, par. [0062]: the server includes a function of delivering, via the network 400 FW update information, which is data for updating the firmware of the ECUs 100a to 100d [of the vehicle, see figure]; par. [0172]: server 500 is configured to include a FW update controlling unit 520a, a FW operation verifying unit 530a; par. [0174]: FW update controlling unit 520a causes firmware operation verifying unit 530a to conduct an operation verification of the firmware update. The FW update controlling unit 520 causes unit 510a to transmit the FW update information to the gateway 300a [i.e., deploy to the vehicle, see figure]; par. [0187]: FW operation verifying unit 530a uses the simulator 800 to simulate an update of setting the updated firmware in the target ECU [i.e., deploying the updated firmware in the target ECU]. With this arrangement, a simulation of the update is executed by the simulator 800 in an operating environment that simulates ECUs of the same type as the ECUs).
As to claim 19, it is a computer-readable medium claim having limitations substantially the same as those of claim 5. It is accordingly rejected for substantially the same reasons.
Further limitations, disclosed by Maeda, include:
one or more non-transitory, computer-readable storage media, storing program instructions that when executed on or across one or more processors cause the one or more processors (e.g., Maeda, par. [0245]: this method may be taken to be a computer program realized by a computer. On espect of the present disclosure may be realized by recording the program on to a medium such as semiconductor memory. One aspect of the present disclosure may be a computer system equipped with a microprocessor and memory in which the memory records the above computer program, and the microprocessor operates according to the computer program) to: (see rejection of claim 5 above).
Claims 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in further view of Watson et al. (US 2020/0310947) (art of record – hereinafter Watson).
As to claim 6, Maeda/Matsumura discloses the method of claim 5 (see rejection of claim 5 above), but Maeda does not explicitly disclose wherein determining the respective configurations for the one or more vECUs comprises: determining respective machine images for the one or more vECUs, wherein the respective machine images emulate respective software environments of the respective ones of the ECUs indicated in the vehicle deployment graph; and determining respective instance types of the one or more virtual compute instances to be used to implement the vECUs.
However, in an analogous art, Matsumura discloses:
the ECUs indicated in the vehicle deployment graph (e.g., Matsumura, Fig. 13 and associated text, par. [0126]: the graph model 80 is a graph-structured system model including SWCs, BUSes and ECUs installed [deployed] in a vehicle).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and information indicating ECUs of a vehicle taught by Maeda such that the ECUs are indicated in a vehicle deployment graph, as taught by Matsumura, as Matsumura would provide the advantage of a mean of proving the information in a standard format. (See Matsumura, pars. [0125-0126], [0004]). Storing information in the form of a graph also provides a means of analyzing relationships that underlie the data, allows certain types of queries to be more easily expressed and permits easier schema changes. (See US 2020/0184026 at par. [0023]).
Further, in an analogous art, Watson discloses:
wherein determining the respective configurations for the one or more vECUs (see below) comprises:
determining respective machine images for the one or more vECUs, wherein the respective machine images emulate respective software environments of the respective ones of the ECUs; (e.g., Watson, par. [0040]: computing resources [ECUs] may be implemented with a general-purpose computer with a processor, memory and interfaces. These hardware components may be virtualized, and the software applications that are otherwise executed on such resources can be executed on the virtualized counterpart; par. [0046]: each virtual machine image 70 includes a hardware abstraction layer that simulates the central processing unit type and so forth of the resource being virtualized; par. [0044]: a virtual machine image is instantiated for each of the network computer resources of the system 18) and
determining respective instance types of the one or more virtual compute instances to be used to implement the vECUs (e.g., Watson, par. [0046]: performance of virtual machines may be set based on configuration options, and this functionality is utilized to instantiate virtual machines that match the performance of the physical counterparts).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ECUs of a deployment graph and determining of vECU configurations of Maeda/Matsumura, to include determining respective machine images for the one or more vECUs, wherein the respective machine images emulate respective software environments of the respective ones of the ECUs and determining respective instance types of the one or more virtual compute instances to be used to implement the vECUs, as taught by Watson, as Watson would provide the advantage of a means of instantiating vECUs that match their physical counterparts as closely as possible. (See Watson, par. [0046]).
As to claim 7, Maeda/Matsumura/Watson discloses the method of claim 6 (see rejection of claim 6 above), and further discloses the ECUs indicated in the vehicle deployment graph (see rejection of claim 5 above) but does not explicitly disclose wherein determining the respective instance types of the one or more virtual compute instances to be used to implement the vECUs comprises: determining the respective instance types based on respective processor types of the one or more ECUs indicated in the vehicle deployment graph; or determining the respective instance types based on the respective machine images determined to be used for the one or more vECUs.
However, in an analogous art, Watson discloses:
wherein determining the respective instance types of the one or more virtual compute instances to be used to implement the vECUs comprises:
determining the respective instance types based on respective processor types of the ECUs (e.g., Watson, par. [0046]: each virtual machine image 70 includes a hardware abstraction layer that simulates the central processing unit type and so forth of the resource being virtualized; ar. [0044]: a virtual machine image is instantiated for each of the network computer resources of the system 18) or
determining the respective instance types based on the respective machine images determined to be used for the one or more vECUs.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the determining of vECU configurations of Maeda/Matsumura to include determining the respective instance types of the one or more virtual compute instances to be used to implement the vECUs by determining the respective instance types based on respective processor types of the one or more ECUs indicated in the vehicle deployment graph, as taught by Watson, as Watson would provide the advantage of a means of instantiating vECUs that match their physical counterparts as closely as possible. (See Watson, par. [0046]).
As to claim 8, Maeda/Matsumura/Watson discloses the method of claim 6 (see rejection of claim 6 above), and further discloses providing the one or more vECUs, having the determined respective configurations, implemented on the one or more the virtual compute instances and the ECUs indicated in the deployment graph (see rejection of claim 5 above) but Maeda does not explicitly disclose wherein providing the one or more vECUs, having the determined respective configurations, implemented on the one or more the virtual compute instances comprises: provisioning the one or more virtual compute instances of the determined instance types based on the respective processor types of the ECUs; and booting the one or more virtual compute instances using the determined respective machine images.
However, in an analogous art, Watson discloses:
wherein providing comprises:
provisioning the one or more virtual compute instances of the determined instance types based on the respective processor types of the ECUs (e.g., Watson, par. [0046]: each virtual machine image 70 includes a hardware abstraction layer that simulates the central processing unit type and so forth of the resource being virtualized; ar. [0044]: a virtual machine image is instantiated for each of the network computer resources of the system 18) and
booting the one or more virtual compute instances using the determined respective machine images (e.g., Watson, par. [0050]: the supervisor 86 thus instantiates the virtual machines based on the images; par. [0049]: execution of all software on each of the virtual machines [i.e., they have been booted]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ECUs of a deployment graph and providing the one or more vECUs having the determined respective configurations implemented on the one or more the virtual compute instances of Maeda/Matsumura, to include provisioning the one or more virtual compute instances of the determined instance types based on the respective processor types of the ECUs and booting the one or more virtual compute instances using the determined respective machine images, as taught by Watson, as Watson would provide the advantage of a means of instantiating vECUs that match their physical counterparts as closely as possible. (See Watson, par. [0046]).
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in view of Watson (US 2020/0310947) in further view of Michelsen et al. (US 2016/0140022) (art of record – hereinafter Michelsen).
As to claim 9, Maeda/Matsumura/Watson discloses the method of claim 6 (see rejection of claim 6 above), but Maeda/Matsumura does not explicitly disclose wherein determining the respective machine images for the one or more vECUs comprises: selecting the respective machine images from a machine image catalog comprising machine images for ECUs used in a plurality of types of vehicles.
However, in an analogous art, Watson discloses:
machine images for the one or more vECUs (e.g., Watson, par. [0044]: vehicle-embedded system such as IFEC system 18, includes a plurality of networked computing resources. Virtualization system 68 may include a plurality of virtual machine images 70; par. [0046] each virtual machine image 70 includes a hardware abstraction layer that simulates the central processing unit type and so forth of the corresponding networked computing resource being virtualized; par. [0040]: these computing resources may be implemented with a general-purpose computer) and
machine images for ECUs used in a plurality of types of vehicles (e.g., Watson, par. [0022]: the virtualization of complex embedded systems may be applicable to other contexts, such as busses, trains, ships and other types of vehicles; par. 0039: different configurations of the IFEC system 18 installed in other aircraft may also be virtualized)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ECUs and vECUs of Maeda/Matsumura, to include machine images for the one or more vECUs for ECUs used in a plurality of types of vehicles, as taught by Watson, as Watson would provide the advantage of a means of expeditiously virtualizing the system. (See Watson, par. [0039]). Watson would also provide a means to instantiate virtual machines, as suggested by Maeda. (See Maeda, par. [0223], Watson, par. [0013]).
Further, in an analogous art, Michelsen discloses:
wherein determining the respective machine images comprises:
selecting the respective machine images from a machine image catalog comprising machine images (e.g., Michelsen, par. [0034]: test manager 210 can identify, from a catalog, a set of images needed for a particular virtual test lab; par. [0045]: virtual machine images).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the machine images for the one or more vECUs for ECUs used in a plurality of types of vehicles of Maeda/Matsumura/Watson to include, determining the respective machine images by selecting the respective machine images from a machine image catalog comprising machine images, as taught by Michelsen, as Michelsen would provide the advantage of a means of virtualizing the resources needed for the test and doing away with the need for additional physical resources. (See Michelsen, par. [0028]). Maintaining a catalog of pre-existing image would also avoid the need to create a new image every time testing is performed.
As to claim 10, Maeda/Matsumura/Watson discloses the method of claim 6 (see rejection of claim 6 above), but Maeda does not explicitly disclose further comprising: receiving ECU information for an ECU from a vehicle manufacturer or a vehicle parts manufacturer; creating a new machine image based on the received ECU information; and adding the new machine image to the machine image catalog.
However, in an analogous art, Watson discloses further comprising:
receiving ECU information for an ECU from a vehicle manufacturer or a vehicle parts manufacturer; (e.g., Watson, par. [0013]: receiving simulated hardware component definitions corresponding to physical hardware components of the plurality of network resources; par. [0044]: vehicle-embedded system such as IFEC system 18, includes a plurality of networked computing resources; par. [0040]: these computing resources may be implemented with a general-purpose computer [i.e., the resources are ECUs. Since the ECUs are part of a vehicle and necessarily manufactured, the ECUs are from a vehicle parts manufacturer]).
creating a new machine image based on the received ECU information; (e.g., Watson, par. [0013]: the virtual images may each include a hardware abstraction layer based upon the simulated hardware component definitions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Maeda/Matsumura to include receiving ECU information for an ECU from a vehicle manufacturer or a vehicle parts manufacturer and creating a new machine image based on the received ECU information, as taught by Watson, as Watson, would provide the advantage of a means of providing an image that simulates the characteristics of the particular ECU being virtualized. (See Watson, par. [0046]).
Further, in an analogous art, Michelsen discloses:
adding the new machine image to the machine image catalog (e.g., Michelsen, par. [0028]: additional virtual machine images can be added to the catalog).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the creation of a new machine image based the received ECU information of Maeda/Matsumura/Watson, to include adding the new machine image to the machine image catalog, as taught by Michelsen, as Michelsen would provide the advantage of a means of extending the scope of the system and potentially doping away with the need for additional physical hardware. (See Michelsen, par. [0028]).
Claims 11-13 are rejected under 35 U.S.C. 103 as being unpatentable over as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in further view of Phatak (US 2018/0060456) and Watson (US 2020/0310947)
As to claim 11, Maeda/Matsumura discloses the method of claim 5 (see rejection of claim 5 above), Maeda further discloses further comprising:
determining the virtual bus connectivity configuration for the vECUs based on the connectivity configuration of the ECUs indicated in the information; (e.g., Maeda, par. [0185]: information for simulating various ECUs stored by the information storing unit 531 may include information regarding the bus connected to each ECU or a communication link used by each ECU; par. [0116]: unit 530 references the ECU information storing unit 531 to construct an operating environment that simulates ECUs of the same type; par. [0213]: software running on the simulator includes a virtual machine monitor 801; par. [0223]: virtual machine monitor 801 may be configured to simulate the bus-mediated communication between ECUs).
Maeda does not explicitly disclose the vehicle deployment graph or configuring the provided vECUs in a network configuration that implements the determined virtual bus connectivity configuration in a virtual private cloud.
However, in an analogous art, Matsumura discloses:
information in the form of the vehicle deployment graph (e.g., Matsumura, Fig. 13 and associated text, par. [0126]: the graph model 80 is a graph-structured system model including SWCs, BUSes and ECUs installed [deployed] in a vehicle).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and information indicating ECUs of a vehicle taught by Maeda such that the ECUs are indicated in a vehicle deployment graph, as taught by Matsumura, as Matsumura would provide the advantage of a mean of proving the information in a standard format. (See Matsumura, pars. [0125-0126], [0004]). Storing information in the form of a graph also provides a means of analyzing relationships that underlie the data, allows certain types of queries to be more easily expressed and permits easier schema changes. (See US 2020/0184026 at par. [0023]).
Further, in an analogous art, Phatak discloses
configuring the provided vECUs in a network configuration that implements the determined virtual bus connectivity configuration in a cloud (e.g., Phatak, Fig. 16 and associated text, par. [0059]: virtual machines 110. The CAN router may provide a virtual CAN bus between multiple simulators, such as multiple vECUs, by enabling communication between the virtual machines 110; par. [0040]: the simulation may be implemented in using virtual machines configured on network computing resources “(sometimes referred to as cloud computing resources)”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the vECUs in network configuration implementing determined virtual bus connectivity taught by Maeda such that the network configuration is in a cloud, as taught by Phatak, as Phatak would provide the advantage of a means of expanding the simulation platform to virtually any desired scale. (See Phatak, par. [0040]).
Further, in an analogous art, Watson discloses:
a virtual private cloud (e.g., Watson, par. [0011]: virtual machines comprising the virtual private cloud).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cloud of Maeda/Matsumura/Phatak such that is a virtual private cloud, as taught by Watson, as Watson would provide the advantage of a means of isolating the cloud from public users.
As to claim 12, Maeda/Matsumura/Phatak/Watson discloses the method of claim 11 (see rejection of claim 11 above) but Maeda does not explicitly disclose wherein configuring the provided vECUs according to the virtual bus connectivity configuration comprises: providing respective network addresses to the vECUs implemented on the virtual private cloud; configuring simulated vehicle bus interfaces for the respective vECUs to send and receive messages via the virtual private cloud, using the provided network addresses, to simulate in-vehicle bus traffic
However, in an analogous art, Phatak further discloses:
wherein configuring the provided vECUs according to the virtual bus connectivity configuration comprises:
providing respective network addresses to the vECUs implemented on the cloud; (e.g., Phatak, par. [0001]: Controller Area Network “(CAN)”; par. [0124]: each of the vECUs may execute on a separate virtual machine; par. [0040]: virtual machines configured on network computing resources “(sometimes referred to as cloud computing resources)”; par. [0125]: the emulator 1408 may be a simulator configured to emulate the vehicle-level CAN traffic of a plurality of ECUs. Each vECU on the virtual can bus 1412 can be assigned a CAN ID [network address] that is unique; par. [0126]: the virtual CAN router may propagate this communication to vECUs 1402 and 1404 using their respective CAN IDs) and
configuring simulated vehicle bus interfaces for the respective vECUs to send and receive messages via the cloud, using the provided network addresses, to simulate in-vehicle bus traffic (see immediately above note the interfaces between the vECUs 1402, 1404, virtual machines 110 and virtual can BUS 1412 in the figure).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the vECUs provided according to the virtual bus connectivity taught by Maeda such that respective network addresses are provided to the vECUs implemented on the cloud; and simulated vehicle bus interfaces are configured for the respective vECUs to send and receive messages via the cloud, using the provided network addresses, to simulate in-vehicle bus traffic, as taught by Phatak, as Phatak would provide the advantages of a means of emulating the vehicle-level traffic of the ECU and a means of expanding the simulation platform to virtually any desired scale. (See Phatak, pars. [0125], [0040]).
Further, in an analogous art, Watson discloses:
a private network; (e.g., Watson, par. [0011]: virtual machines comprising the virtual private cloud [a cloud being a network]) and
a virtual private cloud (e.g., Watson, par. [0011]: virtual machines comprising the virtual private cloud).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cloud network of Maeda/Matsumura/Phatak such that the cloud is a virtual private cloud, as taught by Watson, as Watson would provide the advantage of a means of isolating the cloud from public users.
As to claim 13, the features of this claim are a subset of those of claim 1 and are rejected for substantially the same reasons set forth with respect to that claim above.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in view of Phatak (US 2018/0060456) in view of Watson (US 2020/0310947) in further view of Kislovskiy (US 2018/0341571).
As to claim 14, Phatak/Kozul/Maeda/Watson discloses the method of claim 13 (see rejection of claim 13 above) but does not explicitly disclose further comprising performing a second test plan to certify the software application for use in the given vehicle, wherein the second test plan is performed on a real-world vehicle.
However, in an analogous art, Kislovskiy discloses further comprising:
performing a second test plan to certify the software application for use in the given vehicle, wherein the second test plan is performed on a real-world vehicle (e.g., Kislovskiy, abstract: safety-driven autonomous vehicles “(SDAVs)”. Fully autonomous vehicles “(FAVs)”; par. [061]: when the simulation results 262 indicate that the new software version 252 is pre-certified, the engine 220 can label the new version 252 as being certified for distribution to the SDAVs 281 and/or FAVs 289 for real-world testing and safety verification [i.e., performing a second test plan]. Engine 220 can distribute the new software version 252 to the SDAVs 2871 and/or FAVs 289, which can execute the new software version 252).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the performing a test plan of Maeda/Matsumura/Phatak/Watson, to include performing a second test plan to certify the software application for use in the given vehicle, wherein the second test plan is performed on a real-world vehicle, as taught by Kislovskiy, as Kislovskiy would provide the advantage of a means of performing real-world testing and safety verification. (See Kislovskiy, par. [0061]).
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in further view of Phatak (US 2018/0060456) Kislovskiy (US 2018/0341571) and Wiechowski (US 20118/0101472)
As to claim 16, it is a method claim combining a subset of limitations of claim 1 with the limitations claim 2. Those limitations are taught by or obvious in view of the prior art for reasons substantially as those set forth above with respect to those claims.
As to claim 17, Maeda/Matsumura/Phatak/Kislovskiy/Wiechowski discloses the method of claim 16 (see rejection of claim 16 above), but Maeda/Matsumura does not explicitly disclose wherein the performing the received test plan comprises: performing the received test plan, wherein the performing comprises: modifying the recorded signals of the one or more ECUs based on downstream changes from the software application.
However, in an analogous art, Kislovskiy discloses:
the recorded signals of the one or more ECUs (e.g., Kislovskiy, Fig. 5 and associated text, par. [0112]: the control system 520 [ECU] can transmit log data 527 to transport management system 590. The log data 527 can include sensor data stream 515, and data corresponding to control inputs made by the control system).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing ECUs in a simulation environment utilizing taught by Maeda, by incorporating recorded signals of the one or more ECUs, as taught by Kislovskiy, as Kislovskiy would provide the advantage of a means to perform the simulation using real-world data. (See Kislovskiy, par. [0136]).
Further, in an analogous art, Wiechowski discloses:
wherein the performing the received test plan comprises: performing the received test plan, (e.g., Wiechowski, par. [0006]: executing a test case) wherein the performing comprises:
modifying the recorded signals based on downstream changes from the software application (e.g., Wiechowski, par. [0002]: to test the respective software applications, signals should be defined to execute the software application and evaluate the output values generated; par. [0011]: the output values generated up to the respective point in time by the test platform are taken into account in the automated change of the stimulation signals and new stimuli, are generated on this basis; par. [0050]: the new generation can be implemented in various ways. For example, specific numerical parameters are adjusted in the existing test harness; par. [0050]: as a result of the dynamic adaptability of the test, the test process can turn out quite differently, depending on the reaction of the program to be tested).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the recorded signals of the ECUs used in testing taught by Maeda/Matsumura/Phatak/Kislovskiy such that the signals are modified based on downstream changes from the application being tested, as taught by Wiechowski, as Wiechowski would provide the advantage of a means of generating test signals that are similar to those that actually arise in the real world and achieving the highest level of automation early in the development process. (See Wiechowski, pars. [0006], [0008]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in further view of Phatak (US 2018/0060456) Kislovskiy (US 2018/0341571) and Wiechowski (US 20118/0101472) in further view of Hwang (“Unit Testing Non Deterministic Code”).
As to claim 18, Maeda/Matsumura/Phatak/Kislovskiy/Wiechowski discloses the method of claim 16 (see rejection of claim 16 above), but Maeda does not explicitly disclose further comprising: recording the response of the software application; performing the received test plan to certify the software application for use in the given vehicle, wherein the received test plan is performed using the provided computing resources configured as the vECUs configured in the virtual bus configuration multiple times using the same recorded signals, wherein the software application is non-deterministic.
However, in an analogous art, Phatak discloses further comprising:
recording the response of the software application; (e.g., Phatak, Fig. 15 and associated text, par. [0123]: to test that the motor controllers 1426 [application] respond as intended to external control signals, and output control signals as intended [the response and outputs are recorded in the sense that they are inherently stored in a computer]; par. [0126]: one example of the output of the co-simulation 1400 may be a graph showing motor speed control output) and
performing the received test plan to certify the software application for use in the given vehicle, wherein the received test plan is performed using the provided computing resources configured as the vECUs configured in the virtual bus configuration (e.g., Phatak, par. [0057]: a vECU may be a processor simulator. A user may provide software, such as control software that is to be installed on the real ECU, execute the software on the vECU to determine whether the control software performs as intended; par. [0134]: simulators may execute on the virtual machines; par. [0059]: the CAN router may provide a virtual CAN bus between multiple simulators, such as multiple vECUs, by enabling communication between the virtual machines 110 par. [0092]: the user may provide parameter sweep information, and the simulation platform may execute the simulation with the indicated parameters; par. [0167]: the simulation platform may perform a sweep of more than one parameter in each model).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing of a software application set in vECUs taught by Maeda to include recording the response of the software application; and performing the received test plan to certify the software application for use in the given vehicle, wherein the received test plan is performed using the provided computing resources configured as the vECUs configured in the virtual bus configuration, as taught by Phatak, as Phatak would provide the advantages of a means of testing the simulated system with different sets of parameters and a means of determining whether the application responds as intended. (See Phatak, pars. [0036], [0123]).
Further, in an analogous art, Kislovskiy discloses
wherein the test plan is performed multiple times using the same recorded signals (e.g., Kislovskiy, par. [0138]: the AV software version may be run through the precertification simulations again in steps (905) through (930); par. [0136]: the system can execute a fill forward simulation using real-world log data; par. [0138]: after running a through a series simulation tests, the AV management system can determine whether the software version is pre-certified).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the received test plan performance of Maeda/Matsumura, such that the test plan is performed multiple times using the same recorded signals, as taught by Kislovskiy, as Kislovskiy would provide the advantage of a means of ensuring the application performs as desired. (See Kislovskiy, par. [0138]).
Further, in an analogous art, Hwang discloses:
wherein the software application is non-deterministic (e.g., Hwang, p. 1 line 1: to UnitTest code that is non-deterministic).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software application taught by Phatak/Kislovskiy, such that it is non-deterministic, as taught by Hwang, as Hwang would provide the advantage of a means of testing non-deterministic code. (See Hwang, p. 1 line 1).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Maeda (US 2018/0152341) in view of Matsumura (US 2012/0011097) in further view of Phatak (US 2018/0060456).
As to claim 20, Maeda/Matsumura discloses the one or more non-transitory, computer-readable storage media of claim 19 (see rejection of claim 19 above), Maeda further discloses:
wherein the program instructions that when executed cause the one or more processors (e.g., Maeda, par. [0245]) to:
receive the software application to be certified; (e.g., Maeda, par. [01769]: registration of updated firmware [software application to be certified, see above])
cause the software application to be deployed to at least one of the provided vECUs; (e.g., Maeda, par. [0187]: unit 530a uses the simulator 800 to simulate an update of setting the updated firmware in the target ECU and simulate the operation of each ECU adter updating; par. [0194]: every time on piece of updated firmware is set in one ECU in the simulator 800, unit 530a verifies whether the ECU operates correctly).
the at least one provided vECU having a respective one of the determined configurations, and being included in the network configuration implementing the determined virtual bus connectivity configuration (e.g., Maeda, par. [0185]: the information for simulating various ECUs stored by the ECU information storing unit 531 may include information regarding the bus connected to each ECU; par. [0185]: the FW operation verifying unit 530a sets information about each ECU that should be used in the operation verification in the simulator 800, on the basis of information stored in the ECU information storing unit 531; par. [0223]: the virtual machine monitor may be configured to simulate the bus-mediated communication between ECUs by communicating between the multiple virtual hardware configurations running on the virtual machine monitor 801; par. [0224]: virtual machines in the simulator 800 to perform the same operations as each of the ECUs).
Maeda does not explicitly disclose: to receive a test plan for certifying the software application for use in the given vehicle; and to certify the software application based on performance of the received test plan on the at least one of the provided vECUs.
However, in an analogous art, Phatak discloses:
receive a test plan for certifying the software application for use in the given vehicle; (e.g., Phatak par. [0092]: the user may provide parameter sweep information, and the simulation platform may execute the simulation with the indicated parameters)
certify the software application based on performance of the received test plan on the at least one of the provided vECUs (e.g., Phatak, par. [0057]: a vECU may be a processor simulator. A user may provide software, such as control software that is to be installed on the real ECU, execute the software on the vECU to determine whether the control software performs as intended; par. [0134]: simulators may execute on the virtual machines; par. [0059]: the CAN router may provide a virtual CAN bus between multiple simulators, such as multiple vECUs, by enabling communication between the virtual machines 110 par. [0092]: the user may provide parameter sweep information, and the simulation platform may execute the simulation with the indicated parameters; par. [0167]: the simulation platform may perform a sweep of more than one parameter in each model).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the vehicle software test environment management system verifying software using vECUs and a virtual bus configuration taught by Maeda, to include receiving a test plan for certifying the software application for use in the given vehicle; certifying the software application based on performance of the received test plan on the at least one of the provided vECUs, as taught by Phatak, as Phatak would provide a means of testing the system with different sets of parameters. (See Phatak, par., [0036]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
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, Hyung S Sough can be reached at (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 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
Prosecution Insights