DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is filed in response to Applicant’s Request for Continued Examination dated April 16, 2026. Claims 1, 11-13, 15, and 17-19 are currently amended and claims 1-20 remain pending in the application and have been fully considered by Examiner.
Applicant's arguments with respect to the prior art rejections have been considered, but are moot in view of the new grounds of rejection presented herein.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on April 14, 2026 has been entered.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Objections
Claims 1-17, 19, and 20 are objected to because of the following informality:
With respect to claim 1, line 6 of claim 1 recites “comprising reference entity field”, which appears to be a typographical error that should recite “comprising a reference entity field”.
Claims 2-17 inherit this deficiency.
With respect to claims 2-7, 9, 13, 14, 16, 17, and 20, line 1 of each of these claims should have a comma before “wherein”.
Claim 3 inherits the deficiency of claim 2; claims 9 and 10 inherit the deficiency of claim 7; claim 10 inherits the deficiency of claim 9; claims 14, 16, and 17 inherit the deficiency of claim 13; and claims 16-17 inherit deficiency of claim 14.
With respect to claims 8, 10-12, and 15, line 1 of each of these claims should recite “, further” before “comprising”.
With respect to claim 19, line 9 recites “the input fields”, which appears to be a typographical error that should recite “the set of input fields”. Line 14 recites “the at least one temporal or relational constraint and defined interaction stage”, which appears to be a typographical error that should recite “the at least one temporal or relational constraint and the defined interaction stage”.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data” in claim 1, “a scenario runtime module configured to receive the scenario data of the scenario, to perform a simulation of the scenario based on the scenario data, and to generate runtime output data” in claim 18, and “performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data” in claim 19.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claims 1-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.
With respect to claim 1, as indicated above in the Claim Interpretation section, the limitation “performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data” has been interpreted under 35 USC 112(f). However, as detailed below, this limitation is indefinite because the specification fails to disclose sufficient corresponding structure, materials, or acts that perform the entire claimed function. Claim 1 is therefore rejected under 35 USC 112(a) as failing to comply with the written description requirement because “When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under section 112(a).”1
With respect to claim 18, as indicated above in the Claim Interpretation section, the limitation “a scenario runtime module configured to receive the scenario data of the scenario, to perform a simulation of the scenario based on the scenario data, and to generate runtime output data” has been interpreted under 35 USC 112(f). However, as detailed below, this limitation is indefinite because the specification fails to disclose sufficient corresponding structure, materials, or acts that perform the entire claimed function. Claim 18 is therefore rejected under 35 USC 112(a) as failing to comply with the written description requirement because “When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under section 112(a).”2
With respect to claim 19, as indicated above in the Claim Interpretation section, the limitation “performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data” has been interpreted under 35 USC 112(f). However, as detailed below, this limitation is indefinite because the specification fails to disclose sufficient corresponding structure, materials, or acts that perform the entire claimed function. Claim 19 is therefore rejected under 35 USC 112(a) as failing to comply with the written description requirement because “When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under section 112(a).”3
With respect to all dependent claims, each inherits the 35 US 112(a) deficiency of its respective base claim (see the 35 US 112(a) rejections of claims 1 and 18 above).
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-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.
With respect to claims 1, 18, and 19, the limitations “performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data” in claim 1, “a scenario runtime module configured to receive the scenario data of the scenario, to perform a simulation of the scenario based on the scenario data, and to generate runtime output data” in claim 18, and “performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data” in claim 19 invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (see the Claim Interpretation section above). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
Specifically, MPEP § 2181(II)(B) states “For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b)” (emphasis added). Applicant’s specification only identifies “a scenario runtime module” at lines 7-9 of p. 14, which states, “Data from the scenario model 506, whether received via the nodal interface or the scenario database, is sent to the scenario runtime module 516, which is configured to perform a simulation of the parametrised scenario” (emphasis added). However, this is merely a statement of the claimed function and is not an algorithm for performing the claimed function because there are no steps identified for performing the claimed function or any other explanation as to how the scenario runtime module will perform the simulation of the scenario4. Therefore, claims 1, 18, and 19 are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
With respect to all dependent claims, each inherits the 35 US 112(b) deficiency of its respective base claim (see the 35 USC 112(b) rejections of claims 1 and 18 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, 5, 7, 8, 15, 18, and 19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 8 and 9 of copending Application No. 18/274,259 (reference application) in view of Partridge et al. (US 20200250363, hereinafter Partridge) and Misaki Design, LLC “Simulation Data Editor for Re:sim Manual Part 2: Scenario Data Setting” (hereinafter Misaki), as illustrated with the help of the following table:
Instant Application
Reference App. No. 18/274,259
1. A computer implemented method of generating a scenario to be run in a simulation environment for testing a behaviour of an autonomous vehicle, the method comprising:
rendering on a display of a computer device, an image of a static scene topology;
rendering on the display an object editing node comprising a set of input fields for receiving user input, the object editing node for parameterizing an interaction of a challenger object relative to an ego object, the set of input fields comprising a simulation entity to be used as a reference entity;
receiving into the set of input fields of the object editing node user input defining, in , the ego object as the simulation entity to be used as the reference entity, and further defining at least one temporal or relational constraint of the challenger object relative to the ego object, the at least one temporal or relational constraint defining an interaction point of a defined interaction stage between the ego object and the challenger object;
storing the at least one temporal or relational constraint and the defined interaction stage in an interaction container in a computer memory of the computer device;
generating scenario data of a scenario to be run in a simulation environment, the scenario comprising the defined interaction stage executed on the static scene topology at the interaction point; and
Claims 18 and 19. (text omitted as being substantially similar to claim 1).
1. A computer implemented method for generating a simulation environment for testing an autonomous vehicle, the method comprising:
…
providing to a simulator a dynamic layer of the scenario comprising parameters of the dynamic interaction…
8. (Currently Amended) The method claim 1, wherein the step of generating the scenario comprises:
rendering on a display of a computer device, an image of the static scene topology;
rendering on the display an object editing node comprising a set of input fields for receiving user input, the object editing node for parametrising an interaction of a challenger object relative to an ego object;
receiving into the input fields of the object editing node using input defining at least one temporal or relational constraint of the challenger object relative to the ego object, the at least one temporal or relational constraint defining an interaction point of a defined interaction stage between the ego object and the challenger object;
storing the set of constraints and defined interactions stage in an interaction container in a computer memory of the computer system; and
generating the scenario, the scenario comprising the defined interaction stage executed on the static scene topology at the interaction point.
5. The method of claim 1 wherein the set of input fields comprises a field for .
8. … rendering on the display an object editing node comprising a set of input fields for receiving user input, the object editing node for parametrising an interaction of a challenger object relative to an ego object.
8. The method of claim 1 comprising a step of selecting the static scene topology from a library of predefined scene topologies, and rendering the selected static scene topology on the display.
9. The method of claim 8 comprising the step of selecting the static scene topology from a library of predefined scene topologies, and rendering the selected scene topology on the display.
With respect to claims 1, 18, and 19, As can be seen in the table above, the reference claims disclose all of the limitations except for the following: reference entity field configured to identify … the reference entity field … performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data. However, in analogous art, Partridge teaches: performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data (e.g., Fig. 2 and associated text, e.g., [0058], at block 206, executing a plurality of simulations, each corresponding to a respective value of the variable parameter; [0061], test simulation may be recorded such that the simulation may be replayed in one or more forms to a user; [0063], outputting one or more of the recorded simulations for a user. Outputting a recorded simulation may include, for example, displaying the recorded simulation, transmitting the recorded simulation, or other form of output).
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 invention of reference application with the invention of Partridge because “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—and thoroughly test that component under a wide range of environmental conditions and/or in combination with a wide range of the other components of the autonomous vehicle control system,” as suggested by Partridge (see [0042]).
Furthermore, in additional analogous art, Misaki teaches: reference entity field configured to identify (e.g., p. 6, § 3. The Trigger Data Setting, The TTC of the target object to the … assigned object is calculated, and if the value of the TTC is smaller than the threshold value, the action happen; p. 9, § 3.2,
PNG
media_image1.png
137
506
media_image1.png
Greyscale
5. … In case the reference is another object, set object ID; see also, pp. 32-33, § 7. How to use SEdit Scenario Data in Re:sim simulation.)… the reference entity field (Id., particularly, 5. … In case the reference is another object, set object ID.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Misaki, such that a GUI field is used to set the reference object, because it would give the user more control and flexibility when creating simulation scenarios.
These are provisional nonstatutory obvious type double patenting rejections because the patentably indistinct claims have not in fact been patented.
With respect to claim 5, as seen the table above, claim 8 of the reference application discloses wherein the set of input fields comprises a field for, but does not appear to disclose the following, which is further taught by Partridge: receiving an indication of an object type (e.g., Fig. 1-9 and associated text, e.g., [0023] As noted above, through the Designer 102, the user may also specify vehicle details that is, details of an autonomous vehicle under test (which may be referred to in this disclosure as the “ego vehicle”). The vehicle details may include, for example, the type; [0026], Through the Designer 102, the user may define one or more parameterized features of the scenario or the vehicle. For example, one or more of the following features may be parameterized: … vehicle type.).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 7, the reference claim does not appear to disclose the following, which is further taught in Partridge: wherein the static scene topology comprises a road layout (e.g., Figs. 1-6 and associated text, e.g., [0073], FIG. 6 is an example simulated urban roadway scene 600 that may find use with the method 500 of FIG. 5; see also [0021] and [0048].).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 8, As can be seen in the table above, the limitations are disclosed in claim 9 of the reference application.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 15, the reference claim does not appear to disclose the following, which is further taught in Partridge: storing the interaction container with an interaction container identifier which identifies the defined interaction stage and the scene topology (e.g., Figs. 1-9 and 11 along with associated text, e.g., [0059], executing a simulation may include creating a simulation engine container instance, which container instance includes the scenario of the simulation and remaining test simulation parameter set; [0085], The simulation engine container instance may be specific to a set of test parameter values; see also [0054], [0082], and [0086].).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
Claims 2, 3, 4, 9, 10, 11, 12, 13, 14, 16, 17, and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 8 of copending Application No. 18/274,259 in view Partridge and Misaki, and further in view of Amelunxen et al. (US 20190295335, hereinafter Amelunxen).
With respect to claim 2, The reference claims do not appear to disclose the following, which is taught in analogous art, Amelunxen: wherein the set of input fields comprises a field for receiving an indication of a defined interaction for the challenger object to execute in the scenario (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Amelunxen because “there is apparent interest in technologies which are applicable to simulating different traffic situations for a test vehicle,” as suggested by Amelunxen (see [0011]).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 3, Amelunxen further teaches wherein the set of input fields comprises an input field for receiving an indication of a manner in which the defined interaction is to be executed in the scenario (e.g., Figs.1-4, [0062], As such, if a situation has been detected in which a vehicle [challenger object] is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0064].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Amelunxen for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 4, The reference claims do not appear to disclose the following, which is taught in analogous art, Amelunxen: wherein the set of input fields comprises a field for receiving an indication of a behavior of the challenger object at the interaction point (e.g., Figs. 1-4, [0062], As such, if a situation has been detected in which a vehicle [challenger object] is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met [indication of a behavior of the challenger object at the interaction point].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Amelunxen because “there is apparent interest in technologies which are applicable to simulating different traffic situations for a test vehicle,” as suggested by Amelunxen (see [0011]).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 9, Partridge further teaches wherein the road layout comprises one or more driving lanes, and (e.g., Figs. 1-9 and associated text, e.g., [0021], the user may select from a predetermined set of scenario details (e.g., a predetermined road network, such as a freeway, urban block, parking lot, etc.); [0073], FIG. 6 is an example simulated urban roadway scene 600; [0073], ach of the streets may include one or more lanes; see also [0048].).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Amelunxen: wherein the set of input fields comprises a field for receiving an indication of lane driving behavior of the challenger object (e.g., Figs. 1-4, [0062], As such, if a situation has been detected in which a vehicle is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0063].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Amelunxen because “there is apparent interest in technologies which are applicable to simulating different traffic situations for a test vehicle,” as suggested by Amelunxen (see [0011]).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 10, Amelunxen further teaches assigning lane identifiers to each of the one or more driving lanes of the road layout, and receiving an association via the object editing node of an identified lane and the challenger object at the interaction point (e.g., Figs. 1-4, particularly, Fig. 4, lane_rel=-1, lane_rel=0, lane_rel=1, and associated text e.g., [0065], According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E; see also [0055], [0057]).
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 invention of the reference application with the invention of Amelunxen for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 11, the reference claim also discloses rendering on the display a object editing node for further parameterizing the challenger object and receiving user input into fields of the editing node to define object editing node comprising a set of input fields for receiving user input, the object editing node for parametrising an interaction of a challenger object relative to an ego object; receiving into the input fields of the object editing node using input defining at least one temporal or relational constraint of the challenger object relative to the ego object, the at least one temporal or relational constraint defining an interaction point of a defined interaction stage between the ego object and the challenger object.)
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Amelunxen: second … second … a further stage of a particular defined interaction (e.g., Figs. 2 and 4 and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form … parameters relative to the test vehicle ... is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.), wherein the particular defined interaction is defined as a respective sequence of interaction stages, wherein the generated scenario comprises the respective sequence of interaction stages executed by the challenger object (Id.; [0062] if a situation has been detected in which a vehicle is in front [challenger object] of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it [sequence of stages]; [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow [challenger object], there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0048], [0050], and [0052].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Amelunxen because “there is apparent interest in technologies which are applicable to simulating different traffic situations for a test vehicle,” as suggested by Amelunxen (see [0011]).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 12, Partridge further teaches rendering on the display an ego object editing node for parameterizing the ego vehicle in the scenario by receiving a starting condition of the ego object and behaviour constraints for the ego object prior to the interaction point. However, this is further taught in Partridge (e.g., Figs. 1-9 and associated text, e.g., [0025] In the Designer, the user may also specify a starting location for the ego vehicle [rendering on the display an ego object editing node for parameterizing the ego vehicle in the scenario by receiving a starting condition of the ego vehicle], as well as an intended destination and/or desired path for the ego vehicle through the road network [behaviour constraints for the ego object prior to the interaction point]; see also [0077-78].).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Amelunxen: prior to the interaction point (e.g., Fig. 2 and Fig. 4, particularly the text box labeled “Ego requirements”, along with associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI. FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2 … According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles … According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h.).
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 invention of the reference claim with the invention of Amelunxen because there is “interest in technologies which are applicable to simulating different traffic situations for a test vehicle, and to the randomized testing of a test vehicle”, as suggested by Amelunxen (see [0011]).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 13, Partridge further teaches wherein the challenger object comprises a dynamic actor, wherein the interaction defines an action to be taken by the dynamic actor at a time and defined by the at least one temporal or relational constraint (e.g., Figs. 1-9 and associated text, e.g., and associated text, e.g., [0021], The user may enter aspects including scenario details and vehicle details. A scenario may include one or more scenes—each including … dynamic actors in the scene, including pedestrian and vehicle traffic; [0022], the user may detail the presence of traffic vehicles and/or pedestrians taking specific actions at specific times; [0078] The method 500 may further include, at block 506, placing one or more dynamic actors and setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0027] and [0071].).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Amelunxen: location in the scenario relative to the ego object (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements” … According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E; see also [0034], [0055] and [0057-62].).
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 invention of the reference claim with the invention of Amelunxen because there is “interest in technologies which are applicable to simulating different traffic situations for a test vehicle, and to the randomized testing of a test vehicle”, as suggested by Amelunxen (see [0011]).
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 14, Amelunxen further teaches wherein the action to be taken by the challenger object comprises a manoeuvre or a behaviour (e.g., Figs. 1-4 and associated text, e.g., [0055], When a predefined traffic situation of this kind is detected, a previously defined movement behavior is imparted to the vehicles involved, such as “vehicle ahead slowing at −8 m/s.sup.2 to 15 km/h” or “overtaking vehicle maintaining speed and cutting in 5 m in front of the test vehicle”; [0065], For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met … According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E.; see also [0038], [0055], and [0063-64].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of the reference claim with the invention of Amelunxen for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 16, Amelunxen further teaches wherein the manoeuvre comprises one of cut-in; cut- out; and switch lanes (e.g., Figs. 1-4 and associated text, e.g., [0064] If the situation check has detected a situation in which there are a certain number of vehicles in the right-hand lane, a particular vehicle can be selected that performs a change of lane with previously stipulated parameters. The change of lane can be varied in different runs of the simulation. This is depicted in FIG. 3, in which another vehicle, to the right and front of the test vehicle E, provokes a critical situation by traveling into the middle lane a short distance in front of the test vehicle E; see also [0038], [0055], and [0063-65].).
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 invention of the reference claim with the invention of Amelunxen for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 17, Amelunxen further teaches wherein the behavior comprises one of: deceleration, acceleration, travel at fixed speed and follow lane (e.g., Figs. 1-4, particularly, a=-20 until v=0 [deceleration], and associated text, e.g., [0055], When a predefined traffic situation of this kind is detected, a previously defined movement behavior is imparted to the vehicles involved, such as “vehicle ahead slowing at −8 m/s.sup.2 to 15 km/h” or “overtaking vehicle maintaining speed and cutting in 5 m in front of the test vehicle”; [0065], According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E see also [0039].).
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 invention of the reference claim with the invention of Amelunxen for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
With respect to claim 20, Partridge further teaches wherein the static scene topology comprises a road layout and the road layout comprises one or more driving lane, and (e.g., Figs. 1-9 and associated text, e.g., [0021], the user may select from a predetermined set of scenario details (e.g., a predetermined road network, such as a freeway, urban block, parking lot, etc.); [0073], FIG. 6 is an example simulated urban roadway scene 600; [0073], ach of the streets may include one or more lanes; see also [0048].).
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 invention of reference application with the invention of Partridge for the same reason set forth above.
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Amelunxen: wherein the set of input fields comprises a field for receiving an indication of lane driving behavior of the challenger object (e.g., Figs. 1-4, [0062], As such, if a situation has been detected in which a vehicle is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0063].).
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 invention of the reference claim with the invention of Amelunxen for the same reason set forth above.
This is a provisional nonstatutory obvious type double patenting rejection.
Claim 6 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 8 of copending Application No. 18/274,259 in view of Partridge and Misaki, as applied to instant claim 1 above, and further in view of Amelunxen and Chu et al. (US 11921504, hereinafter Chu).
With respect to claim 6, Partridge further teaches wherein one or more of of predetermined options, enabling selection by a user of one of the predetermined options
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 invention of reference application with the invention of Partridge for the same reason set forth above.
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Amelunxen: the set of input fields comprises (e.g., Figs. 2 and 4 and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of absolute parameters (or parameters relative to the test vehicle) is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.) … to parameterize the challenger object (e.g., Figs. 2 and 4 and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.).
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 invention of the reference claim with the invention of Amelunxen because there is “interest in technologies which are applicable to simulating different traffic situations for a test vehicle, and to the randomized testing of a test vehicle”, as suggested by Amelunxen (see [0011]).
The reference claim as modified does not appear to disclose the following, which is taught in analogous art, Chu: menu (e.g., Fig. 2 and associated text, e.g., col. 17:6-24, the request submission page 206 may include a dataset limitation input box 230 including a menu selectable option 232.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the menu invention of Chu because menus are a well-known and user-friendly means for users to quickly select options.
This is a provisional nonstatutory obvious type double patenting rejection.
Claim Rejections - 35 USC § 103
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5 and 7-20 are rejected under 35 U.S.C. 103 as being unpatentable over Partridge et al. (US 20200250363, hereinafter Partridge; see IDS filed on 7/25/23) in view of Amelunxen et al. (US 20190295335, hereinafter Amelunxen) and Misaki Design, LLC “Simulation Data Editor for Re:sim Manual Part 2: Scenario Data Setting” (hereinafter Misaki).
With respect to claim 1, Partridge discloses A computer implemented method of generating a scenario to be run in a simulation environment for testing a behaviour of an autonomous vehicle (e.g., Figs. 1-9 and associated text, e.g., [0015], a digital simulation environment may be provided in which various aspects of an autonomous vehicle system may be virtually tested and validated.), the method comprising:
rendering on a display of a computer device, an image of a static scene topology (e.g., Figs. 1-6 and associated text, e.g., [0073], FIG. 6 is an example simulated urban roadway scene 600 that may find use with the method 500 of FIG. 5; see also [0021] and [0048].);
rendering on the display an object editing node comprising for receiving user input, the object editing node for parameterizing an interaction of a challenger object (e.g., Figs. 1-6 and associated text, e.g., [0021], Designer 102 may include a user interface, such as a graphical user interface, through which the user enters one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details. A scenario may include … dynamic actors in the scene, including pedestrian and vehicle traffic [challenger object]; [0026], Through the Designer 102, the user may define one or more parameterized features of the scenario or the vehicle; [0078], placing one or more dynamic actors and setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0019], [0023-23], [0027] and [0071].);
receiving into of the object editing node, user input , and further defining at least one temporal or relational constraint of the challenger object , the at least one temporal or relational constraint defining of a defined interaction stage between the ego object and the challenger object (e.g., Figs. 1-6 and associated text, e.g., [0021] The Designer 102 may include a user interface, such as a graphical user interface, through which the user enters one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details. A scenario may include one or more scenes; [0022], a user may detail a specific circumstance or event for which the user would like to test the autonomous vehicle. For example, the user may detail the presence of traffic vehicles and/or pedestrians [challenger object] taking specific actions at specific times [temporal constraint]; [0077], Designating a path of the ego vehicle may include, for example, receiving a user-designated path through the test scene; [0078], setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors [challenge object] may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0027], [0050], [0062], [0071-72].);
storing the at least one temporal or relational constraint and defined interaction stage in an interaction container in a computer memory of the computer device (e.g., Figs. 1-9 and 11 along with associated text, e.g., [0059], executing a simulation may include creating a simulation engine container instance, which container instance includes the scenario of the simulation and remaining test simulation parameter set; see also [0054], [0082], and [0086].); and
generating scenario data of a scenario to be run in a simulation environment, the scenario comprising the defined interaction stage executed on the static scene topology at (e.g., Figs. 1-9 and associated text, e.g., [0028], perform simulations according to the data received from the user through the Designer; [0030] the simulation engine 114 may simulate a scenario; [0071], FIG. 5 is a flow chart illustrating an example method 500 of defining a scenario for a test simulation of an autonomous vehicle and/or component thereof. The method 500, … may be performed by … the Designer 102; [0061], a given test simulation may be recorded as a “video” (i.e., 4D render) in which the user views the ego vehicle moving through the test scenario; [0086], running the simulation according to the linked simulation engine container instance and SUT instance, which may include creating the scene, simulating the environment, simulating the third party dynamic actors, simulating the operation of one or more sensors, and simulating the behavior of the ego vehicle (e.g., along a selected path); see also [0058] and [0073].); and
performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data (e.g., Fig. 2 and associated text, e.g., [0058], at block 206, executing a plurality of simulations, each corresponding to a respective value of the variable parameter; [0061], test simulation may be recorded such that the simulation may be replayed in one or more forms to a user; [0063], outputting one or more of the recorded simulations for a user. Outputting a recorded simulation may include, for example, displaying the recorded simulation, transmitting the recorded simulation, or other form of output.).
Partridge does not appear to disclose the following, which is taught in analogous art, Amelenxen: a set of input fields (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].) … relative to an ego object, the set of input fields comprising (Id., particularly, [0065], For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle [ego object] … is storable via a text input field “requirements.”) … a simulation entity to be used as a reference entity (e.g., Figs. 2 and 4 along with associated text, e.g., [0034] As far as the positions of the other vehicles are concerned, these are preferably given by their relative positions in relation to the test vehicle … It is furthermore advantageous if the speed and/or the acceleration of the other vehicles are, at least optionally, indicated in relation to the test vehicle.) … the set of input fields (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of absolute parameters (or parameters relative to the test vehicle) is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].) … the ego object as the simulation entity to be used as the reference entity (e.g., Figs. 2 and 4 along with associated text, e.g., [0034] As far as the positions of the other vehicles are concerned, these are preferably given by their relative positions in relation to the test vehicle … It is furthermore advantageous if the speed and/or the acceleration of the other vehicles are, at least optionally, indicated in relation to the test vehicle.) … relative to the ego object as the reference entity (Id., particularly, [0065], For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle [ego object] … is storable via a text input field “requirements.”) … an interaction point (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI. FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2 … The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met [interaction point]. According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E [interaction point]; see also [0034], [0055] and [0057-62].) … the interaction point (Id.; see also Abstract, A method for simulating different traffic situations for an autonomous or semiautonomous test vehicle … a determination of whether a predefined traffic situation is satisfied by the test vehicle and at least one of the other vehicles … Where the predefined traffic situation is satisfied … the at least one other vehicle can be made to perform a predetermined driving maneuver; see also [0056].).
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 invention of Partridge with the invention of Amelunxen because there is “interest in technologies which are applicable to simulating different traffic situations for a test vehicle, and to the randomized testing of a test vehicle”, as suggested by Amelunxen (see [0011].
Partridge does not appear to disclose the following, which is taught in analogous art, Misaki: reference entity field configured to identify (e.g., p. 6, § 3. The Trigger Data Setting, The TTC of the target object to the … assigned object is calculated, and if the value of the TTC is smaller than the threshold value, the action happen; p. 9, § 3.2,
PNG
media_image1.png
137
506
media_image1.png
Greyscale
5. … In case the reference is another object, set object ID; see also, pp. 32-33, § 7. How to use SEdit Scenario Data in Re:sim simulation; Examiner notes that the user inputs the identifier of a simulation reference object into the GUI field labeled with the annotation “5” above, i.e., reference entity field configured to identify a simulation entity to be used as a reference entity.) … defining, in the reference entity field (Id., particularly, 5. … In case the reference is another object, set object ID.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Partridge with the invention of Misaki, such that a GUI field is used to set the reference object, because it would give the user more control and flexibility when creating simulation scenarios.
With respect to claim 18, Partridge discloses A computer system for generating a scenario to be run in a simulation environment for testing a behaviour of an autonomous vehicle, the system comprising: computer memory (e.g., Figs. 1 and 11 along with associated text, e.g., [0017], FIG. 1 is a diagrammatic view of an example system 100 for testing and validation of an autonomous vehicle system. The system 100 may include a number of functional modules embodied in hardware and/or software. In embodiments, each of the functional modules described herein may be embodied in one or more non-transitory, computer-readable memory devices storing computer-readable instructions that, when executed by a processor, cause the processor to perform the described functionality of the module; [0106], computing system environment 1100 typically includes at least one processing unit 1102 and at least one memory 1104.);
a user interface configured to display an image of a static scene topology (e.g., Figs. 1-6 and associated text, e.g., [0073], FIG. 6 is an example simulated urban roadway scene 600 that may find use with the method 500 of FIG. 5; see also [0021] and [0048].);
a processor configured to render on the user interface an object editing node comprising for receiving user input, the object editing node for parameterizing an interaction of a challenger object (e.g., Figs. 1-6 and associated text, e.g., [0021], Designer 102 may include a user interface, such as a graphical user interface, through which the user enters one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details. A scenario may include … dynamic actors in the scene, including pedestrian and vehicle traffic [challenger object]; [0026], Through the Designer 102, the user may define one or more parameterized features of the scenario or the vehicle; [0078], placing one or more dynamic actors and setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0019], [0023-23], [0027] and [0071].);
the user interface configured to receive into of the object editing node user input one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details.), and further defining at least one temporal or relational constraint of the challenger object , the at least one temporal or relational constraint defining of a defined interaction stage between the ego object and the challenger object (e.g., Figs. 1-6 and associated text, e.g., [0021] The Designer 102 may include a user interface, such as a graphical user interface, through which the user enters one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details. A scenario may include one or more scenes; [0022], a user may detail a specific circumstance or event for which the user would like to test the autonomous vehicle. For example, the user may detail the presence of traffic vehicles and/or pedestrians [challenger object] taking specific actions at specific times [temporal constraint]; [0077], Designating a path of the ego vehicle may include, for example, receiving a user-designated path through the test scene; [0078], setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors [challenge object] may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0027], [0050], [0062], [0071-72].);
the processor configured to store the at least one temporal or relational constraint and the defined interaction stage in an interaction container in the computer memory of the computer system (e.g., Figs. 1-9 and 11 along with associated text, e.g., [0059], executing a simulation may include creating a simulation engine container instance, which container instance includes the scenario of the simulation and remaining test simulation parameter set; see also [0054], [0082], and [0086].);
to generate scenario data of a scenario to be run in a simulation environment, the scenario comprising the defined interaction stage executed on the static scene topology at (e.g., Figs. 1-9 and associated text, e.g., [0028], perform simulations according to the data received from the user through the Designer; [0030] the simulation engine 114 may simulate a scenario; [0071], FIG. 5 is a flow chart illustrating an example method 500 of defining a scenario for a test simulation of an autonomous vehicle and/or component thereof. The method 500, … may be performed by … the Designer 102; [0061], a given test simulation may be recorded as a “video” (i.e., 4D render) in which the user views the ego vehicle moving through the test scenario; [0086], running the simulation according to the linked simulation engine container instance and SUT instance, which may include creating the scene, simulating the environment, simulating the third party dynamic actors, simulating the operation of one or more sensors, and simulating the behavior of the ego vehicle (e.g., along a selected path); see also [0058] and [0073].); and
the computer system further comprising a scenario runtime module configured to receive the scenario data of the scenario, to perform a simulation of the scenario based on the scenario data, and to generate runtime output data (e.g., Fig. 2 and associated text, e.g., [0058], at block 206, executing a plurality of simulations, each corresponding to a respective value of the variable parameter; [0061], test simulation may be recorded such that the simulation may be replayed in one or more forms to a user; [0063], outputting one or more of the recorded simulations for a user. Outputting a recorded simulation may include, for example, displaying the recorded simulation, transmitting the recorded simulation, or other form of output.).
Partridge does not appear to disclose the following, which is taught in analogous art, Amelenxen: a set of input fields (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].) … relative to an ego object, the set of input fields comprising (Id., particularly, [0065], For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle [ego object] … is storable via a text input field “requirements.”) … a simulation entity to be used as a reference entity (e.g., Figs. 2 and 4 along with associated text, e.g., [0034] As far as the positions of the other vehicles are concerned, these are preferably given by their relative positions in relation to the test vehicle … It is furthermore advantageous if the speed and/or the acceleration of the other vehicles are, at least optionally, indicated in relation to the test vehicle.) … the set of input fields (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of absolute parameters (or parameters relative to the test vehicle) is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].) … the ego object as the simulation entity to be used as the reference entity (e.g., Figs. 2 and 4 along with associated text, e.g., [0034] As far as the positions of the other vehicles are concerned, these are preferably given by their relative positions in relation to the test vehicle … It is furthermore advantageous if the speed and/or the acceleration of the other vehicles are, at least optionally, indicated in relation to the test vehicle.) … relative to the ego object as the reference entity (Id., particularly, [0065], For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle [ego object] … is storable via a text input field “requirements.”) … an interaction point (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI. FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2 … The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met [interaction point]. According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E [interaction point]; see also [0034], [0055] and [0057-62].) … the interaction point (Id.; see also Abstract, A method for simulating different traffic situations for an autonomous or semiautonomous test vehicle … a determination of whether a predefined traffic situation is satisfied by the test vehicle and at least one of the other vehicles … Where the predefined traffic situation is satisfied … the at least one other vehicle can be made to perform a predetermined driving maneuver; see also [0056].).
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 invention of Partridge with the invention of Amelunxen because there is “interest in technologies which are applicable to simulating different traffic situations for a test vehicle, and to the randomized testing of a test vehicle”, as suggested by Amelunxen (see [0011].
Partridge does not appear to disclose the following, which is taught in analogous art, Misaki: a reference entity field configured to identify (e.g., p. 6, § 3. The Trigger Data Setting, The TTC of the target object to the … assigned object is calculated, and if the value of the TTC is smaller than the threshold value, the action happen; p. 9, § 3.2,
PNG
media_image1.png
137
506
media_image1.png
Greyscale
5. … In case the reference is another object, set object ID; see also, pp. 32-33, § 7. How to use SEdit Scenario Data in Re:sim simulation; Examiner notes that the user inputs the identifier of a simulation reference object into the GUI field labeled with the annotation “5” above, i.e., reference entity field configured to identify a simulation entity to be used as a reference entity.) … defining, in the reference entity field (Id., particularly, 5. … In case the reference is another object, set object ID.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Partridge with the invention of Misaki, such that a GUI field is used to set the reference object, because it would give the user more control and flexibility when creating simulation scenarios.
With respect to claim 19, Partridge discloses A non-transitory computer readable media on which is stored computer readable instructions which when executed by one or more processors carry out a method comprising (e.g., Figs. 1 and 11 and associated text, e.g., [0017], each of the functional modules described herein may be embodied in one or more non-transitory, computer-readable memory devices storing computer-readable instructions that, when executed by a processor, cause the processor to perform the described functionality of the module.):
rendering on a display of a computer device, an image of a static scene topology (e.g., Figs. 1-6 and associated text, e.g., [0073], FIG. 6 is an example simulated urban roadway scene 600 that may find use with the method 500 of FIG. 5; see also [0021] and [0048].);
rendering on the display an object editing node comprising for receiving user input, the object editing node for parameterizing an interaction of a challenger object ;
receiving into of the object editing node user input such as a graphical user interface, through which the user enters one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details.), and further defining at least one temporal or relational constraint of the challenger object , the at least one temporal or relational constraint defining of a defined interaction stage between the ego object and the challenger object (e.g., Figs. 1-6 and associated text, e.g., [0021] The Designer 102 may include a user interface, such as a graphical user interface, through which the user enters one or more aspects of a desired simulation. The user may enter aspects including scenario details and vehicle details. A scenario may include one or more scenes; [0022], a user may detail a specific circumstance or event for which the user would like to test the autonomous vehicle. For example, the user may detail the presence of traffic vehicles and/or pedestrians [challenger object] taking specific actions at specific times [temporal constraint]; [0077], Designating a path of the ego vehicle may include, for example, receiving a user-designated path through the test scene; [0078], setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors [challenge object] may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0027], [0050], [0062], [0071-72].);
storing the at least one temporal or relational constraint and defined interaction stage in an interaction container in a computer memory of the computer device (e.g., Figs. 1-9 and 11 along with associated text, e.g., [0059], executing a simulation may include creating a simulation engine container instance, which container instance includes the scenario of the simulation and remaining test simulation parameter set; see also [0054], [0082], and [0086].);
generating scenario data of a scenario to be run in a simulation environment, the scenario comprising the defined interaction stage executed on the static scene topology at (e.g., Figs. 1-9 and associated text, e.g., [0028], perform simulations according to the data received from the user through the Designer; [0030] the simulation engine 114 may simulate a scenario; [0071], FIG. 5 is a flow chart illustrating an example method 500 of defining a scenario for a test simulation of an autonomous vehicle and/or component thereof. The method 500, … may be performed by … the Designer 102; [0061], a given test simulation may be recorded as a “video” (i.e., 4D render) in which the user views the ego vehicle moving through the test scenario; [0086], running the simulation according to the linked simulation engine container instance and SUT instance, which may include creating the scene, simulating the environment, simulating the third party dynamic actors, simulating the operation of one or more sensors, and simulating the behavior of the ego vehicle (e.g., along a selected path); see also [0058] and [0073].); and
performing a simulation of the scenario by a scenario runtime module based on the scenario data, to generate runtime output data (e.g., Fig. 2 and associated text, e.g., [0058], at block 206, executing a plurality of simulations, each corresponding to a respective value of the variable parameter; [0061], test simulation may be recorded such that the simulation may be replayed in one or more forms to a user; [0063], outputting one or more of the recorded simulations for a user. Outputting a recorded simulation may include, for example, displaying the recorded simulation, transmitting the recorded simulation, or other form of output.).
Partridge does not appear to disclose the following, which is taught in analogous art, Amelenxen: a set of input fields (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].) … relative to an ego object, the set of input fields comprising (Id., particularly, [0065], For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle [ego object] … is storable via a text input field “requirements.”) … a simulation entity to be used as a reference entity (e.g., Figs. 2 and 4 along with associated text, e.g., [0034] As far as the positions of the other vehicles are concerned, these are preferably given by their relative positions in relation to the test vehicle … It is furthermore advantageous if the speed and/or the acceleration of the other vehicles are, at least optionally, indicated in relation to the test vehicle.) … the input fields (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of absolute parameters (or parameters relative to the test vehicle) is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].) … the ego object as the simulation entity to be used as the reference entity (e.g., Figs. 2 and 4 along with associated text, e.g., [0034] As far as the positions of the other vehicles are concerned, these are preferably given by their relative positions in relation to the test vehicle … It is furthermore advantageous if the speed and/or the acceleration of the other vehicles are, at least optionally, indicated in relation to the test vehicle.) … relative to the ego object as the reference entity (Id., particularly, [0065], For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle [ego object] … is storable via a text input field “requirements.”) … an interaction point (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI. FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2 … The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met [interaction point]. According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E [interaction point]; see also [0034], [0055] and [0057-62].) … the interaction point (Id.; see also Abstract, A method for simulating different traffic situations for an autonomous or semiautonomous test vehicle … a determination of whether a predefined traffic situation is satisfied by the test vehicle and at least one of the other vehicles … Where the predefined traffic situation is satisfied … the at least one other vehicle can be made to perform a predetermined driving maneuver; see also [0056].).
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 invention of Partridge with the invention of Amelunxen because there is “interest in technologies which are applicable to simulating different traffic situations for a test vehicle, and to the randomized testing of a test vehicle”, as suggested by Amelunxen (see [0011].
Partridge does not appear to disclose the following, which is taught in analogous art, Misaki: a reference entity field configured to identify (e.g., p. 6, § 3. The Trigger Data Setting, The TTC of the target object to the … assigned object is calculated, and if the value of the TTC is smaller than the threshold value, the action happen; p. 9, § 3.2,
PNG
media_image1.png
137
506
media_image1.png
Greyscale
5. … In case the reference is another object, set object ID; see also, pp. 32-33, § 7. How to use SEdit Scenario Data in Re:sim simulation; Examiner notes that the user inputs the identifier of a simulation reference object into the GUI field labeled with the annotation “5” above, i.e., reference entity field configured to identify a simulation entity to be used as a reference entity.) … defining, in the reference entity field (Id., particularly, 5. … In case the reference is another object, set object ID.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Partridge with the invention of Misaki, such that a GUI field is used to set the reference object, because it would give the user more control and flexibility when creating simulation scenarios.
With respect to claim 2, Amelunxen further teaches wherein the set of input fields comprises a field for receiving an indication of a defined interaction for the challenger object to execute in the scenario (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow [challenger object], a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0034], [0055] and [0057-62].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 3, Amelunxen further teaches wherein the set of input fields comprises an input field for receiving an indication of a manner in which the defined interaction is to be executed in the scenario (e.g., Figs.1-4, [0062], As such, if a situation has been detected in which a vehicle [challenger object] is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0064].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above with respect to claim 2.
With respect to claim 4, Amelunxen further teaches wherein the set of input fields comprises a field for receiving an indication of a behavior of the challenger object at the interaction point (e.g., Figs. 1-4, [0062], As such, if a situation has been detected in which a vehicle [challenger object] is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met [indication of a behavior of the challenger object at the interaction point].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 5, Partridge also discloses wherein for receiving an indication of an object type (e.g., Fig. 1-9 and associated text, e.g., [0023] As noted above, through the Designer 102, the user may also specify vehicle details that is, details of an autonomous vehicle under test (which may be referred to in this disclosure as the “ego vehicle”). The vehicle details may include, for example, the type; [0026], Through the Designer 102, the user may define one or more parameterized features of the scenario or the vehicle. For example, one or more of the following features may be parameterized: … vehicle type.) and Amelunxen further teaches the set of input fields comprises a field (e.g., Fig. 4, particularly Ego requirements, Fellow 1 requirements, vehicle maneuver [a set of input fields] and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of absolute parameters (or parameters relative to the test vehicle) is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above and because text fields are a well-known and user-friendly means of inputting data.
With respect to claim 7, Partridge also discloses wherein the static scene topology comprises a road layout (e.g., Figs. 1-6 and associated text, e.g., [0073], FIG. 6 is an example simulated urban roadway scene 600 that may find use with the method 500 of FIG. 5; see also [0021] and [0048].).
With respect to claim 8, Partridge also discloses a step of selecting the static scene topology from a library of predefined scene topologies, and rendering the selected static scene topology on the display (e.g., Figs. 1-9 and associated text, e.g., [0021], the user may select from a predetermined set of scenario details (e.g., a predetermined road network, such as a freeway, urban block, parking lot, etc.); [0073], FIG. 6 is an example simulated urban roadway scene 600; see also [0048].).
With respect to claim 9, Partridge also discloses wherein the road layout comprises one or more driving lanes, and (e.g., Figs. 1-9 and associated text, e.g., [0021], the user may select from a predetermined set of scenario details (e.g., a predetermined road network, such as a freeway, urban block, parking lot, etc.); [0073], FIG. 6 is an example simulated urban roadway scene 600; [0073], ach of the streets may include one or more lanes; see also [0048].) and Amelunxen further teaches wherein the set of input fields comprises a field for receiving an indication of lane driving behavior of the challenger object (e.g., Figs. 1-4, [0062], As such, if a situation has been detected in which a vehicle is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0063].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 10, Amelunxen further teaches assigning lane identifiers to each of the one or more driving lanes of the road layout, and receiving an association via the object editing node of an identified lane and the challenger object at the interaction point (e.g., Figs. 1-4, particularly, Fig. 4, lane_rel=-1, lane_rel=0, lane_rel=1, and associated text e.g., [0065], According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E; see also [0055], [0057]).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 11, Amelunxen further teaches rendering on the display a second object editing node for further parameterizing the challenger object and receiving user input into of the second object editing node to define a further stage of a particular defined interaction (e.g., Figs. 2 and 4 and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form … parameters relative to the test vehicle ... is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.), wherein the particular defined interaction is defined as a respective sequence of stages, wherein the generated scenario comprises the respective sequence of interaction stages executed by the challenger object (Id.; [0062] if a situation has been detected in which a vehicle is in front [challenger object] of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it [sequence of stages]; [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow [challenger object], there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0048], [0050], and [0052].). Furthermore, to the extent that Amelunxen teaches a second object editing node with a singular field as opposed to fields, this is further taught in Misaki (e.g., p. 25, § 5.2.2 Accel/Brake, Steering Override, To override Acceleration/Deceleration and Steering inputted to the vehicle, check “Accel/Brake Input” or “Steering Input” and set profile data to the corresponding tables.
PNG
media_image2.png
181
270
media_image2.png
Greyscale
.).
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 invention of Partridge with the inventions of Amelunxen and Misaki, such that the maneuver in inputted as multiple fields, for the same reason set forth above and also because having separate fields for the driving action would be more visually appealing than a single long field and it would make it easier for the user to quickly understand what the action does.
With respect to claim 12, Partridge also discloses rendering on the display an ego object editing node for parameterizing the ego object in the scenario by receiving a starting condition of the ego object and behaviour constraints for the ego object (e.g., Figs. 1-9 and associated text, e.g., [0025] In the Designer, the user may also specify a starting location for the ego vehicle, as well as an intended destination and/or desired path for the ego vehicle through the road network; [0026], Through the Designer 102, the user may define one or more parameterized features of the scenario or the vehicle. For example, one or more of the following features may be parameterized: … (ii) aspects of the control programming of the autonomous vehicle (e.g., response strategies to particular stimuli or events); (iii) features of the vehicle itself … acceleration and turning performance.) see also [0019], [0021], and [0077-78].) and Amelunxen furth teaches prior to the interaction point (e.g., Fig. 2 and Fig. 4, particularly the text box labeled “Ego requirements”, along with associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI. FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2 … According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles … According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h.).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 13, Partridge also discloses wherein the challenger object comprises a dynamic actor, wherein the interaction defines an action to be taken by the dynamic actor at a time and defined by the at least one temporal or relational constraint (e.g., Figs. 1-9 and associated text, e.g., and associated text, e.g., [0021], The user may enter aspects including scenario details and vehicle details. A scenario may include one or more scenes—each including … dynamic actors in the scene, including pedestrian and vehicle traffic; [0022], the user may detail the presence of traffic vehicles and/or pedestrians taking specific actions at specific times; [0078] The method 500 may further include, at block 506, placing one or more dynamic actors and setting behaviors of the one or more dynamic actors in the test scenario. Dynamic actors may include, for example, traffic vehicles (e.g., cars, trucks, buses, etc.), bicyclists, pedestrians, and other third-party actors relative to the ego vehicle; see also [0027] and [0071].) and Amelunxen further teaches location in the scenario relative to the ego object (e.g., Figs. 1-4 and associated text, e.g., [0065], With reference to FIG. 4 … predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements” … According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E; see also [0034], [0055] and [0057-62].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 14, Amelunxen further teaches wherein the action to be taken by the challenger object comprises a manoeuvre or a behaviour (e.g., Figs. 1-4 and associated text, e.g., [0055], When a predefined traffic situation of this kind is detected, a previously defined movement behavior is imparted to the vehicles involved, such as “vehicle ahead slowing at −8 m/s.sup.2 to 15 km/h” or “overtaking vehicle maintaining speed and cutting in 5 m in front of the test vehicle”; [0065], For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met … According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E.; see also [0038], [0055], and [0063-64].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 15, Partridge also discloses storing the interaction container with an interaction container identifier which identifies the defined interaction stage and the static scene topology (e.g., Figs. 1-9 and 11 along with associated text, e.g., [0059], executing a simulation may include creating a simulation engine container instance, which container instance includes the scenario of the simulation and remaining test simulation parameter set; [0085], The simulation engine container instance may be specific to a set of test parameter values; see also [0054], [0082], and [0086].).
With respect to claim 16, Amelunxen further teaches wherein the manoeuvre comprises one of cut-in; cut- out; and switch lanes (e.g., Figs. 1-4 and associated text, e.g., [0064] If the situation check has detected a situation in which there are a certain number of vehicles in the right-hand lane, a particular vehicle can be selected that performs a change of lane with previously stipulated parameters. The change of lane can be varied in different runs of the simulation. This is depicted in FIG. 3, in which another vehicle, to the right and front of the test vehicle E, provokes a critical situation by traveling into the middle lane a short distance in front of the test vehicle E; see also [0038], [0055], and [0063-65].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
With respect to claim 17, Amelunxen further teaches wherein the behaviour comprises one of: deceleration, acceleration, travel at fixed speed and follow lane (e.g., Figs. 1-4, particularly, a=-20 until v=0 [deceleration], and associated text, e.g., [0055], When a predefined traffic situation of this kind is detected, a previously defined movement behavior is imparted to the vehicles involved, such as “vehicle ahead slowing at −8 m/s.sup.2 to 15 km/h” or “overtaking vehicle maintaining speed and cutting in 5 m in front of the test vehicle”; [0065], According to the example of FIG. 4, the test vehicle is to travel at a speed of at least 40 km/h, and the first fellow is to be in the lane to the left of the test vehicle at a distance of no more than 10 m in front of or behind the test vehicle E see also [0039].).
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above with respect to claim 14.
With respect to claim 20, Partridge also discloses wherein the static scene topology comprises a road layout and the road layout comprises one or more driving lane, and (e.g., Figs. 1-9 and associated text, e.g., [0021], the user may select from a predetermined set of scenario details (e.g., a predetermined road network, such as a freeway, urban block, parking lot, etc.); [0073], FIG. 6 is an example simulated urban roadway scene 600; [0073], ach of the streets may include one or more lanes; see also [0048].) and Amelunxen further teaches wherein the set of input fields comprises a field for receiving an indication of lane driving behavior of the challenger object (e.g., Figs. 1-4, [0062], As such, if a situation has been detected in which a vehicle is in front of the test vehicle E, and in which the left-hand and right-hand lanes are occupied by further vehicles, the vehicle ahead of the test vehicle can have heavy braking imparted to it. The braking delay can be to be configured beforehand, and can be varied in different runs of the simulation. Such is depicted schematically in FIG. 2; [0065], FIG. 4, in particular, depicts the input of traffic situation entries which correspond to the example discussed hereinabove in connection with FIG. 2. The GUI is part of a piece of software for creating a simulation environment. According to the example of FIG. 4, maneuver definition corresponds to the test vehicle E, denoted by “Ego,” and a plurality of “fellow” vehicles [challenger object].… For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver. The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met; see also [0063].).
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 invention of Partridge with the invention of Amelunxen because “there is apparent interest in technologies which are applicable to simulating different traffic situations for a test vehicle,” as suggested by Amelunxen (see [0011]).
Claims 6 is rejected under 35 U.S.C. 103 as being unpatentable over Partridge in view of Amelunxen and Misaki, as applied to claim 1 above, and further in view of Chu et al. (US 11921504, hereinafter Chu).
With respect to claim 6, Partridge also discloses wherein one or more of of predetermined options, enabling selection by a user of one of the predetermined optionsthe set of input fields comprises (e.g., Figs. 2 and 4 and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of absolute parameters (or parameters relative to the test vehicle) is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.) … to parameterize the challenger object (e.g., Figs. 2 and 4 and associated text, e.g., [0065], predefined traffic situations can be input on a screen using a GUI…. For each fellow, a target specification in the form of … parameters relative to the test vehicle … is storable via a text input field “requirements.” For each fellow, there is also a second text input field. This second text input field is labeled “vehicle maneuver.” The “vehicle maneuver” field for a given fellow can be used to define a maneuver that the fellow performs once all of the target specifications, set via the corresponding “requirements” text input field, have been met.)
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 invention of Partridge with the invention of Amelunxen for the same reason set forth above.
Partridge as modified does not appear to disclose a menu. However, this is taught in analogous art, Chu (e.g., Fig. 2 and associated text, e.g., col. 17:6-24, the request submission page 206 may include a dataset limitation input box 230 including a menu selectable option 232.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the menu invention of Chu because menus are a well-known and user-friendly means for users to quickly select options.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Kabirzadeh et al. US 11150660 B1 teaches using simulation scenarios for testing and validating interactions and responses of a vehicle.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
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, Hyung S. Sough can be reached on 571-272-6799. 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.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 See MPEP § 2181(IV). See also § 2163.03(VI).
2 See MPEP § 2181(IV). See also § 2163.03(VI).
3 See MPEP § 2181(IV). See also § 2163.03(VI).
4 See MPEP § 2181(II)(B), 5th para., “An algorithm is defined, for example, as ‘a finite sequence of steps for solving a logical or mathematical problem or performing a task.’”
Prosecution Insights