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.
Claim 21 is newly added.
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. Applicant's arguments filed 11/26/25 have been fully considered but they are not persuasive.
i) With respect to the prior art rejection, Applicants argue that Chen does not disclose “connected based on a universal interface language that is provided as a common interface specification to enable interchangeability of components.” First the Examiner notes although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Second, the Examiner notes that although addressed here the limitation “to enable interchangeability of components” represents an intended use and as such is not afforded patentable weight. Further, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. Lastly, Applicants have noted the use in Chen of both ROS and Gazebo. 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.
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.” 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.” Once again, 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.
Applicants have not explained how the use of either or both of these software packages would not read on the claimed “universal interface language that is provided as a common interface specification to enable interchangeability of components.” Specifically as examples see 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.
ii) 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.” First the Examiner notes although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Applicants arguments are heavily reliant on their exemplary embodiments in the specification however the claims are read in view of their broadest reasonable interpretation. As noted in the previous office action, Chen recited 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.”)
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: A method of a simulation system, comprising: generating, by a simulation module, simulated sensor data; simulating, by at least one mock component in connection with the simulation module, operation of a module of a vehicle system; and testing, during operation of the simulation system and based on the generated simulated sensor data, at least one testing hardware component in connection with the simulation module and the at least one mock component. 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, 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. (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: The reference discloses A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to: generate, by a simulation module, simulated sensor data; simulate, by at least one mock component in connection with the simulation module, operation of a module of a vehicle system; and test, during operation of the simulation system and based on the generated simulated sensor data, at least one testing hardware component in connection with the simulation module and the at least one mock component 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, 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. (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. 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.
6. All Claims are rejected.
7. 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.
8. 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 2188