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.
Status of the application
This Office Action is in response to Applicant's amendment filed on 11/26/2025. 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.
Acknowledgement
In light of the applicant’s amendments to claims 1, 13 and 19, objection to these claims for being not ending with a period has been withdrawn.
In light of the applicant’s amendment to claim 18, objection to claim 18 for being dependent on the wrong claim, has been withdrawn.
In light of the applicant’s amendments to claims 1, 4 and 5, the 35 USC 112(b) rejection of these claims have been withdrawn.
Claims 1, 2, 4, 5, 11, 12, 18 and 19 have been amended.
Response to Amendment/Arguments
Applicants' arguments have been carefully and respectfully considered and addressed but found not persuasive. Arguments are moot in light of the new ground of rejection, which relies upon prior art made of record Wakabayashi (Pub. No.: US 2025/0390420), Pirog et al. (Pub. No.: US 2020/0183337) and Chen et al. (Pub. No.: US 2025/0061052). Accordingly, this action has been made FINAL.
Applicant is welcome to set up an examiner interview to discuss further amendments for probable advancement of prosecution.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1 and 11 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “detect a change in the software, wherein a change in the software comprises at least one of degradation of performance or when a predetermined test execution schedule is reached;”. This means that change in software is detected when software performance is degraded or change in software is detected when a predetermined test execution is scheduled. Apparently, this claim has been taken from paragraph [0085] of the specification. The specification recites “It can be understood that, in addition to or in alternative of determining the breaking change, the at least one processor may determine whether or not any other condition(s) have been satisfied so as to determine whether or not the test execution should be triggered. For instance, the
at least one processor may determine whether or not a performance of the associated node (e.g., first node 420-1) has degraded, whether or not a pre-set test execution schedule is reached, or the like, and may determine whether or not the test execution should be triggered based thereon.” This teaches that “when a predetermined test execution schedule is reached;”, it does not depend on any other condition including “detecting a change in the software”. As such, in the examiner’s opinion, the claim limitation is not supported by the specification.
Claim 11 has substantially similar claim limitation and can be rejected using the same rationale.
Claim 2-10 and 12-20 are rejected under 35 USC 112(a) for being dependent on a rejected base claim.
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), Pirog et al. (hereinafter Pirog, Pub. No.: US 2020/0183337) and Chen et al. (hereinafter Chen, Pub. No.: US 2025/0061052).
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, wherein a change in the software comprises 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, “when a predetermined test execution schedule is reached; 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,
or when a predetermined test execution schedule is reached; (Pirog recites in [0065] starting at line 5, “The activation is automatic, in the sense that the test software 308, and specifically master 400 in the present embodiment, triggers it based on the chosen configuration data, without any requirement for a human operator to manually activate the object code portions at the test platform 200.” This shows that a test execution starts when specified in the configuration. This means that the schedule was predetermined and entered in the configuration file.)
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
of ECU testing by incorporating the teaching “when a predetermined test execution schedule is reached; 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 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, Chen teaches,
determining a plurality of test environments associated with the test bench; and
(Chen recites [0003] starting at line 4, “In the context of vehicle systems, a cross-domain test may be required during development of advanced features in a
vehicle system, such as Lane Change Assist, Mobile Smart Keys, and the like, and the cross-domain test may involve testing the interaction between different electronic control units (ECUs) and the associated software and hardware components across different systems. For instance, different testing systems may be utilized for providing testing at different fidelity levels (e.g., virtual ECU, emulated ECU, simulated ECU, etc.), for providing testing at different vehicle variants or platforms, and/or for providing testing
for software developed by different developers.” This shows a plurality of test environment.)
performing the cross-domain test based on the plurality of test environments, (Chen recites [0003] starting at line 4, “In the context of vehicle systems, a cross-domain test may be required during development of advanced features in a
vehicle system, such as Lane Change Assist, Mobile Smart Keys, and the like, and the cross-domain test may involve testing the interaction between different electronic control units (ECUs) and the associated software and hardware components across different systems. For instance, different testing systems may be utilized for providing testing at different fidelity levels (e.g., virtual ECU, emulated ECU, simulated ECU, etc.), for providing testing at different vehicle variants or platforms, and/or for providing testing
for software developed by different developers.”)
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. (Chen recites in [0054] “According to embodiments, at least a portion of the plurality of nodes 130-1 to 130-N may be associated with one or more test environments. For instance, said portion of nodes may have at least one software-based test environment (e.g., software-in-the-loop (SIL) test environment,
virtual ECU (V-ECU) test environment, model-in-the-loop (MIL) test environment, processor-in-the-loop (PIL) test environment, etc.) and/or at least one hardware-based test environment (e.g., hardware-in-the-loop (HIL) test environment) communicatively coupled thereto (e.g., wired coupling, wireless coupling, etc.) or deployed thereto.” This shows ECU, 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 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 Chen. 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, Pirog and Chen as applied to claims 1 and 11 in view of Mayhew (Pub. No.: US 2016/0189056).
As of claim 2, (Currently amended) Wakabayashi, Pirog and Chen 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, Pirog and Chen 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, Pirog and Chen as applied to claims 1 and 11 in view of Kwak (Pub. No.: US 2023/0161931).
As of claim 3, (Original) Wakabayashi, Pirog and Chen 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, Pirog and Chen 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, Pirog, Chen 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, (Currently amended) Wakabayashi, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, (Currently amended) Wakabayashi, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen 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, Pirog, Chen and 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, Pirog, Chen, 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, Pirog and Chen 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, Pirog and Chen 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, Pirog and Chen 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, Pirog and Chen 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, Pirog and Chen 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 11, 19 and 20, these are system claims that substantially parallel the limitations of the method claims 1, 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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