DETAILED ACTION
Response to Amendment
This office action regarding application number 18/490,947, filed October 20, 2023, in response to the applicants arguments and amendments filed March 9, 2026. Claim 1, 9, and 18 have been amended. Claims 1-2, 5-10 and 13-18 are currently pending and are addressed below.
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 .
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 March 9, 2026 has been entered.
Response to Arguments
The applicants arguments and amendments to the application have overcome some of the objections and rejections previously set forth in the Final action mailed December 10, 2025. Applicants amendments to claims 1, 9, and 10 have been deemed sufficient to overcome the rejections under 35 USC 101 through the addition of “causing the ADS-equipped vehicle to collect operational data specific to the operational parameter(s) in need of further observance when the ADS-equipped vehicle is located at the identified at least first geographical location as defined in the mapping”, therefore the rejections are withdrawn. Applicants amendments to claims 1, 9, and 18 have been deemed sufficient to overcome the previous rejection under 35 USC 103 through the addition of “deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements … the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed”, therefore the rejections are withdrawn. However as this changes the scope of the claims, new art rejections have been made based on the changes in scope.
Applicant’s arguments with respect to claim(s) 1, 9, and 18, in regards to the previous 102 rejections and the newly amended subject matter have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1-2, 5-10, and 13-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moustafa (US-20220126864) in view of Gyllenhammar (EP 3895950).
Regarding claim 1, Moustafa teaches a computer-implemented method performed by an automated driving system (ADS) development system for supporting proving fulfilment of safety requirements imposed on ADSs, the method comprising (Paragraph [0329], "The autonomous driving stack implemented through the in-vehicle computing system of an example autonomous vehicle may be enhanced to learn and detect irregular behavior exhibited by HVs, and respond safely to them. In some aspects, for example, an autonomous vehicle system can observe, and track the frequency of, irregular behaviors (e.g., those shown in the Table below) and learn to predict that an individual HV is likely to exhibit irregular behavior in the near future, or that a certain type of irregular behavior is more likely to occur in a given region of the country," here the system is learning/developing an automated driving system to improve the safety and behavior of the system by observing and analyzing exterior data)
deriving, based on the safety requirements and predeterminable models for a set of operational parameters of an ADS, a corresponding set of parameter specific ADS safe driving policies (Paragraph [0266], “In some embodiments, the social norm understanding model 2000 may be responsible for generating social norms as observation-based constraints for the ego-vehicle behavioral policy,” here the system is generating social norms/parameter specific policies) (Paragraph [0262], “In the example shown, the social norm modeling system first loads an environment model and a behavioral model for the autonomous vehicle at 2002. The environment model may be an environment model passed to the social norm modeling system from a perception system of an autonomous vehicle control pipeline (e.g., as shown in FIG. 19). The behavioral policy may be received from a planning phase of an autonomous vehicle control pipeline (e.g., as shown in FIG. 19),” this social norm system uses inputs from the predeterminable models and behavioral policy/safety requirements)
each safe driving policy exhibiting a respective uncertainty inflicted by an uncertainty of the corresponding operational parameter (Paragraph [0279], “In this manner, vehicles equipped with these additional behavioral models may plan a risk-optimized decision based on current observations and model-based predictions that present a lower uncertainty,” here the policies and models of the system have an uncertainty associated with them that the system works towards reducing)
identifying at least a first parameter specific ADS safe driving policy inflicted with an uncertainty fulfilling predeterminable criteria the criteria filtering out uncertainties indicating, respectively, that the corresponding operational parameter needs to be further observed in order to modify the ADSs currently allowed safety requirements fulfilled ADS safe driving policy (Paragraph [0249], “As noted above, in some implementations, an autonomous vehicle may detect instances when it should invoke a remote valet service for assistance. … The vehicle may further provide a report (after or during the service) describing the performance of the remote valet system (e.g., describing maneuvers or paths taken by the remote valet, describing passenger satisfaction with the service, etc.). Such report data (e.g., 1630) may be later used to train machine learning models and otherwise enhance the services provided by the backend or cloud-based system (e.g., 150). Insights and improved models may be derived by the system 150 and then shared with the vehicle's autonomous driving system (as well as its remote valet support logic 1605). In some cases, the autonomous vehicle may record information describing the remote valet's maneuvers and reactions and use this to further train and improve models used in its own autonomous driving machine learning models. Similarly, report data (e.g., through 1620) may be provided from the remote valet system 1505 to cloud-based services or to the vehicle for use in enhancing the vehicle's (and other vehicles') autonomous driving logic and handover requests, among other example uses, such as described herein,” here the system has identified a safe driving policy/remote valet service in which there was uncertainty, the system will then collect data and use the data to improve/modify models) (Paragraph [0438], “Creating quality machine learning models includes using robust data sets during training for model creation. In general, a model is only as good as the data set it uses for training. In many applications, such as training on images for object or person identification, data set collection is fairly simple. However, in other cases, data set collection for less common contexts or combinations thereof can be extremely difficult. This presents a difficult challenge for model development as the model may be tasked with identifying or classifying a context based on inadequate data.”)
identifying at least a first geographical location exhibiting conditions allowing the operational parameter in need of further observance, to be observed (Paragraph [0348], “Further, in some embodiments, driving patterns that are more likely to occur in a given context may be learned. For example, based on the tracked sequences, it may be learned whether a certain irregular driving pattern is more common in a given city when it snows, or whether certain driving actions are more likely to occur with angry drivers. This information may be used to model the conditional probability distributions of driving patterns for a given context. These context-based models allow the autonomous vehicle to anticipate the likely sequence of actions that an unsafe vehicle may take in a given scenario. For example, a contextual graph that tracks how often a driving pattern occurs in a given context is shown in FIG. 35. As shown, the contextual graph may track the identified sequences (“driving patterns” nodes in FIG. 35) along with context information (“context” nodes in FIG. 35) and the associated frequency of observation of the sequences and context (the weights of the edges in FIG. 35) to identify whether there are particular behavior patterns that occur more often in certain contexts than others (e.g., patterns that occur overwhelmingly in certain geographical contexts, time contexts, etc.). The identified patterns can also be used to train reinforcement learning models which identify the actions that the autonomous vehicle should take to avoid the unsafe behavior. For example, the learned contextual behavior patterns may be used to modify a behavioral model of an autonomous vehicle, such as, for example, dynamically when the autonomous vehicle enters or observes the particular context associated with the contextual behavior pattern,” here the system can identify certain contexts including geographical ones in which exhibit conditions that can be observed to train vehicle models)
and generating a mapping associating the identified at least first geographical location with the operational parameter in need of further observance (Paragraph [0315], “All of the location specific and related metadata (such as weather) may be used to score the data sent by the autonomous vehicle in order to determine whether to store the data in a crowdsourced data store. In some cases, the data scoring algorithm may achieve saturation for the geography with regards to data collection by using a cascade of location context-based heatmaps or density maps for scoring the data, as described further below,” here the system can used context tags in order to determine a saturation for a geography using mapping the data into location based maps, such as heat maps or density maps)
implementing the mapping as digital map data accessible by an ADS-equipped vehicle (Paragraph [0200], "and data (e.g., map data) describing the geography and maps of routes the vehicle may take," here the system is using map data/digital map) (Paragraph [0251], "In some implementations, displays of the autonomous vehicle may present warnings or instructions to in-vehicle passengers regarding an upcoming, predicted issue and the possibility of a pull-over and/or remote valet handover. In some cases, this information may be presented in an interactive display through which a passenger may register their preference for handling the upcoming trip segment either through a handover to the passenger, handover to a remote valet service, selection of alternative route, or a pull-over event. In still other implementations, cloud-based knowledge reflecting troublesome segments of road may be communicated to road signs or in-vehicle road maps to indicate the trouble segments to drivers and other autonomous vehicles, among other example implementations," here map data can be displayed within an autonomous vehicle) (Paragraph [0617], “FIG. 88 illustrates an example of a map 8800 wherein each area of the roadways 8810 listed shows a road safety score 8820 for that portion of the road. This map can be displayed by a vehicle in a similar fashion to current GPS maps, wherein traffic and speed limit are displayed on the maps. In some examples, the mapping system (e.g., path planner module 242) can calculate the safety score based on inputs from sensors or other data in the geographic region of the road.”)
and causing the ADS-equipped vehicle to collect operational data (Paragraph [0175], “For instance, a data collection module 234 may be provided with logic to determine sources from which data is to be collected (e.g., for inputs in the training or use of various machine learning models 256 used by the vehicle).”)
specific to the operational parameters in need of further observance (Paragraph [0234], “For instance, scenes and events where the autonomous driving system's decision making is likely to be more active (e.g., an urban setting in inclement weather) may result in the recommender system directing high-fidelity data collection”)
when the ADS-equipped vehicle is located at the identified at least first geographical location as defined in the mapping (Paragraph [0313], “Accordingly, in some aspects, crowdsourced data may be scored and ranked based on geolocation information for the autonomous vehicle. In some aspects, the crowdsourced data may be scored and ranked by considering location metadata in addition to vehicular metadata. By using geolocation information to score and rank data, location specific models may be generated as opposed to vehicle specific ones.”) (Paragraph [0321], “Thus, the goal of the data scoring algorithm may be to score the data such that enough data is collected in the geographic co-ordinates of the lighter areas of the heatmap. Since the collected data is scarce in the lighter regions, it will be scored leniently. On the other hand, if data is collected from the darker region of the map, which has dense data, factors such as noise in the data will have more influence on data score,” here when the vehicle is in a location that has been identified as lacking data, the system will collect and store the collected operational data because the region is in need of further observance).
However Moustafa does not explicitly teach deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed.
Gyllenhammar teaches systems and methods for monitoring and managing an Automated Driving System, ADS, of a vehicle including
deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements (Paragraph [0028], “An Operational design domain (ODD) is to be understood as a description of the operating domains in which an automated or a semi-automated driving system (i.e. AD or ADAS) is designed to function, including, but not limited to, geographic, roadway (e.g. type, surface, geometry, edges and markings), environmental parameters, connectivity, surrounding objects, traffic parameters, and speed limitations.”) (Paragraph [0042], “Thereby, the plurality of ground vehicles are provided with an up-to-date statistical model such that the ADS of each vehicle 1 is provided with the means to "understand" what it can statistically expect in various environments and adapt accordingly. The adaptation may for example manifest in inhibition of one or more ADS features, or adjustments of operational margins (e.g. speed limits, distance to lead vehicles, overtaking manoeuvres, etc.),” here the system is using an operational design domain in order to derive a set of adaptations for the current environment including allowable operation of ADS features)
and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed (Paragraph [0042], “inhibition of one or more ADS features, or adjustments of operational margins (e.g. speed limits, distance to lead vehicles, overtaking manoeuvres, etc.),” here the system is using updated information to change the limiting/inhibiting the operation of the ADS based on the received information) (Paragraph [0041], “The step of updating 102 the statistical model may be understood as a step of applying the obtained 101 data points to the existing statistical model so to generate an updated statistical model, which accordingly then further comprises up-to-date information related to the probabilities of various scenarios and events within an operating environment of the ADS,” here the system is observing information/obtaining data of the environment and using that information in order to update the information sent to vehicles, this system of updating and limiting operating of the ADS based on updated information could reasonably be applied to the system of Moustafa which determines updates based on heatmaps of an area which indicates areas which need further observance).
Moustafa and Gyllenhammar are analogous art as they are both generally related to systems for collecting sensor data and controlling autonomous vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed of Gyllenhammar in the system for controlling an vehicle is automated based on at least a portion of the sensor data generated by the first set of sensors of Moustafa with a reasonable expectation of success in order to improve the safety of the vehicle system by ensuring that the vehicle monitors current conditions and limits or inhibits functions of the vehicle to match the current scenario (Paragraph [0012], “Accordingly, the present inventors realized that in addition to ensuring that the ADS performs safely it is also paramount that the statistical models used to make the safety assurance of the ADS (i.e. supporting the requirements of the ODD) in the first place are also updated and kept valid.”).
Regarding claim 2, the combination of Moustafa and Gyllenhammar teaches the system as discussed above in claim 1, Moustafa further teaches wherein the generating a mapping comprises generating a heat map in which the identified at least first geographical location is attributed with the operational parameters in need of further observance (Paragraph [0321], "FIG. 30 is a simplified diagram of an example heatmap FIG. 3000 for use in computing a sensor data goodness score in accordance with at least one embodiment. In the example shown, the heatmap signifies the crowdsourced data availability according to geographic co-ordinates metadata. Each location in the heatmap indicates a value associated with the data availability.").
Regarding claim 5, the combination of Moustafa and Gyllenhammar teaches the system as discussed above in claim 1, Moustafa further teaches retrieving one or more potential vehicle routes for the ADS equipped vehicle (Paragraph [0200], "which may take as inputs data collected automatically by sensors on the vehicle, data from other vehicles or nearby infrastructure (e.g., roadside sensors and cameras, etc.), and data (e.g., map data) describing the geography and maps of routes the vehicle may take")
and selecting a route out of the potential vehicle routes, comprising one or more of the at least first geographical location (Paragraph [0258], "which takes the actively updated environment information and constructs a plan of action in response (which may include, e.g., route information, behavior information, prediction information, and trajectory information) to the predicted behavior of these environment conditions. The plan is then provided to an actuation system 1906, which can make the car act on said plan (e.g., by actuating the gas, brake, and steering systems of the autonomous vehicle).").
Regarding claim 6, the combination of Moustafa and Gyllenhammar teaches the system as discussed above in claim 1, Moustafa further teaches determining with support from a positioning system, a geographical position of the ADS-equipped vehicle along the selected route (Paragraph [0384], "FIG. 41 illustrates an autonomous processing pipeline from sensors through sensor fusion and planning ECU, and through vehicle control ECUs. FIG. 41 shows a variety of sensor inputs including non-line of sight, line of sight, vehicle state, and positioning. In particular, such inputs may be provided by V2X 4154A, a radar 4154B, a camera 4154C, a LIDAR 4154D, an ultrasonic device 4154E, motion of the vehicle 4154F, speed of the vehicle 4154G, GPS, inertial, and telemetry 4154H, and/or High definition (HD) maps 41541. These inputs are fed into a central unit (e.g., central processing unit) via sensor models 4155")
and collected operational data when the vehicle position is within one or both of a predeterminable distance of and time range from respective one or more of the at least first geographical location (Paragraph [0225], "For instance, sensor data collection may be reduced by applying distributed machine learning training and transfer model techniques to reduce this cost/overhead. In such an approach the “conditions” for which additional data is “required” by any device may be specified and communicated with a machine learning engine on the device (e.g., a machine learning engine in the connected autonomous vehicle). As a result, the connected device will only collect and transport the sensor data that meets the specified conditions, which may be updated (e.g., dynamically) as the model continues to evolve and train.") (Paragraph [0418], “the metadata may include one or more classifiers describing the type of an object (e.g., vehicle, tree, pedestrian, etc.), a position (e.g., coordinates) of the object, depth of the object, context associated with the object (e.g., any of the contexts described herein, such as the time of the day, type of road, or geographical location associated with the capture of the data used to detect the object), or other suitable information.”).
Regarding claim 7, the combination of Moustafa and Gyllenhammar teaches the system as discussed above in claim 1, Moustafa further teaches updating the models with at least a portion of the collected data (Paragraph [0366], "The vehicle behavior model learns a baseline low-rank stationary model and then models the deviation of the temporal model from the stationary one. As the event set is generally static over time, the vehicle behavior model can be updated through occasional parameter re-weighting given previous and new, vetted training samples that have passed the fault and intrusion detection system and been retained.") (Paragraph [0382], "Cloud vehicle data system 3820 may train and update regression models (e.g., 3844) for multiple vehicles. In one example, cloud vehicle data system 3820 may receive feedback 3825 from regression models (e.g., 3844) in operational vehicles (e.g., 3850). Feedback 3825 can be sent to cloud vehicle data system 3820 for aggregation and re-computation to update regression models in multiple vehicles to optimize behavior").
Regarding claim 8, the combination of Moustafa and Gyllenhammar teaches the system as discussed above in claim 1, Moustafa further teaches wherein the first geographical location is a taken from an ADS compliant digital map (Paragraph [0200], "and data (e.g., map data) describing the geography and maps of routes the vehicle may take," here the system is using map data/digital map) (Paragraph [0251], "In some implementations, displays of the autonomous vehicle may present warnings or instructions to in-vehicle passengers regarding an upcoming, predicted issue and the possibility of a pull-over and/or remote valet handover. In some cases, this information may be presented in an interactive display through which a passenger may register their preference for handling the upcoming trip segment either through a handover to the passenger, handover to a remote valet service, selection of alternative route, or a pull-over event. In still other implementations, cloud-based knowledge reflecting troublesome segments of road may be communicated to road signs or in-vehicle road maps to indicate the trouble segments to drivers and other autonomous vehicles, among other example implementations," here map data can be displayed within an autonomous vehicle).
Regarding claim 9, Moustafa teaches an automated driving system (ADS) development system for supporting proving fulfilment of safety requirements imposed on ADSs, the ADS development system comprising one or more processors configured to (Paragraph [0329], "The autonomous driving stack implemented through the in-vehicle computing system of an example autonomous vehicle may be enhanced to learn and detect irregular behavior exhibited by HVs, and respond safely to them. In some aspects, for example, an autonomous vehicle system can observe, and track the frequency of, irregular behaviors (e.g., those shown in the Table below) and learn to predict that an individual HV is likely to exhibit irregular behavior in the near future, or that a certain type of irregular behavior is more likely to occur in a given region of the country," here the system is learning/developing an automated driving system to improve the safety and behavior of the system by observing and analyzing exterior data) (Paragraph [0173], “a vehicle 105 may be equipped with one or more processors 202, such as central processing units (CPUs), graphical processing units (GPUs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), tensor processors and other matrix arithmetic processors, among other examples.”)
derive, based on the safety requirements and predeterminable models for a set of operational parameters of an ADS, a corresponding set of parameter specific ADS safe driving policies (Paragraph [0266], “In some embodiments, the social norm understanding model 2000 may be responsible for generating social norms as observation-based constraints for the ego-vehicle behavioral policy,” here the system is generating social norms/parameter specific policies) (Paragraph [0262], “In the example shown, the social norm modeling system first loads an environment model and a behavioral model for the autonomous vehicle at 2002. The environment model may be an environment model passed to the social norm modeling system from a perception system of an autonomous vehicle control pipeline (e.g., as shown in FIG. 19). The behavioral policy may be received from a planning phase of an autonomous vehicle control pipeline (e.g., as shown in FIG. 19),” this social norm system uses inputs from the predeterminable models and behavioral policy/safety requirements)
each safe driving policy exhibiting a respective uncertainty inflicted by an uncertainty of the corresponding operational parameter (Paragraph [0279], “In this manner, vehicles equipped with these additional behavioral models may plan a risk-optimized decision based on current observations and model-based predictions that present a lower uncertainty,” here the policies and models of the system have an uncertainty associated with them that the system works towards reducing)
identify at least a first parameter specific ADS safe driving policy inflicted with an uncertainty fulfilling predetermined criteria, the criteria filtering out uncertainties indicating, respectively, that the corresponding operational parameter needs to be further observed in order to modify the ADSs currently allowed safety requirements fulfilled ADS safe driving policy (Paragraph [0249], “As noted above, in some implementations, an autonomous vehicle may detect instances when it should invoke a remote valet service for assistance. … The vehicle may further provide a report (after or during the service) describing the performance of the remote valet system (e.g., describing maneuvers or paths taken by the remote valet, describing passenger satisfaction with the service, etc.). Such report data (e.g., 1630) may be later used to train machine learning models and otherwise enhance the services provided by the backend or cloud-based system (e.g., 150). Insights and improved models may be derived by the system 150 and then shared with the vehicle's autonomous driving system (as well as its remote valet support logic 1605). In some cases, the autonomous vehicle may record information describing the remote valet's maneuvers and reactions and use this to further train and improve models used in its own autonomous driving machine learning models. Similarly, report data (e.g., through 1620) may be provided from the remote valet system 1505 to cloud-based services or to the vehicle for use in enhancing the vehicle's (and other vehicles') autonomous driving logic and handover requests, among other example uses, such as described herein,” here the system has identified a safe driving policy/remote valet service in which there was uncertainty, the system will then collect data and use the data to improve models) (Paragraph [0438], “Creating quality machine learning models includes using robust data sets during training for model creation. In general, a model is only as good as the data set it uses for training. In many applications, such as training on images for object or person identification, data set collection is fairly simple. However, in other cases, data set collection for less common contexts or combinations thereof can be extremely difficult. This presents a difficult challenge for model development as the model may be tasked with identifying or classifying a context based on inadequate data.”)
identify at least a first geographical location exhibiting conditions allowing the operational parameter in need of further observance, to be observed (Paragraph [0348], “Further, in some embodiments, driving patterns that are more likely to occur in a given context may be learned. For example, based on the tracked sequences, it may be learned whether a certain irregular driving pattern is more common in a given city when it snows, or whether certain driving actions are more likely to occur with angry drivers. This information may be used to model the conditional probability distributions of driving patterns for a given context. These context-based models allow the autonomous vehicle to anticipate the likely sequence of actions that an unsafe vehicle may take in a given scenario. For example, a contextual graph that tracks how often a driving pattern occurs in a given context is shown in FIG. 35. As shown, the contextual graph may track the identified sequences (“driving patterns” nodes in FIG. 35) along with context information (“context” nodes in FIG. 35) and the associated frequency of observation of the sequences and context (the weights of the edges in FIG. 35) to identify whether there are particular behavior patterns that occur more often in certain contexts than others (e.g., patterns that occur overwhelmingly in certain geographical contexts, time contexts, etc.). The identified patterns can also be used to train reinforcement learning models which identify the actions that the autonomous vehicle should take to avoid the unsafe behavior. For example, the learned contextual behavior patterns may be used to modify a behavioral model of an autonomous vehicle, such as, for example, dynamically when the autonomous vehicle enters or observes the particular context associated with the contextual behavior pattern,” here the system can identify certain contexts including geographical ones in which exhibit conditions that can be observed to train vehicle models)
generate a mapping associating the identified at least first geographical location with the operational parameters in need of further observance (Paragraph [0315], “All of the location specific and related metadata (such as weather) may be used to score the data sent by the autonomous vehicle in order to determine whether to store the data in a crowdsourced data store. In some cases, the data scoring algorithm may achieve saturation for the geography with regards to data collection by using a cascade of location context-based heatmaps or density maps for scoring the data, as described further below,” here the system can used context tags in order to determine a saturation for a geography using by mapping the data into location based maps, such as heat maps or density maps)
implement the mapping as digital map data accessible by the ADS-equipped vehicle (Paragraph [0200], "and data (e.g., map data) describing the geography and maps of routes the vehicle may take," here the system is using map data/digital map) (Paragraph [0251], "In some implementations, displays of the autonomous vehicle may present warnings or instructions to in-vehicle passengers regarding an upcoming, predicted issue and the possibility of a pull-over and/or remote valet handover. In some cases, this information may be presented in an interactive display through which a passenger may register their preference for handling the upcoming trip segment either through a handover to the passenger, handover to a remote valet service, selection of alternative route, or a pull-over event. In still other implementations, cloud-based knowledge reflecting troublesome segments of road may be communicated to road signs or in-vehicle road maps to indicate the trouble segments to drivers and other autonomous vehicles, among other example implementations," here map data can be displayed within an autonomous vehicle) (Paragraph [0617], “FIG. 88 illustrates an example of a map 8800 wherein each area of the roadways 8810 listed shows a road safety score 8820 for that portion of the road. This map can be displayed by a vehicle in a similar fashion to current GPS maps, wherein traffic and speed limit are displayed on the maps. In some examples, the mapping system (e.g., path planner module 242) can calculate the safety score based on inputs from sensors or other data in the geographic region of the road.”)
and cause the ADS-equipped vehicle to collect operational data (Paragraph [0175], “For instance, a data collection module 234 may be provided with logic to determine sources from which data is to be collected (e.g., for inputs in the training or use of various machine learning models 256 used by the vehicle).”)
specific to the operational parameters in need of further observance (Paragraph [0234], “For instance, scenes and events where the autonomous driving system's decision making is likely to be more active (e.g., an urban setting in inclement weather) may result in the recommender system directing high-fidelity data collection”)
when the ADS-equipped vehicle is located at the identified at least first geographical location as defined in the mapping (Paragraph [0313], “Accordingly, in some aspects, crowdsourced data may be scored and ranked based on geolocation information for the autonomous vehicle. In some aspects, the crowdsourced data may be scored and ranked by considering location metadata in addition to vehicular metadata. By using geolocation information to score and rank data, location specific models may be generated as opposed to vehicle specific ones.”) (Paragraph [0321], “Thus, the goal of the data scoring algorithm may be to score the data such that enough data is collected in the geographic co-ordinates of the lighter areas of the heatmap. Since the collected data is scarce in the lighter regions, it will be scored leniently. On the other hand, if data is collected from the darker region of the map, which has dense data, factors such as noise in the data will have more influence on data score,” here when the vehicle is in a location that has been identified as lacking data, the system will collect and store the collected operational data because the region is in need of further observance).
However Moustafa does not explicitly teach deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed.
Gyllenhammar teaches systems and methods for monitoring and managing an Automated Driving System, ADS, of a vehicle including
deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements (Paragraph [0028], “An Operational design domain (ODD) is to be understood as a description of the operating domains in which an automated or a semi-automated driving system (i.e. AD or ADAS) is designed to function, including, but not limited to, geographic, roadway (e.g. type, surface, geometry, edges and markings), environmental parameters, connectivity, surrounding objects, traffic parameters, and speed limitations.”) (Paragraph [0042], “Thereby, the plurality of ground vehicles are provided with an up-to-date statistical model such that the ADS of each vehicle 1 is provided with the means to "understand" what it can statistically expect in various environments and adapt accordingly. The adaptation may for example manifest in inhibition of one or more ADS features, or adjustments of operational margins (e.g. speed limits, distance to lead vehicles, overtaking manoeuvres, etc.),” here the system is using an operational design domain in order to derive a set of adaptations for the current environment including allowable operation of ADS features)
and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed (Paragraph [0042], “inhibition of one or more ADS features, or adjustments of operational margins (e.g. speed limits, distance to lead vehicles, overtaking manoeuvres, etc.),” here the system is using updated information to change the limiting/inhibiting the operation of the ADS based on the received information) (Paragraph [0041], “The step of updating 102 the statistical model may be understood as a step of applying the obtained 101 data points to the existing statistical model so to generate an updated statistical model, which accordingly then further comprises up-to-date information related to the probabilities of various scenarios and events within an operating environment of the ADS,” here the system is observing information/obtaining data of the environment and using that information in order to update the information sent to vehicles, this system of updating and limiting operating of the ADS based on updated information could reasonably be applied to the system of Moustafa which determines updates based on heatmaps of an area which indicates areas which need further observance).
Moustafa and Gyllenhammar are analogous art as they are both generally related to systems for collecting sensor data and controlling autonomous vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed of Gyllenhammar in the system for controlling an vehicle is automated based on at least a portion of the sensor data generated by the first set of sensors of Moustafa with a reasonable expectation of success in order to improve the safety of the vehicle system by ensuring that the vehicle monitors current conditions and limits or inhibits functions of the vehicle to match the current scenario (Paragraph [0012], “Accordingly, the present inventors realized that in addition to ensuring that the ADS performs safely it is also paramount that the statistical models used to make the safety assurance of the ADS (i.e. supporting the requirements of the ODD) in the first place are also updated and kept valid.”).
Regarding claim 10, claim 10 is similar in scope to claim 2 and therefore is rejected under similar rationale.
Regarding claim 13, claim 13 is similar in scope to claim 5 and therefore is rejected under similar rationale.
Regarding claim 14, claim 14 is similar in scope to claim 6 and therefore is rejected under similar rationale.
Regarding claim 15, claim 15 is similar in scope to claim 7 and therefore is rejected under similar rationale.
Regarding claim 16, claim 16 is similar in scope to claim 8 and therefore is rejected under similar rationale.
Regarding claim 17, the combination of Moustafa and Gyllenhammar teaches the system as discussed above in claim 9, Moustafa further teaches wherein the ADS development system is comprised in one or both of an offboard system and a vehicle (Paragraph [0185], "In some implementations, an autonomous vehicle system 105 may interface with and leverage information and services provided by other computing systems to enhance, enable, or otherwise support the autonomous driving functionality of the device 105").
Regarding claim 18, Moustafa teaches a non-transitory computer readable storage medium storing a computer program configured to cause a computer or a processor to perform a method for supporting proving fulfilment of safety requirements imposed on Automated Driving Systems (ADSs), the method comprising: (Paragraph [0171], “Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium.”) (Paragraph [0329], "The autonomous driving stack implemented through the in-vehicle computing system of an example autonomous vehicle may be enhanced to learn and detect irregular behavior exhibited by HVs, and respond safely to them. In some aspects, for example, an autonomous vehicle system can observe, and track the frequency of, irregular behaviors (e.g., those shown in the Table below) and learn to predict that an individual HV is likely to exhibit irregular behavior in the near future, or that a certain type of irregular behavior is more likely to occur in a given region of the country," here the system is learning/developing an automated driving system to improve the safety and behavior of the system by observing and analyzing exterior data)
deriving, based on the safety requirements and predeterminable models for a set of operational parameters of an ADS, a corresponding set of parameter specific ADS safe driving policies (Paragraph [0266], “In some embodiments, the social norm understanding model 2000 may be responsible for generating social norms as observation-based constraints for the ego-vehicle behavioral policy,” here the system is generating social norms/parameter specific policies) (Paragraph [0262], “In the example shown, the social norm modeling system first loads an environment model and a behavioral model for the autonomous vehicle at 2002. The environment model may be an environment model passed to the social norm modeling system from a perception system of an autonomous vehicle control pipeline (e.g., as shown in FIG. 19). The behavioral policy may be received from a planning phase of an autonomous vehicle control pipeline (e.g., as shown in FIG. 19),” this social norm system uses inputs from the predeterminable models and behavioral policy/safety requirements)
each safe driving policy exhibiting a respective uncertainty inflicted by an uncertainty of the corresponding operational parameter (Paragraph [0279], “In this manner, vehicles equipped with these additional behavioral models may plan a risk-optimized decision based on current observations and model-based predictions that present a lower uncertainty,” here the policies and models of the system have an uncertainty associated with them that the system works towards reducing)
identifying at least a first parameter specific ADS safe driving policy inflicted with an uncertainty fulfilling predeterminable criteria the criteria filtering out uncertainties indicating, respectively, that the corresponding operational parameter needs to be further observed in order to modify the ADSs currently allowed safety requirements fulfilled ADS safe driving policy (Paragraph [0249], “As noted above, in some implementations, an autonomous vehicle may detect instances when it should invoke a remote valet service for assistance. … The vehicle may further provide a report (after or during the service) describing the performance of the remote valet system (e.g., describing maneuvers or paths taken by the remote valet, describing passenger satisfaction with the service, etc.). Such report data (e.g., 1630) may be later used to train machine learning models and otherwise enhance the services provided by the backend or cloud-based system (e.g., 150). Insights and improved models may be derived by the system 150 and then shared with the vehicle's autonomous driving system (as well as its remote valet support logic 1605). In some cases, the autonomous vehicle may record information describing the remote valet's maneuvers and reactions and use this to further train and improve models used in its own autonomous driving machine learning models. Similarly, report data (e.g., through 1620) may be provided from the remote valet system 1505 to cloud-based services or to the vehicle for use in enhancing the vehicle's (and other vehicles') autonomous driving logic and handover requests, among other example uses, such as described herein,” here the system has identified a safe driving policy/remote valet service in which there was uncertainty, the system will then collect data and use the data to improve models) (Paragraph [0438], “Creating quality machine learning models includes using robust data sets during training for model creation. In general, a model is only as good as the data set it uses for training. In many applications, such as training on images for object or person identification, data set collection is fairly simple. However, in other cases, data set collection for less common contexts or combinations thereof can be extremely difficult. This presents a difficult challenge for model development as the model may be tasked with identifying or classifying a context based on inadequate data.”)
identifying at least a first geographical location exhibiting conditions allowing the operational parameter in need of further observance, to be observed (Paragraph [0348], “Further, in some embodiments, driving patterns that are more likely to occur in a given context may be learned. For example, based on the tracked sequences, it may be learned whether a certain irregular driving pattern is more common in a given city when it snows, or whether certain driving actions are more likely to occur with angry drivers. This information may be used to model the conditional probability distributions of driving patterns for a given context. These context-based models allow the autonomous vehicle to anticipate the likely sequence of actions that an unsafe vehicle may take in a given scenario. For example, a contextual graph that tracks how often a driving pattern occurs in a given context is shown in FIG. 35. As shown, the contextual graph may track the identified sequences (“driving patterns” nodes in FIG. 35) along with context information (“context” nodes in FIG. 35) and the associated frequency of observation of the sequences and context (the weights of the edges in FIG. 35) to identify whether there are particular behavior patterns that occur more often in certain contexts than others (e.g., patterns that occur overwhelmingly in certain geographical contexts, time contexts, etc.). The identified patterns can also be used to train reinforcement learning models which identify the actions that the autonomous vehicle should take to avoid the unsafe behavior. For example, the learned contextual behavior patterns may be used to modify a behavioral model of an autonomous vehicle, such as, for example, dynamically when the autonomous vehicle enters or observes the particular context associated with the contextual behavior pattern,” here the system can identify certain contexts including geographical ones in which exhibit conditions that can be observed to train vehicle models)
and generating a mapping associating the identified at least first geographical location with the operational parameter in need of further observance (Paragraph [0315], “All of the location specific and related metadata (such as weather) may be used to score the data sent by the autonomous vehicle in order to determine whether to store the data in a crowdsourced data store. In some cases, the data scoring algorithm may achieve saturation for the geography with regards to data collection by using a cascade of location context-based heatmaps or density maps for scoring the data, as described further below,” here the system can used context tags in order to determine a saturation for a geography using by mapping the data into location based maps, such as heat maps or density maps)
implementing the mapping as digital map data accessible by the ADS-equipped vehicle (Paragraph [0200], "and data (e.g., map data) describing the geography and maps of routes the vehicle may take," here the system is using map data/digital map) (Paragraph [0251], "In some implementations, displays of the autonomous vehicle may present warnings or instructions to in-vehicle passengers regarding an upcoming, predicted issue and the possibility of a pull-over and/or remote valet handover. In some cases, this information may be presented in an interactive display through which a passenger may register their preference for handling the upcoming trip segment either through a handover to the passenger, handover to a remote valet service, selection of alternative route, or a pull-over event. In still other implementations, cloud-based knowledge reflecting troublesome segments of road may be communicated to road signs or in-vehicle road maps to indicate the trouble segments to drivers and other autonomous vehicles, among other example implementations," here map data can be displayed within an autonomous vehicle) (Paragraph [0617], “FIG. 88 illustrates an example of a map 8800 wherein each area of the roadways 8810 listed shows a road safety score 8820 for that portion of the road. This map can be displayed by a vehicle in a similar fashion to current GPS maps, wherein traffic and speed limit are displayed on the maps. In some examples, the mapping system (e.g., path planner module 242) can calculate the safety score based on inputs from sensors or other data in the geographic region of the road.”)
and causing the ADS-equipped vehicle to collect operational data (Paragraph [0175], “For instance, a data collection module 234 may be provided with logic to determine sources from which data is to be collected (e.g., for inputs in the training or use of various machine learning models 256 used by the vehicle).”)
specific to the operational parameters in need of further observance (Paragraph [0234], “For instance, scenes and events where the autonomous driving system's decision making is likely to be more active (e.g., an urban setting in inclement weather) may result in the recommender system directing high-fidelity data collection”)
when the ADS-equipped vehicle is located at the identified at least first geographical location as defined in the mapping (Paragraph [0313], “Accordingly, in some aspects, crowdsourced data may be scored and ranked based on geolocation information for the autonomous vehicle. In some aspects, the crowdsourced data may be scored and ranked by considering location metadata in addition to vehicular metadata. By using geolocation information to score and rank data, location specific models may be generated as opposed to vehicle specific ones.”) (Paragraph [0321], “Thus, the goal of the data scoring algorithm may be to score the data such that enough data is collected in the geographic co-ordinates of the lighter areas of the heatmap. Since the collected data is scarce in the lighter regions, it will be scored leniently. On the other hand, if data is collected from the darker region of the map, which has dense data, factors such as noise in the data will have more influence on data score,” here when the vehicle is in a location that has been identified as lacking data, the system will collect and store the collected operational data because the region is in need of further observance).
However Moustafa does not explicitly teach deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed.
Gyllenhammar teaches systems and methods for monitoring and managing an Automated Driving System, ADS, of a vehicle including
deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements (Paragraph [0028], “An Operational design domain (ODD) is to be understood as a description of the operating domains in which an automated or a semi-automated driving system (i.e. AD or ADAS) is designed to function, including, but not limited to, geographic, roadway (e.g. type, surface, geometry, edges and markings), environmental parameters, connectivity, surrounding objects, traffic parameters, and speed limitations.”) (Paragraph [0042], “Thereby, the plurality of ground vehicles are provided with an up-to-date statistical model such that the ADS of each vehicle 1 is provided with the means to "understand" what it can statistically expect in various environments and adapt accordingly. The adaptation may for example manifest in inhibition of one or more ADS features, or adjustments of operational margins (e.g. speed limits, distance to lead vehicles, overtaking manoeuvres, etc.),” here the system is using an operational design domain in order to derive a set of adaptations for the current environment including allowable operation of ADS features)
and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed (Paragraph [0042], “inhibition of one or more ADS features, or adjustments of operational margins (e.g. speed limits, distance to lead vehicles, overtaking manoeuvres, etc.),” here the system is using updated information to change the limiting/inhibiting the operation of the ADS based on the received information) (Paragraph [0041], “The step of updating 102 the statistical model may be understood as a step of applying the obtained 101 data points to the existing statistical model so to generate an updated statistical model, which accordingly then further comprises up-to-date information related to the probabilities of various scenarios and events within an operating environment of the ADS,” here the system is observing information/obtaining data of the environment and using that information in order to update the information sent to vehicles, this system of updating and limiting operating of the ADS based on updated information could reasonably be applied to the system of Moustafa which determines updates based on heatmaps of an area which indicates areas which need further observance).
Moustafa and Gyllenhammar are analogous art as they are both generally related to systems for collecting sensor data and controlling autonomous vehicles.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include deriving a corresponding set of parameter specific ADS safe driving policies governing allowable operation of the ADS under the safety requirements and the corresponding operational parameter currently limits the operation of the ADS and needs to be further observed of Gyllenhammar in the system for controlling an vehicle is automated based on at least a portion of the sensor data generated by the first set of sensors of Moustafa with a reasonable expectation of success in order to improve the safety of the vehicle system by ensuring that the vehicle monitors current conditions and limits or inhibits functions of the vehicle to match the current scenario (Paragraph [0012], “Accordingly, the present inventors realized that in addition to ensuring that the ADS performs safely it is also paramount that the statistical models used to make the safety assurance of the ADS (i.e. supporting the requirements of the ODD) in the first place are also updated and kept valid.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Palanisamy (US-20200033868) teaches systems can include a set of autonomous driver agents, and a driving policy generation module that includes a set of driving policy learner modules for generating and improving policies based on the collective experiences collected by the driver agents. Gendron (US-20190332923) teaches systems and methods for a reinforcement learning system using a plurality of vehicles in a plurality of locations. Lockwood (US 20190011910) teaches a driverless vehicle autonomously traveling along the route and encountering such events may reduce its travel speed or come to a stop due to, for example, potential safety concerns related to the event or a lack of sufficient information to continue traveling along the route.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER FEES whose telephone number is (303)297-4343. The examiner can normally be reached Monday-Thursday 7:30 - 5:30 MT.
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, Aniss Chad can be reached at (571) 270-3832. 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.
/CHRISTOPHER GEORGE FEES/Primary Examiner, Art Unit 3662
Prosecution Insights