DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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.
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 05/22/2026 has been entered. An action on the RCE follows.
Status of the application
This Office Action is in response to Applicant's amendment filed on 05/22/2026. Claims 1-20 are pending for this examination.
Claim Interpretation
Claims use the term “test bench”. The specification recites in [0068] starting at line 2, “In general, a test bench in software testing may refer to information or parameters, such as a set of procedures, a collection of test scenarios, or the like, which provide a simulation or configuration of required testing inputs.” In other words, a test bench is simply a set of test procedures (and required parameters and test environment) for testing a piece of software.
Response to Amendment/Arguments
Applicants' arguments have been carefully and respectfully considered. Arguments are moot in light of the new ground of rejection, which relies upon prior art made of record Solmaz et al (hereinafter Solmaz, “A Novel Testbench for Development, Calibration and Functional Testing of ADAS/AD Functions”, 2019, IEEE) and Nilsson et al. (hereinafter Nilsson, Pub. No.: US 2024/0171423). Accordingly, this action has been made non-final.
At this time examiner does not have any suggestion on probable amendments for advancing prosecution. However, applicant is welcome to set up an examiner interview to discuss further 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.
Claims 1 and 11 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi (Pub. No.: US 2025/0390420) in view of Nilsson et al. (hereinafter Nilsson, Pub. No.: US 2024/0171423) in view of Pirog et al. (hereinafter Pirog, Pub. No.: US 2020/0183337) and Solmaz et al. (hereinafter Solmaz, “A Novel Testbench for Development, Calibration and Functional Testing of ADAS/AD Functions”, 2019, IEEE).
As of claim 1, (Currently amended) Wakabayashi teaches,
A method, implemented by at least one processor, for facilitating provisioning of a cross-domain test for testing software of an embedded system, the method comprising:
detecting a change in the software, or that a condition has been satisfied,
wherein the condition is satisfied based on at least one of a degradation of performance (Wakabayashi recites in [0008] “In a software analysis system according to the invention, when a performance degradation of second software is detected by a performance test, a version updated by merging first software is specified or a version where reference information of the first software is changed from that before is specified among past versions of the second software, thereby specifying a candidate in the first software which is a cause of the degradation.” This shows that a change in the software detected when software test showed performance degradation.)
Wakabayashi teaches software analysis and testing of an ECU. Wakabayashi does not explicitly teach, “wherein the condition is satisfied based on at least one of a degradation of performance or whether a predetermined test execution schedule is reached;”. However, in analogous art of software testing, Nilsson teaches,
[wherein the condition is satisfied based on at least one of a degradation of
performance] or whether a predetermined test execution schedule is reached; (Nilsson recites in [0046] starting at line 7, “The fault injection interface 155 may be actively used for discrete periods of a simulation or a software test, e.g., in accordance with an operator's desire or with a pre-specified test schedule.” This shows software test is performed at a pre-determined test schedule.)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi
of ECU testing by incorporating the teaching “wherein the condition is satisfied based on at least one of a degradation of performance or whether a predetermined test execution schedule is reached;” of Nilsson. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function running a test at a pre-determined scheduled time to keep checking quality of an ECU software.
Wakabayashi and Nilsson teach software analysis and testing of an ECU. They do not explicitly teach, “obtaining a test configuration file associated with the software; obtaining, based on the test configuration file, a test bench;”. However, in analogous art of software testing, Pirog teaches,
obtaining a test configuration file associated with the software; (Pirog Fig. 3 Box 312 shows test configuration files.)
obtaining, based on the test configuration file, a test bench; (Pirog recites in [0005] starting at line 4, “Testing is performed using a test platform. The test platform is an apparatus that interconnects with the environmental control system, or components thereof, during testing. The test platform includes a computing device for executing test software that, under the control of a human operator, can be made to run various test procedures, each simulating a usage scenario, and to record system response for verifying proper system functionality.” This is the test bench.)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi and Nilsson of ECU testing by incorporating the teaching “obtaining a test configuration file associated with the software; obtaining, based on the test configuration file, a test bench;” of Pirog. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function obtaining a test configuration file and configuring a test bench according to the configuration before performing appropriate testing.
Wakabayashi, Nilsson and Pirog teach software testing for an ECU. They do not teach “determining a plurality of test environments associated with the test bench; and performing the cross-domain test based on the plurality of test environments, wherein the software of the embedded system is within an in-vehicle electronic control unit (ECU), and wherein the plurality of tests environments comprises at least one software-in-the-loop (SIL) test environment at least one hardware-in-the-loop (HIL) test environment.” However, in analogous art of software testing, Solmaz teaches,
determining a plurality of test environments associated with the test bench; and (Solmaz recites on page 1, column 2, starting at line 1, “To address this problem, novel testing paradigms that combine virtual and real testing in various ways have been
proposed in the last decade. In the automotive domain, real-time hardware-in-the-loop (HIL) simulation is quite commonly studied and employed for engine development [3], electronic control-unit (ECU) development [4], [5] as well as for the development and testing of electric vehicle components [6]. An extension of the HIL-simulation technique for the specific implementation on a complete automotive vehicle was named as vehicle-in-the-loop (VEHIL) simulation in the seminal work by TNO [7] and was suggested for longitudinal and lateral control system development as a testing concept in [8].” This shows a plurality of test environments.)
performing the cross-domain test based on the plurality of test environments, (Solmaz page 43 section IV titles “Cross Domain Integration”. This recites “For testing ADAS/AD functions on a test bench, components of the vehicle-testbed unit that are not available have to be integrated virtually via simulation or recorder. From the integration point of view, the framework is a multi-tool, multi-vendor application, with different communication media, interfaces and platforms.” This shows cross-domain testing.)
wherein the software of the embedded system is within an in-vehicle electronic control unit (ECU), and (Solmaz recites on page 1, column2, starting at line 1, “To address this problem, novel testing paradigms that combine virtual and real testing in various ways have been proposed in the last decade. In the automotive domain, real-time hardware-in-the-loop (HIL) simulation is quite commonly studied and employed for engine development [3], electronic control-unit (ECU) development [4], [5] as well as for the development and testing of electric vehicle components [6].) This shows ECU.)
wherein the plurality of tests environments comprises at least one software-in-the-loop (SIL) test environment at least one hardware-in-the-loop (HIL) test environment. (Solmaz recites on page 1, column 2, starting at line 1, “To address this problem, novel testing paradigms that combine virtual and real testing in various ways have been proposed in the last decade. In the automotive domain, real-time hardware-in-the-loop (HIL) simulation is quite commonly studied and employed for engine development [3], electronic control-unit (ECU) development [4], [5] as well as for the development and testing of electric vehicle components [6]. An extension of the HIL-simulation technique for the specific implementation on a complete automotive vehicle was named as vehicle-in-the-loop (VEHIL) simulation in the seminal work by TNO [7] and was suggested for longitudinal and lateral control system development as a testing concept in [8].” This shows HIL testing. It also mentions simulation. Simulation of vehicle-in-the-loop is a mentioned where simulation is a software. As such the test environments include HIL and SIL.)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson and Pirog of ECU testing by incorporating the teaching “determining a plurality of test environments associated with the test bench; and performing the cross-domain test based on the plurality of test environments, wherein the software of the embedded system is within an in-vehicle electronic control unit (ECU), and wherein the plurality of tests environments comprises at least one software-in-the-loop (SIL) test environment at least one hardware-in-the-loop (HIL) test environment.” of Solmaz. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of performing various tests for testing ECUs of different functionality and also performing cross-domain testing to ensure that different ECU performing different functions work together.
As per claim 11, this is a systems claim that substantially parallels the limitations of the method claim 1. It would have been obvious to one of ordinary skill in the art before the time of the effective filing date of the invention to implement the prescribed method steps as a system.
Claims 2 and 12 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi, Nilsson, Pirog and Solmaz as applied to claims 1 and 11 in view of Mayhew (Pub. No.: US 2016/0189056).
As of claim 2, (Previously presented) Wakabayashi, Nilsson, Pirog and Solmaz teach ECU testing. They do not explicitly teach, “wherein the change in the software further comprises a breaking change.” However, in analogous art of ECU testing Mayhew teaches,
wherein the change in the software comprises a breaking change. (In light of the specification [0083] “breaking change” means introduction of a bug in code. Mayhew recites in [0025] starting at line 9 “For example, if the anomalous events are traced to a particular ECU, then a warning that the ECU is compromised (either intentionally or due to some flawed firmware upgrade, malfunction, or the like that is causing the ECU to generate glitches). Such a warning may appear on the on-board computer display of the vehicle 40, or may be wirelessly transmitted to a centralized location (e.g. a monitoring center of the automobile manufacturer, who uses the information to monitor firmware upgrades) or so forth.” This shows that firmware upgrade includes some flaw.)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog and Solmaz of ECU testing by incorporating the teaching “wherein the change in the software comprises a breaking change” of Mayhew. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of handling an error in updated software. As such, a user must identify the error in the updated code.
As per claim 12, this is a system claim that substantially parallels the limitations of the method claim 2. It would have been obvious to one of ordinary skill in the art before the time of the invention to implement the prescribed method steps as a system.
Claims 3 and 13 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi, Nilsson, Pirog and Solmaz as applied to claims 1 and 11 in view of Kwak (Pub. No.: US 2023/0161931).
As of claim 3, (Original) Wakabayashi, Nilsson, Pirog and Solmaz teach ECU testing. They do not explicitly teach “wherein the test configuration file comprises information of a plurality of ECUs associated with the software and information of a test environment associated with each of the plurality of ECUs.” However, in analogous art of ECU testing Kwak teaches,
wherein the test configuration file comprises information of a plurality of ECUs associated with the software and information of a test environment associated with each of the plurality of ECUs. (Kwak recites in [0089] “Referring to FIG. 3, the HILS module 110 according to the exemplary embodiment may be configured to include plurality of ECUs 117 (117a, 117b, 117c, 117d, 117e, and 117f) and the SILS software 125 may be configured to include a plurality of virtual ECUs 127 (127a, 127b, 127c, 127d, 127e, and 127f. In the following description, the HILS module 110 and the SILS software 125 will be illustrated as having the above configuration. However, the number of ECUs 117 included in the HILS module 110 and the number of virtual ECUs 127 included in the SILS software 125 may be variously provided according to embodiments.”)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog and Solmaz of ECU testing by incorporating the teaching “wherein the test configuration file comprises information of a plurality of ECUs associated with the software and information of a test environment associated with each of the plurality of ECUs.” of Kwak. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of testing multiple ECUs because a vehicle usually has multiple ECUs and perform different functionalities.
As per claim 13, this is a system claim that substantially parallels the limitations of the method claim 3. It would have been obvious to one of ordinary skill in the art before the time of the invention to implement the prescribed method steps as a system.
Claims 4, 6, 7, 14, 16 and 17 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi, Nilsson, Pirog, Solmaz and Kwak as applied to claims 3 and 13 in view of Mesde et al. (hereinafter Mesde, Pub. No.: US 2024/0419429).
As of claim 4, (Previously presented) Wakabayashi, Nilsson, Pirog, Solmaz and Kwak teach ECU testing. They do not explicitly teach “wherein at least a portion of the plurality of ECUs is associated with one or more nodes different from the software of the one or more of the plurality of ECUs under test.” However, in analogous art of ECU testing Mesde teaches,
wherein at least a portion of the plurality of ECUs is associated with one or more nodes different from the software of the one or more of the plurality of ECUs under test. (Mesde recites in [0017] starting at line 7, “For example, because there are numerous software modules for different types of ECUs the edge device may not be able to store all of the possible software modules that may be used. Even if available software modules are limited to those that occur for a single vehicle model,”…)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog, Solmaz and Kwak of ECU testing by incorporating the teaching “wherein at least a portion of the plurality of ECUs is associated with one or more nodes different from the software of the one or more of the plurality of ECUs under test.” of Mesde. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of testing multiple ECUs with various software on it because various ECUs perform different tasks in a vehicle and their software will be different.
As of claim 6, (Original) Wakabayashi, Nilsson, Pirog, Solmaz and Kwak teach ECU testing. They do not explicitly teach “wherein the plurality of ECUs comprises: at least one virtual ECU, at least one emulated ECU, at least one physical ECU, or a combination thereof.” However, in analogous art of ECU testing, Mesde teaches,
wherein the plurality of ECUs comprises: at least one virtual ECU, at least one emulated ECU, at least one physical ECU, or a combination thereof. (Mesde recites in [0002] “FIG. 1 illustrates a vehicle software test environment management system that receives a vehicle deployment graph indicating various electronic control units (ECUs) of a vehicle and indicating a network configuration of the vehicle, wherein the vehicle software test environment management system provides instructions for implementing (or orchestrates the implementation of) virtual electronic control units (vECUs) having a virtual bus connectivity configuration that simulates that of the vehicle, wherein the configured ECUs are used in performing software certification for one or more software applications to be deployed on the vehicle, according to some embodiments.” Mesde recites in [0006] “FIG. 3A illustrates a more detailed view of a vehicle software test environment management system that obtains information regarding available virtual instance types and machine images and determines a virtual instance type and a machine image needed to simulate respective ECUs of the vehicle using respective vECUs, according to some embodiments.”)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog, Solmaz and Kwak of ECU testing by incorporating the teaching “wherein the plurality of ECUs comprises: at least one virtual ECU, at least one emulated ECU, at least one physical ECU, or a combination thereof.” of Mesde. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of testing multiple ECUs with various software on it because various ECUs perform different tasks in a vehicle and their software will be different.
As of claim 7, (Original) Wakabayashi, Nilsson, Pirog, Solmaz and Kwak teach ECU testing. They do not explicitly teach “wherein the plurality of ECUs comprises at least one of: Central ECU (CECU), Instrument Cluster (IC) ECU, In-Vehicle Infotainment (IVI) ECU, and Advanced Driver Assistance Systems (ADAS) ECU.” However, in analogous art of ECU testing, Mesde teaches,
wherein the plurality of ECUs comprises at least one of: Central ECU (CECU), Instrument Cluster (IC) ECU, In-Vehicle Infotainment (IVI) ECU, and Advanced Driver Assistance Systems (ADAS) ECU. (Mesde recites in [0021] starting at line 21, “For example, the edge device may obtain information about a vehicle configuration of a customized ECU of an infotainment system, and based on the customization, determine that a software module for the infotainment system may not be installed.”)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog, Solmaz and Kwak of ECU testing by incorporating the teaching “wherein the plurality of ECUs comprises at least one of: Central ECU (CECU), Instrument Cluster (IC) ECU, In-Vehicle Infotainment (IVI) ECU, and Advanced Driver Assistance Systems (ADAS) ECU.” of Mesde. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of testing multiple ECUs with various software on it because various ECUs perform different tasks in a vehicle and their software will be different.
As per claims 14, 16 and 17, these are system claims that substantially parallel the limitations of the method claim 4, 6 and 7. It would have been obvious to one of ordinary skill in the art before the time of the invention to implement the prescribed method steps as a system.
Claims 5 and 15 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi, Nilsson, Pirog, Solmaz and Kwak as applied to claims 3 and 13 in view of Harel et al. (hereinafter Harel, Pub. No.: US 2023/0275877).
As of claim 5, (Previously presented) Wakabayashi, Nilsson, Pirog, Solmaz and Kwak teach ECU testing. They do not explicitly teach “wherein at least a portion of the plurality of ECUs is distributed across geographical locations different from the software of the one or more of the plurality of ECUs under test.” However, in analogous art of ECU testing Harel teaches,
wherein at least a portion of the plurality of ECUs is distributed across geographical locations different from the software of the one or more of the plurality of ECUs under test. (Harel recites in [0020], “Consistent with the present embodiments, a method for detecting and blocking potential attacks to vehicle ECUs based on a geographically distributed ECU trap network is disclosed.”)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog, Solmaz and Kwak of ECU testing by incorporating the teaching “wherein at least a portion of the plurality of ECUs is distributed across geographical locations different from the software of the one or more of the plurality of ECUs under test.” of Harel. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of testing distributed ECUs because vehicles which contain these ECUs will be located in different locations.
As per claim 15, this is a system claim that substantially parallels the limitations of the method claim 5. It would have been obvious to one of ordinary skill in the art before the time of the invention to implement the prescribed method steps as a system.
Claims 8 and 18 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi, Nilsson, Pirog, Solmaz and Mayhew as applied to claims 2 and 12 in view of Nagamitsu (hereinafter Nagamitsu, Pub. No.: US 2022/0318003) and further in view of Sonalker et al. (hereinafter Sonalker, Pub. No.: US 2016/0188396).
As of claim 8, (Original) Wakabayashi, Nilsson, Pirog and Solmaz and Mayhew teach ECU testing. They do not explicitly teach, “wherein the detecting the change in the software comprises: obtaining, from a node associated with the software, information of a current status of the software; determining, based on the obtained status information, whether or not the software has changed from a previous version;”. However, in analogous art of ECU testing, Nagamitsu teaches,
wherein the detecting the change in the software comprises:
obtaining, from a node associated with the software, information of a current status of the software; (Nagamitsu recites [0012] “In the center according to the first aspect of the present disclosure, the one or more processors may be configured to, when the current version received by the one or more processors contains a defect, distribute update data for eliminating the defect without disabling the update data distribution to the vehicle.” This shows obtaining status of the current version.)
determining, based on the obtained status information, whether or not the software has changed from a previous version; and (Nagamitsu recites [0012] “In the center according to the first aspect of the present disclosure, the one or more processors may be configured to, when the current version received by the one or more processors contains a defect, distribute update data for eliminating the defect without disabling the update data distribution to the vehicle.” Here update data means that software has been changed from previous version.)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog, Solmaz and Mayhew of ECU testing by incorporating the teaching “wherein the detecting the change in the software comprises: obtaining, from a node associated with the software, information of a current status of the software; determining, based on the obtained status information, whether or not the software has changed from a previous version;” of Nagamitsu. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of updating software of an ECU after detecting a later version is available.
Wakabayashi, Nilsson, Pirog, Solmaz, Mayhew and Nagamitsu teach ECU testing. They do not explicitly teach “based on determining that the software has changed, determining whether or not the change is the breaking change.” However, in analogous art of ECU software testing and updating, Sonalker teaches,
based on determining that the software has changed, determining whether or not the change is the breaking change. (Sonalker recites in [0024] starting at line 8 “For example, if the anomalous events are traced to a particular ECU, then a warning that the ECU is compromised (either intentionally or due to some flawed firmware upgrade or the like that is causing the ECU to generate glitches).” This teaches that software change includes breaking change.)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog, Solmaz, Mayhem and Nagamitsu of ECU testing by incorporating the teaching “based on determining that the software has changed, determining whether or not the change is the breaking change” of Sonalker. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of testing ECU update to detect any new bug introduced by the update.
As per claim 18, this is a system claim that substantially parallels the limitations of the method claim 8. It would have been obvious to one of ordinary skill in the art before the time of the invention to implement the prescribed method steps as a system.
Claims 9, 10, 19 and 20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wakabayashi, Nilsson, Pirog and Solmaz as applied to claims 1 and 11 in view of Zhao et al. (hereinafter Zhao, Pub. No.: US 2022/0136930).
As of claim 9, (Original) Wakabayashi, Nilsson, Pirog and Solmaz teach software update of an ECU. They do not explicitly teach, “wherein the determining the plurality of test environments comprises: creating, based on the obtained test bench, a test job comprises a plurality of tasks; and selecting, based on one or more requirements for executing the plurality of tasks, the plurality of test environments.” However, in analogous art of software update, Zhao teaches,
wherein the determining the plurality of test environments comprises:
creating, based on the obtained test bench, a test job comprises a plurality of tasks; and selecting, based on one or more requirements for executing the plurality of tasks, the plurality of test environments. (Zhao recites in [0055] starting at line 2, “The use-case testing is mainly used to test the response of a certain function of the intelligent vehicle during the test, such as single function in the development of autonomous driving, performance of advanced driving assistance system (ADAS) and active safety. The scenario testing is mainly used to determine the response of an intelligent vehicle to a specific target or task in a preset scenario, such as rural scenarios, urban scenarios, and highway scenarios. The road testing is performed in a
real road or a real traffic environment, where traffic events involving environmental conditions, dynamic targets, road information, and road infrastructure all occur randomly.”)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog and Solmaz of ECU updating and testing by incorporating the teaching “wherein the determining the plurality of test environments comprises: creating, based on the obtained test bench, a test job comprises a plurality of tasks; and selecting, based on one or more requirements for executing the plurality of tasks, the plurality of test environments.” of Zhao. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of performing various tests for testing ECUs of different functionality based on requirements.
As of claim 10, (Original) Wakabayashi, Nilsson, Pirog, Solmaz teach software update of an ECU. They do not explicitly teach, “wherein the performing the cross-domain test comprises: assigning one or more tasks of the test job to the plurality of test environments; receiving, from the plurality of test environments, a test result associated with the assigned one or more tasks; and generating, based on the test result associated with the assigned one or more tasks, a test result of the cross-domain test.” However, in analogous art of software update, Zhao teaches,
wherein the performing the cross-domain test comprises:
assigning one or more tasks of the test job to the plurality of test environments; (Zhao recites in [0056] “Testing tools mainly include model-in-the-loop testing, software-in-the-loop testing, hardware-in-the-loop testing, vehicle-in-the-loop testing, and closed-field testing, which have been introduced above.”)
receiving, from the plurality of test environments, a test result associated with the assigned one or more tasks; and generating, based on the test result associated with the assigned one or more tasks, a test result of the cross-domain test.
(Zhao recites in [0055] starting at line 2, “The use-case testing is mainly used to test the response of a certain function of the intelligent vehicle during the test, such as single function in the development of autonomous driving, performance of advanced driving assistance system (ADAS) and active safety. The scenario testing is mainly used to determine the response of an intelligent vehicle to a specific target or task in a preset scenario, such as rural scenarios, urban scenarios, and highway scenarios. The road testing is performed in a real road or a real traffic environment, where traffic events involving environmental conditions, dynamic targets, road information, and road infrastructure all occur randomly.”)
Therefore, it would have been obvious to a person of the ordinary skill in the art before the effective filling date of the invention to modify the above teaching of Wakabayashi, Nilsson, Pirog and Solmaz of ECU updating and testing by incorporating the teaching “wherein the performing the cross-domain test comprises: assigning one or more tasks of the test job to the plurality of test environments; receiving, from the plurality of test environments, a test result associated with the assigned one or more tasks; and generating, based on the test result associated with the assigned one or more tasks, a test result of the cross-domain test.” of Zhao. The modification would have been obvious because one of the ordinary skills of the art would have implemented the function of performing various tests for testing ECUs of different functionality based on requirements. Tests also need to ensure that different ECUs with different functionality or domain can work together.
As per claims 19 and 20, these are system claims that substantially parallel the limitations of the method claims 9 and 10, respectively. It would have been obvious to one of ordinary skill in the art before the time of the invention to implement the prescribed method steps as a system.
References of Note
Examiner has cited particular columns, line numbers, references, or figures in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses to fully consider the reference in entirety, as potentially teaching all or part of the claimed invention. See MPEP §§ 2141.02 and 2123.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOSSAIN MORSHED whose telephone number is (571)272-3335. The examiner can normally be reached on Monday – Friday12:00 PM – 9 PM Eastern Time. The email address for the examiner is hossain.morshed@uspto.gov.
Examiner interviews are available via telephone or 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, Wei Mui can be reached on (571)272-3708.
/HOSSAIN M MORSHED/Primary Examiner, Art Unit 2191 June 11, 2026
Prosecution Insights