DETAILED ACTION
1. Claims 1, 4-8, 11-15, and 18-21 have been presented for examination.
Claims 2-3, 9-10, and 16-17 have been cancelled.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
3. 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 6/4/26 has been entered.
i) With respect to the prior art rejection, Applicants argue that Chen does not disclose “a system in which a vehicle system has a defined pathway of modules converting sensor information into actuator commands, and in which specific modules within that pathway are selectively replaced by software mock components while other modules remain in the pathway as non-replaced components under test.” Applicants further argue that “Chen's performance index is a parameter governing path planning behavior within the overall simulation. It is not a fidelity adjuster that modifies operational parameters of a mock component that has replaced a corresponding module within a sensor-to-actuator pathway. The claimed fidelity adjuster operates on a mock component a software simulation that has taken the place of a specific module in the pathway. Chen's performance index does not operate on any such mock component because Chen does not have mock components that replace individual modules within a defined processing pathway.” The Examiner disagrees and notes that the description of Figure 1 in Chen reads on this argument reciting “Vehicle states include throttle, brake, steering and fuel percentage reports for top-level control of ECU.” The Examiner specifically notes that the throttle, brake, steering, and fuel percentage reports read on the simulated modules of the vehicle system and the ECU reads on the claimed non-replaced component under test. The Examiner further notes that the claim recites at least one non-replaced component under test and does not require a plurality of components. Applicants are encouraged to incorporate the specificity of their arguments into the claim language. As such the prior art rejection is MAINTAINED.
ii) Applicants further argue Chen does not disclose "a language-independent description of data types exchanged at interfaces ... such that components sharing an interface use different programming languages while communicating via the universal interface language" as recited in the claim. The distinction is as follows. ROS nodes communicate through ROS-defined topics and message types within the ROS framework. Components operating within ROS are written to conform to the ROS ecosystem. The claimed universal interface language, by contrast, is a language-independent description of data types that exists at the interface level specifically so that components on either side of an interface may be written in different programming languages while still communicating. This is an interface description language in the architectural sense it defines the data types exchanged at a boundary between components so that the components themselves need not share a common programming language or software platform. ROS does not serve this function. ROS provides a common platform that components must operate within, rather than a language-independent type description that sits between components written in different languages. Chen does not disclose or suggest this architectural concept.” The Examiner notes that although Applicants appear to argue the ROS recited in Chen no argument is made, as was noted by the Examiner of both ROS and Gazebo. Specifically, as noted in the previous office action Gazebo is defined, on at least page 949, right column, as “a ROS built-in 3D simulation software that helps to accurately construct and evaluate the kinematics of robots in complex indoor and outdoor environments. It offers high-fidelity physical simulations, a large set of sensors, and numerous procedural and user-facing interfaces.” This definition alone would read on the broadest reasonable interpretation of the claim limitation as it provides a software environment with “a universal interface language”, see recitation of nodes in the same paragraph, as well as “a common interface specification”, the environment of the software, and further allows for “interchangeability of components” since the software is clearly not designed to simulate one and only one component. Further with respect to Applicants arguments that “ROS provides a common platform that components must operate within, rather than a language-independent type description that sits between components written in different languages” the Examiner once again notes that ROS is further defined as “a robotic software platform that provides similar operating system functions for heterogeneous computer clusters. It offers customary operating system services such as hardware abstraction, underlying device control, common feature implementation, inter-process messaging and packet management.” The Examiner notes the cited arts teaching of heterogenous computer clusters, common feature implementation, and inter-process messaging which also reads on the claimed limitation. The Examiner also once again notes that ROS includes nodes which are defined as “the core component of ROS graph architecture” and which “at different points of a process can accept, publish, and aggregate various categories of information for sensing, controlling, status monitoring or any other specific purpose.” The Examiner further notes Section III(a) “This is a standardized format in ROS that permits the description of all elements that specifies the motion and dynamics of a single robot. Rigid controlled parts like car body, steering wheel, brake, throttle and other essential components can be described here.” Therefore, the prior art rejection is MAINTAINED.
iii) Applicants further argue that Chen does not disclose “a fidelity adjuster configured to modify operational parameters of the mock component to adjust simulation complexity without recompilation of the mock component or construction of a new mock component.” The Examiner once again notes that contrary to Applicants conclusion that the “two concepts are structurally distinct” Chen recites on page 953-954, “Path planning is a crucial part of driver-less technology and plays an vital role between modules of environment perception and motion control. Based on the environmental data of the sensing system, the car must plan out an accessible and reliable global path in a complex road environment based on a certain performance index (i.e., the highest safety, the lowest energy cost, etc.).” The performance index reads on the fidelity adjuster. See also Page 953, left column, last paragraph, “In the end the system creates different dynamic traffic scenarios over time (e.g., lane congestion). Our simulation of these scenarios can be used to assist reproduction, analysis and the judgment of certain complex traffic phenomena that people usually cannot practically observe in the real world.” The complex path planning and traffic phenomena of Chen reads on the claimed “modify operational parameters of the mock component” as the path planning reads on the modification of operation parameters of the “mock component” represented by the vehicle. Furthermore, Chen’s use of real time decision making, see Figure 1, does not necessitate either of the claimed “without recompilation of the mock component or construction of a new mock component” as noted in the claim as well. Therefore, the prior art rejection is MAINTAINED.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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.
4. Claims 1, 4-8, 11-15, and 18-21 are rejected under 35 U.S.C. 102(a)(1) as being clearly anticipated by Chen, Yu, et al. "Autonomous vehicle testing and validation platform: Integrated simulation system with hardware in the loop." 2018 IEEE Intelligent Vehicles Symposium (IV). IEEE, 2018.
Regarding Claim 1: The reference discloses A simulation system based on a vehicle system, comprising:
a simulation module configured to generate simulated sensor data; (Page 950, Figure 1, “Sensor data comes from virtual sensors like LiDAR (Light Detection and Ranging), camera, millimeter radar and all other sensor devices.”)
at least one mock component in connection with the simulation module, the at least one mock component configured to simulate operation of a module of the vehicle system; and (Page 950, Figure 1, “Vehicle states include throttle, brake, steering and fuel percentage reports for top-level control of ECU.” Examiner Note: The throttle, brake, steering, and fuel percentage reports read on the simulated module of the vehicle system. See also the top left of figure including the vehicle models)
at least one testing hardware component in connection with the simulation module and the at least one mock component, the operation of which is tested during operation of the simulation system based on the generated simulated sensor data. (Page 950, Figure 1, “The ECU then processes the transformed data with core algorithms and sends corresponding actuator commands to a lower simulation interface after making real-time decision.”)
wherein the simulation module, the at least one mock component, and the at least one testing hardware component are connected based on a universal interface language that is provided as a common interface specification to enable interchangeability of components, (Page 949, “The software simulation interface of the proposed platform is centered around the Robot Operating System (ROS) and its embedded software Gazebo [4], [5]. ROS is a robotic software platform that provides similar operating system functions for heterogeneous computer clusters. It offers customary operating system services such as hardware abstraction, underlying device control, common feature implementation, inter-process messaging and packet management. A node is the core component of ROS graph architecture. It’s usually a short piece of code scripted in programming language Python or C ++ to perform a relatively simple task or process. Multiple nodes communicate messages to each other and can be independently started or terminated. Therefore, nodes at different points of a process can accept, publish, and aggregate various categories of information for sensing, controlling, status monitoring or any other specific purpose. Further to this, Gazebo is a ROS builtin 3D simulation software that helps to accurately construct and evaluate the kinematics of robots in complex indoor and outdoor environments. It offers high-fidelity physical simulations, a large set of sensors, and numerous procedural and user-facing interfaces.” Examiner notes that in view of the broadest reasonable interpretation of the claimed universal interface language both the ROS and Gazebo use respective universal interface languages to intercommunicate the components of the simulation as seen in at least Figure 1.)
wherein the at least one mock component includes a fidelity adjuster configured to modify operational parameters of the mock component to adjust simulation complexity without recompilation of the mock component or construction of a new mock component, (Page 953-954, “Path planning is a crucial part of driver-less technology and plays an vital role between modules of environment perception and motion control. Based on the environmental data of the sensing system, the car must plan out an accessible and reliable global path in a complex road environment based on a certain performance index (i.e., the highest safety, the lowest energy cost, etc.).” The performance index reads on the fidelity adjuster. See also Page 953, left column, last paragraph, “In the end the system creates different dynamic traffic scenarios over time (e.g., lane congestion). Our simulation of these scenarios can be used to assist reproduction, analysis and the judgment of certain complex traffic phenomena that people usually cannot practically observe in the real world.”)
wherein the vehicle system includes a plurality of modules that participate in a pathway of converting information received from sensors into output commands to actuators, and wherein the at least one mock component is a software simulation that replaces a corresponding module of the vehicle system in the pathway, (Page 950, Figure 1, “Vehicle states include throttle, brake, steering and fuel percentage reports for top-level control of ECU.” Examiner Note: The throttle, brake, steering, and fuel percentage reports read on the simulated module of the vehicle system. See also the top left of figure including the vehicle models) while the at least one testing hardware component remains in the pathway as a non-replaced component under test, (Page 950, Figure 1, “Vehicle states include throttle, brake, steering and fuel percentage reports for top-level control of ECU.”)
wherein the universal interface language comprises a language-independent description of data types exchanged at interfaces between the simulation module, the at least one mock component, and the at least one testing hardware component, such that components sharing an interface use different programming languages while communicating via the universal interface language. (Page 949, “The software simulation interface of the proposed platform is centered around the Robot Operating System (ROS) and its embedded software Gazebo [4], [5]. ROS is a robotic software platform that provides similar operating system functions for heterogeneous computer clusters. It offers customary operating system services such as hardware abstraction, underlying device control, common feature implementation, inter-process messaging and packet management. A node is the core component of ROS graph architecture. It’s usually a short piece of code scripted in programming language Python or C ++ to perform a relatively simple task or process. Multiple nodes communicate messages to each other and can be independently started or terminated. Therefore, nodes at different points of a process can accept, publish, and aggregate various categories of information for sensing, controlling, status monitoring or any other specific purpose. Further to this, Gazebo is a ROS builtin 3D simulation software that helps to accurately construct and evaluate the kinematics of robots in complex indoor and outdoor environments. It offers high-fidelity physical simulations, a large set of sensors, and numerous procedural and user-facing interfaces.” Examiner notes that in view of the broadest reasonable interpretation of the claimed universal interface language both the ROS and Gazebo use respective universal interface languages to intercommunicate the components of the simulation as seen in at least Figure 1.)
Regarding Claim 4: The reference discloses The simulation system of claim 1, wherein the at least one testing hardware component comprises a planning module configured to generate strategy information based on perception information and localization information. (Page 950, Figure 1, Core Algorithms including perception, driving policy, and path planning. Examiner Notes the driving policy and path planning read on the broadest reasonable interpretation of localization information particularly in combination with the localization sensor information in the middle of the figure.)
Regarding Claim 5: The reference discloses The simulation system of claim 4, wherein the at least one mock component comprises a perception mock configured to generate the perception information based on the generated simulated sensor data. (Page 950, Figure 1, Core Algorithms including perception interconnected with simulated sensor signals in middle of figure. An example of this is shown on page 954 left column, 2nd paragraph, “Next, when the car starts to get ahead under uncertainty of environmental factors, the motion planning needs to be triggered. In this instance, the input of the local planning algorithm includes not only the surrounding environment information acquired by sensors in real time, such as the shape and location data of the surrounding obstacles and the structure of the road, but also the traffic signals and the driving status of the car itself.”)
Regarding Claim 6: The reference discloses The simulation system of claim 4, wherein the at least one mock component comprises a localization mock configured to generate the localization information based on the generated simulated sensor data. (Page 950, Figure 1, Core Algorithms including driving policy, and path planning. Examiner Notes the driving policy and path planning read on the broadest reasonable interpretation of localization information particularly in combination with the localization sensor information in the middle of the figure.)
Regarding Claim 7: The reference discloses The simulation system of claim 1, further comprising a controller mock configured to output at least one command generated by the at least one testing hardware component to the simulation module. (Page 950, Figure 1, “The ECU then processes the transformed data with core algorithms and sends corresponding actuator commands to a lower simulation interface after making real-time decisions.” Page 954, Figure 6, throttle/brake command or steering command)
Regarding Claim 8: See rejection for claim 1.
Regarding Claim 11: The reference discloses The method of claim 8, wherein at least one testing hardware component comprises a planning module configured to generate strategy information based on perception information and localization information. (See rejection for claim 4)
Regarding Claim 12: The reference discloses The method of claim 11, wherein the at least one mock component comprises a perception mock configured to generate the perception information based on the generated simulated sensor data. (See rejection for claim 5)
Regarding Claim 13: The reference discloses The method of claim 11, wherein the at least one mock component comprises a localization mock configured to generate the localization information based on the generated simulated sensor data. (See rejection for claim 6)
Regarding Claim 14: The reference discloses The method of claim 8, further comprising outputting, by a controller mock, at least one command generated by the at least one testing hardware component to the simulation module. (See rejection for claim 7)
Regarding Claim 15: See rejection for claim 1.
Regarding Claim 18: The reference discloses The storage medium of claim 15, wherein at least one testing hardware component comprises a planning module configured to generate strategy information based on perception information and localization information. (See rejection for claim 4)
Regarding Claim 19: The reference discloses The storage medium of claim 18, wherein the at least one mock component comprises a perception mock configured to generate the perception information based on the generated simulated sensor data. (See rejection for claim 5)
Regarding Claim 20: The reference discloses The storage medium of claim 18, wherein the at least one mock component comprises a localization mock configured to generate the localization information based on the generated simulated sensor data. (See rejection for claim 6)
Regarding Claim 21: The reference discloses The simulation system of claim 1, wherein the universal interface language enables k-subset testing by allowing any combination of vehicle system modules to be implemented as either mock components or testing hardware components; (Figure 1) and the at least one mock component is selected from multiple available mock components having different fidelity levels. (Page 953-954, “Path planning is a crucial part of driver-less technology and plays an vital role between modules of environment perception and motion control. Based on the environmental data of the sensing system, the car must plan out an accessible and reliable global path in a complex road environment based on a certain performance index (i.e., the highest safety, the lowest energy cost, etc.).” The performance index reads on the fidelity adjuster. See also Page 953, left column, last paragraph, “In the end the system creates different dynamic traffic scenarios over time (e.g., lane congestion). Our simulation of these scenarios can be used to assist reproduction, analysis and the judgment of certain complex traffic phenomena that people usually cannot practically observe in the real world.”)
Conclusion
5. All Claims are rejected.
6. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
i) Rosique, Francisca, et al. "A systematic review of perception system and simulators for autonomous vehicles research." Sensors 19.3 (2019): 648.
ii) Matar, Mahmoud, et al. "A high performance real-time simulator for controllers hardware-in-the-loop testing." Energies 5.6 (2012): 1713-1733.
iii) Fathy, Hosam K., et al. "Review of hardware-in-the-loop simulation and its prospects in the automotive area." Modeling and simulation for military applications. Vol. 6228. SPIE, 2006.
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Saif A. Alhija whose telephone number is (571) 272-8635. The examiner can normally be reached on M-F, 10:00-6:00.
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, Renee Chavez, can be reached at (571) 270-1104. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300. Informal or draft communication, please label PROPOSED or DRAFT, can be additionally sent to the Examiners fax phone number, (571) 273-8635.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
SAA
/SAIF A ALHIJA/Primary Examiner, Art Unit 2186
Prosecution Insights