DETAILED ACTION
This action is in response to the claims filed March 10, 2026. Claims 1, 2, 4-12, and 14-20 are pending. Claims 1 and 11 are independent claims. Claims 1, 5-7, 11, and 15-17 have been amended. Claims 3 and 13 have been cancelled.
The rejection of the claims under 35 U.S.C. 101 has been withdrawn in view of applicant’s arguments and amendments to the claims.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-12, and 14-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 11 recite the limitation "the hardware component" in lines 11 and 13, respectively. There is insufficient antecedent basis for this limitation in the claim. For the purposes of examination, “the hardware component” is interpreted to read “the at least one hardware component” as is consistent with the language of claims 1 and 11. Claims 2 and 4-10 are rejected in view of their dependency on claim 1. Claims 12 and 14-20 are rejected in view of their dependency on claim 11.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5-12, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220058113 A1 (hereinafter “Mizoguchi”), in view of “Autonomous Vehicle Testing and Validation Platform: Integrated Simulation System with Hardware in the Loop” by Chen et. al (hereinafter “Chen”), further in view of JP 2008084121 A (hereinafter “Yutaka”).
Regarding claim 1, Mizoguchi discloses:
A method, implemented by at least one processor of a system, for managing a test bench for a cross-domain test for testing software of an embedded system, the method comprising (Paragraph [0004]):
- obtaining a test bench configuration associated with the software (Paragraph [0041], “One test case corresponds to one test specification form 30. The test case ID 300 is identification information uniquely allocated for one test case, and is also information for identifying a test specification form 30. The target requirements 302 are requirements described for specifications that a test target needs to satisfy, e.g. a lowest operating frequency, a minimum memory area amount, a minimum number of I/O ports, and a required number of communication channels for the ECU, and specified by lower limit values or ranges of these items. The environment requirements 303 are requirements described for specifications that a test environment needs to satisfy, e.g. a lowest operating frequency, a minimum memory area amount, a minimum number of I/O ports, and a required number of communication channels for the HiLS 102 constituting the test environment, and specified by lower limit values or ranges of these items [obtaining a test bench configuration associated with the software]”) [Examiner’s remarks: Configurations associated with tests for a vehicle (software) are obtained, which may be used as specifications for a test bench.],
- obtaining information of a plurality of test artifacts associated with the test bench configuration, the plurality of test artifacts comprising at least one software component and at least one hardware component (Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303 [obtaining information of a plurality of test artifacts associated with the test bench configuration]”); Paragraph [0004], “In the simulation system described in PTL 1, a test environment is automatically determined, with electronic control units (ECUs) presented as test targets and hardware-in-the-loop simulators (HiLSs) and software-in-the-loop simulators (SiLSs) presented as test environments”) [Examiner’s remarks: Information regarding test artifacts (target requirements and environment requirements) are obtained, where the test artifact comprise software components (environment including SiLS) and hardware components (target requirements including ECUs).];
- generating, based on the plurality of test artifacts, a test bench associated with the cross-domain test (Paragraph [0004], “In the simulation system described in PTL 1, a test environment is automatically determined, with electronic control units (ECUs) presented as test targets and hardware-in-the-loop simulators (HiLSs) and software-in-the-loop simulators (SiLSs) presented as test environments”; Paragraph [0029], “In addition, each of the HiLS environments 1 is connected to an ECU 3. In this embodiment, the number of HiLS environments 1 is three and the number of SiLS environments 2 is two, but the respective numbers of HiLS environments 1 and SiLS environments 2 are not limited thereto, and may be singular or arbitrarily plural”; Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”; Paragraph [0064], “Thus, candidate[i][j] is TRUE only when a combination of a test target and a test environment is available while both the target requirements 302 and the environment requirements 303 are satisfied. Therefore, a combination whose candidate[i][j] value is TRUE is output as a selectable combination” [generating, based on the plurality of test artifacts, a test bench associated with the cross-domain test.) [Examiner’s remarks: a plurality of test artifacts (test targets and environments) are selected based on the configuration associated with a test, and the selected artifacts include a ECUs.],
- determining, based on the test bench, a first node associated with the at least one software component and a second node associated with the hardware component (Paragraph [0004], “In the simulation system described in PTL 1, a test environment is automatically determined, with electronic control units (ECUs) presented as test targets and hardware-in-the-loop simulators (HiLSs) and software-in-the-loop simulators (SiLSs) presented as test environments”; Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”; Paragraph [0064], “Thus, candidate[i][j] is TRUE only when a combination of a test target and a test environment is available while both the target requirements 302 and the environment requirements 303 are satisfied. Therefore, a combination whose candidate[i][j] value is TRUE is output as a selectable combination”) [Examiner’s remarks: A test bench with requirements is used to determine a first node associated with a software component (software-in-the-loop simulator) and a second node associated with the hardware (hardware-in-the-loop simulators, ECUs).]…
…
- wherein the software of the embedded system comprises an in-vehicle electronic control unit (ECU) (Paragraph [0004], “In the simulation system described in PTL 1, a test environment is automatically determined, with electronic control units (ECUs) presented as test targets and hardware-in-the-loop simulators (HiLSs) and software-in-the-loop simulators (SiLSs) presented as test environments”; Paragraph [0029], “In addition, each of the HiLS environments 1 is connected to an ECU 3).
Mizoguchi does not explicitly disclose:
- … the first node communicatively coupled to the at least one processor via a first network and the second node communicatively coupled to the at least one processor via a second network; and
- creating, based on the at least one software component and the at least one hardware component, a virtual vehicle model,
…
However, Chen discloses:
- creating, based on the at least one software component and the at least one hardware component, a virtual vehicle model (Pages 949-950, “Real sensors and loads are replaced by virtual ones to simulate the real-time physical relationship between actuators and sensors on a simulated car model [10]. This subsequently allows the ECU to operate in an electrical environment that is considerably close to that in a real vehicle and performs a series of tests to verify whether its performance meets our design requirements”) [Examiner’s remarks: A combination of hardware ECUs and software (virtual sensors and loads) are combined to create a virtual vehicle for testing.],
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Chen into the teachings of Mizoguchi to include “creating, based on the at least one software component and the at least one hardware component, a virtual vehicle model”. As stated in Chen, “By contrast, a simulation test of vehicle control using mounted sensors and comprehensive environments provides a reasonable and cost-effective option” (Page 949). Using a combination of hardware (ECUs) and software (modeled sensors/vehicles) allows tests on vehicles to be performed without requiring a fully physical setup, saving time, cost, and space, and reduces errors in the final stages of testing. Therefore, it would be obvious to one of ordinary skill in the art to combine ECU test bench configuration with software models of a vehicle.
The combination of Mizoguchi and Chen does not explicitly disclose:
- … the first node communicatively coupled to the at least one processor via a first network and the second node communicatively coupled to the at least one processor via a second network; and
However, Yutaka discloses:
- … the first node communicatively coupled to the at least one processor via a first network and the second node communicatively coupled to the at least one processor via a second network (Paragraph [0012], “In another configuration, as shown in Figure 2, multiple simulators SM are networked to a single host computer PC acting as a management device. Multiple model programs MP to be ported to each simulator SM are managed as software resources on a per-simulator SM basis in the user folder 1 of memory M on the host computer PC. A simulation information management area A is individually set up for each simulator SM to set environmental conditions such as input/output conditions and operation setting screens for the model programs”; Paragraph [0037], “The simulator SM that can be connected to the system consists of a HILS system, which is a hardware simulator composed of an ECU (Electronic Control Unit) as control system hardware into which the program to be evaluated is incorporated, and hardware blocks that simulate controlled system hardware, i.e., the engine and transmission, into which the model program is incorporated and controlled by the ECU, or a SILS system, which is a software simulator in which control system software that simulates the ECU and controlled system software that simulates the controlled system hardware are implemented on a single computer”) [Examiner’s remarks: Multiple nodes (simulators) are connected to a PC (one of ordinary skill int eh art understands that a PC contains processors). Each simulator is connected through their own network. Yutaka discloses the simulations being either HiLS or SiLS systems, analogous to the HiLS and SiLS systems of Mizoguchi. Therefore, one of ordinary skill in the art may combine the centralized control system of Yutaka with that of Mizoguchi.]; and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Yutaka into the combined teachings of Mizoguchi and Chen to include “… the first node communicatively coupled to the at least one processor via a first network and the second node communicatively coupled to the at least one processor via a second network”. As stated in Yutaka, “When evaluating development software using the simulation system described above, a distributed simulation system is constructed that realizes large-scale and complex models by connecting multiple simulators, each with different model programs ported to it, in parallel and performing parallel calculations at set calculation cycles for each simulator. This allows for a comprehensive evaluation of the program under evaluation when it is installed on the system” (Paragraph [0008]). Using a central management device allows for the coordinated testing of multiple types of simulators with less human intervention and less specific software, thereby increasing efficiency. Therefore, it would be obvious to one of ordinary skill in the art to combine simulation testing with a centralized processor.
Regarding claim 2, the rejection of claim 1 is incorporated; and Mizoguchi further discloses:
wherein the obtaining the test bench configuration comprises:
- receiving, from a user, one or more inputs defining the test bench (Paragraph [0111], “In the test environment determination device 0, an interface (e.g. an input screen) may be provided to allow the user to input target requirements 302 and environment requirements 303”);
- obtaining a components catalog including information of available test artifacts (Paragraph [0046], “FIGS. 5A-B are a diagram showing the performance information stored in the performance information storage unit 5. The performance information includes target performance information 501 and environment performance information 502. As shown in FIG. 5A, the target performance information 501 is information about each test target such as an ECU, including an operating frequency, a memory area size, the number of I/O ports, and the number of communication channels. As shown in FIG. 5B, the environment performance information 502 is information about each test environment, including an operating frequency, a memory area size, the number of I/O ports, and the number of communication channels. The target performance information 501 and the environment performance information 502 may not include some or all of the data items illustrated, and may include other data items that are not illustrated.”);
- determining, based on the one or more inputs and from among the available test artifacts, one or more test artifacts associated with the user-defined test bench (Paragraph [0063] – Paragraph [0064], “A value stored in candidate[i][j] is determined by deciding a value of ECU_choice[i], a value of ENV_choice[j], and a value of combine[i][j] (902). If ECU_choice[i] is TRUE, ENV_choice[j] is TRUE, and combine[i][j] is 1, the value of candidate[i][j] is TRUE (903). Otherwise, the value of candidate[i][j] is FALSE (904). Thus, candidate[i][j] is TRUE only when a combination of a test target and a test environment is available while both the target requirements 302 and the environment requirements 303 are satisfied. Therefore, a combination whose candidate[i][j] value is TRUE is output as a selectable combination”) [Examiner’s remarks: Based on the given test bench parameters, it is determined whether each available target and environment choice may be selected.]; and
- building, based on the determined one or more test artifacts, the test bench configuration (Paragraph [0063] – Paragraph [0064], “A value stored in candidate[i][j] is determined by deciding a value of ECU_choice[i], a value of ENV_choice[j], and a value of combine[i][j] (902). If ECU_choice[i] is TRUE, ENV_choice[j] is TRUE, and combine[i][j] is 1, the value of candidate[i][j] is TRUE (903). Otherwise, the value of candidate[i][j] is FALSE (904). Thus, candidate[i][j] is TRUE only when a combination of a test target and a test environment is available while both the target requirements 302 and the environment requirements 303 are satisfied. Therefore, a combination whose candidate[i][j] value is TRUE is output as a selectable combination”).
Regarding claim 5, the rejection of claim 1 is incorporated; and Mizoguchi further discloses:
- … and wherein the at least one hardware component comprises at least one physical ECU (Paragraph [0029], “In addition, each of the HiLS environments 1 is connected to an ECU 3. In this embodiment, the number of HiLS environments 1 is three and the number of SiLS environments 2 is two, but the respective numbers of HiLS environments 1 and SiLS environments 2 are not limited thereto, and may be singular or arbitrarily plural”).
Mizoguchi does not explicitly disclose:
- wherein the at least one software component comprises at least one virtual ECU, at least one emulated ECU, or a vehicle-related model;
However, Chen discloses:
- wherein the at least one software component comprises at least one virtual ECU, at least one emulated ECU, or a vehicle-related model (Page 950, “In this paper, the ECU being tested is connected to the simulation interface for all-round and systematic tests while realizing a closed-loop simulation system. The simulation interface exports sensor signals and vehicle states in realtime to the ECU via CAN (Controller Area Network) bus devices for data transmission”) [Examiner’s remarks: The software components include at least a vehicle-related model (simulation interface exports sensor signals and vehicle states).];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Chen into the teachings of Mizoguchi to include “wherein the at least one software component comprises at least one virtual ECU, at least one emulated ECU, or a vehicle-related model”. As stated in Chen, “By contrast, a simulation test of vehicle control using mounted sensors and comprehensive environments provides a reasonable and cost-effective option” (Page 949). Using a combination of hardware (ECUs) and software (modeled sensors/vehicles) allows tests on vehicles to be performed without requiring a fully physical setup, saving time, cost, and space, and reduces errors in the final stages of testing. Therefore, it would be obvious to one of ordinary skill in the art to combine ECU test bench configuration with software models of a vehicle.
Regarding claim 6, the rejection of claim 1 is incorporated; and Mizoguchi further discloses:
- deploying, based on the test bench, the at least one software component (Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”) [Examiner’s remarks: At least one software component (test environment) is deployed.]; and
- reserving, based on the test bench, the at least one hardware component (Paragraph [0044], “The combination availability information storage unit 6 stores therein information on whether combinations of the test targets and the test environments are available. A detailed configuration of the combination availability information storage unit 6 will be described below with reference to FIG. 8. With respect to the test environments and the test targets selected by the element selection unit 4, the combination determination unit 7 outputs a plurality of available combinations of the test targets and the test environments based on the combination availability information”; Paragraph [0029], “In addition, each of the HiLS environments 1 is connected to an ECU 3.) [Examiner’s remarks: At least one hardware component (ECU, test target) is selected.].
Regarding claim 7, the rejection of claim 6 is incorporated; and Mizoguchi further discloses:
- wherein the deploying the at least one software component comprises (Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”):
- determining, based on the test bench, at least one resource requirement for deploying the at least one software component (Paragraph [0041], “The target requirements 302 are requirements described for specifications that a test target needs to satisfy, e.g. a lowest operating frequency, a minimum memory area amount, a minimum number of I/O ports, and a required number of communication channels for the ECU, and specified by lower limit values or ranges of these items. The environment requirements 303 are requirements described for specifications that a test environment needs to satisfy, e.g. a lowest operating frequency, a minimum memory area amount, a minimum number of I/O ports, and a required number of communication channels for the HiLS 102 constituting the test environment, and specified by lower limit values or ranges of these items”; Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”);
- determining, from among a plurality of nodes communicatively coupled to the system, the first node which satisfies the at least one resource requirement (Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”) [Examiner’s remarks: From among the plurality of nodes (test targets and test environments), a first node (selectable target or environment) is selected based on the given target or environment requirements.]; and
- deploying the at least one software component on the first node, wherein the plurality of nodes include the first node and the second node Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”) [Examiner’s remarks: As noted in the rejection of claim 1, test target and environment may refer to hardware and software components, respectively. One of the nodes (targets) selected by the previous step to fulfil requirements may be deployed for testing.].
Regarding claim 8, the rejection of claim 6 is incorporated; and Mizoguchi further discloses:
wherein the reserving the at least one hardware component comprises:
- determining, based on the test bench, at least one hardware resource requirement (Paragraph [0041], “The target requirements 302 are requirements described for specifications that a test target needs to satisfy, e.g. a lowest operating frequency, a minimum memory area amount, a minimum number of I/O ports, and a required number of communication channels for the ECU, and specified by lower limit values or ranges of these items”; Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”);
- determining, from among a plurality of hardware components communicatively coupled to the system, the at least one hardware component, wherein the at least one hardware component satisfies the at least one hardware resource requirement (Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303”); and
- reserving the at least one hardware component (Paragraph [0004], “In the simulation system described in PTL 1, a test environment is automatically determined, with electronic control units (ECUs) presented as test targets and hardware-in-the-loop simulators (HiLSs) and software-in-the-loop simulators (SiLSs) presented as test environments”; Paragraph [0044], “The environment operation information acquisition unit 8 acquires operation information on each of the HiLS environments and the SiLS environments included in the test environments. The usage cost calculation unit 9 calculates costs for using the environments based on the acquired operation information. With respect to the combinations of the test targets and the test environments output by the combination determination unit 7, the environment selection unit 10 selects and outputs one combination with the lowest usage cost calculated by the usage cost calculation unit 9”).
Regarding claim 9, the rejection of claim 6 is incorporated; and Mizoguchi further discloses:
wherein the creating the virtual vehicle model comprises:
- determining, based on the test bench, a relationship among the at least one software component and the at least one hardware component (Paragraph [0044], “The element selection unit 4 acquires the target requirements 302 or the environment requirements 303, compares the acquired requirements with performance information on each test target or each test environment stored in the performance information storage unit 5, and selects one or more selectable test targets or test environments based on the target requirements 302 or the environment requirements 303. The combination availability information storage unit 6 stores therein information on whether combinations of the test targets and the test environments are available”; Paragraph [0064], “Thus, candidate[i][j] is TRUE only when a combination of a test target and a test environment is available while both the target requirements 302 and the environment requirements 303 are satisfied. Therefore, a combination whose candidate[i][j] value is TRUE is output as a selectable combination”); and
- connecting, based on the determined relationship, the at least one software component to the at least one hardware component (Paragraph [0064], “Thus, candidate[i][j] is TRUE only when a combination of a test target and a test environment is available while both the target requirements 302 and the environment requirements 303 are satisfied. Therefore, a combination whose candidate[i][j] value is TRUE is output as a selectable combination”).
Regarding claim 10, the rejection of claim 6 is incorporated; and Mizoguchi does not explicitly disclose:
- further comprising generating, based on the virtual vehicle model, a test rig for the cross-domain test.
However, Chen discloses:
- further comprising generating, based on the virtual vehicle model, a test rig for the cross-domain test (Pages 949-950, “Real sensors and loads are replaced by virtual ones to simulate the real-time physical relationship between actuators and sensors on a simulated car model [10]. This subsequently allows the ECU to operate in an electrical environment that is considerably close to that in a real vehicle and performs a series of tests to verify whether its performance meets our design requirements”) [Examiner’s remarks: The virtual vehicle model is used as a test rig to run a series of tests to verify performance.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Chen into the teachings of Mizoguchi to include “further comprising generating, based on the virtual vehicle model, a test rig for the cross-domain test”. As stated in Chen, “In terms of safety, feasibility and reasonable cost, the HiL simulation test has become an integral aspect of autonomous driving development flow, reducing the number of real road tests, shortening the development time, minimizing the cost and improving the quality of ECU development.” (Page 950). Therefore, it would be obvious to one of ordinary skill in the art to combine ECU test bench configuration with using virtual models of a vehicle as a test rig.
Claims 11, 12, and 15-20 are system claims corresponding to the method claims hereinabove (claims 1, 2, and 5-10 respectively). Therefore, claims 11, 12, and 15-20 are rejected for the same reasons as set forth in the rejection of claims 1, 2, and 15-20, respectively.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220058113 A1 (hereinafter “Mizoguchi”), in view of “Autonomous Vehicle Testing and Validation Platform: Integrated Simulation System with Hardware in the Loop” by Chen et. al (hereinafter “Chen”), further in view of JP 2008084121 A (hereinafter “Yutaka”), and further in view of “The Cat Vehicle Testbed: A Simulator with Hardware in the Loop for Autonomous Vehicle Applications” by Bhadani et. al (hereinafter “Bhadani”).
Regarding claim 4, the rejection of claim 1 is incorporated; and the combination of Mizoguchi, Chen, and Yutaka does not explicitly disclose:
- wherein at least a portion of the plurality of test artifacts is deployed at different geographical locations.
However, Bhadani discloses:
- wherein at least a portion of the plurality of test artifacts is deployed at different geographical locations (Page 43, “During the first three stages of the competition, participants were unable to access the physical platform. They used the CAT Vehicle Testbed with the software in the loop simulation and validated their algorithms and model, submitting bagfile artifacts from their simulation in order to qualify for continued performance in the challenge. In the fourth and final stage, selected participants were invited to the University of Arizona campus to work with the physical platform. Each team selected in the final stage of the competition was able to verify their model with the CAT Vehicle and real sensors within the span of two days. They successfully demonstrated their controllers in action by operating the CAT Vehicle autonomously. The result of the final stage was a configuration file for Gazebo simulator to create a virtual world to mirror the environment from which the data was extracted”) [Examiner’s remarks: The software simulations are run in a separate location from the physical platform.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Bhadani into the combined teachings of Mizoguchi, Chen and Yutaka to include “wherein at least a portion of the plurality of test artifacts is deployed at different geographical locations”. As stated in Bhadani, “However, researchers who want to demonstrate new results on a physical platform face difficult challenges, if they do not have access to a robotic platform in their own labs. Thus, there is a need for a research testbed where simulation-based results can be rapidly validated through hardware in the loop simulation, in order to test the software on board the physical platform. The CAT Vehicle Testbed offers such a testbed that can mimic dynamics of a real vehicle in simulation and then seamlessly transition to reproduction of use cases with hardware” (Abstract). Testing integrating hardware and software allows for rapid and flexible vehicle testing. Allowing different testing components to be in different locations increases flexibility by allowing testing to happen even if there is no physical rig on location. Therefore, it would be obvious to one of ordinary skill in the art to combine ECU test bench configuration with components in different locations.
Claim 14 is a system claim corresponding to the method claim hereinabove (claim 4). Therefore, claim 14 is rejected for the same reasons as set forth in the rejection of claim 4.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-2, 14-12, and 14-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191
/QING CHEN/Primary Examiner, Art Unit 2191
Prosecution Insights