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 .
DETAILED ACTION
Claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 102(a)(1)
The following is a quotation of 35 U.S.C. 102(a)(1) which forms the basis for all anticipation rejections:
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-7 and 11-20 are rejected U.S.C. § 102(a)(1) as being unpatentable over Konrardy et al., U.S. 10,324,463.
On claim 1, Konrardy cites :
A system, comprising:
a memory configured to store computer-executable instructions;
figure 1A, program memory 160, RAM 164 and processor 162, col. 14, lines 57-58 algorithms programs.
and
at least one processor configured to execute the computer-executable instructions to:
acquire sensor data and vehicle data from a user equipment,
col. 8, lines 38-61, FIG. 1A illustrates a block diagram of an exemplary autonomous vehicle data system 100 on which the exemplary methods described herein may be implemented. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The autonomous vehicle data system 100 may be roughly divided into front-end components 102 and back-end components 104. The front-end components 102 may obtain information regarding a vehicle 108 (e.g., a car, truck, motorcycle, etc.) and the surrounding environment. An on-board computer 114 may utilize this information to operate the vehicle 108 according to an autonomous operation feature or to assist the vehicle operator in operating the vehicle 108. To monitor the vehicle 108, the front-end components 102 may include one or more sensors 120 installed within the vehicle 108 that may communicate with the on-board computer 114. The front-end components 102 may further process the sensor data using the on-board computer 114 or a mobile device 110 (e.g., a smart phone, a tablet computer, a special purpose computing device, smart watch, wearable electronics, etc.) to determine when the vehicle is in operation and information regarding the vehicle.
wherein the sensor data is associated with a region including a plurality of roads;
col. 9, lines 66-67 and col. 10, lines 1-13. Some of the sensors 120 (e.g., radar, LIDAR, or camera units) may actively or passively scan the vehicle environment for obstacles (e.g., other vehicles, buildings, pedestrians, etc.), roadways, lane markings, signs, or signals. Other sensors 120 (e.g., GPS, accelerometer, or tachometer units) may provide data for determining the location or movement of the vehicle 108 (e.g., via GPS coordinates, dead reckoning, wireless signal triangulation, etc.). Other sensors 120 may be directed to the interior or passenger compartment of the vehicle 108, such as cameras, microphones, pressure sensors, thermometers, or similar sensors to monitor the vehicle operator and/or passengers within the vehicle 108. Information generated or received by the sensors 120 may be communicated to the on-board computer 114 or the mobile device 110 for use in autonomous vehicle operation
determine a function class of each of the plurality of roads based on the sensor data;
col. 35, lines 32-37 Regardless of the source, the data received may be associated with geographic locations. Such associations may be indicated by geospatial coordinates (e.g., GPS position), relative location data (e.g., street addresses, intersections, etc.), or area indications (e.g., cities, counties, types of roads, etc.).
And
Col. 39, lines 47-61 At block 606, the minimum requirements for the route may be determined by the mobile device 110. The minimum requirements may relate to the acceptable range of scores for road segments along the route, such as requiring a minimum score for each road segment. Such minimum requirements may be selected by the user or may be automatically determined based upon conditions of vehicle operation. For example, the user may request a route suitable for fully autonomous operation. As another example, automatic emergency operation may require fully autonomous operation throughout the route. In some embodiments, the user may specify different minimum requirements for different types of road segments. For example, the user may require fully autonomous operation on highway road segments, but may allow semi-autonomous operation on residential street road segments
determine a type of a vehicle associated with the user equipment, based on the vehicle data;
col 36 lines 56-63. Such risk factors may include time of day, weather conditions, traffic conditions, speed, type of vehicle, types of sensors used by the vehicle, types of autonomous operation features in use, versions of autonomous operation features, interactions between autonomous operation features, autonomous operation feature settings or configurations, driver behavior, or other similar factors that may be derived from the data.
determine coverage data of the vehicle for each of the plurality of roads based on the function class of a respective road of the plurality of roads and the type of the vehicle;
col. 41, lines 41-42 In further embodiments, adjusting the parameters may include allowing for the inclusion of short distances of road segments that may be suitable for significantly less autonomous or semi-autonomous operation. For example, road segments of less than one mile that connect on both ends to road segments meeting the minimum requirements (or that connect to or contain the first or destination geospatial locations) may be included, even if such road segments are not suitable for any autonomous operation feature use (or are suitable for only the lowest levels of such feature use). This may allow the driver to travel most of the trip autonomously using an efficient route, but the route may require the driver to take control for a short distance (e.g., while passing through a construction zone).r pre-defined combination of road types indicative of a specific or typical drive for a user.
and
output a first notification associated with the coverage data of the vehicle.
Col. 40, lines 51-67 At block 612, the server 140 may determine whether at least one route exists that forms a connected path between the first geospatial location and the destination geospatial location along the identified road segments that meet the minimum requirements. This may include iteratively checking road segments until either a connecting path is found or all road segments have been checked. In some embodiments, this may include a preliminary step of determining whether both the first and destination geospatial positions lie along road segments that meet the minimum requirements, which may be used to quickly determine that no suitable route exists if one or both geospatial locations are not upon a road segment meeting the minimum requirements. If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616). If no paths meeting the minimum requirements are found, the method 600 may instead attempt to adjust the parameters (block 614) to find a suitable route. Once the parameters have been adjusted (block 614), the method 600 may continue by accessing map data using the new parameters (block 608). Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
And
Col 21, lines 48-54. The server 140 may then process the data to determine a route, risk level, recommendation, or other action. The server 140 may then communicate the determined information to the mobile device 110 and/or on-board computer 114, which may cause the vehicle 108 to operate in accordance with the determined information (e.g., travel along a determined optimal route).
On claim 2, Konrardy cites:
The system according to claim 1, wherein the at least one processor is further configured to:
compare the coverage data of the vehicle for each of the plurality of roads with a respective threshold value of a plurality of threshold values, the plurality of threshold values being associated with the plurality of roads such that each road of the plurality of roads has a corresponding threshold value;
Col. 40, lines 51-67 At block 612, the server 140 may determine whether at least one route exists that forms a connected path between the first geospatial location and the destination geospatial location along the identified road segments that meet the minimum requirements. This may include iteratively checking road segments until either a connecting path is found or all road segments have been checked. In some embodiments, this may include a preliminary step of determining whether both the first and destination geospatial positions lie along road segments that meet the minimum requirements, which may be used to quickly determine that no suitable route exists if one or both geospatial locations are not upon a road segment meeting the minimum requirements. If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616). If no paths meeting the minimum requirements are found, the method 600 may instead attempt to adjust the parameters (block 614) to find a suitable route. Once the parameters have been adjusted (block 614), the method 600 may continue by accessing map data using the new parameters (block 608). Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
output a second notification when the coverage data of the vehicle for at least one road of the plurality of roads is one of equal to or greater than at least one threshold value, wherein the plurality of threshold values includes the at least one threshold value
see above,
If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616).
and
output a third notification when on the coverage data of the vehicle for the at least one road is less than the at least one threshold value.
As above, Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
On claim 3, Konrardy cites:
The system of claim 2, wherein the at least one processor is further configured to control a display device to display a warning based on the third notification.
col. 17, lines 19-28 FIG. 2 illustrates a block diagram of an exemplary mobile device 110 or an exemplary on-board computer 114 consistent with the system 100 and the system 180. The mobile device 110 or on-board computer 114 may include a display 202, a GPS unit 206, a communication unit 220, an accelerometer 224, one or more additional sensors (not shown), a user-input device (not shown), and/or, like the server 140, a controller 204. In some embodiments, the mobile device 110 and on-board computer 114 may be integrated into a single device, or either may perform the functions of both.
On claim 4, Konrardy cites:
The system of claim 1, wherein the coverage data of the vehicle for each of the plurality of roads indicates mileage of the vehicle on the respective road.
Col. 40, lines 10-19 Such additional information may include details regarding available types, configurations, settings, and operating status of autonomous operation features (which may include information regarding sensors 120 or software versions). Part or all of the additional information may be stored in a vehicle profile within the database 146 to reduce data transmission over the network. The relevant map data may be limited to road segments in a predefined or algorithmically determined distance from the geospatial locations.
On claim 5, Konrardy cites except as underlined:
The system of claim 4, wherein the at least one processor is further configured to calculate total mileage of the vehicle in the region based on analysis of the mileage on each of the plurality of roads.
Konrardy cites:
Col 30, lines 24-49 Alternatively, suitability data may be received for a plurality of road segments in proximity to the current location of the vehicle 108 (e.g., all road segments within a predetermined distance of the current location). The suitability data may be requested by the on-board computer 114 or may be received from a database without a request. In some embodiments, the on-board computer 114 may store the suitability data in the program memory 208 for use throughout a vehicle trip or multiple vehicle trips. For example, the on-board computer 114 may store suitability data for a plurality of road segments in an area of frequent operation of the vehicle 108 for repeated use over a period of time, which stored suitability data may be updated periodically by communication with a server 140. The on-board computer 114 may then access the map data as needed.
On claim 6, Konrardy cites:
The system of claim 1, wherein the at least one processor is further configured to:
generate statistical data metrics for the vehicle on each of the plurality of roads based on the function class of the respective road and the type of the vehicle; and
control a display device to display the generated statistical data metrics for the vehicle.
Col 44, lines 17-48. At block 702, the on-board computer 114 may receive suitability data relating to autonomous operation features usage for a plurality of road segments. The suitability data may include risk levels or suitability scores indicating the suitability or permissibility of autonomous operation feature usage for the road segments. The suitability data may be included in map data received from a map database or map server via the network 130, either directly or through a mobile device 110. Such map data may further include location data associated with each of the plurality of road segments (such as GPS data), which may be used to identify current road segments where the vehicle 108 is currently located during operation. The map data may be received with or without graphical map tile data, in various embodiments. The suitability data may be received for the plurality of road segments based upon a route of the vehicle 108, such as a route determined by the methods described elsewhere herein. Alternatively, suitability data may be received for a plurality of road segments in proximity to the current location of the vehicle 108 (e.g., all road segments within a predetermined distance of the current location). The suitability data may be requested by the on-board computer 114 or may be received from a database without a request. In some embodiments, the on-board computer 114 may store the suitability data in the program memory 208 for use throughout a vehicle trip or multiple vehicle trips. For example, the on-board computer 114 may store suitability data for a plurality of road segments in an area of frequent operation of the vehicle 108 for repeated use over a period of time, which stored suitability data may be updated periodically by communication with a server 140.
On claim 7, Konrardy cites:
The system of claim 6, wherein the at least one processor is further configured to execute histogram analysis for the vehicle on each of the plurality of roads based on the generated statistical data metrics.
Col 44, lines 17-48. At block 702, the on-board computer 114 may receive suitability data relating to autonomous operation features usage for a plurality of road segments. The suitability data may include risk levels or suitability scores indicating the suitability or permissibility of autonomous operation feature usage for the road segments. The suitability data may be included in map data received from a map database or map server via the network 130, either directly or through a mobile device 110. Such map data may further include location data associated with each of the plurality of road segments (such as GPS data), which may be used to identify current road segments where the vehicle 108 is currently located during operation. The map data may be received with or without graphical map tile data, in various embodiments. The suitability data may be received for the plurality of road segments based upon a route of the vehicle 108, such as a route determined by the methods described elsewhere herein. Alternatively, suitability data may be received for a plurality of road segments in proximity to the current location of the vehicle 108 (e.g., all road segments within a predetermined distance of the current location). The suitability data may be requested by the on-board computer 114 or may be received from a database without a request. In some embodiments, the on-board computer 114 may store the suitability data in the program memory 208 for use throughout a vehicle trip or multiple vehicle trips. For example, the on-board computer 114 may store suitability data for a plurality of road segments in an area of frequent operation of the vehicle 108 for repeated use over a period of time, which stored suitability data may be updated periodically by communication with a server 140.
(In short, the cited “suitability data” is the same as the claimed “generated statistical data metric” of the disclosed accepted road segments).
On claim 11, Konrardy cites:
The system of claim 1, wherein the sensor data indicates at least one of a driving condition of the vehicle in the region or a surrounding environmental condition of the vehicle.
Column 27, line 44-51: The Data Application may record such information even when no control actions are determined to be necessary or where such control actions are not implemented. Such information may include information regarding the vehicle operating environment determined from the processed sensor data (e.g., construction, other vehicles, pedestrians, anomalous environmental conditions, etc.).
On claim 12, Konrardy cites:
The system of claim 1, wherein the at least one processor
figure 1A, program memory 160, RAM 164 and processor 162, col. 14, lines 57-58 algorithms programs.
is further configured to:
receive dynamic data from a server based on the reception of the sensor data;
col. 8, lines 38-61, FIG. 1A illustrates a block diagram of an exemplary autonomous vehicle data system 100 on which the exemplary methods described herein may be implemented. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The autonomous vehicle data system 100 may be roughly divided into front-end components 102 and back-end components 104. The front-end components 102 may obtain information regarding a vehicle 108 (e.g., a car, truck, motorcycle, etc.) and the surrounding environment. An on-board computer 114 may utilize this information to operate the vehicle 108 according to an autonomous operation feature or to assist the vehicle operator in operating the vehicle 108. To monitor the vehicle 108, the front-end components 102 may include one or more sensors 120 installed within the vehicle 108 that may communicate with the on-board computer 114. The front-end components 102 may further process the sensor data using the on-board computer 114 or a mobile device 110 (e.g., a smart phone, a tablet computer, a special purpose computing device, smart watch, wearable electronics, etc.) to determine when the vehicle is in operation and information regarding the vehicle.
col. 9, lines 66-67 and col. 10, lines 1-13. Some of the sensors 120 (e.g., radar, LIDAR, or camera units) may actively or passively scan the vehicle environment for obstacles (e.g., other vehicles, buildings, pedestrians, etc.), roadways, lane markings, signs, or signals. Other sensors 120 (e.g., GPS, accelerometer, or tachometer units) may provide data for determining the location or movement of the vehicle 108 (e.g., via GPS coordinates, dead reckoning, wireless signal triangulation, etc.). Other sensors 120 may be directed to the interior or passenger compartment of the vehicle 108, such as cameras, microphones, pressure sensors, thermometers, or similar sensors to monitor the vehicle operator and/or passengers within the vehicle 108. Information generated or received by the sensors 120 may be communicated to the on-board computer 114 or the mobile device 110 for use in autonomous vehicle operation
execute a map matching process for the vehicle based on the sensor data and the dynamic data;
Col. 39, lines 47-61 At block 606, the minimum requirements for the route may be determined by the mobile device 110. The minimum requirements may relate to the acceptable range of scores for road segments along the route, such as requiring a minimum score for each road segment. Such minimum requirements may be selected by the user or may be automatically determined based upon conditions of vehicle operation. For example, the user may request a route suitable for fully autonomous operation. As another example, automatic emergency operation may require fully autonomous operation throughout the route. In some embodiments, the user may specify different minimum requirements for different types of road segments. For example, the user may require fully autonomous operation on highway road segments, but may allow semi-autonomous operation on residential street road segments
and
determine the coverage of the vehicle for each of the plurality of roads based on the execution of the map matching process.
col. 41, lines 41-42 In further embodiments, adjusting the parameters may include allowing for the inclusion of short distances of road segments that may be suitable for significantly less autonomous or semi-autonomous operation. For example, road segments of less than one mile that connect on both ends to road segments meeting the minimum requirements (or that connect to or contain the first or destination geospatial locations) may be included, even if such road segments are not suitable for any autonomous operation feature use (or are suitable for only the lowest levels of such feature use). This may allow the driver to travel most of the trip autonomously using an efficient route, but the route may require the driver to take control for a short distance (e.g., while passing through a construction zone).r pre-defined combination of road types indicative of a specific or typical drive for a user.
On claim 13, Konrardy cites:
A method, comprising:
acquiring sensor data and vehicle data from a user equipment, wherein the sensor data is associated with a region including a plurality of roads;
col. 8, lines 38-61, FIG. 1A illustrates a block diagram of an exemplary autonomous vehicle data system 100 on which the exemplary methods described herein may be implemented. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The autonomous vehicle data system 100 may be roughly divided into front-end components 102 and back-end components 104. The front-end components 102 may obtain information regarding a vehicle 108 (e.g., a car, truck, motorcycle, etc.) and the surrounding environment. An on-board computer 114 may utilize this information to operate the vehicle 108 according to an autonomous operation feature or to assist the vehicle operator in operating the vehicle 108. To monitor the vehicle 108, the front-end components 102 may include one or more sensors 120 installed within the vehicle 108 that may communicate with the on-board computer 114. The front-end components 102 may further process the sensor data using the on-board computer 114 or a mobile device 110 (e.g., a smart phone, a tablet computer, a special purpose computing device, smart watch, wearable electronics, etc.) to determine when the vehicle is in operation and information regarding the vehicle.
determining a function class of each of the plurality of roads based on the sensor data;
col. 8, lines 38-61, FIG. 1A illustrates a block diagram of an exemplary autonomous vehicle data system 100 on which the exemplary methods described herein may be implemented. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The autonomous vehicle data system 100 may be roughly divided into front-end components 102 and back-end components 104. The front-end components 102 may obtain information regarding a vehicle 108 (e.g., a car, truck, motorcycle, etc.) and the surrounding environment. An on-board computer 114 may utilize this information to operate the vehicle 108 according to an autonomous operation feature or to assist the vehicle operator in operating the vehicle 108. To monitor the vehicle 108, the front-end components 102 may include one or more sensors 120 installed within the vehicle 108 that may communicate with the on-board computer 114. The front-end components 102 may further process the sensor data using the on-board computer 114 or a mobile device 110 (e.g., a smart phone, a tablet computer, a special purpose computing device, smart watch, wearable electronics, etc.) to determine when the vehicle is in operation and information regarding the vehicle.
col. 9, lines 66-67 and col. 10, lines 1-13. Some of the sensors 120 (e.g., radar, LIDAR, or camera units) may actively or passively scan the vehicle environment for obstacles (e.g., other vehicles, buildings, pedestrians, etc.), roadways, lane markings, signs, or signals. Other sensors 120 (e.g., GPS, accelerometer, or tachometer units) may provide data for determining the location or movement of the vehicle 108 (e.g., via GPS coordinates, dead reckoning, wireless signal triangulation, etc.). Other sensors 120 may be directed to the interior or passenger compartment of the vehicle 108, such as cameras, microphones, pressure sensors, thermometers, or similar sensors to monitor the vehicle operator and/or passengers within the vehicle 108. Information generated or received by the sensors 120 may be communicated to the on-board computer 114 or the mobile device 110 for use in autonomous vehicle operation
And
Col. 30, lines 9-15, The additional location and environmental data may include information regarding the position of the vehicle 108 from the GPS unit 206 and its surrounding environment (e.g., road conditions, weather conditions, nearby traffic conditions, type of road, construction conditions, presence of pedestrians, presence of other obstacles, availability of autonomous communications from external sources, etc.).
determining a type of a vehicle based on the vehicle data;
col 36 lines 56-63. Such risk factors may include time of day, weather conditions, traffic conditions, speed, type of vehicle, types of sensors used by the vehicle, types of autonomous operation features in use, versions of autonomous operation features, interactions between autonomous operation features, autonomous operation feature settings or configurations, driver behavior, or other similar factors that may be derived from the data.
determining coverage data of the vehicle for each of the plurality of roads based on the function class of a respective road of the plurality of roads and the type of the vehicle;
col. 41, lines 41-42 In further embodiments, adjusting the parameters may include allowing for the inclusion of short distances of road segments that may be suitable for significantly less autonomous or semi-autonomous operation. For example, road segments of less than one mile that connect on both ends to road segments meeting the minimum requirements (or that connect to or contain the first or destination geospatial locations) may be included, even if such road segments are not suitable for any autonomous operation feature use (or are suitable for only the lowest levels of such feature use). This may allow the driver to travel most of the trip autonomously using an efficient route, but the route may require the driver to take control for a short distance (e.g., while passing through a construction zone).r pre-defined combination of road types indicative of a specific or typical drive for a user.
and
outputting a first notification associated with the coverage data of the vehicle.
Col. 40, lines 51-67 At block 612, the server 140 may determine whether at least one route exists that forms a connected path between the first geospatial location and the destination geospatial location along the identified road segments that meet the minimum requirements. This may include iteratively checking road segments until either a connecting path is found or all road segments have been checked. In some embodiments, this may include a preliminary step of determining whether both the first and destination geospatial positions lie along road segments that meet the minimum requirements, which may be used to quickly determine that no suitable route exists if one or both geospatial locations are not upon a road segment meeting the minimum requirements. If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616). If no paths meeting the minimum requirements are found, the method 600 may instead attempt to adjust the parameters (block 614) to find a suitable route. Once the parameters have been adjusted (block 614), the method 600 may continue by accessing map data using the new parameters (block 608). Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
And
Col 21, lines 48-54. The server 140 may then process the data to determine a route, risk level, recommendation, or other action. The server 140 may then communicate the determined information to the mobile device 110 and/or on-board computer 114, which may cause the vehicle 108 to operate in accordance with the determined information (e.g., travel along a determined optimal route).
On claim 14, Konrardy cites:
The method of claim 13, further comprising:
comparing the coverage data of the vehicle for each of the plurality of roads with a respective threshold value of a plurality of threshold values, the plurality of threshold values being associated with the plurality of roads such that each road of the plurality of roads has a corresponding threshold value;
Col. 40, lines 51-67 At block 612, the server 140 may determine whether at least one route exists that forms a connected path between the first geospatial location and the destination geospatial location along the identified road segments that meet the minimum requirements. This may include iteratively checking road segments until either a connecting path is found or all road segments have been checked. In some embodiments, this may include a preliminary step of determining whether both the first and destination geospatial positions lie along road segments that meet the minimum requirements, which may be used to quickly determine that no suitable route exists if one or both geospatial locations are not upon a road segment meeting the minimum requirements. If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616). If no paths meeting the minimum requirements are found, the method 600 may instead attempt to adjust the parameters (block 614) to find a suitable route. Once the parameters have been adjusted (block 614), the method 600 may continue by accessing map data using the new parameters (block 608). Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
outputting a second notification when the coverage data of the vehicle for at least one road of the plurality of roads is one of equal to or greater than at least one threshold value for the at least one road, wherein the plurality of threshold values includes the at least one threshold value;
see above,
If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616).
and outputting a third notification when the coverage data of the vehicle for the at least one road is less than the at least one threshold value.
As above, Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
On claim 15, Konrardy cites:
The method of claim 14, further comprising controlling a display device to display a warning based on the third notification.
col. 17, lines 19-28 FIG. 2 illustrates a block diagram of an exemplary mobile device 110 or an exemplary on-board computer 114 consistent with the system 100 and the system 180. The mobile device 110 or on-board computer 114 may include a display 202, a GPS unit 206, a communication unit 220, an accelerometer 224, one or more additional sensors (not shown), a user-input device (not shown), and/or, like the server 140, a controller 204. In some embodiments, the mobile device 110 and on-board computer 114 may be integrated into a single device, or either may perform the functions of both.
On claim 16, Konrardy cites:
The method of claim 13, wherein the coverage data of the vehicle for each of the plurality of roads indicates mileage of the vehicle on the respective road.
Col. 40, lines 10-19 Such additional information may include details regarding available types, configurations, settings, and operating status of autonomous operation features (which may include information regarding sensors 120 or software versions). Part or all of the additional information may be stored in a vehicle profile within the database 146 to reduce data transmission over the network. The relevant map data may be limited to road segments in a predefined or algorithmically determined distance from the geospatial locations.
On claim 17, Konrardy cites:
The method of claim 16, further comprising: calculating total mileage of the vehicle in the region based on analysis of the mileage on each of the plurality of roads.
Konrardy cites:
Col 30, lines 24-49 Alternatively, suitability data may be received for a plurality of road segments in proximity to the current location of the vehicle 108 (e.g., all road segments within a predetermined distance of the current location). The suitability data may be requested by the on-board computer 114 or may be received from a database without a request. In some embodiments, the on-board computer 114 may store the suitability data in the program memory 208 for use throughout a vehicle trip or multiple vehicle trips. For example, the on-board computer 114 may store suitability data for a plurality of road segments in an area of frequent operation of the vehicle 108 for repeated use over a period of time, which stored suitability data may be updated periodically by communication with a server 140. The on-board computer 114 may then access the map data as needed.
On claim 18, Konrardy cites:
The method of 13, further comprising: generating statistical data metrics for the vehicle on each of the plurality of roads based on the function class of the respective road and the type of the vehicle; and controlling a display device to display the generated statistical data metrics for the vehicle.
Col 44, lines 17-48. At block 702, the on-board computer 114 may receive suitability data relating to autonomous operation features usage for a plurality of road segments. The suitability data may include risk levels or suitability scores indicating the suitability or permissibility of autonomous operation feature usage for the road segments. The suitability data may be included in map data received from a map database or map server via the network 130, either directly or through a mobile device 110. Such map data may further include location data associated with each of the plurality of road segments (such as GPS data), which may be used to identify current road segments where the vehicle 108 is currently located during operation. The map data may be received with or without graphical map tile data, in various embodiments. The suitability data may be received for the plurality of road segments based upon a route of the vehicle 108, such as a route determined by the methods described elsewhere herein. Alternatively, suitability data may be received for a plurality of road segments in proximity to the current location of the vehicle 108 (e.g., all road segments within a predetermined distance of the current location). The suitability data may be requested by the on-board computer 114 or may be received from a database without a request. In some embodiments, the on-board computer 114 may store the suitability data in the program memory 208 for use throughout a vehicle trip or multiple vehicle trips. For example, the on-board computer 114 may store suitability data for a plurality of road segments in an area of frequent operation of the vehicle 108 for repeated use over a period of time, which stored suitability data may be updated periodically by communication with a server 140.
On claim 19, Konrardy cites:
The method of 13, further comprising:
receiving dynamic data from a server based on the reception of the sensor data;
col. 8, lines 38-61, FIG. 1A illustrates a block diagram of an exemplary autonomous vehicle data system 100 on which the exemplary methods described herein may be implemented. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The autonomous vehicle data system 100 may be roughly divided into front-end components 102 and back-end components 104. The front-end components 102 may obtain information regarding a vehicle 108 (e.g., a car, truck, motorcycle, etc.) and the surrounding environment. An on-board computer 114 may utilize this information to operate the vehicle 108 according to an autonomous operation feature or to assist the vehicle operator in operating the vehicle 108. To monitor the vehicle 108, the front-end components 102 may include one or more sensors 120 installed within the vehicle 108 that may communicate with the on-board computer 114. The front-end components 102 may further process the sensor data using the on-board computer 114 or a mobile device 110 (e.g., a smart phone, a tablet computer, a special purpose computing device, smart watch, wearable electronics, etc.) to determine when the vehicle is in operation and information regarding the vehicle.
col. 9, lines 66-67 and col. 10, lines 1-13. Some of the sensors 120 (e.g., radar, LIDAR, or camera units) may actively or passively scan the vehicle environment for obstacles (e.g., other vehicles, buildings, pedestrians, etc.), roadways, lane markings, signs, or signals. Other sensors 120 (e.g., GPS, accelerometer, or tachometer units) may provide data for determining the location or movement of the vehicle 108 (e.g., via GPS coordinates, dead reckoning, wireless signal triangulation, etc.). Other sensors 120 may be directed to the interior or passenger compartment of the vehicle 108, such as cameras, microphones, pressure sensors, thermometers, or similar sensors to monitor the vehicle operator and/or passengers within the vehicle 108. Information generated or received by the sensors 120 may be communicated to the on-board computer 114 or the mobile device 110 for use in autonomous vehicle operation
executing a map matching process for the vehicle based on the sensor data and the dynamic data;
Col. 39, lines 47-61 At block 606, the minimum requirements for the route may be determined by the mobile device 110. The minimum requirements may relate to the acceptable range of scores for road segments along the route, such as requiring a minimum score for each road segment. Such minimum requirements may be selected by the user or may be automatically determined based upon conditions of vehicle operation. For example, the user may request a route suitable for fully autonomous operation. As another example, automatic emergency operation may require fully autonomous operation throughout the route. In some embodiments, the user may specify different minimum requirements for different types of road segments. For example, the user may require fully autonomous operation on highway road segments, but may allow semi-autonomous operation on residential street road segments
and determining the coverage data of the vehicle for each of the plurality of roads based on the execution of the map matching process.
col. 41, lines 41-42 In further embodiments, adjusting the parameters may include allowing for the inclusion of short distances of road segments that may be suitable for significantly less autonomous or semi-autonomous operation. For example, road segments of less than one mile that connect on both ends to road segments meeting the minimum requirements (or that connect to or contain the first or destination geospatial locations) may be included, even if such road segments are not suitable for any autonomous operation feature use (or are suitable for only the lowest levels of such feature use). This may allow the driver to travel most of the trip autonomously using an efficient route, but the route may require the driver to take control for a short distance (e.g., while passing through a construction zone).r pre-defined combination of road types indicative of a specific or typical drive for a user.
On claim 20, Konrardy cites:
A non-transitory computer-readable medium having stored thereon computer-executable instructions,
figure 1A, program memory 160, RAM 164 and processor 162, col. 14, lines 57-58 algorithms programs.
which when executed by a computer, cause the computer to execute operations, the operations comprising:
acquiring sensor data and vehicle data from a user equipment, wherein the sensor data is associated with a region including a plurality of roads;
col. 8, lines 38-61, FIG. 1A illustrates a block diagram of an exemplary autonomous vehicle data system 100 on which the exemplary methods described herein may be implemented. The high-level architecture includes both hardware and software applications, as well as various data communications channels for communicating data between the various hardware and software components. The autonomous vehicle data system 100 may be roughly divided into front-end components 102 and back-end components 104. The front-end components 102 may obtain information regarding a vehicle 108 (e.g., a car, truck, motorcycle, etc.) and the surrounding environment. An on-board computer 114 may utilize this information to operate the vehicle 108 according to an autonomous operation feature or to assist the vehicle operator in operating the vehicle 108. To monitor the vehicle 108, the front-end components 102 may include one or more sensors 120 installed within the vehicle 108 that may communicate with the on-board computer 114. The front-end components 102 may further process the sensor data using the on-board computer 114 or a mobile device 110 (e.g., a smart phone, a tablet computer, a special purpose computing device, smart watch, wearable electronics, etc.) to determine when the vehicle is in operation and information regarding the vehicle.
determining a function class of each of the plurality of roads based on the sensor data;
col. 35, lines 32-37 Regardless of the source, the data received may be associated with geographic locations. Such associations may be indicated by geospatial coordinates (e.g., GPS position), relative location data (e.g., street addresses, intersections, etc.), or area indications (e.g., cities, counties, types of roads, etc.).
And
Col. 39, lines 47-61 At block 606, the minimum requirements for the route may be determined by the mobile device 110. The minimum requirements may relate to the acceptable range of scores for road segments along the route, such as requiring a minimum score for each road segment. Such minimum requirements may be selected by the user or may be automatically determined based upon conditions of vehicle operation. For example, the user may request a route suitable for fully autonomous operation. As another example, automatic emergency operation may require fully autonomous operation throughout the route. In some embodiments, the user may specify different minimum requirements for different types of road segments. For example, the user may require fully autonomous operation on highway road segments, but may allow semi-autonomous operation on residential street road segments
determining a type of a vehicle based on the vehicle data;
col 36 lines 56-63. Such risk factors may include time of day, weather conditions, traffic conditions, speed, type of vehicle, types of sensors used by the vehicle, types of autonomous operation features in use, versions of autonomous operation features, interactions between autonomous operation features, autonomous operation feature settings or configurations, driver behavior, or other similar factors that may be derived from the data.
determining coverage data of the vehicle for each of the plurality of roads based on the function class of a respective road of the plurality of roads and the type of the vehicle; and
col. 41, lines 41-42 In further embodiments, adjusting the parameters may include allowing for the inclusion of short distances of road segments that may be suitable for significantly less autonomous or semi-autonomous operation. For example, road segments of less than one mile that connect on both ends to road segments meeting the minimum requirements (or that connect to or contain the first or destination geospatial locations) may be included, even if such road segments are not suitable for any autonomous operation feature use (or are suitable for only the lowest levels of such feature use). This may allow the driver to travel most of the trip autonomously using an efficient route, but the route may require the driver to take control for a short distance (e.g., while passing through a construction zone).r pre-defined combination of road types indicative of a specific or typical drive for a user.
outputting a first notification associated with the coverage data of the vehicle.
Col. 40, lines 51-67 At block 612, the server 140 may determine whether at least one route exists that forms a connected path between the first geospatial location and the destination geospatial location along the identified road segments that meet the minimum requirements. This may include iteratively checking road segments until either a connecting path is found or all road segments have been checked. In some embodiments, this may include a preliminary step of determining whether both the first and destination geospatial positions lie along road segments that meet the minimum requirements, which may be used to quickly determine that no suitable route exists if one or both geospatial locations are not upon a road segment meeting the minimum requirements. If at least one path between the first and destination geospatial locations is found, the method 600 may continue with determining an optimal route (block 616). If no paths meeting the minimum requirements are found, the method 600 may instead attempt to adjust the parameters (block 614) to find a suitable route. Once the parameters have been adjusted (block 614), the method 600 may continue by accessing map data using the new parameters (block 608). Alternatively, the method 600 may notify the user that no suitable route exists or may terminate with an error message if no suitable path is found
And
Col 21, lines 48-54. The server 140 may then process the data to determine a route, risk level, recommendation, or other action. The server 140 may then communicate the determined information to the mobile device 110 and/or on-board computer 114, which may cause the vehicle 108 to operate in accordance with the determined information (e.g., travel along a determined optimal route).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) 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.
Claims 8 and 10 are rejected U.S.C. § 103 as being unpatentable over Konrardy et al., U.S.10,324,463.
On claim 8, Konrardy cites except as underlined:
The system of claim 6, wherein the at least one processor is further configured to:
classify the generated statistical data metrics based on a degree of importance of a specific time period; and
execute statistical analysis on the classified statistical data metrics based on the degree of importance of the specific time period.
Konrardy cites:
Col. 36, lines 50-63 At block 510, the external computing device 186 (such as a server 140) may determine one or more risk levels associated with the road segment. Machine learning techniques (e.g., support vectors, neural networks, random forests, naïve Bayesian classifiers, etc.) may be used to identify or estimate the magnitude of salient risk factors associated with autonomous operation feature use on the road segment. Such risk factors may include time of day, weather conditions, traffic conditions, speed, type of vehicle, types of sensors used by the vehicle, types of autonomous operation features in use, versions of autonomous operation features, interactions between autonomous operation features, autonomous operation feature settings or configurations, driver behavior, or other similar factors that may be derived from the data.
Konrardy doesn’t specifically disclose the excepted claim limitations, that is, the claimed “degree of importance.”
However, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to include into Konrardy an embodiment based on the cited features of Konrardy such that the claimed invention is realized.
Konrardy disclosed an embodiment wherein one or more risk levels are realized in an analysis of a particular road segment. Included in this assessment are risk factors associated with the time of day. However, the claimed “degree of importance” is not shown in detail. But, a “degree of importance of a specific time period” is synonymously disclosed as part of the embodiment. In this instance, the “risk levels” disclosed in Konrardy are analogous to an importance a driver must consider when considering taking the cited route with attendant “risk levels.” Thus, the riskier the road segment, a higher degree of alertness and careful driving is presumed should a driver take that road segment. Accordingly, that road segment is said to be “of a higher degree of importances” as compared to a safer road segment without the number of hazardous considerations as the previously disclosed “risky” road segment. Accordingly, one of ordinary skill, would have arrived at the conclusion that the cited embodiment, based on the known definitions of risks as analyzed above.
On claim 10, Konrardy cites except as underlined:
The system of claim 1, wherein the vehicle comprises a plurality of sensors,
col. 9, lines 66-67 and col. 10, lines 1-13. Some of the sensors 120 (e.g., radar, LIDAR, or camera units) may actively or passively scan the vehicle environment for obstacles (e.g., other vehicles, buildings, pedestrians, etc.), roadways, lane markings, signs, or signals. Other sensors 120 (e.g., GPS, accelerometer, or tachometer units) may provide data for determining the location or movement of the vehicle 108 (e.g., via GPS coordinates, dead reckoning, wireless signal triangulation, etc.). Other sensors 120 may be directed to the interior or passenger compartment of the vehicle 108, such as cameras, microphones, pressure sensors, thermometers, or similar sensors to monitor the vehicle operator and/or passengers within the vehicle 108.
And
Col. 36, lines 50-63 At block 510, the external computing device 186 (such as a server 140) may determine one or more risk levels associated with the road segment. Machine learning techniques (e.g., support vectors, neural networks, random forests, naïve Bayesian classifiers, etc.) may be used to identify or estimate the magnitude of salient risk factors associated with autonomous operation feature use on the road segment.
and the at least one processor is further configured to generate statistical data metrics for the vehicle based on a category of each sensor of the plurality of sensors.
Col 36 lines 56-63. Such risk factors may include time of day, weather conditions, traffic conditions, speed, type of vehicle, types of sensors used by the vehicle, types of autonomous operation features in use, versions of autonomous operation features, interactions between autonomous operation features, autonomous operation feature settings or configurations, driver behavior, or other similar factors that may be derived from the data.
Regarding the excepted claim limitations, Kornardy disclosed a variety of sensors used to monitor the movement of a user’s vehicle. Furthermore, Konrardy disclosed using sensors to determine risk factors associated with traversing a road segment. Konrardy doesn’t disclose the excepted claim limitations. However, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to include into Konrardy the feature of including statistical data metrics for the vehicle traversing the claimed road segment.
Merriam-Webster’s Online Dictionary defines the limitation “risk” in the following manner:
“1 risk: possibility of loss or injury” (emphasis added).
Merriam-Webster’s Online Dictionary defines the limitation “possible” in the following manner:
“4 possibility: potential or prospective value”
Konrardy’s embodiment is built on assessing risks to a user’s vehicle traversing a certain road segment assigned with those risks. In that determination, Konrardy disclosed using a series of different sensors to associate risks with the road segment. Therefore, one of ordinary skill, based on features disclosed in Konrardy, would include at least one or more of the cited sensors used to determine the risk of traveling on the cited road segment wherein the determined risk factors asserted by measured parameters of the cited sensors would find include generating statistical data metrics as part of the risk assessment feature of Konrardy. As disclosed above, the definition of “risk” means a likelihood that an occurrence will happen. In this case, the sensors are defining a risk associated with the particular road segment.
Furthermore, the definition of “statistics” is disclosed in Merriam-Webster’s Online Dictionary:
“1 statistics: a branch of mathematics dealing with the collection, analysis, interpretation, and presentation of masses of numerical data.”
Hence, the cited “risk,” as associated with each sensor, would be analogous to the claimed “statistical data metrics” since “risk” infers a “possibility value” or “potential value” (“value” as something associated with a quantity, which can be measured in numbers).
Accordingly, one of ordinary skill, apprised of the related nature of numerical analysis between statistics and risk, would conclude the cited features disclosed in Konrardy provided an embodiment meeting the claimed limitations.
Claim 9 are rejected U.S.C. § 102(a)(1) as being unpatentable over Konrardy et al., U.S. 10,324,463 in view of Lewis et al., U.S. 2023/0082960.
On claim 9, Konrardy cites except:
The system of claim 1, wherein the vehicle data includes an identifier of the vehicle, and the at least one processor is further configured to determine the type of the vehicle based on the identifier of the vehicle.
Konrardy, as previously disclosed, includes:
Col. 36, lines 50-63 At block 510, the external computing device 186 (such as a server 140) may determine one or more risk levels associated with the road segment. Machine learning techniques (e.g., support vectors, neural networks, random forests, naïve Bayesian classifiers, etc.) may be used to identify or estimate the magnitude of salient risk factors associated with autonomous operation feature use on the road segment.
Konrardy doesn’t disclose the excepted claim limitations. In the same art of vehicle road segment selection, Lewis cites:
[0058] In some embodiments, trip information generator 240 may generate trip information for the trip using the association between the GPS data and the base map (e.g., ordered sequence of edges for the trip). The trip information generator 240 may, for a unique vehicle identifier provided as input, generate trip information 250 including, but not limited to, information about road segments at which the vehicle has traversed (e.g., based on identified edge traversals), information about the time at which the vehicle enters and exits the road segment, and/or any information associated with the road, the vehicle, or its movement on the road such as average speed or maximum speed, speed limit, direction of travel, road type, road name, vehicle make, model, and year, city ID, county ID, country ID, etc. In some embodiments, the average speed of the vehicle may be computed by averaging all raw speed observations of the vehicle over the course of movement on the road (i.e., over the course of traversing the edge). In some embodiments, the maximum speed of the vehicle may represent a maximum observed speed that the vehicle has achieved over the course of movement on the road (i.e., over the course of traversing the edge).
It would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to include into Konrardy the features disclosed in Lewis such that the claimed invention is realized. Konrardy, while disclosing the risks in an identified road segment, Konrardy didn’t disclose an embodiment in which the route the vehicle is identified to traverse includes an identification of the user’s vehicle. One of ordinary skill would have included Lewis’s embodiment to allow the user’s vehicle to be identified and associated with the cited route selection feature to identify the vehicle traversing the risk laden road segment in case an accident or other law enforcement action requires documentation on the vehicle.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAL EUSTAQUIO whose telephone number is (571)270-7229. The examiner can normally be reached on 8am-5pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Brian Zimmerman, can be reached at (571) 272-3059. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application lnformation Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAlR only. For more information about the PAlR system, see http:/lpair-direct.uspto.gov. Should you have questions on access to the Private PAlR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-91 99 (IN USA OR CANADA) or 571-272-1000.
/CAL J EUSTAQUIO/Examiner, Art Unit 2686 /BRIAN A ZIMMERMAN/Supervisory Patent Examiner, Art Unit 2686