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 .
Claims 1-5, 7-12, 14-20 have been presented for examination based on the application filed on 3/6/2026.
Claim 19-20 are new & Claims 6 & 13 are cancelled.
Claims 1, 3, 4, 8, 10, 11, 15 and 18 are amended.
Claim 1-5, 7-12, 14-20 are newly rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
Claims 1-5, 7-12, 14-20 are newly rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite.
Claim(s) 1, 2, 5, 8-9, 12, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190050520 A1 by Alvarez; Ignacio et al., in view of US PGPUB No. US 20110288841 A1 by Larsson1; Johan et al..
Claim(s) 3-4, 7, 10-11, 14, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Alvarez, in view of Larsson, further in view of US PGPUB No. US 20200001888 A1 by PRETSCH; Christian et al.
This action is made Final.
Response to Arguments
(Argument 1) Applicant has argued in Remarks Pg.14:
PNG
media_image1.png
310
670
media_image1.png
Greyscale
(Response 1) Examiner respectfully disagree, as the applicant has not distinctuished in the exemplary independent claim 1 what is the second core simulator. If the implied interpretation is the second core simulator is hardware-in-the-loop (HIL) simulator interfacing with the first core simulator (Software-in-the-loop (SIL) simulator, such is clearly shown in the comparing the results of HIL and SIL in Larsson: Figs.20-22. Connection between them would be required to perform data exchange which is further elaborated by Pretsch as mapped.
No new argument is made on Pgs.15-16. Examiner respectfully maintains the rejection. Applicant’s are encouraged to request an interview to explain there mapping in newly amended/new claims to overcome rejection under 35 USC 112¶1st /2nd.
---- This page is left blank after this line ----
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claim 1-5, 7-12, 14-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains 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, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Specifically amended claim 1 now recites:
(Currently Amended) A server for providing an autonomous driving simulation architecture for testing an application, the server comprising:
a storage storing a plurality of simulation data models; and
at least one processor configured to execute instructions to implement:
at least one first interface to integrate the plurality of simulation data models with a first core simulator that runs an a first autonomous driving simulation for testing the application;
at least one second interface to integrate the plurality of simulation data models with a second core simulator that runs a second autonomous driving simulation for testing the application, different from the first autonomous driving simulation, wherein the plurality of simulation data models are selectively connectable to the first core simulator via the at least one first interface and the second core simulator via the at least one second interface;…
a common interface to selectively connect the first core simulator and the second core interface to a client device providing the application, wherein the common interface is configured to receive a command from the client device, the command being input by a user to selectively control a first switch;
The specification only discloses ONE core simulator operational at a time where the plurality of simulation data models connect to ONE core simulator via respective first and second interfaces. The claim on the other hand implies there are two core simulators operational at same time (the first core simulator and the second core simulator). This is contrary to what specification Fig.4 & [0011], [0018], [0052], [0066] and the claims call for one core simulator at a time.
PNG
media_image2.png
656
650
media_image2.png
Greyscale
Further the first simulation model 453a/453b and second simulation model 455a/455b forming plurality of simulation model only connect to one core simulator 500 at a time and not concurrent connect to the first core simulator and the second core simulator (as claimed in now amended wherein the plurality of simulation data models are selectively connectable to the first core simulator via the at least one first interface and the second core simulator via the at least one second interface) and hence this is considered as new matter. See Fig.4:
PNG
media_image3.png
510
692
media_image3.png
Greyscale
Dependent claims 2-5, 7, 16-20 inherit this deficiency and are rejected likewise.
Claim 8 also recites both first core simulator and second core simulator simultaneously, which is not supported in the disclosure as identified above. Claim 10 specify that "...wherein the first core simulator is configured for a software in the loop simulation and the second core simulator is configured for a hardware in the loop simulation...", however no where in the specification it states software in loop and hardware in loop are run concurrently. Providing them does not imply they are concurrently being used. Further specification shows no embodiment where both of them are used at same time. Amended claim 11 also makes the same implication of concurrent use.
PNG
media_image4.png
364
638
media_image4.png
Greyscale
Dependent claims 9-11, 12 and 14 inherit this deficiency and are rejected likewise.
Specifically now amended claim 18 recite:
PNG
media_image5.png
623
747
media_image5.png
Greyscale
As per A, There is no second interface connected to the second core simulator. Inheriting the deficiency from claim 7 and claim 1, the disclosure does not support first core simulator and second core simulator being executed/connected at same time as identified above. Issue B there is support for the limitation in specification (and is also rejected under indefiniteness).
Claim 19 (New) recites:
PNG
media_image6.png
188
668
media_image6.png
Greyscale
This claim implies that both first core simulator and second core simulator are operational concurrently and in communication with application, which is not supported by Fig.1 or specification ¶[0011], [0018], [0052], [0066] as identified above for claim 1 (parent of claims 18 from which this claim depends). Hence this is new matter.
Further this implies two different data formats (one from each of first and second core simulator) are concurrently sent to application, which is also new matter.
---- This page is left blank after this line ----
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-5, 7-12, 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.
PNG
media_image7.png
624
654
media_image7.png
Greyscale
Claim 1 recites the limitation "the second core interface" in “a common interface” limitation. There is insufficient antecedent basis for this limitation in the claim.
In fact besides the lack of antecedent basis the claim introduces ambiguity as there is no “second core interface”. As can be clearly seen in Fig.4 there is only “second interface 480b”, which is how the claim is now interpreted. Clalim 8 and 15 are rejected similarly.
Specifically now amended claim 18 recite:
PNG
media_image5.png
623
747
media_image5.png
Greyscale
Issue B recites "... wherein the data format of the second core simulator is different from the data format of the second core simulator..." . Even if the second core simulator is present in the claim, this appears to be a typographical error which cannot be easily resolved. E.g. it states A is different than A, A being data format of the second core simulator.
New claim 20 recites:
PNG
media_image8.png
782
674
media_image8.png
Greyscale
Claim 1 appears to indicate first core simulator and second core simulator appear to be executed concurrently, but claim 20 appears to imply they are selectively. Its not clear what is run and when. Applicant are advised to review all 112¶1 and 2nd rejections before responding.
Dependent claims 2-5, 7, 16-20 inherit this deficiency and are rejected likewise.
Examiner Note
A written description rejection (under 35 USC 112¶1st) is made above along with indefiniteness (under 35 USC 112¶2nd) where concurrent use of first core simulator and second core simulator is not disclosed in the specification. Enablement rejection is not made as the cosimulation of hardware-in-the-loop and software in the loop simulation is known in the art2, although no such indication is presented in the disclosure.
---- This page is left blank after this line ----
Relevant Prior Art not used in Rejection
Prior art US 20220136930 A1 by ZHAO; Xiangmo et al. – teaches the second core simulator can be hardware-in-the-loop (HIL) simulator which is known in the art to be simulated with software in the loop (SIL) simulator for autonomous vehicle. This prior art may be used in future rejections to show detailed interaction between HIL (second core simulator) and SIL (first core simulator).
PNG
media_image9.png
582
658
media_image9.png
Greyscale
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 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 2, 5, 8-9, 12, 15 and 20 are newly rejected under 35 U.S.C. 103 as being unpatentable over US 20190050520 A1 by Alvarez; Ignacio et al., in view of US PGPUB No. US 20110288841 A1 by Larsson3; Johan et al..
Regarding Claims 1, 8 & 15 (Updated 10/2/2026)
Alvarez teaches (Claim 1) A server (Alvarez : [0056], [0060] & Fig.7) for providing an autonomous driving simulation architecture for testing an application (Alvarez: [0026]) , the server comprising/ (Claim 8). A method for providing an autonomous driving simulation architecture for testing an application, the method (Alvarez: [0026] & Fig.6) / (Claim 15). A non-transitory computer-readable storage medium (Alvarez: Fig.7 elements 704, 706, 716), storing instructions executable by at least one processor to perform a method (Alvarez: [0026] & Fig.6) comprising:
a storage storing a plurality of simulation data models (Alvarez: [0059]-[0060] & Fig.7; simulation models in [0015]-[0016], [0028]) ;
at least one processor (Alvarez : [0056][0058][0059] Fig.7 element 702) configured to execute instructions to implement:
at least one first interface to integrate the plurality of simulation data models with a first core simulator that runs a first autonomous driving simulation (Alvarez: Fig.6 step 608; interfaces in at least [0016] "... The vehicle performance fingerprint may be used to create vehicle physics models and to customize responses to control interfaces (e.g., acceleration, brakes, or steering) in the driving simulator. A vehicle physics model may include kinematic and dynamic models....") for testing the application (Alvarez: [0016] showing various vehicle physics models model integrated to control interfaces; Fig.2 element 230; Fig.6 step 608-610) ;
a common interface to selectively connect the first core simulator to a client device providing the application (Alvarez: [0033]-[0034] showing interface as driving directive unit controlling the simulated vehicle; Fig.6 step 605 ), wherein the common interface is configured to receive a command from the client device, the command being input by a user to selectively control a first switch (Alvarez: [0029] "... The simulation engine 200 may receive user input, such as through an IO connected device 205 (e.g., a keyboard) via the IO controller 210, to change values in the vehicle performance fingerprint and alter the construction of the simulated vehicle constructed by the simulation construction unit 225. For example, after performing simulations with the simulated vehicle, a testing engineer may wish to determine the effects of altering the specifications for the simulated vehicle. This may be done to assist in determining what alterations may be made to the vehicle so that is may handle and perform better....") ; and the first switch, wherein the first switch is configured to selectively disconnect a first simulation data model responsive to the command input by the user (Alvarez: [0029]-[0030] as above) , among the plurality of simulation data models, from the first core simulator (Alvarez: [0028] shows different version being switched over time), wherein the first switch disconnects the first simulation data model by switching from the first simulation data model to ,
Alvarez does not specifically teach wherein: the first switch disconnects the first simulation dummy model.
Alvarez does not specifically teach wherein the plurality of simulation data models comprises the first simulation data model, the first dummy model, a second simulation data model, and a second dummy model, wherein the first simulation data model and the first dummy model are vehicle simulation models for simulating one or more ego vehicles, and the second simulation data model and the second dummy model are sensor simulation models for simulating one or more sensors of the one or more ego vehicles, and wherein the first switch is configured to selectively disconnect the first simulation data model by switching to the first dummy model such that: (a) the first simulation data model is selectively connectable to the first core simulator together with the second simulation data model while the first dummy model is disconnected, and (b) the first dummy model is selectively connectable to the first core simulator together with the second simulation data model while the first simulation data model is disconnected.
Larsson teaches at least one second interface4 to integrate the plurality of simulation data models with a second core simulator5 that runs a second autonomous driving simulation for testing the application (Larsson: Second Interface can be related to hardware in the loop(HIL) models as discussed in Figs.21-22; first core simulator models can be software in the loop (SIL) models as discussed in Fig.21-22; [0109]-[0110]"... [0110] In FIG. 22, a view of a window 749 with a hardware in-the-loop (HIL) plot 750 and a SIL plot 751 for a certain object is shown. The HIL plot and the SIL plot are for vehicle speed and provided respectively during HIL testing and SIL testing...."), different from the first autonomous driving simulation, wherein the plurality of simulation data models are selectively connectable to the first core simulator via the at least one first interface (Larsson : [0041] SIL testing e.g. interface shown in Fig.11-12 for one of the plant selection models) and the second core simulator via the at least one second interface (Larsson: [0109]-[0110] HIL based simulation and testing) ;
Larson teaches a common interface to selectively connect the first core simulator and the second [core] interface to a client device providing the application (Larson: [0005]-[0006]; [0063] "... [0063] The plant model selecting module 90 selects a fidelity level of one or more plant models, such as the fidelity level of the plant models 38. A fidelity level refers to the complexity of the plant model and the degree to which the plant model accurately simulates corresponding components and/or systems of a vehicle. For example, a plant model may simulate a vehicle system with or without simulation of sensors. For example, when a low plant fidelity level is selected, an engine may be simulated and speed of the engine may be directly fed back to the transmission control block 36. As an alternative, when a high plant fidelity level is selected, operation of the engine and an engine speed sensor may be simulated. Output of an engine speed sensor block may be fed back to the transmission control block 36....")- all the selected models instances interact with each other and provide results to client (Host 70); the selecting can also be seen as selecting from hardware inputs as shown in [0051] "... [0051] The sensor signals, hardware inputs and outputs and CAN inputs may be provided using 3 different techniques. The techniques may be selected via selection blocks (shown in FIG. 9) of a driver input block. An example driver input block is shown in FIGS. 4 and 9. The first technique includes manually entering inputs via the GUI 32. Another example of a GUI is shown in FIG. 13. The second technique includes accessing predefined and stored input signals. Examples of predefined and stored input signals are shown in FIG. 10. The third technique includes accessing recorded vehicle signals. For example, a recorded vehicle signal may be a stored signal generated from a temperature sensor of a vehicle. The recorded vehicle signal may be used during a simulation as an input to the transmission model 36...."; [0052] "... The bypass models 64 may be used to replace or may be used as an alternative to model(s) in the transmission model 36. For example, the transmission model 36 may include a first model (first version) that simulates a ring. The incubator block may include a second model (second version) that simulates the same ring as that of the first model. Code associated with the first model and/or the second model may be executed during a simulation....").
Larsson teaches wherein the plurality of simulation data models comprises the first simulation data model, the first dummy model (Larsson: Fig.3 & [0054]-[0069], specifically Vehicle models 136, which may have high fidelity model (as first simulation model) and low fidelity model (as first dummy model); [0063]) , a second simulation data model, and a second dummy model (Larsson: Fig.3 & [0054]-[0069], specifically sensor models 126, which may have high fidelity model (as second simulation model) and low fidelity model (as second dummy model); [0063]),
wherein the first simulation data model and the first dummy model are vehicle simulation models for simulating one or more ego vehicles (Larsson: Fig.3 & [0054]-[0069], specifically Vehicle models 136, or , which may have high fidelity model (as first simulation model) and low fidelity model (as first dummy model); [0063]), and the second simulation data model and the second dummy model are sensor simulation models for simulating one or more sensors of the one or more ego vehicles (Larsson: Fig.3 & [0054]-[0069], specifically sensor models 126, trans models 134, actuation models 130, CAN models 128 which may have high fidelity model (as second simulation model) and low fidelity model (as second dummy model); [0063]), and
wherein the first switch is configured to selectively disconnect the first simulation data model by switching to the first dummy model (Larsson : Fig. 3 element Plant Model Selecting Module 90 & [0054][0063] [0118] "... [0118] At 820, updates performed at 810 and 818 are saved. At 822, the plant model selecting module 90 may select a plant model fidelity level based on a received user input signal....") such that: (a) the first simulation data model is selectively connectable to the first core simulator together with the second simulation data model while the first dummy model is disconnected (Larsson: [0063] high fidelity model) , and (b) the first dummy model is selectively connectable to the first core simulator together with the second simulation data model while the first simulation data model is disconnected (Larsson: [0063] low fidelity model) .
It would have been obvious to one (e.g. a designer) of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Larsson to Alvarez to select a plant model fidelity level based on a received user input signal (Larsson: [0063][0118]). Further motivation to combine would have been that Larsson and Alvarez are analogous art to the instant claim in the field of simulating autonomous vehicle behavior (Larsson: Abstract; Alvarez: Fig.6 flow 608).
Regarding Claims 2 & 9
Larsson teaches wherein the switching from the first simulation data model to a first dummy model, integrates the first dummy model with the first core simulator via the at least one first interface (Larsson: See Fig.12 [0092]-0093] for plant (vehicle/sensor model) fidelity selection interface; See [0131] "... The above-described embodiments allow control module algorithm models to be integrated into a vehicle simulation model such that a user can selectively execute auto generated code for a SIL block. The embodiments provide user selectable plant model fidelity levels. Driving cycles are selectable with GUI control. Algorithm model development is facilitated via generation of SIL blocks and/or corresponding bypass switches. ..."Fig.2 [0051] interface as graphical user interface (GUI) to accept inputs, such as selection to which model to simulate, Larsson Claim 8 "... activating user inputs (i) received by SIL block of the vehicle simulation model and (ii) displayed on a graphical user interface; selecting a pre-defined signal set; and selecting a vehicle recorded signal set, wherein the simulation control module executes the one of the first simulation model and the second simulation model based on the selected set of inputs....";).; and wherein the first dummy model is of lower accuracy than the first simulation data model (Larsson: [0063]) .
Regarding Claims 5 & 12
Larsson teaches The server of claim 1, wherein the at least one processor is further configured to execute the instructions to implement a second switch to selectively switch between a second simulation data model (Larsson: Fig.12 fidelity selection; Fig.9 showing plurality of switches part of bypass switching module 98) , among the plurality of simulation data models, and a second dummy model, for integration with the first core simulator ( (Larsson: Fig.3 shows plurality of sensor models which are also selectable based on fidelity [0063]; Fig.12 [0092]-[0093] "... The first fidelity level may simulate a simplified transmission fork actuation system relative to that simulated using the second fidelity level....") .
Regarding Claim 20 (New)
Larsson teaches The server of claim 1, wherein the first core simulator and the second core simulator respectively define a virtual world of the first and second autonomous driving simulations, respectively (Larsson: [0132]"... Transmission algorithm development is provided using a virtual vehicle environment without use of vehicle hardware...." ) , and execute a scenario in which the first and second autonomous driving simulations are respectively run selectively using the plurality of simulation data models (Larsson: shows selectively running various plant models as shown in Fig.3 & [0131]) .
---- This page is left blank after this line ----
Claim(s) 3-4, 7, 10-11, 14, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Alvarez, in view of Larsson, further in view of US PGPUB No. US 20200001888 A1 by PRETSCH; Christian et al.
Regarding Claims 3 & 10 (Updated 10/2/26)
Teachings of Alvarez & Larsson are shown in the parent claim 1.
Alvarez & Larsson does not specifically teach wherein the at least one processor is further configured to execute the instructions to implement at least one second interface to connect one or more of the plurality of simulation data models with a second core simulator.
Pretsch teaches wherein the first core simulator is configured for a software in the loop simulation (Pretsch : [0023] sensor model – [0004] "... or this purpose, the procedure has in the meantime been adopted of also using a mathematical model to model and simulate the series-control device, that is to say the control device hardware or at least the software which is close to the hardware. Such a control device can be simulated at varying levels physical detail...."; [0017] "... Raw format of the static environmental data is a data description of the static surroundings which is not adapted to the simulation surroundings of the simulator (software) or to the equipment level of the simulator and its computing units (hardware)....") and the second core simulator is configured for a hardware in the loop simulation (Pretsch: [0049] "... As a result, the desired simulation is in many cases only made possible, for example, if the simulation is based on speed requirements, in the case of classic HIL simulations this is the requirement for a real time simulation....") .
It would have been obvious to one (e.g. a designer) of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Pretsch to Alvarez to distribute the various sensor models/vehicle model to reduce the data exchange load across common interface (Pretsch: [0016]-[0024], [0049], [0051]). Further motivation to combine would have been that Pretsch and Alvarez are analogous art to the instant claim in the field of vehicle/sensor model simulation (Pretsch: [0051]; Alvarez: Abstract; Fig.6 flow 608).
Regarding Claims 4 & 11 (Updated 10/2/2026)
Pretsch & Alvarez teaches The server of claim 3/10, wherein the common interface is configured to translate or convert a first data format of the first core simulator to a common data format used to communicate with the application, and to translate or convert a second data format, different from the first data format, of the second core simulator to the common data format used to communicate with the application. (Pretsch: [0054] "... [0054] In the exemplary embodiment according to FIG. 5 there is provision that before the storage in the directly accessible memories of the identified computing units 4b, 4c the static environmental data 14a is transformed from a raw format E.sub.stat,R into a data structure format E.sub.stat,S on a host computer 15. The transformed static environmental data 14a is then transmitted from the host computer 15 to the individual computing units 4a, 4b, 4c. In addition to the identified computing unit 4b, 4c, the computing unit 4a also receives the static environmental data 14a, since the entire environmental model 14 is calculated on it. For the transformation, the host computer 15 must have precise knowledge of the software and hardware conditions at the computing units 4...." Fig.9 element 17 showing the common interface connecting first (12a)/second(4a/4b) core simulator to client device 16 & Alvarez: shows the server client implementation). Motivation to combine Pretsch & Alvarez is incorporated from the parent claim.
Regarding Claims 6 & 13 (Cancelled).
Regarding Claims 7 & 14
Pretsch & Alvarez both teaches The server of claim 1/8, wherein the at least one first interface is configured to convert data between one or more data formats of the plurality of simulation data models and a data format of the first core simulator (Alvarez: [0024], [0039]; Pretsch: [0016]-[0023]) . Larsson teaches wherein a data format of the first simulation data model is different from a data format of the second simulation data model, and the data format of the first core simulator is different from the data formats of the first simulation data model and the second simulation data model, such that the at least one first interface is configured to convert data of the first simulation data model from the data format of the first simulation data model to the data format of the first core simulator and to convert data of the second simulation data model from the data format of the second simulation data model to the data format of the first core simulator (Larsson: [0065]"... The source code based library 110 includes models (or model sets 121) that are generated based on source code and/or hand code. The source code and/or hand code is converted to model-based code that can be loaded in a model-based environment. The models and corresponding blocks may be viewed in a simulation environment as models generated using model-based software. The models may include .xml files 123, .dll and .lib files 125 and .zip files 127...."); [0080]-[0086], where each of the first (vehicle model) and second (sensor model at least) model are identified in Fig.3).
Motivation to combine Pretsch & Larson & Alvarez is incorporated from the parent claim.
Regarding Claim 18 (Updated 10/2/26)
wherein the at least one second interface is configured to convert data between the one or more data formats of the plurality of simulation data models and a data format of the second core simulator, wherein the data format of the second core simulator is different from the data format of the second core simulator (Pretsch: [0054] "... [0054] In the exemplary embodiment according to FIG. 5 there is provision that before the storage in the directly accessible memories of the identified computing units 4b, 4c the static environmental data 14a is transformed from a raw format E.sub.stat,R into a data structure format E.sub.stat,S on a host computer 15. The transformed static environmental data 14a is then transmitted from the host computer 15 to the individual computing units 4a, 4b, 4c. In addition to the identified computing unit 4b, 4c, the computing unit 4a also receives the static environmental data 14a, since the entire environmental model 14 is calculated on it. For the transformation, the host computer 15 must have precise knowledge of the software and hardware conditions at the computing units 4...." Fig.9 element 17 showing the common interface connecting first (12a)/second(4a/4b) core simulator to client device 16 & Alvarez: shows the server client implementation). Motivation to combine Pretsch & Alvarez is incorporated from the parent claim.
Regarding Claim 19 (New)
Pretsch teaches The server of claim 18, wherein the common interface is configured to translate or convert the data format of the first core simulator to a common data format used to communicate with the application (Pretsch: Fig.9 shows client/application can be ECU connected to the core simulator 5 having core simulators 4a, 4b, 4c) , and to translate or convert the data format of the second core simulator, different from the data format of the first core simulator, to the common data format used to communicate with the application (Pretsch: [0054] "... [0054] In the exemplary embodiment according to FIG. 5 there is provision that before the storage in the directly accessible memories of the identified computing units 4b, 4c the static environmental data 14a is transformed from a raw format E.sub.stat,R into a data structure format E.sub.stat,S on a host computer 15. The transformed static environmental data 14a is then transmitted from the host computer 15 to the individual computing units 4a, 4b, 4c [considered as first core simulator, second core simulator etc respectively] . In addition to the identified computing unit 4b, 4c, the computing unit 4a also receives the static environmental data 14a, since the entire environmental model 14 is calculated on it. For the transformation, the host computer 15 must have precise knowledge of the software and hardware conditions at the computing units 4. If the simulator 5 had, for example, a further computing unit on which just one vehicle model were calculated, the static environmental data would not be transmitted to this computing unit....") .
Regarding Claim 16
Pretsch teaches The server of claim 1, wherein the at least one processor is further configured to execute the instructions to test a perception application (Pretsch : [0009] perception application as sensor model) and to not test a vehicle simulation model, wherein the first data model is the vehicle simulation model (Pretsch: [0051] "... In the illustrated exemplary embodiment, the vehicle models 12 and the sensor models 13 are calculated independently of one another on different computing units 4...") .
Regarding Claim 17
Pretsch teaches The server of claim 16, wherein the perception application simulates a camera (Pretsch: [0040]) , the vehicle simulation model simulates an engine, and the selectively disconnect a first simulation data model responsive to the command input by the user causes the engine to not be simulated (Pretsch: [0051] "... In the illustrated exemplary embodiment, the vehicle models 12 and the sensor models 13 are calculated independently of one another on different computing units 4..." a first simulation data model is the vehicle model).
---- This page is left blank after this line ----
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.
---- This page is left blank after this line ----
Communication
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AKASH SAXENA whose telephone number is (571)272-8351. The examiner can normally be reached Mon-Fri, 7AM-3:30PM.
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, RYAN PITARO can be reached on (571) 272-4071. 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.
AKASH SAXENA
Primary Examiner
Art Unit 2188
/AKASH SAXENA/Primary Examiner, Art Unit 2188 Friday, October 2, 2026
1 Larsson identified in PE2E Search string L56.
2 US 20220136930 A1 by ZHAO; Xiangmo et al.
3 Larsson identified in PE2E Search string L56.
4 Interface is not understood as graphical user interface but a medium through which the results can be communicated. See specification [0067].
5 The second core simulator can be hardware-in-the-loop (HIL) simulator which is known in the art to be simulated with software in the loop (SIL) simulator as shown in Prior art US 20220136930 A1 by ZHAO; Xiangmo et al. – this prior art may be used in future rejections to show detailed interaction between HIL (second core simulator) and SIL (first core simulator).
