DETAILED ACTION
This action is in response to the amendments filed on Mar. 23rd, 2026. A summary of this action:
Claims 1-22 have been presented for examination.
Claims 11 and 22 are objected to because of informalities
As a point of clarity on having multiple § 102/103 rejection, see MPEP § 2120(I): “Prior art rejections should ordinarily be confined strictly to the best available art. Exceptions may properly be made, for example, where: (A) the propriety of a 35 U.S.C. 102 or 103 rejection depends on a particular interpretation of a claim;… In the interest of compact prosecution, such rejections should be backed up by the best other art rejections available. Keep in mind the best backup rejection(s) could be based on alternate embodiments from the same "best available" reference(s).” – i.e. multiple rejections are presented below, depending on whether patentable weight is assigned to the preamble’s intended use.
Claim(s) 1, 3, 11-12, 14, and 22 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017.
Claim(s) 2 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017
Claim(s) 1-3, 5-14, 16-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamaura, Masahiro, et al. "ADAS virtual prototyping using modelica and unity co-simulation via openmeta." The First Japanese Modelica Conferences. No. 124. 2016 in view of Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017
Claim(s) 4 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamaura, Masahiro, et al. "ADAS virtual prototyping using modelica and unity co-simulation via openmeta." The First Japanese Modelica Conferences. No. 124. 2016 in view of Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017 and in further view of Jayaraman, Arvind, Ashley Micks, and Ethan Gross. Creating 3d virtual driving environments for simulation-aided development of autonomous driving and active safety. No. 2017-01-0107. SAE Technical Paper, 2017
Claims 1-2, 4-13, 15-22 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2, 4-8, 9-10, 12-16 of U.S. Patent No. 12061846.
Claims 3 and 14 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2, 4-8, 9-10, 12-16 of U.S. Patent No. 12061846 in view of Liu, “A New Concept of a Generic Co-Simulation Platform for Energy Systems Modeling”, 2017
This action is Final
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 .
Response to Arguments/Amendments
Regarding the objects and § 112(b) rejection
Withdrawn in view of the amendments.
Regarding the Double Patenting Rejection
Maintained, updated as necessitated by amendment.
Remarks submit request for abeyance, however per MPEP § 804(I)(B)(1): “As filing a terminal disclaimer, or filing a showing that the claims subject to the rejection are patentably distinct from the reference application’s claims, is necessary for further consideration of the rejection of the claims, such a filing should not be held in abeyance. Only compliance with objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated. Replies with an omission should be treated as provided in MPEP § 714.03. Therefore, an application must not be allowed unless the required compliant terminal disclaimer(s) is/are filed and/or the withdrawal of the nonstatutory double patenting rejection(s) is made of record by the examiner.” – and see MPEP § 714.03 title: “ Amendments Not Fully Responsive, Action To Be Taken”
At present, the Examiner treats this a “minor deficiency” and acts on the amendment and response.
Regarding the § 102
Maintained.
With respect to the remarks at 8-9, first they allege an inherent advantage, but no evidence is shown to demonstrate inherency, either via specification or extrinsic evidence. MPEP § 2163.07(a): “In re Smythe, 480 F. 2d 1376, 178 USPQ 279 (CCPA 1973); Yeda Research and Dev. Co. v. Abbott GMBH & Co., 837 F.3d 1341, 120 USPQ2d 1299 (Fed. Cir. 2016) ("Under the doctrine of inherent disclosure, when a specification describes an invention that has certain undisclosed yet inherent properties, that specification serves as adequate written description to support a subsequent patent application that explicitly recites the invention’s inherent properties." (citing Kennecott Corp. v. Kyocera Int’l, Inc., 835 F.2d 1419, 1423, 5 USPQ2d 1194, 1198 (Fed. Cir. 1987))). "To establish inherency, the extrinsic evidence ‘must make clear that the missing descriptive matter is necessarily present in the thing described in the reference, and that it would be so recognized by persons of ordinary skill. Inherency, however, may not be established by probabilities or possibilities. The mere fact that a certain thing may result from a given set of circumstances is not sufficient.’" In re Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999) (citations omitted)”
Furthermore, it alleges that the simulations are decoupled and independent, however the disclosure of the as filed specification shows otherwise.
See figure 1, for “gPRC” between the simulation engine container and the SUT container.
To clarify on the relevance of this, see the appendix in the instant provisional application 62802108, appendix B, : “SUTs are stored and executed within Docker containers publis!1ed to a private Docker registry created just for your organization and hosted in your Metamoto private cloud. Pushed Docker images are available in Vecotrs if your Ego Vehicle configuration has any Sensors or Controllers that are marked as System Under Test…Your SUT must implement the gRPC Sensor OR Controller service, to handle the corresponding gRPC requests sent to it from the simulation engine.
See in appendix B # 1 SUT requirements ¶¶ 1-3: “SUT binaries must support one of the command-line arguments -port XXXX or ···•port XXXX and start their gRPC server on 0.0.0.0.XXXX...Be sure your SUT is not writing any files to local directory…when it is executed in a container in the cloud. Instead, use the results_directory that is passed to the SUTs Initialize() method…” – and note # 3 ¶ 2; then see # 8, noting in particular “the Getting Stated Tutorial for an example of integrating an external SUT” with presumably the “Sensor or Controller” container as also discussed (note this container needs the “absolute path to the SUT executable”
Then, see appendix D, subsection “Engine”: “…The Engine provides a gRPC-based API that SUTs use to integrate into a simulation”.
See Liu, fig. 3, note the use of a Rest API instead of gRPC (note, RPC is well-known to stand for remote procedure call), i.e. both systems are required to pass messages via an API between the various simulators.
Remarks do not address what is actually the disclosed as filed specification.
With respect to the remarks at 9 to 10 regarding: “the claim requires a single simulation engine container that executes the simulation and it is connected to the system under test containers for data therefrom as they operate during the simulation” and similar such remarks – see above, for the claim requires that the simulation engine container is to for an executed simulation wherein this is connected to the SUT container. More particularly, these remarks appear to imply that SUT container is not to perform any co-simulation, but again see the provisional appendix as discussed above, i.e. its receives gRPC requests senit to it for it to handle as it is a “service”, and has its own “SUT code” (Appendix B), and # 1 in appendix B see ¶¶ 1-2 and # 2 for building the SUT, # 3 for copying hte SUT executable into the SUT container, etc.
Then, see ¶ 45 of the as filed specification: “…The simulation engine 114 may serve as a source of "control" aspects of a given simulation, in order to test the components and features of the SUT(s) of the user” - i.e. its simulating everything but the user provided SUT code. ¶ 46: “The container-based approach of the Director 104 advantageously enables a user to provide a component of an autonomous vehicle control system-e.g., a specific sensor, a specific sensor arrangement, a specific vehicle control strategy for a specific event” – in view of ¶ 42: “In embodiments, the functionality of one or more sensors are simulated through the Director 104. The underlying mathematical models of such sensors may be based on known physics of the interaction between a sensor's sensing means ( e.g., a laser, electromagnetic pulses for radar, etc.), applied in the digital simulated scene through ray tracing techniques, computer shaders, finite difference analysis, finite element analysis, finite volume analysis, method of moments and/or simplified models…” See ¶¶ 56-57 as well.
See ¶ 62: “Each simulation may include moving the ego vehicle through a test scenario according to the control logic of the ego vehicle. The simulated control logic, in turn, may respond to the simulated input from the one or more sensors.”
In sum, the specification as filed and the provisional application make clear that SUT container performs a simulation of the SUT, and the simulation engine container performs a simulation of the other parts. In the exemplary, the SUT is a simulated sensor (or controller; see provisional), and the simulation engine container is the ego vehicle and the like, i.e. several things but not that sensor. These use an API to pass messages between the two containers.
See Liu, fig. 3 as discussed above. In particular, note “Simulator X”, “Simulator Y”, and “Simulator Z” – even the lettering makes clear these are distinct simulations, unlike the alleged remarks which appear to mischaracterize the claimed invention with respect to the as filed disclosure and provisional application. Liu fig 2 further clarify: “Simulator 1” corresponds to “S1”, etc. See the other relied upon portions of Liu.
Liu teaches what is claimed.
With respect to the remarks at 10 regarding “As such, while Liu discloses simulation of a wind turbine model, it does not teach or suggest treating that model as a system under test, because Liu's architecture fails to distinguish a test target, i.e., system under test, from the simulation environment. Instead, all simulation nodes in Liu operate as peer components in a co-simulation…” – again, see Liu – the SUT in the example of Liu is the wind power turbine, and the simulation engine container is the weather simulation node. See above citations to provisional on the gRPC for the messages via this API passed between the two, and see the art rejection and its particular citations.
These remarks alleging an unreasonable interpretation of these claims inconsistent with both the as-filed disclosure and provisional application.
Should further clarification be sought on an example of where a user might provide such a sensor simulation for the SUT container, see previously cited Chi, at page 4 ¶ 2: “Sensor simulation is also a key area of development for Metamoto, because the sensors required for autonomous driving are constantly evolving and not yet fully standardized. There are traditional radars, new radar companies, and new sensors like LiDAR, all of which are note ncountered in traditional simulation. Interestingly, Chad [CEO of Metamoto at the time of the article] mentioned that after talking with OEMs, they found that they tend to purchase LiDAR sensors with corresponding simulation solutions.”
With respect to the remarks at 10 for the parameter partitioning, the claim recites: “creating a simulation engine container instance that is configured to receive values for at least a first portion of a set of parameters; creating one or more system under test instance containers that are configured to receive values for at least a second portion of the set of parameters; connecting the simulation engine container instance to the one or more system
under test instance containers; receiving a first set of parameter values for the set of parameters; executing the simulation engine container instance using the first set of parameter values; and” – i.e. some of the set of parameter values are to the SUT; others in the set are to the simulation engine container – see Liu, as relied upon in § IV: “the wind turbine simulation node is parameterized by setting the values of a list of static configuration parameters which specify the height of the wind turbine and the diameter of its rotor. Similarly, the weather simulation node or weather data source node is configured to send weather data according to a certain time scheme (e.g. every 5 seconds)."” And cf. 5 and 7, i.e. there are a plurality/set of parameter values to run the co-simulation, some of them are used in Liu to configure/set the parameters of the wind turbine simulation, and others are used for configuring the weather simulation node, e.g. time scheme such as period of time, and on viewing fig. 7 and noting January was the time in 2010, POSITA would have also inferred the time range of the weather was also configured for the weather simulation (i.e. simulate the weather data from Jan. 2nd, 2010 to Jan. 31st, 2010) as part of the “time scheme”.
To further clarify, given this is an example application of Liu per Liu, see Liu fig. 1 for the “Co-Simulation Configuration Storage” and its multiple “Config” files”; i.e. as detailed in the example in Liu there are a set of parameters for configuring the simulators (i.e. the collection of config files), wherein each simulator is using at least a portion of the set of config files, and to execute the simulation all of the config. files are used.
Also, note that the claim recites “at least a… portion” and “comprising” (i.e. an open-ended phrase that does not excluded unclaimed subject matter; MPEP § 2111.03), i.e. its not limited to even partitioning the parameter set as alleged, but rather even encompasses in its breadth that each container uses all of the parameter set, as it merely requires that it uses at least a portion of each set.
With respect to the remarks at 11 for the unified parameter set, see above.
With respect to the remarks at 11 regarding the connecting step, claim has no such exclusionary basis expressly recited, i.e. it does not state the manner in which the connection is required to be, nor place an exclusion for having a connection between the two containers via Liu’s message server. To clarify, see the preamble for the “comprising”, i.e. it is an open-ended claim.
To further clarify, what is shown in the exemplary fig. 1 (i.e. should an exclusionary provision to exclude the architecture of Liu be amended into the claims) is commonly referred to a brokerless architecture, whereas Liu’s is commonly referred to as a brokered architecture (the Kaftka server). But this is not what is claimed, for the claim does not exclude the two modules being connected with a middleman (the Kafka server of Liu) in the connection, but rather includes it by having an open-ended transitional phrase of “comprising”.
To clarify, Liu teaches:
connecting the simulation engine container instance to the one or more system
under test instance containers via a messaging server; - which is within the scope of the present claims.
And even if it was by recitation of an exclusionary limitation expressly in the claim itself (e.g. directly connected without a messaging server), newly cited art of record indicates that this may have been obvious, e.g.
Tasci, Timur, Jan Melcher, and Alexander Verl. "A container-based architecture for real-time control applications." 2018 IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC). IEEE, 2018.
See Tasci, § III, subsection C on “Messaging”: “The advantages of the container architecture are most apparent when a control system is split into multiple modules. These modules need a way to synchronize and send data to each other. In a conventional, monolithic application, modules can communicate using simple function calls and shared memory. When modules run in different containers, they can no longer call each other and they cannot necessarily access shared memory. Instead, the modules can communicate over network protocol…” then see in this subsection # 2: “Message brokers are components that receive messages and route them to their destination. Employing a message broker in an architecture has many benefits as it brings features that are likely to be required from service discovery over management to monitoring. However, its main disadvantage – the introduced latency and overhead – has to be considered, especially for a real-time application… once from the broker to the next module – is significant. …Therefore, the disadvantage of the extra overhead introduced by a broker is emphasized in our architecture…”
Then, see # 3: “In a messaging system without a broker, the whole messaging functionality needs to be implemented in the communicating modules themselves. The brokerless messaging framework ZeroMQ implements a variety of transport mechanisms from in-process to network protocols and offers a clean uniform API…” – see # 4 including “…There is no canonical categorization of messaging patterns, but the ones defined by ZeroMQ [16] match our use case well, because they are designed for a brokerless system. In total, four patterns are provided: Request-Reply, PublishSubscribe, Push-Pull (or Pipeline) and Exclusive pair…. The bottom row shows the result of adding a third module M3, which needs to process the result of M2 before it is sent to M1. In this bidirectional case, the result is passed through M2 because request and reply flow cannot be separated; in the unidirectional case, the transport is direct…” then # 6: “A brokerless solution is preferred because it minimizes latency, which is especially important in loops with small cycle period lengths. The Publish-Subscribe messaging pattern should be supported explicitly because it is needed to implement the requirements and it cannot easily be implemented without framework support. Other patterns like Request-Reply do not need special support because they can be implemented within the modules.”
To clarify, see § III.E: “Fig. 4 illustrates the architecture from a functional view. An application consists of several modules (M1, M2, and M3 in the example). A module is a piece of executable software (in the form of a container image), combined with its metadata….: - and see the accompanying fig. 5 clarifying this is in the “Docker environment” [same as Liu]” and see § V: “We analyzed the opportunities and challenges that come with a real-time control application based on containers and proposed a reference architecture that enables reusability, portability and flexibility. The architecture incorporates solutions for communication between containers and between containers and hardware…”
See pertinent prior art newly cited below for additional clarification.
With respect to the remarks at 11 regarding Liu conceptually, this alleging unrecited features, and also see above. Also this fails to point out how the claim itself distinguishes from Liu.
With respect to the remarks at 11 regarding Liu regarding the single model, see above, for that is not what the claim scope is, nor what is conveyed in the instant specification or provisional application as discussed, with substantial citation, above.
With respect to remarks at 12, regarding the AV, its an intended use for the purposes of the § 102 rejection, as it exists purely in the preamble as an intent of how this could be used, but the body of the claim sets forth no express recitation of doing this. See the § 103 should it not be found to be an intended use.
Regarding the § 103
Maintained, updated as necessitated by amendment.
With respect to the remarks at 13 these are conclusory and don’t state how the claim is distinguished from the prior art.
With respect to remarks at 14 regarding “test targets” – as discussed above, the examples of such SUTs in the instant specification and provisional are simulating sensors or controllers for an AV. See Yamaura as relied upon - “…we propose a closed-loop simulation framework that improves ADAS design and evaluation [testing AVs]. …Simulink is used for vehicle control software modeling” and “The sensor data in Unity is also sent to the Simulink controller via UDP” – then, § 4: “As the first case study for this simulation toolchain with PET, we decided to model the Adaptive Cruise Control (ACC) system [the system under test].” – see § 4.4 to further clarify, as this is discussing the evaluation of the test results of the control system under test in Yamaura.
And for testing a sensor, see the § 103 for claim 4.
With respect to the containers, this is purely a piecemeal attack against Yamura alone and fails to address the § 103 combination that was relied upon, i.e. Yamura teaches a simulation environment with multiple simulators using UDP to communicate between the simulators (e.g. fig. 2, and other citations as relied upon).
The distinction is that Yamura is not containerizing the simulators, however Liu was relied upon for this feature, for the detailed rationale stated in the rejection and left unaddressed.
With respect to the remarks at 14 regarding the partitioning of parameters, the Examienr respectfully disagrees for similar reasons as detailed above in the § 102 rejection regarding claim interpretation, and to clarify on Yamura see the cited portions of Yamura, i.e. Unity has per table 2 and fig. 4(1) parameters such as the initial speed and the like as discussed, and § 4.4 discusses portions of the set of parameters for the simulation that were used in the other simulators.
With respect to remarks at 14 regarding the communication, see the discussion of Liu and the BRI in the § 102 rejection on a similar set of remarks above.
With respect to remarks at 14 regarding the parameters, see above.
With respect to the remarks at 15 regarding the motivation, these are moot and conclusory.
With respect to the remarks at 15 regarding Yamura in view of Liu, this is implying an attack on analgous art. MPEP 2141.01(a): “In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). Note that "same field of endeavor" and "reasonably pertinent" are two separate tests for establishing analogous art; it is not necessary for a reference to fulfill both tests in order to qualify as analogous art. See Bigio, 381 F.3d at 1325, 72 USPQ2d at 1212” – thus, as even pointed two in the remarks, both are in the same field of endeavor of “co-simulation”, and furthermore Liu is pertitent to the problem faced by the instant inventor of doing co-simulation in the Docker container environment (see provisional application as discussed above to clarify).
Notice of potential § 102(a)(1) issue
See MPEP § 2120.02, with respect to the requirement for information.
For the time being, the present claims are rejected in view of the best possible art of record (MPEP § 2120(I)).
However, evidence (see below) is now of record that indicates that the presently claimed invention may have been on sale, or otherwise available to the public, or in public use, prior to the grace period of § 102, but the evidence does not yet necessitate a rejection for this reason, as the evidence does not fully anticipate, nor make obvious, each and every feature recited in ordered combination in the present claims. MPEP 2133.03(b): “An impermissible sale has occurred if there was a definite sale, or offer to sell, more than 1 year before the effective filing date of the claimed invention and the subject matter of the sale, or offer to sell, fully anticipated the claimed invention or would have rendered the claimed invention obvious by its addition to the prior art.”
To clarify, MPEP § 2133.03(c)(I), and (III): “Minton v. National Ass’n. of Securities Dealers, Inc., 336 F.3d 1373, 1378, 67 USPQ2d 1614, 1618 (Fed. Cir. 2003) (finding a fully operational computer program implementing and thus embodying the claimed method to trigger the on-sale bar). However, the sale of a prior art device different from that disclosed in a patent that is asserted after the critical date to be capable of performing the claimed method is not an on-sale bar of the process. Poly-America LP v. GSE Lining Tech. Inc., 383 F.3d 1303, 1308-09, 72 USPQ2d 1685, 1688-89 (Fed. Cir. 2004) (stating that the transaction involving the sale of the prior art device did not involve a transaction of the claimed method but instead only a device different from that described in the patent for carrying out the claimed method, where the device was not used to practice the claimed method until well after the critical date, and where there was evidence that it was not even known whether the device could perform the claimed process”
Also note MPEP § 2133.03(e) and also see MPEP § 2133.03(a).
At present, no requirement for information is made, as sufficient evidence of unpatentability in view of other prior art exists, as discussed below.
Should all reasonably applicable grounds of rejection be overcome, and the only remaining question is whether or not the present invention was on public sale/use/otherwise available to the public, then the Examiner shall further consider, at that time, making a requirement for information.
Should such information be material to patentability of the presently claimed invention, the Examiner suggests that, to aid in compact prosecution, the applicant provide such information anyway, regardless of there being no requirement of information being made yet.
Metamoto, Website Homepage, accessed via the WayBack Machine with archive date of Jan. 2018, URL: metamoto(dot)com – see its “News” section, including pointing to the news article on Leiphone.
See Zhang Chi, “Autonomous driving simulation systems are becoming anew hot topic, and Metamoto aims to provide large-scale simulation-as-a-service.”, News article on Leiphone, Nov. 2017, machine-translation by Google Chrome into English, URL: leiphone(dot)com/category/transportation/Dew0qfWC601HBspX(dot)html
In particular, in Chi, see “Metamoto is also a Silicon Valley company that provides autonomous driving simulation services. It offers cloud-based, scalable Simulation as a Service (SAS) that allows all autonomous driving system components to be placed in a cloud environment for testing unique edge cases, thereby increasing system reliability on top of physical environment testing. Metamoto charges based on the time spent using the simulation service, similar to using AWS cloud computing services… “What autonomous driving needs is a massively scalable simulation service capable of conducting millions of tests simultaneously, just like Google does, but Google doesn’t provide its technology to external parties. Current simulation services are driver/hardware in the loop.”… “The simulations required for autonomous driving systems are geared towards machines and software, while traditional simulations are geared towards the driver. We have achieved true Software in the Loop in the cloud…. To make autonomous driving safer and more reliable, sufficient testing scenarios are needed. Chad told Leifeng.com that Metamoto hopes its partner companies can share data and build a collection of scenarios. For example, Tesla accidents can be simulated to form a new Corner Case and accumulated into a set. Of course, more importantly, Metamoto can also parameterize scenes. For example, in a specific scene, factors such as time, weather, road conditions, and road signs can be changed. It can even change the sensor configuration, data latency, and communication status in a simulated environment. This allows for the creation of more scenarios from a single scenario… Metamoto's scenario development tools also include different vehicle types and allow for flexible sensor configuration, enabling users to understand the impact of these configurations on the system. Chad stated that this is an important part of simulation and represents another application scenario and value. Sensor simulation is also a key area of development for Metamoto, because the sensors required for autonomous driving are constantly evolving and not yet fully standardized. There are traditional radars, new radar companies, and new sensors like LiDAR, all of which are not encountered in traditional simulation. Interestingly, Chad mentioned that after talking with OEMs, they found that they tend to purchase LiDAR sensors with corresponding simulation solutions. Currently, Metamoto already has some early adopters, including car manufacturers, Tier 1 suppliers, autonomous driving system companies, and sensor companies.” – and, the Examiner further notes the two pictures in Chi showing the simulation software in use.
Claim Rejections - 35 USC § 101
While some of the present dependent claims (claims 9-10 and 20-21) may recite a mental process, this is not the focus of the claimed advance, i.e. the claims are not directed to the mental process, but rather directed to a particular computerized implementation for executing a simulation by means of using coupled/connected containers (containers such as Docker containers, see the instant provisional application for clarification, and the prosecution record of the instant parent non-provisional application as well), i.e. its rooted in the software arts for what is presently claimed as the focus of the claimed advance. E.g. see Enfish and BASCOM as discussed in the MPEP including § 2106.04(d)(1). See Research Corp. in MPEP § 2106.04(a)(2)(III)(A) as well.
See ¶ 20 to clarify, as the present claims are current directed to the particular computer implementation of the simulation architecture with container technology, providing the improvement to technology discussed in ¶ 20.
Claim Rejections - 35 USC § 102
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 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.
Claim(s) 1, 3, 11-12, 14, and 22 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017.
Regarding Claim 1
Liu teaches:
A method for performing an electronic simulation of an autonomous vehicle using container instances, the method comprising: (Liu, abstract, teaches a “co-simulation” system using “Docker Containers”, the intended use of doing this for an AV is not given any patentable weight, as no limitation in the independent claim positively recites what is to be simulated. See MPEP § 2111.01(II))
creating a simulation engine container instance that is configured to receive values for at least a first portion of a set of parameters; creating one or more system under test instance containers that are configured to receive values for at least a second portion of the set of parameters; connecting the simulation engine container instance to the one or more system under test instance containers; (Liu, § III, incl. seeing fig. 1 which visually represents the “Co-simulation platform” wherein each “Simulator” is in a distinctly different container (see fig. 3 to further clarify, its “Docker-Container[s]” for each of the simulators , wherein these are all connected to each other via the “Rest API” communicating via the “Communication Infrastructure”, wherein there a plurality of “Config” files to starting the simulations. See Liu, § III.A: “The co-simulation service connects, starts, monitors and controls the different Docker containers running the simulators automatically based on the co-simulation configuration described by a JSON format. Generic microservices implementing the communication infrastructure provide access to Kafka message channels for exchanging data between individual simulation nodes and data services. Specific adapters for different simulators connect the simulators to the communication infrastructure and the co-simulation service.” – to further clarify, see § III.B and § III.C, include seeing fig. 3 which explicitly states the “Docker” “Containers” in use, note § III.D discusses the use of a “adapter” for connecting the simulations, include seeing its discussion in the last paragraph: “While the Matlab adapter is clearly specific to Matlab, many simulators (including Matlab) support the Functional Mockup Interface (FMI) standard for model and data exchange in co-simulations. The FMI standard defines a standard CAPI for data exchange which can be used together with all simulators supporting this standard. Thus, the co-simulation platform implements a generic FMI adapter that allows to connect all simulators to the co-simulation platform, which implement the FMI specification. This connects a whole bunch of simulators to the co-simulation platform in a very generic way.”
Then, see an example application of this in § IV: “As another more practical but simple modeling example for the usage of the co-simulation platform, a co-simulation of a wind power turbine simulating its power output [example of a system under test] in one node and providing input data (e.g. wind velocity and temperature) by a second weather simulation node [example of the simulation container] or weather data source node will be demonstrated. Fig. 5 illustrates the concept of the co-simulation which consists of two simulators:… A data source or simulation node that generates or retrieves input data of the wind power turbine, such as pressure, wind velocity, temperature and the roughness length, and provides it to the wind turbine model (and potentially other simulation nodes) via an Apache Kafka queue with a topic named “Weather-Information” 2) A Python simulator that uses the library “windpowerlib” which is provided by the Python Software Foundation (US) to build up diverse practical wind power models and used to calculate time series of electricity production output of the wind power plant based on the weather input data [12]… Firstly, before a simulation is started, the wind turbine simulation node is parameterized by setting the values of a list of static configuration parameters which specify the height of the wind turbine and the diameter of its rotor. Similarly, the weather simulation node or weather data source node is configured to send weather data according to a certain time scheme (e.g. every 5 seconds).”
As further clarification, § V: “The flexibility that this co-simulation provides allows users to upload different kinds of simulators (power grid and technical plant models) and various types of data sources as well as real hardware nodes instrumented by measurement devices (electrical power grid and others) to build up and operate customized cosimulations for simulating and solving large multi-domain future energy system problems. It is also possible that users choose and combine simulators that already exist on the platform to set up a co-simulation with only using existing simulation or data source components and just tuning their configurations…In the future, a larger modeling library has to be integrated into the framework for building up complicated co-simulations, which will instrument other simulation environments, such as Modelica tools, Simulink, OpenDSS, DigSilent (power factory), PSLF (positive sequence load flow), etc., in order to further improve the generic applicability of the platform…”
receiving a first set of parameter values for the set of parameters; executing the simulation engine container instance using the first set of parameter values; and outputting a result of the executed simulation. (Liu, as cited above, see § IV as was discussed above which provides an example implementation of Liu’s simulation for the first set of parameter values and outputs a result, as visually depicted in fig. 7; also see fig 5)
Regarding Claim 3
Liu teaches:
The method of claim 1, wherein the execution of the simulation engine container instance and its connected one or more system under test instance containers is performed in a distributed environment comprising a plurality of computing systems. (Liu, as cited above for claim 1, then see page 98 the paragraph split between the columns: “It runs distinct simulation models as separate processes with each encapsulating a dedicated simulator environment as runtime environment of the model by using container automation technology (e.g. Docker) on a large computing cluster”)
Regarding Claim 11.
Liu teaches:
The method of claim 1, wherein outputting the result of the executed simulation comprises outputting one or more of:
a 4D visualization of the autonomous vehicle of the simulation;
a sensor data playback of the simulation;
a log file display of the simulation; (Liu, see fig. 5 and 7, then see § IV last paragraph: “A part of the output data stream of the wind power turbine is shown in Fig. 6. This data is converted from time series format to JSON object data and is then stored in the Kafka server before it is exported to a database [example of a log file]. In Fig. 7, a visualization template for this scenario used by the visualization component shows an overview of power data of a wind turbine over a specific period of time in January 2010, since the weather data contained in the csv file is from 2010” – to clarify, see fig. 6)
a code trace in the system under test in the simulation;
or an indication whether the simulation passed or failed a pass/fail condition.
Regarding Claim 12.
Claim 12 is rejected under a similar rationale as claim 1.
Regarding Claim 14.
Claim 14 is rejected under a similar rationale as claim 3.
Regarding Claim 22.
Claim 22 is rejected under a similar rationale as 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.
Claim(s) 2 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017
Regarding Claim 2
While Liu does not anticipate the following, Liu does suggest it and thus renders obvious:
The method of claim 1, further comprising: repeating the method using a second set of parameter values instead of the first set of parameter values. (Liu, § IV incl: “Firstly, before a simulation is started, the wind turbine simulation node is parameterized by setting the values of a list of static configuration parameters which specify the height of the wind turbine and the diameter of its rotor” as taken in view of § V: “In the future…The web user interface consisting of the parameters settings panel for models can be enhanced to allow users to dynamically adjust the value of parameters in order to obtain different cosimulation results”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Liu on a co-simulation system which had static parameter values with the teachings from Liu on a settings panel for dynamically adjusting the parameters and thus repeating the co-simulation for different parameter values to supply “different cosimulation results” The motivation to combine would have been that Liu already suggests this as a future improvement, i.e. “The web user interface consisting of the parameters settings panel for models can be enhanced to allow users to dynamically adjust the value of parameters in order to obtain different cosimulation results” (Liu, § IV).
Regarding Claim 13.
Rejected under a similar rationale as claim 2 above.
As a point of clarity on having multiple § 102/103 rejection, see MPEP § 2120(I): “Prior art rejections should ordinarily be confined strictly to the best available art. Exceptions may properly be made, for example, where: (A) the propriety of a 35 U.S.C. 102 or 103 rejection depends on a particular interpretation of a claim;… In the interest of compact prosecution, such rejections should be backed up by the best other art rejections available. Keep in mind the best backup rejection(s) could be based on alternate embodiments from the same "best available" reference(s).” – i.e. multiple rejections of the same claims are presented, depending on whether patentable weight is assigned to the preamble’s intended use.
Claim(s) 1-3, 5-14, 16-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamaura, Masahiro, et al. "ADAS virtual prototyping using modelica and unity co-simulation via openmeta." The First Japanese Modelica Conferences. No. 124. 2016 in view of Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017
Regarding Claim 1
Yamaura, in view of Liu teaches:
A method for performing an electronic simulation of an autonomous vehicle using container instances, the method comprising: creating a simulation engine container instance that is configured to receive values for at least a first portion of a set of parameters; creating one or more system under test instance containers that are configured to receive values for at least a second portion of the set of parameters; connecting the simulation engine container instance to the one or more system under test instance containers; receiving a first set of parameter values for the set of parameters; executing the simulation engine container instance using the first set of parameter values; and outputting a result of the executed simulation. (Yamaura, abstract: “Automotive control systems, such as modern Advanced Driver Assistance Systems (ADAS), are becoming more complex and prevalent in the automotive industry…In this paper, we propose a closed-loop simulation framework that improves ADAS design and evaluation. The proposed simulation framework consists of four tools: Dymola, Simulink, OpenMETA and Unity 3D game engine. Dymola simulates vehicle dynamics models written in Modelica. Simulink is used for vehicle control software modeling. OpenMETA provides horizontal integration between design tools. OpenMETA also has the capability to improve design efficiency through the use of PET (Parametric Exploration Tool) and DSE (Design Space Exploration) tools. Unity provides the key functionality to enable interactive, or closed-loop ADAS simulation, which contains sensor models for ADAS, road environment models and provides visualization.”
Then, see fig. 1, as discussed in § 3.1, wherein this teaches a computer-implemented method which connects the “Unity” game engine to a system under test simulation engine via “UDP”, including: “The Unity model also has road environments, other vehicle models, and sensor models for ADAS systems. The sensor data in Unity is also sent to the Simulink controller via UDP.” And as visually depicted it provides an output of the executed simulation with the vehicle on the road – see table 1 for the data being communicated, wherein fig. 3 shows “Adaptive cruise control diagram” [example of an autonomous vehicle feature] – i.e. § 4, ¶¶ 1-2: “As the first case study for this simulation toolchain with PET, we decided to model the Adaptive Cruise Control (ACC) system. The ACC is one of the ADAS systems. This system helps mitigate driver fatigue by assisting accelerator operations. Toyota’s ACC system has 2 modes: constant speed control mode and vehicleto- vehicle distance control mode. Constant speed control mode is the same as a conventional cruise control system. While this mode is active the system works to maintain a target velocity. Vehicle-to-vehicle distance mode works with sensors, such as millimeter wave radar sensor that detects the presence of lead vehicles. Upon detecting a vehicle, the ACC adjusts the speed in order to maintain a safe following distance. The control flow is shown in Figure 3.”
Then, § 4 ¶ 3: “For the ACC case study in this paper, we defined following scenario as shown in Figure 4…” and lists the parameters used in the simulation, include seeing table 2, noting § 4.1: “The first mode utilizes vehicle-to-vehicle distance as the desired value and the second mode uses a velocity set point as the desired value” [table 2, vset and dset] – and § 4.2: “For the ACC case study, we added a long straight road, two vehicles and a millimeter wave radar sensor model. The sensor model obtains a distance between two vehicles and their relative speed” – see fig. 5 to clarify on additional “Simulation settings” as well in the test bench
As a point of clarity on some of the parameter values being used for the Unity simulation engine, in fig. 1 note that this engine handles the “Other vehicles” in the simulation, i.e. § 2.1 last paragraph: “Unity allows us to provide a far richer, virtual reality testing environment, including traffic, pedestrians, sensor models and effects of weather and the environment, such as those due to fog, heavy rain, and icy road conditions.” And see § 2.2 including ¶ 2 including: “For example, road editors, vehicle physics, and car traffic simulators are available as ready-to-use assets with Unity.” - then note the initial speeds and initial distances in table 2, as visually depicted in fig. 4 (1), i.e. the unity engine would have set the speed and distance for the car in front, and positioned the vehicles on initialization (note § 4.2 incl.: “The sensor model obtains a distance between two vehicles and their relative speed”
See § 4.3 for additional parameters and associated values and see § 4.4 which discusses the “Simulation results” incl.: “A designer can find PD gains by clicking on a point in a plot.” (clarified on in §§ 4.1 and 4.3)
Wherein Yamaura does not teach the use of containers in the manner claimed for the co-simulation system of Yamaura [i.e. fig. 2, note these are distinctly different simulation programs, hence the “UDP” coupling], however this would have been obvious when Yamaura was taken in view of Liu as cited above for claim 1, include also seeing the paragraph split between the columns on page 98: “Therefore, as an important application service and planning tool of the IT infrastructure for EnergyLab 2.0 and ES 2050, a generic co-simulation platform framework is developed for modeling and simulating intelligent multi-domain energy system solutions (Smart Grids, microgrids, etc.) on the basis of large computer clusters as distributed runtime infrastructure. This solution tries to overcome the above mentioned limitations and possesses the following features to remedy the mentioned shortcomings: It runs distinct simulation models as separate processes with each encapsulating a dedicated simulator environment as runtime environment of the model by using container automation technology (e.g. Docker) on a large computing cluster…” and page 101, col. 2, ¶ 2: “The FMI standard defines a standard CAPI for data exchange which can be used together with all simulators supporting this standard. Thus, the co-simulation platform implements a generic FMI adapter that allows to connect all simulators to the co-simulation platform, which implement the FMI specification. This connects a whole bunch of simulators to the co-simulation platform in a very generic way.”
Then see § V: “The main scientific contribution described in this paper is the development of a new scalable and very generic system architecture for a co-simulation platform framework that is capable to model, design, plan, perform, control, analyze and evaluate co-simulations of e.g. Smart Grids… It is also possible that users choose and combine simulators that already exist on the platform to set up a co-simulation with only using existing simulation or data source components and just tuning their configurations…In the future, a larger modeling library has to be integrated into the framework for building up complicated co-simulations, which will instrument other simulation environments, such as Modelica tools, Simulink, OpenDSS, DigSilent (power factory), PSLF (positive sequence load flow), etc., in order to further improve the generic applicability of the platform. The web user interface consisting of the parameters settings panel for models can be enhanced to allow users to dynamically adjust the value of parameters in order to obtain different cosimulation results….”
Liu is considered analogous art as it is in the same field of endeavor of co-simulation (i.e. the art of coupling/combining multiple independent simulations together to run a co-simulation); and is reasonably pertinent to the problem faced by the instant inventor of coupling simulations in Docker containers together.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Yamaura on a co-simulation framework (abstract and fig. 2) with the teachings from Liu on “a generic co-simulation platform framework” which includes “connect[ing] a whole bunch of simulators to the co-simulation platform in a very generic way” (Liu, page 101), i.e. “The main scientific contribution described in this paper is the development of a new scalable and very generic system architecture for a co-simulation platform framework that is capable to model, design, plan, perform, control, analyze and evaluate co-simulations” (Liu, § V).
The motivation to combine would have been that “The flexibility that this co-simulation provides allows users to upload different kinds of simulators (power grid and technical plant models) and various types of data sources as well as real hardware nodes instrumented by measurement devices (electrical power grid and others) to build up and operate customized cosimulations… Through utilization of container virtualization and microservices the execution of different independent simulation nodes on the computing cluster is easily and efficiently implemented….” (Liu, § V)
Regarding Claim 2
Yamaura, in view of Liu, teaches:
The method of claim 1, further comprising:
repeating the method using a second set of parameter values instead of the first set of parameter values. (Yamura, as discussed above in view of Liu, note Yamura, fig. 5 including the “Test Bench”, and § 4 including table 2, then see § 4.3 ¶ 2, then § 4.4: “We ran the PET of the ACC case study with parameters which are shown in Table 2. The result of the PET simulation results can be visualized as a “Constraint Plot” in the OpenMETA dashboard, which is shown in Figure 6. The horizontal axis and vertical axis of this plot are the PD gains mentioned above. The plots show boundaries, which represent which combinations of parameters that meet the overshoot requirements. Thresholds are adjustable in the dashboard. The threshold values in Figure 6 are overshoot < 0. A designer can find PD gains by clicking on a point in a plot. We picked gains which are close to the boundary which meets both overshoot requirements. The graphs in Figure 7 are Dymola simulation results using gains selected by examining the constraint plot shown in Figure 6…” – also, see Yamura, § 2.1, last paragraph: “Although existing tools mentioned above allow us to build a vehicle model with cyber components and physical components, the proposed integration with Unity allows us to provide a far richer, virtual reality testing environment, including traffic, pedestrians, sensor models and effects of weather and the environment, such as those due to fog, heavy rain, and icy road conditions. These effects are important, because they can potentially compromise the correct functionality of ADAS systems.” – in view of Liu, § V as cited above, incl.: “The web user interface consisting of the parameters settings panel for models can be enhanced to allow users to dynamically adjust the value of parameters in order to obtain different cosimulation results….”
Regarding Claim 3
Yamaura, in view of Liu, teaches:
The method of claim 1, wherein the execution of the simulation engine container instance and its connected one or more system under test instance containers is performed in a distributed environment comprising a plurality of computing systems. (Yamaura, as taken in view of Liu as cited above, including Liu page 98 the paragraph split between the columns: “It runs distinct simulation models as separate processes with each encapsulating a dedicated simulator environment as runtime environment of the model by using container automation technology (e.g. Docker) on a large computing cluster”)
Regarding Claim 5
Yamaura, in view of Liu, teaches:
The method of claim 1, wherein the simulation engine container instance comprises a body of the autonomous vehicle. (Yamaura, fig. 2, depicts this visually – see §§ 2.2 and 3.1 to clarify, and the other cited sections above)
Regarding Claim 6
Yamaura, in view of Liu, teaches:
The method of claim 1, wherein the simulation engine container instance comprises one or more performance characteristics of the autonomous vehicle. (Yamaura, fig. 2, depicts this visually – see §§ 2.2 and 3.1 to clarify, and the other cited sections above, in particular in fig. 2: “Vehicle Dynamics Tire-road Interaction” – and table 1 the “wheel rotation speeds” are also from the Unity engine; and § 4.2: “For the ACC case study, we added a long straight road, two vehicles and a millimeter wave radar sensor model. The sensor model obtains a distance between two vehicles and their relative speed. These signals are communicated to Dymola via UDP and are used as inputs to the controller. The sensor model was built by using “Ray” class in Unity scripting C# API which is often used in shooting game”)
Regarding Claim 7
Yamaura, in view of Liu, teaches:
The method of claim 1, wherein the simulation engine container instance comprises a scene. (Yamaura, fig. 2, as discussed above, see §§ 2.1-3.1 as discussed above as well for further clarity).
Regarding Claim 8
Yamaura, in view of Liu, teaches:
The method of claim 7, wherein the scene comprises a roadway scene. (Yamaura, fig. 2, as discussed above, see §§ 2.1-3.1 as discussed above as well for further clarity).
Regarding Claim 9
Yamaura, in view of Liu, teaches:
The method of claim 1, further comprising: designating a body of the autonomous vehicle; designating performance characteristics of the autonomous vehicle; designating a sensor arrangement of the autonomous vehicle; and designating a control logic for the autonomous vehicle; wherein the simulation engine container instance and the connected one or more system under test container instances collectively comprise the body, the performance characteristics, the sensor arrangement, and the control logic. (Yamaura, fig. 2, as discussed above, see §§ 2.1-3.1 as discussed above as well for further clarity
i.e. the vehicle dynamics model (fig. 2) and the like, e.g. the control system in fig. 3, are in the system under test instance (container instance, in view of Liu), the body was designated (fig. 2 shows this, § 3.1 ¶ 2 clarifies there are “other vehicle models” in Unity as well for use, and this includes the body of the vehicle as visually depicted)
as to the sensor arrangement, § 4.2: “For the ACC case study, we added a long straight road, two vehicles and a millimeter wave radar sensor model. The sensor model obtains a distance between two vehicles and their relative speed. These signals are communicated to Dymola via UDP and are used as inputs to the controller. The sensor model was built by using “Ray” class in Unity scripting C# API which is often used in shooting games” as taken in view of the following suggestions by Yamaura - § 2.1 last paragraph: “the proposed integration with
Unity allows us to provide a far richer, virtual reality testing environment, including traffic, pedestrians, sensor models and effects of weather and the environment, such as those due to fog, heavy rain, and icy road conditions.” - and § 3.1 ¶ 2: “The Unity model also has road environments, other vehicle models, and sensor models for ADAS systems” – also, note the “etc.” in table 1 for the sensor data, i.e. Liu’s at least suggesting the use of additional sensors, and Liu has a sensor arrangement of the Lidar sensor
Regarding Claim 10.
Yamaura, in view of Liu, teaches:
The method of claim 1, further comprising: designating a roadway; determining one or more environmental conditions; and determining one or more traffic vehicles; wherein the simulation engine container instance comprises the roadway, the one or more environmental conditions, and the one or more traffic vehicles. (Liu, as discussed above, including § 2.1 last paragraph, § 2.2 including ¶¶ 1-2, fig. 2 for the “Unity” with its listing, and § 3.1 ¶ 2)
Regarding Claim 11.
Yamaura, in view of Liu, teaches:
The method of claim 1, wherein outputting the result of the executed simulation comprises outputting one or more of:
a 4D visualization of the autonomous vehicle of the simulation; (Yamaura, fig. 2 visually depicts a 4D visualization – see §§ 2.2 and 3.1 to clarify)
a sensor data playback of the simulation;
a log file display of the simulation; (Yamaura,§§ 4.3-4.4 as discussed above, as taken in view of Liu, see fig. 5 and 7, then see § IV last paragraph: “A part of the output data stream of the wind power turbine is shown in Fig. 6. This data is converted from time series format to JSON object data and is then stored in the Kafka server before it is exported to a database [example of a log file]. In Fig. 7, a visualization template for this scenario used by the visualization component shows an overview of power data of a wind turbine over a specific period of time in January 2010, since the weather data contained in the csv file is from 2010”)
a code trace in the system under test in the simulation;
or an indication whether the simulation passed or failed a pass/fail condition. (Yamaura, §§ 4.3-4.5, including in § 4.4: “As a result, designers may calibrate control software parameters more efficiently.” – such as by the means discussed in § 4.4”, i.e. it provides visual indications such as of the “overshoot” (§ 4.4), and the designer can simply adjust the parameters to meet them (§§ 4.4-4.5) until it meets their requirements [example of passing], i.e. “This plot shows that there is no overshoot in either graph, demonstrating that the PET was useful in selecting design parameters” (§ 4.4))
Regarding Claims 12-14 and 16-22
These are rejected under similar rationales as their parallel limitations found in claims 1-3, 5-11 as discussed above in detail, see above.
Claim(s) 4 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yamaura, Masahiro, et al. "ADAS virtual prototyping using modelica and unity co-simulation via openmeta." The First Japanese Modelica Conferences. No. 124. 2016 in view of Liu, Jianlei, Clemens Düpmeier, and Veit Hagenmeyer. "A new concept of a generic co-simulation platform for energy systems modeling." Proceedings of the Future Technologies Conference (FTC), Pan Pacific Hotel Vancouver, BC, Canada. 2017 and in further view of Jayaraman, Arvind, Ashley Micks, and Ethan Gross. Creating 3d virtual driving environments for simulation-aided development of autonomous driving and active safety. No. 2017-01-0107. SAE Technical Paper, 2017.
Regarding Claim 4
Yamaura, in view of Liu and Jayaraman, teaches:
The method of claim 1, wherein the system under test is a sensor. (Yamaura, § 4.2: “For the ACC case study, we added a long straight road, two vehicles and a millimeter wave radar sensor model. The sensor model obtains a distance between two vehicles and their relative speed. These signals are communicated to Dymola via UDP and are used as inputs to the controller. The sensor model was built by using “Ray” class in Unity scripting C# API which is often used in shooting games”, as was taken in view of Liu as discussed above
As taken in view of Jayaraman, abstract: “In order to facilitate the development of perception and control algorithms for level 4 autonomy, a shared memory interface between MATLAB, Simulink, and Unreal Engine 4 can send information (such as vehicle control signals) back to the virtual environment. The shared memory interface conveys arbitrary numerical data, RGB image data, and point cloud data for the simulation of LiDAR sensors. The interface consists of a plugin for Unreal Engine, which contains the necessary read/write functions, and a beta toolbox for MATLAB, capable of reading and writing from the same shared memory locations specified in Unreal Engine, MATLAB, and Simulink. The LiDAR sensor model was tested by generating point clouds with beam patterns that mimic Velodyne HDL-32E (32 beam) sensors and is demonstrated to run at sufficient frame rates for real-time computations by leveraging the Graphics Processing Unit (GPU).” And figure 1, noting that the “Sensor…Algorithms” are now simulated in Simulink (for clarity, see the above discussed Yamaura fig. 2, for the “Simulink model” and the abstract: “Simulink is used for vehicle control software modeling.” And § 3.1 ¶ 2: “The sensor data in Unity is also sent to the Simulink controller via UDP”)
To clarify, see the section “Virtual camera setup: “The Unreal Engine-based virtual simulator platform provides photo-realistic images which can be used to facilitate prototyping computer vision algorithms in MATLAB; these extract useful information such as vehicles, pedestrians, lanes etc. from images… In addition, it is also feasible to add arbitrary post processing effects to the camera in order to model lens distortion effects often present in actual camera sensors. Image disturbances can also be introduced after transmission of the image to MATLAB. To facilitate operating on these images in MATLAB, the rendered images are transposed and the image format is changed; the memory layout of the image is column-major, with separate image planes for each RGB color channel” – to clarify, see fig. 4
Also, see the suggestions in “Future Work”: “As part of future work on the camera sensor, the current model needs to be extended to offer additional sensor parameters that can be configured to match the settings of real world camera sensors. For instance, we need the ability to specify intrinsic camera parameters, such as focal length and principal point. We also plan to add fisheye and wide-angle lens distortion parameters. In addition, we intend to collect ground truth for objects viewed by the camera for use in the training of machine learning algorithms, with applications such as object detection and classification, or image segmentation.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Yamaura on a system which coupled the Unity game engine with Simulink (fig. 2) with the teachings from Jayaraman on post-processing the camera input from a game engine so as to more closely model a real, actual sensor. The motivation to combine would have been that “it is also feasible to add arbitrary post processing effects to the camera in order to model lens distortion effects often present in actual camera sensors. Image disturbances can also be introduced after transmission of the image to MATLAB” (section Virtual Camera setup as cited above) as well as ““As part of future work on the camera sensor, the current model needs to be extended to offer additional sensor parameters that can be configured to match the settings of real world camera sensors. For instance, we need the ability to specify intrinsic camera parameters, such as focal length and principal point. We also plan to add fisheye and wide-angle lens distortion parameters. In addition, we intend to collect ground truth for objects viewed by the camera for use in the training of machine learning algorithms, with applications such as object detection and classification, or image segmentation.”” (section Future Work)
In other words, by simulating an actual camera for its optics in Simulink, this would have provided a more realistic simulation for simulating autonomous driving in the real world (abstract of Jayaraman)
Another motivation to combine would have been that Yamaura was using the “Ray” class in Unity (§ 4.2); see Jayaraman, section “Alternative Methods to Model LiDAR Sensors”: “Another technique explored was modeling the LiDAR sensor using ray tracing, which is a method that is already provided as part of the Unreal Engine programming environment. We found that performing ray tracing for a large number of LiDAR beams using this method is computationally very expensive” – and POSITA would have inferred that as both Unity and Un-real are game engines, similar results would have been expected by using the “Ray” class in Unity
Regarding Claim 15.
Rejected under a similar rationale as claim 4 above.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-2, 4-13, 15-22 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2, 4-8, 9-10, 12-16 of U.S. Patent No. 12061846.
Claims 3 and 14 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2, 4-8, 9-10, 12-16 of U.S. Patent No. 12061846 in view of Liu, “A New Concept of a Generic Co-Simulation Platform for Energy Systems Modeling”, 2017
As an initial point of clarity, claim 12 and the dependents thereof are rejected under a similar rationale as claim 1, and the parallel dependents thereof, as discussed below, but in view of the ‘846 claims 9-10, 12-16 (parallel claims to the representative claim 1, and dependents thereof, of the ‘846).
Although the claims at issue are not identical, they are not patentably distinct from each other because:
The instant independent claims are merely a broader form of the ‘846 claimed invention, i.e. the ‘846 claimed invention in its independent claims anticipates the presently recited claims as an embodiment of it (as a point of clarity, slight differences of word choice but for words that have the similar meaning, e.g. linked (which requires an act of linking to be performed before they are linked) vs connecting, still convey the same BRI when construed in view of the disclosure).
Regarding Claim 3
While the ‘846 does not explicitly recite the following feature, it would have been obvious when it was taken in view of Liu
The method of claim 1, wherein the execution of the simulation engine container instance and its connected one or more system under test instance containers is performed in a distributed environment comprising a plurality of computing systems. (Claim 1 of the ‘846, taken in view of Liu, abstract and § III including fig. 1 and its accompanying description, also see fig. 3 and its accompanying description, the see page 98, col. 1, ¶ 5: “Therefore, as an important application service and planning tool of the IT infrastructure for EnergyLab 2.0 and ES 2050, a generic co-simulation platform framework is developed for modeling and simulating intelligent multi-domain energy system solutions (Smart Grids, microgrids, etc.) on the basis of large computer clusters as distributed runtime infrastructure”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from ‘846 claimed invention with the teachings from Liu on a similar simulation architecture using connected containers, but using computer clusters as distributed runtime infrastructure. The motivation to combine would have been that “These latter users do neither need to setup nor to configure any simulation environment on their local PC since startup and management of simulation nodes is completely managed and automated by the co-simulation service and solely performed on nodes of the underlying computing cluster. Additionally, users performing modeling do not necessarily need detailed IT knowledge.” (Liu, page 98, col. 2, ¶ 1).
Regarding Claim 14
Rejected under a similar rationale as claim 3 above.
Instant Application
US Patent 12061846
Regarding Claim 1
A method for performing an electronic simulation of an autonomous vehicle using container instances, the method comprising:
creating a simulation engine container instance that is configured to receive values for at least a first portion of a set of parameters;
creating one or more system under test instance containers that are configured to receive values for at least a second portion of the set of parameters;
connecting the simulation engine container instance to the one or more system under test instance containers;
receiving a first set of parameter values for the set of parameters;
executing the simulation engine container instance using the first set of parameter values;
and outputting a result of the executed simulation.
Regarding Claim 1
A method for performing an electronic simulation of an autonomous vehicle, the method comprising:
receiving a system under test from a user, the system under test comprising a component of an autonomous vehicle;
receiving a pass/fail condition from the user;
receiving an indication of a variable parameter from the user;
determining a plurality of values of the variable parameter;
creating a respective system under test container instance for each of the plurality of values;
creating a respective container instance of a simulation engine for each of the plurality of values, each simulation engine container instance linked to a respective system under test container;
performing, with the simulation container instances, a respective simulation for each of the plurality of values;
determining, for each of the respective simulations, whether the simulation passed or failed the pass/fail condition;
and outputting, to the user, a result of the respective simulations.
Regarding Claim 2
The method of claim 1, further comprising:
repeating the method using a second set of parameter values instead of the first set of parameter values.
See the independent claims, the “performing…” limitation in particular with “for each of the plurality of values” – instant claim 2 is an obvious variant of this, because instant claim 2 merely recites a substantially similar scope under the BRI
See the ‘846 claims 4-5 for further clarification, if needed
Regarding Claim 4
The method of claim 1, wherein the system under test is a sensor.
Regarding Claim 2
The method of claim 1, wherein the system under test is a sensor, and each simulation engine container instance comprises a body of the autonomous vehicle, one or more performance characteristics of the autonomous vehicle, and a scene, the scene comprising a roadway.
Regarding Claim 5
The method of claim 1, wherein the simulation engine container instance comprises a body of the autonomous vehicle.
Regarding Claim 2
The method of claim 1, wherein the system under test is a sensor, and each simulation engine container instance comprises a body of the autonomous vehicle, one or more performance characteristics of the autonomous vehicle, and a scene, the scene comprising a roadway.
Regarding Claim 6
The method of claim 1, wherein the simulation engine container instance comprises one or more performance characteristics of the autonomous vehicle.
Regarding Claim 2
The method of claim 1, wherein the system under test is a sensor, and each simulation engine container instance comprises a body of the autonomous vehicle, one or more performance characteristics of the autonomous vehicle, and a scene, the scene comprising a roadway.
Regarding Claim 7
The method of claim 1, wherein the simulation engine container instance comprises a scene.
Regarding Claim 2
The method of claim 1, wherein the system under test is a sensor, and each simulation engine container instance comprises a body of the autonomous vehicle, one or more performance characteristics of the autonomous vehicle, and a scene, the scene comprising a roadway.
Regarding Claim 8
The method of claim 7, wherein the scene comprises a roadway scene.
Regarding Claim 2
The method of claim 1, wherein the system under test is a sensor, and each simulation engine container instance comprises a body of the autonomous vehicle, one or more performance characteristics of the autonomous vehicle, and a scene, the scene comprising a roadway.
Regarding Claim 9
The method of claim 1, further comprising:
designating a body of the autonomous vehicle;
designating performance characteristics of the autonomous vehicle;
designating a sensor arrangement of the autonomous vehicle;
and designating a control logic for the autonomous vehicle;
wherein the simulation engine container instance and the connected one or more system under test container instances collectively comprise the body, the performance characteristics, the sensor arrangement, and the control logic.
Regarding Claim 6
The method of claim 1, further comprising:
designating a body of the autonomous vehicle;
designating performance characteristics of the autonomous vehicle;
designating a sensor arrangement of the autonomous vehicle;
and designating a control logic for the autonomous vehicle;
wherein each system under test container instance and the associated simulation engine container instance collectively comprise the body, the performance characteristics, the sensor arrangement, and the control logic.
Regarding Claim 10.
The method of claim 1, further comprising:
designating a roadway;
determining one or more environmental conditions;
and determining one or more traffic vehicles;
wherein the simulation engine container instance comprises the roadway, the one or more environmental conditions, and the one or more traffic vehicles.
Regarding Claim 7
The method of claim 1, further comprising:
designating a roadway;
determining one or more environmental conditions;
and determining one or more traffic vehicles;
wherein each simulation engine container instance comprises the roadway, the one or more environmental conditions, and the one or more traffic vehicles.
Regarding Claim 11.
The method of claim 1, wherein outputting the result of the executed simulation comprises outputting one or more of:
a 4D visualization of the autonomous vehicle of the simulation;
a sensor data playback of the simulation;
a log file display of the simulation;
a code trace in the system under test in the simulation;
or an indication whether the simulation passed or failed a pass/fail condition.
Regarding Claim 8
The method of claim 1, wherein outputting, to the user, a result of the respective simulations comprises outputting one or more of:
a 4D visualization of the autonomous vehicle in at least one of the simulations;
sensor data playback in at least one of the simulations;
a log file display of one or more of the simulations;
a code trace in the system under test in at least one of the simulations;
or whether each of the simulations passed or failed the pass/fail condition.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Nally, Martin. REST vs RPC: What problems are you trying to solve with your APIs?. Oct. 15th, 2018. Blog post by Google Cloud. URL: cloud(dot)google(dot)com/blog/products/application-development/rest-vs-rpc-what-problems-are-you-trying-to-solve-with-your-apis – see the “Following procedure” section, followed by the “Unsolved problems”, then the section on “REST APIs, and how they can help”, then section on “How HTTP helps make software easier to change” in particular: “We saw that the RPC model makes it very simple and direct for programmers to write a procedure in one program and call it from another.” And section “No gain without pain” incl.: “If efficiency is your first priority, RPC may be a better choice.” Then “Pick the API style that fits your goals”
Punnen, Alex. REST is not the Best for Micro-Services GRPC and Docker makes a compelling case. June 8th, 2017. Medium Article. URL: medium(dot)com/better-software/rest-in-peace-grpc-for-micro-service-and-grpc-for-the-web-a-how-to-908cc05e1083 – see pages 1-3, including ¶¶ 1-5 and the last paragraph before section 1 on the static typed & Versioned interface, then see # 2 Efficency and Stability, then # 5 “Almost Serverless”: “The other being the fact that the GRPC implementation is as server-less as you can get, without going full serverless. That is you don’t need Java’sJetty/Jersey/Tomcat/Jboss (in the increasing order of server-side thickness),Scala’s Spray (and accompanying DSL monstrosity), C++ nothing/G-SOAP ? orany other full-fledged server or embedded servers…”
Docker Core Engineering. Docker 1.12: Now with Built-in Orchestration!. June 20th, 2016. URL: docker(dot)com/blog/docker-1-12-built-in-orchestration/ - see ¶¶ 2-4 incl: “With Docker 1.12, the best way to orchestrate Docker is Docker!” and see the “four principles” list for the benefits then see section on “Creating Swarms with One Decentralized Building Block” , note the “Basic Architecture” figure in section “Creating and Scaling Services” and the figure in the ”Security” section, then see “Bundles” section, followed by “Under the hood of Docker 1.12” in particular: “When you take a look under the hood, Docker 1.12 uses a number of other interesting technologies. Inter-node communication is done using gRPC, which gives us HTTP/2 benefits like connection multiplexing and header compression. Our data structures are transmitted efficiently thanks to protobufs.”
Indrasiri, Kasun. Build Real-World Microservices with gRPC. Nov. 27th, 2018. URL: thenewstack(dot)io/build-real-world-microservices-with-grpc/ - ¶ 1: “Early microservices implementations leveraged Representational State Transfer (REST) architecture as the de-facto communication technology… As they are based on conventional text-based messaging (JSON, XML, CVS over HTTP, etc.), which are optimized for humans, these are not ideal choices for internal service-to-service communication… Rather, using a text-based messaging protocol, we can leverage a binary protocol that is optimized for inter-service communication. The Cloud Native Computing Foundation’s gRPC (gRPC Remote Procedure Call) is an ideal choice for inter-service communication since it uses protocol buffers as the binary data interchange format for inter-service communication.” – then, see fig. 1-2
Hadlow, Mike. Message Queue Shootout. Apr. 10th, 2011. Blogspot Blog. URL: mikehadlow(dot)blogspot(dot)com/2011/04/message-queue-shootout(dot)html – see the bulleted list for its point on ZeroMQ, followed by the paragraph describing ZeroMQ in more detail, then see the chart and its description: “As you can see, there’s ZeroMQ and the others. Its performance is staggering. To be fair, ZeroMQ is quite a different beast from the others, but even so, the results are clear: if you want one application to send messages to another as quickly as possible, you need ZeroMQ. This is especially true if you don’t particularly mind loosing the occasional message.”
Samet, Nadav, et al. RPCZ Github Repository. Last updated Mar. 26th, 2017. URL: github(dot)com/thesamet/rpcz – see the readme, specifically see the introduction: “RPCZ is a library for writing fast and robust RPC clients and servers that speak Protocol Buffers… RPCZ is built on top of ZeroMQ for handling the low-level I/O details in a lock-free manner.” – and see the note in the heading: “NOTE: rpcz is no longer being maintained. Consider using grpc.”
ZeroMQ. Broker vs. Brokerless. Wiki on ZeroMQ website. Last revised 2017. URL: wiki(dot)zeromq(dot)org/whitepapers:brokerless – see the discussion of “Broker” including the discussion of the drawbacks of the broker model (also note the example is using “RPC”; see the figures; then see the section “No Broker” and its figure then see the conclusion.
THIS ACTION IS MADE FINAL. 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 DAVID A. HOPKINS whose telephone number is (571)272-0537. The examiner can normally be reached Monday to Friday, 10AM to 7 PM EST.
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 at (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.
/David A Hopkins/Primary Examiner, Art Unit 2188
Prosecution Insights