DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 and 11-13 recites the limitation "the automated testing", “the driving function”, “in the vehicle to updating”, “the simulation results”, “the modified function” in lines 1, 3, 6, 10 and 15. There is insufficient antecedent basis for this limitation in the claim
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because
As per claim 1
under Step 2A, Prong 1,
Claim 1
A computer-implemented method for the automated testing and release of functions or safety functions integrated into an end-to-end process from data collection in the vehicle to updating the driving function back into the vehicle and/or virtual homologation of at least partially autonomous driving functions to be tested, the method comprising:
receiving vehicle data from at least one real vehicle, obtained in a real driving operation, wherein the vehicle data contain measured sensor values of the vehicle;
extracting at least one parameter from the vehicle data;
creating a simulation parameterized with the at least one extracted parameter;
carrying out at least one test with the created simulation;
evaluating the simulation results using at least one manually and/or automatically selected key performance indicator (KPI) and
determining if the KPI falls below and/or exceeds a defined threshold value and optimizing and/or changing the function to be tested and testing the function using the steps of carrying out at least one test and evaluating the simulation results; and
releasing the modified function and/or transmitting the modified function to the at least one real vehicle.
Under its broadest reasonable interpretation,
extracting at least one parameter from the vehicle data;
creating a simulation parameterized with the at least one extracted parameter;
carrying out at least one test with the created simulation;
evaluating the simulation results using at least one manually and/or automatically selected key performance indicator (KPI) and determining if the KPI falls below and/or exceeds a defined threshold value and optimizing and/or changing the function to be tested and testing the function using the steps of carrying out at least one test and evaluating the simulation results as drafted is a process that recite of mental processes. These limitations encompass a human mind carrying out these functions through extracting, carrying, evaluating, judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
Under Step 2 A prong 2
The judicial exception is not integrated into a practical application. The claims recite the following additional elements, receiving vehicle data from at least one real vehicle, obtained in a real driving operation, wherein the vehicle data contain measured sensor values of the vehicle and releasing the modified function and/or transmitting the modified function to the at least one real vehicle. The additional elements implement as abstract idea on a computer or merely using a generic computer of computer components as a tool to perform the abstract idea. See MPEP 2106(f).
Under Step 2 B
The additional elements receiving vehicle data from at least one real vehicle, obtained in a real driving operation, wherein the vehicle data contain measured sensor values of the vehicle and releasing the modified function and/or transmitting the modified function to the at least one real vehicle does nothing more than additional insignificant extra solution activity to the judicial expectation, such as determine and releasing modified function see MPEP 2106(g). Accordingly, the additional elements don’t integrate the abstract idea into practical application because it does not impose any meaningful limits on practicing the abstract idea thus fail to integrate the abstract idea into practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than judicial expectation. As discussed above with respect to integration of the abstract idea into practical application, the additional elements are well understood routine and conventional activity see MPEP 2106(d). Accordingly, the additional elements recited in the claims are mental process concept. Thus, claims are not patent eligible.
Claims 2-7,10 and 12-13 as drafted, recite a process that under its broadest reasonable interpretation covers steps that could reasonably be performed in the mind, including with the aid of pen and paper but for the recitation a function of vehicle test and/or simulation, parameter extracted…, evaluate simulation…, driving function, setting function… as drafted is a process that under its broadest interpretation, recite that abstract idea of mental process. These limitations encompass a human carrying out this function through observation, evaluation even with the aid of pen and paper. Thus, these limitations recite and fall with in Mental Process grouping of abstract idea, furthermore fail to integrate the abstract idea into a practical application and fail to amount the abstract idea as discussed above. Thus, the claims are not patent eligible.
Claims 8-9 as drafted, recite a process that under its broadest reasonable interpretation covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components, “digital behavior of the real vehicle …” as drafted is a process that under its broadest interpretation, recite that abstract idea of mental process. These limitations encompass a human carrying out this function through observation, evaluation even with the aid of pen and paper. Thus, these limitations recite and fall with in Mental Process grouping of abstract idea, furthermore fail to integrate the abstract idea into a practical application and fail to amount the abstract idea as discussed above. Thus, the claims are not patent eligible.
Regarding claim 13
With respect to claim 13, the claim is directed to program code. As recited, however, is reasonably interpreted as entirely software or descriptive material per se. The recited program code does not include any hardware that would permit the functionality of the system to be realized. Thus, the claim is directed to non-statutory subject matter.
Claim Rejections - 35 USC § 112
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.
Use of the word “means” (or “step for”) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C.112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in this application that use the word “means” (or “step for”) are presumed to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”) are presumed not to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
Claim limitation “configured to” has/have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses/they use a generic placeholder “configured to” coupled with functional language control and store without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier [00029 such a component and/or driving function can be tested as to whether pedestrians are correctly recognized in various scenarios. If this is the case, the current model configuration can be retained. If there are deviations, the model is adjusted further until the formulated minimum performance is achieved]. Since the claim limitation(s) invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claim(s) 11-12 has/have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation: paragraphs [0007 and 0008]. However, these section does not provide any structure thereof and only summarize the functionality.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 el seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011)
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Heit et al US 2019/0155291 in view of Vardharajan teaches USPN 11/420,645.
Regarding claims 1 and 11
Heit et al teaches
receiving vehicle data from at least one real vehicle, obtained in a real driving operation, wherein the vehicle data contain measured sensor values of the vehicle [0006] Examples described herein include simulating an autonomous and/or semi-autonomous vehicle in one or more scenarios (e.g., traffic scenarios, weather scenarios, etc.). In some embodiments, scenarios include scenario parameters which can describe the environment of an autonomous vehicle system and can vary incrementally between consecutive scenarios (e.g., scenario parameters can describe objects and their locations in the vehicle's environment, weather conditions in the vehicle's environment, etc.). Vehicle performance can be evaluated, or quality of the autonomous vehicle system can be tested, by determining a performance metric for each scenario (e.g., a quantitative indication of the performance of one or more aspects of the autonomous vehicle, such as the performance of vehicle sensors, the performance of vehicle brakes, etc. in the various scenarios). Vehicle parameters can describe an autonomous vehicle system's configuration, including locations of sensors, vehicle dimensions, automated driving systems included in a vehicle, etc.];
extracting at least one parameter from the vehicle data [0026] in some examples, one or more of scenario parameters 110 may be imported, or may be extracted, from a vehicle database and/or a database of analysis of vehicle accidents or other vehicle scenarios. For example, processor 102 may determine one or more scenario parameters 110 based on data imported into storage 104 from a database of the German In-Depth Accident Study or GIDAS. Further, some examples may import, receive and/or extract one or more of scenario parameters 110 from data reported from real-world vehicles or real-world autonomous vehicle systems. For example, processor 102 may import data from automotive sensors of one or more real-world autonomous vehicle systems. For example, data imported by processor 102 from automotive sensors of one or more autonomous vehicle systems may describe various roads, weather data, and traffic conditions, encountered by those autonomous vehicles, that system 100 can use to determine scenario parameters 110 describing scenarios that include a portion of the imported data];
creating a simulation parameterized with the at least one extracted parameter [0017] the various examples of the present invention relate to simulation, validation, and/or testing of an automated vehicle. Specifically, in some examples, an autonomous vehicle can be simulated in a number of different environments (e.g., “scenarios”), environments in which the autonomous vehicle performs most-poorly can be identified (e.g., “minimum performance scenarios”), parameters of the autonomous vehicle (e.g., tire width, sensor locations, etc.) can be varied for those identified minimum performance scenarios to improve the performance of the vehicle in those minimum performance scenarios, and the vehicle having the updated vehicle parameters can be re-simulated to ensure new minimum performance scenarios have not resulted from the changes to the vehicle parameters. In this way, vehicle simulation, validation, testing and/or improvement can be automated];
carrying out at least one test with the created simulation [0005] in various examples described herein, testing may include representing an automated vehicle using a software program configured to simulate real-world environments. In some examples, a representation of an automated vehicle can be derived from inputs extracted from a physical vehicle, such as its dimensions, weight distribution, and other information. In some examples, optimized vehicle configurations may be determined using techniques described herein, and exported to a vehicle. For example, vehicle control systems, optimal vehicle parameters (e.g., sensor positions), and other information can be retrieved from systems described herein to create a safe and reliable autonomous vehicle];
evaluating the simulation results using at least one manually and/or automatically selected key performance indicator (KPI) [0019] examples described herein include simulating an autonomous and/or semi-autonomous vehicle in one or more scenarios (e.g., traffic scenarios, weather scenarios, etc.). In some embodiments, scenarios include scenario parameters which can describe the environment of an autonomous vehicle system and can vary incrementally between consecutive scenarios (e.g., scenario parameters can describe objects and their locations in the vehicle's environment, weather conditions in the vehicle's environment, etc.). Vehicle performance can be evaluated, or quality of the autonomous vehicle system can be tested, by determining a performance metric for each scenario (e.g., a quantitative indication of the performance of one or more aspects of the autonomous vehicle, such as the performance of vehicle sensors, the performance of vehicle brakes, etc. in the various scenarios). Vehicle parameters can describe an autonomous vehicle system's configuration, including locations of sensors, vehicle dimensions, automated driving systems included in a vehicle, etc.];
determining if the KPI falls below and/or exceeds a defined threshold value and optimizing and/or changing the function to be tested and testing the function using the steps of carrying out at least one test and evaluating the simulation results [0040] FIG. 2 illustrates an example process 200 for simulation of an autonomous vehicle system according to examples of the disclosure. Some examples of process 200 may be performed by system 100. Alternatively or in addition, some examples of process 200 may be performed by the autonomous vehicle system 500, a server and/or a cloud computing system. As a general example, system 100 may perform process 200 by simulating several scenarios of the autonomous vehicle system and incrementally varying scenario parameters 110 between successive scenarios, determining performance metrics 112 of the various scenarios, determining minimum performance scenarios 116 as a subset of the scenarios, and improving vehicle parameters 114 by comparing performance metrics 112 determined from several scenarios with identical scenario parameters 110 and incrementally varying vehicle parameters 114 to optimize vehicle parameters and performance, as will be described in more detail below]. Heit et al teaches extracting, receiving driving operations and creating simulation parameter but doesn’t teach explicitly releasing the modified function and/or transmitting the modified function to the at least one real vehicle however, Vardharajan teaches (column 5, line 45, FIG. 2A is a block diagram illustrating an example, non-limiting embodiment of a system determining personalized driving style profiles functioning within the communication network of FIG. 1 in accordance with various aspects described herein. In one or more embodiments, a system 200 can determine a personalized driving style profile of a driver 210, where that personalized driving style profile can be used in an autonomous vehicle control system to mimic this driving style when the driver is a passenger in the autonomous vehicle) and (column 2, line 42, the modification can be received from an application at a mobile communication device. The operations can include providing the personalized driving style profile to an autonomous vehicle control system. The providing the personalized driving style profile can be via the application at the mobile communication device. The autonomous vehicle control system can modify a default driving style algorithm…). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate functions which can be modify or changed. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into automated testing and data collection in vehicle to improves functions and features released in the vehicle for safety, reliability and further to improve with simulation.
Regarding claim 2
Heit et al teaches
a function of a vehicle comprises functions for supporting a driver of the vehicle in certain driving situations and/or traffic situations, wherein the functions enable an increase in the safety and/or energy efficiency and/or driving comfort [0026] in some examples, one or more of scenario parameters 110 may be imported, or may be extracted, from a vehicle database and/or a database of analysis of vehicle accidents or other vehicle scenarios. For example, processor 102 may determine one or more scenario parameters 110 based on data imported into storage 104 from a database of the German In-Depth Accident Study or GIDAS. Further, some examples may import, receive and/or extract one or more of scenario parameters 110 from data reported from real-world vehicles or real-world autonomous vehicle systems. For example, processor 102 may import data from automotive sensors of one or more real-world autonomous vehicle systems. For example, data imported by processor 102 from automotive sensors of one or more autonomous vehicle systems may describe various roads, weather data, and traffic conditions, encountered by those autonomous vehicles, that system 100 can use to determine scenario parameters 110 describing scenarios that include a portion of the imported data]. The feature of providing traffic situation…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 3
Heit et al teaches
a test and/or a simulation is carried out virtually and/or partially virtually [0038] in some examples, simulator 126 and simulation controller 128 may simulate the various scenarios according to scenario parameters 110 and vehicle parameters 114 as determined by scenario analyzer 120 and vehicle analyzer 124. The simulator 126 may utilize contents of storage 104 (e.g., scenario and vehicle parameters 110, 114, performance metrics 112, minimum performance scenarios 116 and/or instructions 118) to simulate the autonomous vehicle system and its environment (e.g., other vehicles, pedestrians, cyclists, the weather, and other scenario parameters 110 as described above) to behave in a manner that is substantially identical to their real-world counterparts. Certain examples of system 100 may present a simulation performed by simulator 126 in a visual format on display 106. Alternatively or in addition, some examples of system 100 may record information associated with a simulation performed by simulator 126 in storage 104. For example, simulator 126 may store scenario and vehicle parameters 110, 114, performance metrics 112 and other data, in storage 104 following each scenario of the autonomous vehicle system]. The feature of providing test/simulation…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 4
Heit et al teaches
a vehicle parameter having at least one vehicle setting and/or a sensor value that indicates a vehicle property [0026] in some examples, one or more of scenario parameters 110 may be imported, or may be extracted, from a vehicle database and/or a database of analysis of vehicle accidents or other vehicle scenarios. For example, processor 102 may determine one or more scenario parameters 110 based on data imported into storage 104 from a database of the German In-Depth Accident Study or GIDAS. Further, some examples may import, receive and/or extract one or more of scenario parameters 110 from data reported from real-world vehicles or real-world autonomous vehicle systems. For example, processor 102 may import data from automotive sensors of one or more real-world autonomous vehicle systems. For example, data imported by processor 102 from automotive sensors of one or more autonomous vehicle systems may describe various roads, weather data, and traffic conditions, encountered by those autonomous vehicles, that system 100 can use to determine scenario parameters 110 describing scenarios that include a portion of the imported data];
an environmental parameter having at least one of the features a number and/or a width of a lane and/or curves and/or road restrictions and/or an ambient temperature [0025… parameters 110 may describe a wide variety of scenarios, and may include one or more of: a distance between the autonomous vehicle system and an object entering its path (e.g., a pedestrian entering the vehicle's path at a distance of 500 meters, 400 meters, 250 meters, 100 meters, or 50 meters, among other possibilities), a type of object present in the scenario (e.g., a cyclist, another vehicle, a pedestrian, an animal, debris, etc.), roads and transportation infrastructure generally (e.g., a winding mountain road, a straight flat road, a four way stoplight intersection, a stop sign intersection, a roundabout, a road under construction, bridges, tunnels, and the like), weather and other environmental data (e.g., precipitation, ambient temperature, humidity, cloud cover, time of day, ambient luminosity or strength of sunlight, wind speed, etc.), traffic conditions (e.g., heavy traffic, light traffic, substantially no other vehicles, large number of pedestrians such as in a crowded parking lot, emergency vehicles driving atypically to arrive at an emergency, among other types of traffic conditions), and events to which the autonomous vehicle system must respond (e.g., a collision between two or more vehicles in the autonomous vehicle system's path, another vehicle suddenly stopping in front of the autonomous vehicle system, another vehicle failing to obey a stop sign or other traffic law, etc.];
driving situation parameter describing a number and properties of moving objects, having at least one of the features a number of road users and/or a number of lane changes in a traffic situation and/or a speed of the road users and/or type of transport or vehicle [0052] At 310, system 100 determines vehicle performance metrics 112 of the scenario simulated at step 308. As explained in greater detail above with reference to FIG. 1, performance metrics 112 determined at step 310 may indicate the quality of the autonomous vehicle system or of a driving maneuver attempted by the autonomous vehicle system and/or a driver of the autonomous vehicle system (e.g., an automatic braking maneuver, autonomous lane change, driver assisted cruise control, among other possibilities). Moreover, and also described above with reference to FIG. 1, some examples of performance metrics 112 may include one or more of: a length of a delay before the autonomous vehicle system senses an object within range of a specified sensor (e.g., delay of 300 milliseconds for the vehicle to detect an object via LIDAR, delay of 800 milliseconds to detect an object via radar, etc.), a braking distance…]. The feature of providing vehicle, driving and environmental parameter…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 5
Heit et al teaches
a KPI value is determined by a KPI, which value is used to evaluate the current simulation and/or at least one simulation step, and a threshold value is defined for a KPI [0019…. vehicle performance can be evaluated, or quality of the autonomous vehicle system can be tested, by determining a performance metric for each scenario (e.g., a quantitative indication of the performance of one or more aspects of the autonomous vehicle, such as the performance of vehicle sensors, the performance of vehicle brakes, etc. in the various scenarios). Vehicle parameters can describe an autonomous vehicle system's configuration, including locations of sensors, vehicle dimensions, automated driving systems included in a vehicle, etc.]. The feature of providing determining performance…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 6
Heit et al teaches
the defined threshold value of the KPI for evaluating the simulation and/or at least one simulation step indicates a degree of fulfillment of requirements for virtual homologation/release of the function [0066] Some examples may determine step size of, or the amount of change in, vehicle parameters based on a slope of the performance metrics 112 determined during process 400, such as a slope between two points of performance metrics 112 graphed as a function of vehicle parameters 110 in FIG. 4B. As an example, system 100 may determine step size in vehicle parameters 114 between two scenarios during process 400 based on whether the amount of change in the performance metrics 112 of previous scenarios during process 400 exceeded a specified threshold amount. For example, the threshold amount of change in the performance metrics 112 of scenarios during process 400 may be an average amount of change in the performance metrics 112 of the scenarios simulated during process 400 up to that point, or as determined from several previous implementations of process 400. As a specific example, performance metrics 112 of scenarios during process 400 could include delays of 500 milliseconds, 505 milliseconds, 506 milliseconds, and 510 milliseconds for various vehicle parameters of previous scenarios simulated during process 400]. The feature of providing threshold value…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 7
Vardharajan teaches
a degree of fulfillment of requirements for virtual homologation/release of the function is indicated by a risk balance, which is positive if the driving function generates a greater safety, driving comfort, and/or energy efficiency than a human driver and negative if a human driver achieves a greater safety, driving comfort, and/or energy efficiency without the intervention of the driving function [column 5, line 22, however, this transition to autonomous vehicular control may be more challenging for personal vehicles, such as self-driving passenger cars and trucks, self-piloting drones, and so forth, where a large majority of future passengers of autonomous versions may be people, who are used to driving or piloting similar vehicles in similar traffic contexts. Giving over complete control of their vehicles to fully-automated systems based around computers, sonars, cameras, sensors, satellite signals, and communication networks may be a big step, especially for people, who have driven for a lifetime. These passengers (i.e., former drivers) may know, first hand, the complexity, potential hazards, and “unwritten” rules of driving that they have personally relied upon for achieving safety, comfort, efficiency, and “driving the right way.” They may know, intuitively, what “correct driving” feels like, and, for many, this may “correct driving” may feel like the way that they drive. So, conversion to autonomous vehicles may present a challenge for gaining trust and acceptance of passengers, who are former, long-time drivers. However, a pathway for gaining this trust and acceptance may be found in developing ways for autonomous vehicles to mimic the feel of “correct driving” for these new passengers by imitating their driving style]. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate requirements to generate safety and comfort. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into incorporating different functionality in the vehicle for a driver to provide driving comfort and other features available to make vehicle with minimize driving risk.
Regarding claim 8
Heit et al teaches
wherein a digital behavioral twin of the real vehicle and/or driving function is generated with a simulation environment corresponding to the driving situations and/or traffic situations based on the extracted parameters in order to create a virtual and/or partial virtual simulation, so that a realistic testing and optimization of the function takes place in a time-efficient manner [0026] in some examples, one or more of scenario parameters 110 may be imported, or may be extracted, from a vehicle database and/or a database of analysis of vehicle accidents or other vehicle scenarios. For example, processor 102 may determine one or more scenario parameters 110 based on data imported into storage 104 from a database of the German In-Depth Accident Study or GIDAS. Further, some examples may import, receive and/or extract one or more of scenario parameters 110 from data reported from real-world vehicles or real-world autonomous vehicle systems. For example, processor 102 may import data from automotive sensors of one or more real-world autonomous vehicle systems. For example, data imported by processor 102 from automotive sensors of one or more autonomous vehicle systems may describe various roads, weather data, and traffic conditions, encountered by those autonomous vehicles, that system 100 can use to determine scenario parameters 110 describing scenarios that include a portion of the imported data] and [0040] FIG. 2 illustrates an example process 200 for simulation of an autonomous vehicle system according to examples of the disclosure. Some examples of process 200 may be performed by system 100. Alternatively or in addition, some examples of process 200 may be performed by the autonomous vehicle system 500, a server and/or a cloud computing system. As a general example, system 100 may perform process 200 by simulating several scenarios of the autonomous vehicle system and incrementally varying scenario parameters 110 between successive scenarios, determining performance metrics 112 of the various scenarios, determining minimum performance scenarios 116 as a subset of the scenarios, and improving vehicle parameters 114 by comparing performance metrics 112 determined from several scenarios with identical scenario parameters 110 and incrementally varying vehicle parameters 114 to optimize vehicle parameters and performance, as will be described in more detail below]. The feature of providing traffic situation…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 9
Heit et al teaches
a digital behavioral twin is automatically created and parameterized according to the test task, therefore, the driving function to be tested formed of at least one software and/or electronic function and the necessary release-relevant tests, which are derived from approval criteria for the driving function to be tested formed of at least one software and/or electronic function [0017] the various examples of the present invention relate to simulation, validation, and/or testing of an automated vehicle. Specifically, in some examples, an autonomous vehicle can be simulated in a number of different environments (e.g., “scenarios”), environments in which the autonomous vehicle performs most-poorly can be identified (e.g., “minimum performance scenarios”), parameters of the autonomous vehicle (e.g., tire width, sensor locations, etc.) can be varied for those identified minimum performance scenarios to improve the performance of the vehicle in those minimum performance scenarios, and the vehicle having the updated vehicle parameters can be re-simulated to ensure new minimum performance scenarios have not resulted from the changes to the vehicle parameters. In this way, vehicle simulation, validation, testing and/or improvement can be automated]. The feature of providing parameterized…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 10
Heit et al teaches
wherein at least one setting of the function and/or at least one behavior rule of the function are adjusted iteratively during the optimization [see fig 3 A, [0054] at 314, system 100 changes scenario parameters 110 to use in simulating the next scenario of the autonomous vehicle system at step 308, and begins an additional iteration of process 300. In certain examples, the amount of change in scenario parameters 110 between consecutive scenarios may be a constant or fixed amount of change for a portion of changes in scenario parameters 110 between the scenarios of process 300. For example, in simulating several scenarios in which the autonomous vehicle system travels down an incline, the grade of the incline may be increased by 1 degree after some portion of the scenarios (e.g., change a 10 degree incline of one scenario to an 11 degree incline in the following scenario then to a 12 degree incline in the third scenario, and so on). Alternatively or in addition, some examples may include dynamically determining one or more changes in scenario parameters 110 between consecutive scenarios of the autonomous vehicle system…]. The feature of providing traffic situation…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 12
Heit et al teaches
wherein the test unit comprises a control unit for which at least one function of a vehicle is tested by virtual and/or real tests [0039] simulator 126 and simulation controller 128 may operate to perform any control logic of systems 100, 500 or processes 200, 300 and 400 as described herein. For example, the simulation controller 128 may determine whether to perform additional iterations of process 200 at step 214 of that process, as described in greater detail below with reference to FIG. 2]. The feature of providing control unit…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 13
Heit et al teaches
when the computer program is executed on a computer [see summary of the invention and figs 1 and 5].
Relevant Prior Art
US 12014424 B2 Halder et al teaches Autonomous Vehicle Premium Computation Using Predictive Models
US 9715711 B1 Konrardy et al teaches Autonomous Vehicle Insurance Pricing And Offering Based Upon Accident Risk
US 11960292 B2 Nayhouse et al teaches Method And System For Developing Autonomous Vehicle Training Simulations
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anil Khatri whose telephone number is (571)272-3725. The examiner can normally be reached M-F 8:30-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Zhen can be reached at 571-272-3708. 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.
/ANIL KHATRI/Primary Examiner, Art Unit 2191