Detailed Office Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a non-final Office Action on the merits. Claims 1-20 are currently pending and are addressed below.
Priority
Acknowledgment is made of applicant's claim priority for Provisional Application 63326547.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 09/30/2024 and 01/10/2025 are being considered by the examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 8-9, 17, and 20 rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kentley-Klay et al (US 11067983 B2), hereafter referred to as Kentley.
Independent Claims
Regarding Claim 1, Kentley teaches a remote computing system (see at least Kentley [C4 L53 to C5 L22] FIG. 1 is a diagram depicting an implementation of a fleet of autonomous vehicles that are communicatively networked to an autonomous vehicle service platform, according to some embodiments. Diagram 100 depicts a fleet of autonomous vehicles 109 (e.g., one or more of autonomous vehicles 109a to 109e) operating as a service, each autonomous vehicle 109 being configured to self-drive a road network 110 and establish a communication link 192 with an autonomous vehicle service platform 101)
comprising:
a communication interface structured to couple to a network (see at least Kentley [Fig. 1, Fig. 4, C13 L47-50, C4 L63 to C5 L2] element of autonomous vehicle service platform 401 may independently communicate with the autonomous vehicle 430 via the communication layer 402… user 102 may transmit a request 103 for autonomous transportation via one or more networks 106 to autonomous vehicle service platform 101. In response, autonomous vehicle service platform 101 may dispatch one of autonomous vehicles 109 to transport user 102 autonomously from geographic location 119 to geographic location 111)
a map database storing centralized map data (see at least Kentley [C11 L65 to C12 L25, C15 L45-48] According to some examples, localizer 468 retrieves reference data originating from a reference data repository 405, which includes a map data repository 405a for storing 2O map data, 3O map data, 4O map data, and the like…reference data generator 705 may be configured to access 2D maps in 2D map data repository 720, access 3D maps in 3D map data repository 722, and access route data in route data repository 724)
one or more processors; and one or more memory devices storing instructions (see at least Kentley [C15 L 50-52, C36 L17-25] Vehicle data controller 702 may be configured to perform a variety of operations... module 3350 of FIG. 33, module 3450 of FIG. 34, and module 3550 of FIG. 35, or one or more of its components, or any process or device described herein, can be implemented in one or more computing devices (i.e., any mobile computing device, such as a wearable device, an audio device (such as headphones or a headset) or mobile phone, whether worn or carried) that include one or more processors configured to execute one or more algorithms in memory)
that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving a transport request, the transport request comprising a first location and a second location; selecting a first vehicle of a plurality of vehicles for the transport request, the first vehicle selected based on at least one of the transport request and a vehicle status for each of the plurality of vehicles (see at least Kentley [C24 L11-32] FIG. 17 is an example of a flow diagram to manage a fleet of autonomous vehicles, according to some embodiments. At 1702, flow 1700 begins. At 1702, policy data is received. The policy data may include parameters that define how best apply to select an autonomous vehicle for servicing a transit request....At 1706, data representing a transit request is received. For exemplary purposes, the transit request could be for transportation from a first geographic location to a second geographic location. At 1708, attributes based on the policy data are calculated to determine a subset of autonomous vehicles that are available to service the request. For example, attributes may include a battery charge level and time until next scheduled maintenance. At 1710, an autonomous vehicle is selected as transportation from the first geographic location to the second geographic location, and data is generated to dispatch the autonomous vehicle to a third geographic location associated with the origination of the transit request)
selectively transmitting the centralized map data to the first vehicle (see at least Kentley [Fig.4, C9 L12-19, C11 L66 to C12 L2] autonomous vehicle controller 347a may receive any other sensor data 356, as well as reference data 339. In some cases, reference data 339 includes map data (e.g., 3D map data, 2D map data, 4D map data (e.g., including Epoch Determination)) and route data (e.g., road network data, including, but not limited to, RNDF data (or similar data), MDF data (or similar data), etc....localizer 468 retrieves reference data originating from a reference data repository 405, which includes a map data repository 405a for storing 2O map data, 3O map data, 4O map data, and the like)
causing the first vehicle to complete the transport request (see at least Kentley [C4 L63 to C5 L6] a user 102 may transmit a request 103 for autonomous transportation via one or more networks 106 to autonomous vehicle service platform 101. In response, autonomous vehicle service platform 101 may dispatch one of autonomous vehicles 109 to transport user 102 autonomously from geographic location 119 to geographic location 111. Autonomous vehicle service platform 101 may dispatch an autonomous vehicle from a station 190 to geographic location 119, or may divert an autonomous vehicle 109c, already in transit (e.g., without occupants), to service the transportation request for user 102)
wherein completing the transport request comprises:
causing the first vehicle to autonomously transport from the first location to the second location (see at least Kentley [C32 L15-26] Transportation controller 3242 is configured to receive, schedule, select, or perform operations related to autonomous vehicles and/or autonomous vehicle fleets for which a user 3202 may arrange transportation from the user's location to a destination)
causing the first vehicle to collect first sensor data while autonomously transporting from the first location to the second location (see at least Kentley [C6 L3-24, C9 L20-29] the localizer may use acquired sensor data, such as sensor data associated with surfaces of buildings 115 and 117, which can be compared against reference data, such as map data (e.g., 3D map data, including reflectance data) to determine a local pose. Further, a perception engine (not shown) of autonomous vehicle controller 147 may be configured to detect, classify, and predict the behavior of external objects, such as external object 112 (a “tree” and external object 114 (a “pedestrian”). Classification of such external objects may broadly classify objects as static objects, such as external object 112, and dynamic objects, such as external object 114. The localizer and the perception engine, as well as other components of the AV controller 147, collaborate to cause autonomous vehicles 109 to drive autonomously.... Localizer 368 is configured to receive sensor data from one or more sources, such as GPS data 352, wheel data, MU data 354, Lidar data 346a, camera data 340a, radar data 348a, and the like, as well as reference data 339 (e.g., 3D map data and route data). Localizer 368 integrates (e.g., fuses the sensor data) and analyzes the data by comparing sensor data to map data to determine a local pose (or position) of bidirectional autonomous vehicle 330. According to some examples, localizer 368 may generate or update the pose or position of any autonomous vehicle in real-time or near real-time)
receiving the first sensor data; and selectively updating the centralized map data with the first sensor data (see at least Kentley [C13 L50-62] Map updater 406 is configured to receive map data (e.g., from local map generator 440, sensors 460, or any other component of autonomous vehicle controller 447), and is further configured to detect deviations, for example, of map data in map data repository 405a from a locally-generated map. Vehicle data controller 408 can cause map updater 406 to update reference data within repository 405 and facilitate updates to 20, 30, and/or 40 map data. In some cases, vehicle data controller 408 can control the rate at which local map data is received into autonomous vehicle service platform 408 as well as the frequency at which map updater 406 performs updating of the map data).
Regarding Claim 8, Kentley teaches a method comprising:
receiving, by a computing system, a transport request, the transport request comprising a first location and a second location and selecting, by the computing system, a first vehicle of a plurality of vehicles for the transport request, the first vehicle selected based on at least one of the transport request and a vehicle status for each of the plurality of vehicles (see at least Kentley [C24 L11-32] FIG. 17 is an example of a flow diagram to manage a fleet of autonomous vehicles, according to some embodiments. At 1702, flow 1700 begins. At 1702, policy data is received. The policy data may include parameters that define how best apply to select an autonomous vehicle for servicing a transit request....At 1706, data representing a transit request is received. For exemplary purposes, the transit request could be for transportation from a first geographic location to a second geographic location. At 1708, attributes based on the policy data are calculated to determine a subset of autonomous vehicles that are available to service the request. For example, attributes may include a battery charge level and time until next scheduled maintenance. At 1710, an autonomous vehicle is selected as transportation from the first geographic location to the second geographic location, and data is generated to dispatch the autonomous vehicle to a third geographic location associated with the origination of the transit request)
selectively transmitting, by the computing system, centralized map data to the first vehicle (see at least Kentley [Fig.4, C9 L12-19, C11 L66 to C12 L2] autonomous vehicle controller 347a may receive any other sensor data 356, as well as reference data 339. In some cases, reference data 339 includes map data (e.g., 3D map data, 2D map data, 4D map data (e.g., including Epoch Determination)) and route data (e.g., road network data, including, but not limited to, RNDF data (or similar data), MDF data (or similar data), etc....localizer 468 retrieves reference data originating from a reference data repository 405, which includes a map data repository 405a for storing 2O map data, 3O map data, 4O map data, and the like)
causing, by the computing system, the first vehicle to complete the transport request (see at least Kentley [C4 L63 to C5 L6] a user 102 may transmit a request 103 for autonomous transportation via one or more networks 106 to autonomous vehicle service platform 101. In response, autonomous vehicle service platform 101 may dispatch one of autonomous vehicles 109 to transport user 102 autonomously from geographic location 119 to geographic location 111. Autonomous vehicle service platform 101 may dispatch an autonomous vehicle from a station 190 to geographic location 119, or may divert an autonomous vehicle 109c, already in transit (e.g., without occupants), to service the transportation request for user 102)
wherein completing the transport request comprises:
causing the first vehicle to autonomously transport from the first location to the second location (see at least Kentley [C32 L15-26] Transportation controller 3242 is configured to receive, schedule, select, or perform operations related to autonomous vehicles and/or autonomous vehicle fleets for which a user 3202 may arrange transportation from the user's location to a destination)
causing the first vehicle to collect first sensor data while autonomously transporting from the first location to the second location (see at least Kentley [C6 L3-24, C9 L20-29] the localizer may use acquired sensor data, such as sensor data associated with surfaces of buildings 115 and 117, which can be compared against reference data, such as map data (e.g., 3D map data, including reflectance data) to determine a local pose. Further, a perception engine (not shown) of autonomous vehicle controller 147 may be configured to detect, classify, and predict the behavior of external objects, such as external object 112 (a “tree” and external object 114 (a “pedestrian”). Classification of such external objects may broadly classify objects as static objects, such as external object 112, and dynamic objects, such as external object 114. The localizer and the perception engine, as well as other components of the AV controller 147, collaborate to cause autonomous vehicles 109 to drive autonomously.... Localizer 368 is configured to receive sensor data from one or more sources, such as GPS data 352, wheel data, MU data 354, Lidar data 346a, camera data 340a, radar data 348a, and the like, as well as reference data 339 (e.g., 3D map data and route data). Localizer 368 integrates (e.g., fuses the sensor data) and analyzes the data by comparing sensor data to map data to determine a local pose (or position) of bidirectional autonomous vehicle 330. According to some examples, localizer 368 may generate or update the pose or position of any autonomous vehicle in real-time or near real-time)
receiving, by the computing system, the first sensor data and selectively updating, by the computing system, the centralized map data with the first sensor data. (see at least Kentley [C13 L50-62] Map updater 406 is configured to receive map data (e.g., from local map generator 440, sensors 460, or any other component of autonomous vehicle controller 447), and is further configured to detect deviations, for example, of map data in map data repository 405a from a locally-generated map. Vehicle data controller 408 can cause map updater 406 to update reference data within repository 405 and facilitate updates to 20, 30, and/or 40 map data. In some cases, vehicle data controller 408 can control the rate at which local map data is received into autonomous vehicle service platform 408 as well as the frequency at which map updater 406 performs updating of the map data).
Regarding Claim 17, Kentley teaches a system comprising:
one or more sensors; and a controller coupled to the one or more sensors (see at least Kentley [C5 L60-67] bidirectional autonomous vehicle 130 may include an autonomous vehicle controller 147 that includes logic (e.g., hardware or software, or as combination thereof) that is configured to control a predominate number of vehicle functions, including driving control (e.g., propulsion, steering, etc.) and active sources 136 of light, among other functions. Bidirectional autonomous vehicle 130 also includes a number of sensors 139 disposed at various locations on the vehicle (other sensors are not shown)
the controller configured to:
receive, from a remote computing system, map data (see at least Kentley [Fig.4, C9 L12-19, C11 L66 to C12 L2] autonomous vehicle controller 347a may receive any other sensor data 356, as well as reference data 339. In some cases, reference data 339 includes map data (e.g., 3D map data, 2D map data, 4D map data (e.g., including Epoch Determination)) and route data (e.g., road network data, including, but not limited to, RNDF data (or similar data), MDF data (or similar data), etc....localizer 468 retrieves reference data originating from a reference data repository 405, which includes a map data repository 405a for storing 2O map data, 3O map data, 4O map data, and the like)
receive, from the remote computing system, transportation instructions, the transportation instructions comprising a first location and a second location (see at least Kentley [C24 L11-32] At 1706, data representing a transit request is received. For exemplary purposes, the transit request could be for transportation from a first geographic location to a second geographic location. At 1708, attributes based on the policy data are calculated to determine a subset of autonomous vehicles that are available to service the request. For example, attributes may include a battery charge level and time until next scheduled maintenance. At 1710, an autonomous vehicle is selected as transportation from the first geographic location to the second geographic location, and data is generated to dispatch the autonomous vehicle to a third geographic location associated with the origination of the transit request)
generate autonomous vehicle control signals, the autonomous vehicle control signals causing a vehicle including the system to autonomously transport from the first location to the second location (see at least Kentley [C4 L63 to C5 L6, C32 L15-26] Autonomous vehicle service platform 101 may dispatch an autonomous vehicle from a station 190 to geographic location 119, or may divert an autonomous vehicle 109c, already in transit (e.g., without occupants), to service the transportation request for user 102…Transportation controller 3242 is configured to receive, schedule, select, or perform operations related to autonomous vehicles and/or autonomous vehicle fleets for which a user 3202 may arrange transportation from the user's location to a destination)
receive, from the one or more sensors, sensor data while autonomously transporting from the first location to the second location (see at least Kentley [C6 L3-24, C9 L20-29] the localizer may use acquired sensor data, such as sensor data associated with surfaces of buildings 115 and 117, which can be compared against reference data, such as map data (e.g., 3D map data, including reflectance data) to determine a local pose. Further, a perception engine (not shown) of autonomous vehicle controller 147 may be configured to detect, classify, and predict the behavior of external objects, such as external object 112 (a “tree” and external object 114 (a “pedestrian”). Classification of such external objects may broadly classify objects as static objects, such as external object 112, and dynamic objects, such as external object 114. The localizer and the perception engine, as well as other components of the AV controller 147, collaborate to cause autonomous vehicles 109 to drive autonomously.... Localizer 368 is configured to receive sensor data from one or more sources, such as GPS data 352, wheel data, MU data 354, Lidar data 346a, camera data 340a, radar data 348a, and the like, as well as reference data 339 (e.g., 3D map data and route data). Localizer 368 integrates (e.g., fuses the sensor data) and analyzes the data by comparing sensor data to map data to determine a local pose (or position) of bidirectional autonomous vehicle 330. According to some examples, localizer 368 may generate or update the pose or position of any autonomous vehicle in real-time or near real-time)
selectively updating the received map data with the sensor data (see at least Kentley [C13 L50-62] Map updater 406 is configured to receive map data (e.g., from local map generator 440, sensors 460, or any other component of autonomous vehicle controller 447), and is further configured to detect deviations, for example, of map data in map data repository 405a from a locally-generated map. Vehicle data controller 408 can cause map updater 406 to update reference data within repository 405 and facilitate updates to 20, 30, and/or 40 map data. In some cases, vehicle data controller 408 can control the rate at which local map data is received into autonomous vehicle service platform 408 as well as the frequency at which map updater 406 performs updating of the map data).
Dependent Claims
Regarding Claim 2 and Claim 9, Kentley teaches all limitations of the system of Claim 1 and the method of Claim 8 as set forth above. Kentley further teaches wherein the first vehicle is positioned at a third location, and wherein the operations further comprise:
causing the first vehicle to autonomously transport from the third location to the first location (see at least Kentley [C24 L28-33] At 1710, an autonomous vehicle is selected as transportation from the first geographic location to the second geographic location, and data is generated to dispatch the autonomous vehicle to a third geographic location associated with the origination of the transit request)
causing the first vehicle to collect second sensor data while autonomously transporting from the third location to the first location (see at least Kentley [C9 L20-29] Localizer 368 is configured to receive sensor data from one or more sources, such as GPS data 352, wheel data, MU data 354, Lidar data 346a, camera data 340a, radar data 348a, and the like, as well as reference data 339 (e.g., 3D map data and route data). Localizer 368 integrates (e.g., fuses the sensor data) and analyzes the data by comparing sensor data to map data to determine a local pose (or position) of bidirectional autonomous vehicle 330. According to some examples, localizer 368 may generate or update the pose or position of any autonomous vehicle in real-time or near real-time).
Regarding Claim 20, Kentley in view of Abramson teaches all limitations of Claim 17 as set forth above. Kentley further teaches wherein wherein the autonomous vehicle control signals comprise at least one of: an acceleration control that causes the vehicle to accelerate by increasing a fueling rate of an engine or increasing a power provided to an electric motor; a steer control that causes the vehicle to change direction by actuating a vehicle steering assembly; or a brake control that causes the vehicle to brake by actuating a brake system of the vehicle (see at least Kentley [C13 L18-26, C15 L31-35, C10 L17-39] User experience may be optimized by moderating accelerations in various linear and angular directions (e.g., to reduce jerking-like travel or other unpleasant motion)…Motion controller process uses trajectories data 665 to generate low-level commands or control signals for application to actuators 650 to cause changes in steering angles and/or velocity…planner 364 may transmit steeling and propulsion commands (as well as decelerating or braking commands) to motion controller 362. Motion controller 362 subsequently may convert any of the commands, such as a steering command, a throttle or propulsion command, and a braking command, into control signals (e.g., for application to actuators or other mechanical interfaces) to implement changes in steering or wheel angles 351 and/or velocity 353).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 3 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Kentley-Klay et al (US 11067983 B2) in view of Kislovskiy et al (US 20180341880 A1) and Willis et al (EP 3640102 A1). Hereafter referred to as Kentley, Kislovskiy and Willis respectively.
Regarding Claim 3 and Claim 10, Kentley teaches all limitations of the system of Claim 1 and the method of Claim 8 as set forth above. However, Kentley does not explicitly teach comparing a load value of the transport request to a load threshold of the first vehicle; and selecting the first vehicle responsive to determining that the load value is at or below the load threshold.
Kislovskiy, in the same field as the endeavor, teaches comparing a load value of the transport request to a load threshold of the first vehicle; and selecting the first vehicle responsive to determining that the load value is at or below the load threshold (see at least Kislovskiy [¶ 78] if the trip risk value 332 is below all thresholds for a verified software version 346, then the trip classifier 350 can enable all vehicles types (HDVs 387, SDAVs 381, and FAVs 389) to service the transport request 371....the matching engine 320 will ultimately select an optimal vehicle to service the transport request 371 across those vehicles authorized by the trip classifier(s) 350, and other factors such as estimated trip cost or revenue 348, and estimated distance or time of the vehicle from the pick-up location)
Willis, in the same field as the endeavor, teaches wherein load is specifically a value regarding the weight of the vehicle and its cargo (see at least Willis [English Translation pg.5 para.3, pg.3 para.6] a route (or route portion) is divided into the first route segment and the second route segment in response to the controller determining or predicting that the load condition of the vehicle in the first route segment differs from the load condition of the vehicle in the second route segment by greater than a specified load threshold (e.g., a weight of the load)...a route can be a predetermined route or a route that can change on the fly as the vehicle proceeds on its trip).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for comparing a load value of the transport request to a load threshold of the first vehicle; and selecting the first vehicle responsive to determining that the load value is at or below the load threshold with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of reducing the risk of the vehicle selection by only choosing vehicles that can handle the requirements of the request as discussed in Kislovskiy.
Claims 4, 5, 7 11, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kentley-Klay et al (US 11067983 B2) in view of Arditi (US 20190147331 A1). Hereafter referred to as Kentley and Arditi respectively.
Regarding Claim 4 and Claim 11, Kentley teaches all limitations of the system of Claim 1 and the method of Claim 8 as set forth above. Kentley further teaches wherein the first sensor data comprises map data and the operations further comprise:
comparing the map data to the centralized map data (see at least Kentley [C13 L50-62] Map updater 406 is configured to receive map data (e.g., from local map generator 440, sensors 460, or any other component of autonomous vehicle controller 447), and is further configured to detect deviations, for example, of map data in map data repository 405a from a locally-generated map. Vehicle data controller 408 can cause map updater 406 to update reference data within repository 405 and facilitate updates to 20, 30, and/or 40 map data. In some cases, vehicle data controller 408 can control the rate at which local map data is received into autonomous vehicle service platform 408 as well as the frequency at which map updater 406 performs updating of the map data.
However, Kentley does not explicitly teach responsive to determining that a difference between the map data and the centralized map data is less than a predetermined threshold, discarding the map data; and responsive to determining that the difference between the map data and the centralized map data is equal to or greater than the predetermined threshold, updating the centralized map data.
Arditi, in the same field as the endeavor, teaches responsive to determining that a difference between the map data and the centralized map data is less than a predetermined threshold, discarding the map data; and responsive to determining that the difference between the map data and the centralized map data is equal to or greater than the predetermined threshold, updating the centralized map data (see at least Arditi [¶ 47] at step 730, the computing system may access the HD map stored on the autonomous vehicle for map data associated with the particular location (e.g., x, y coordinates). Then at step 740, the computing system may compare the map data associated with the location (e.g., x, y coordinates) with the object detected in step 720 to determine whether the detected objects exist in the map data. For example, for each detected object, the system may check whether that object exists in the map data. In particular embodiments, the system may generate a confidence score representing the likelihood of the detected object being accounted for in the map data. The confidence score may be based on, for example, a similarity comparison of the measured size, dimensions, classification, and/or location of the detected object with known objects in the map data. At step 745, if the comparison results in a determination that the detected object(s) exists or is known in the HD map (e.g., the confidence score in the object existing in the map is higher than a threshold), then the system may not perform any map-updating operation and return to obtaining sensor data (e.g., step 710). On the other hand, if the comparison results in a determination that at least one detected object does not exist or is not known in the HD map (e.g., the confidence score in the object existing in the map is lower than a threshold), then the system may proceed with a map-updating operation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for determining that a difference between the map data and the centralized map data is less than a predetermined threshold, discarding the map data; and responsive to determining that the difference between the map data and the centralized map data is equal to or greater than the predetermined threshold, updating the centralized map data with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the safety of the operation of vehicles by keeping their maps up to date via updating as discussed by Arditi (see at least Arditi [¶ 14] HD maps need to include highly accurate and detailed information to ensure the safe operation of autonomous vehicles).
Regarding Claim 5 and Claim 12, Kentley in view of Arditi teaches all limitations of the system of Claim 4 and the method of Claim 11 as set forth above. However, Kentley does not explicitly teach wherein updating the centralized map data further comprises updating a first portion of the centralized map data, and wherein a difference between a portion the centralized map data and a corresponding portion of the map data is greater than or equal to the predetermined threshold.
Arditi, in the same field as the endeavor, teaches wherein updating the centralized map data further comprises updating a first portion of the centralized map data, and wherein a difference between a portion the centralized map data and a corresponding portion of the map data is greater than or equal to the predetermined threshold (see at least Arditi [¶ 41, 47] the computing system may use the generated map data, which may be associated with a particular location, to generate or update a portion of an HD map of a region…At step 730, the computing system may access the HD map stored on the autonomous vehicle for map data associated with the particular location (e.g., x, y coordinates). Then at step 740, the computing system may compare the map data associated with the location (e.g., x, y coordinates) with the object detected in step 720 to determine whether the detected objects exist in the map data. For example, for each detected object, the system may check whether that object exists in the map data. In particular embodiments, the system may generate a confidence score representing the likelihood of the detected object being accounted for in the map data. The confidence score may be based on, for example, a similarity comparison of the measured size, dimensions, classification, and/or location of the detected object with known objects in the map data. At step 745, if the comparison results in a determination that the detected object(s) exists or is known in the HD map (e.g., the confidence score in the object existing in the map is higher than a threshold), then the system may not perform any map-updating operation and return to obtaining sensor data (e.g., step 710). On the other hand, if the comparison results in a determination that at least one detected object does not exist or is not known in the HD map (e.g., the confidence score in the object existing in the map is lower than a threshold), then the system may proceed with a map-updating operation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for wherein updating the centralized map data further comprises updating a first portion of the centralized map data, and wherein a difference between a portion the centralized map data and a corresponding portion of the map data is greater than or equal to the predetermined threshold with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the safety of the operation of vehicles by keeping their maps up to date via updating as discussed by Arditi (see at least Arditi [¶ 14] HD maps need to include highly accurate and detailed information to ensure the safe operation of autonomous vehicles).
Regarding Claim 7 and Claim 14, Kentley teaches all limitations of the system of Claim 1 and the method of Claim 8 as set forth above. Kentley further teaches wherein the operations further comprise:
communicably coupling to one or more sensors (see at least Kentley [C11 L19-50] sensors 470 may be configured to provide sensor data to components of autonomous vehicle controller 447 and to elements of autonomous vehicle service platform 401)
receiving, from the one or more sensors, map data (see at least Kentley [C6 L3-24, C9 L20-29] the localizer may use acquired sensor data, such as sensor data associated with surfaces of buildings 115 and 117, which can be compared against reference data, such as map data (e.g., 3D map data, including reflectance data) to determine a local pose. Further, a perception engine (not shown) of autonomous vehicle controller 147 may be configured to detect, classify, and predict the behavior of external objects, such as external object 112 (a “tree” and external object 114 (a “pedestrian”). Classification of such external objects may broadly classify objects as static objects, such as external object 112, and dynamic objects, such as external object 114. The localizer and the perception engine, as well as other components of the AV controller 147, collaborate to cause autonomous vehicles 109 to drive autonomously.... Localizer 368 is configured to receive sensor data from one or more sources, such as GPS data 352, wheel data, MU data 354, Lidar data 346a, camera data 340a, radar data 348a, and the like, as well as reference data 339 (e.g., 3D map data and route data). Localizer 368 integrates (e.g., fuses the sensor data) and analyzes the data by comparing sensor data to map data to determine a local pose (or position) of bidirectional autonomous vehicle 330. According to some examples, localizer 368 may generate or update the pose or position of any autonomous vehicle in real-time or near real-time)
comparing the map data to the centralized map data (see at least Kentley [C13 L50-62] Map updater 406 is configured to receive map data (e.g., from local map generator 440, sensors 460, or any other component of autonomous vehicle controller 447), and is further configured to detect deviations, for example, of map data in map data repository 405a from a locally-generated map. Vehicle data controller 408 can cause map updater 406 to update reference data within repository 405 and facilitate updates to 20, 30, and/or 40 map data. In some cases, vehicle data controller 408 can control the rate at which local map data is received into autonomous vehicle service platform 408 as well as the frequency at which map updater 406 performs updating of the map data).
However, Kentley does not explicitly teach responsive to determining that a difference between the map data and the centralized map data is less than a predetermined threshold, discarding the map data; and responsive to determining that the difference between the map data and the centralized map data is equal to or greater than the predetermined threshold, updating the centralized map data.
Arditi, in the same field as the endeavor, teaches responsive to determining that a difference between the map data and the centralized map data is less than a predetermined threshold, discarding the map data; and responsive to determining that the difference between the map data and the centralized map data is equal to or greater than the predetermined threshold, updating the centralized map data (see at least Arditi [¶ 47 and FIG. 8] At step 730, the computing system may access the HD map stored on the autonomous vehicle for map data associated with the particular location (e.g., x, y coordinates). Then at step 740, the computing system may compare the map data associated with the location (e.g., x, y coordinates) with the object detected in step 720 to determine whether the detected objects exist in the map data. For example, for each detected object, the system may check whether that object exists in the map data. In particular embodiments, the system may generate a confidence score representing the likelihood of the detected object being accounted for in the map data. The confidence score may be based on, for example, a similarity comparison of the measured size, dimensions, classification, and/or location of the detected object with known objects in the map data. At step 745, if the comparison results in a determination that the detected object(s) exists or is known in the HD map (e.g., the confidence score in the object existing in the map is higher than a threshold), then the system may not perform any map-updating operation and return to obtaining sensor data (e.g., step 710). On the other hand, if the comparison results in a determination that at least one detected object does not exist or is not known in the HD map (e.g., the confidence score in the object existing in the map is lower than a threshold), then the system may proceed with a map-updating operation).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for responsive to determining that a difference between the map data and the centralized map data is less than a predetermined threshold, discarding the map data; and responsive to determining that the difference between the map data and the centralized map data is equal to or greater than the predetermined threshold, updating the centralized map data with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the safety of the operation of vehicles by keeping their maps up to date via updating as discussed by Arditi (see at least Arditi [¶ 14] HD maps need to include highly accurate and detailed information to ensure the safe operation of autonomous vehicles).
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Kentley-Klay et al (US 11067983 B2) in view of Sergeev et al (US 20210199445 A1). Hereafter referred to as Kentley and Arditi respectively.
Regarding Claim 6 and Claim 13, Kentley teaches all limitations of the system of Claim 1 and the method of Claim 8 as set forth above. However, Kentley does not explicitly teach wherein selectively transmitting the centralized map data to the first vehicle comprises providing a first portion of the centralized map data to the first vehicle, wherein the first portion of the centralized map data comprises information regarding a route between the first location and the second location.
Sergeev, in the same field as the endeavor, teaches wherein selectively transmitting the centralized map data to the first vehicle comprises providing a first portion of the centralized map data to the first vehicle, wherein the first portion of the centralized map data comprises information regarding a route between the first location and the second location (see at least Sergeev [¶ 32, 15, 39] The rideshare service 158 can receive requests to be picked up or dropped off from passenger ridesharing application 170 and can dispatch autonomous vehicle 102 for the trip....maps, defined by a geographical area around an autonomous vehicle navigating a route, can be received and stored in shared memory, where the shared memory can be a specific physical block of RAM. Concurrent access to the map within the shared memory can be granted to downstream nodes on the autonomous vehicle as the autonomous vehicle navigates the route....In FIG. 3A, method 300 starts by receiving (302) a map defined by a geographical area around an autonomous vehicle navigating a route, which will become a map shared by multiple nodes at the same time. In some embodiments, the entire map may be too large for efficient map processing in a micro-service architecture, which relies on multiple nodes to handle different services (e.g., lidar service, camera service, etc.), and so a subset of the entire map can be received by and stored (304) in shared memory).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for selectively transmitting the centralized map data to the first vehicle comprises providing a first portion of the centralized map data to the first vehicle, wherein the first portion of the centralized map data comprises information regarding a route between the first location and the second location. with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the efficient processing of the system by only providing the section of map that is necessary for the route as discussed in Sergeev (see at least Sergeev [¶ 39] the entire map may be too large for efficient map processing in a micro-service architecture, which relies on multiple nodes to handle different services (e.g., lidar service, camera service, etc.), and so a subset of the entire map can be received by and stored (304) in shared memory).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Kentley-Klay et al (US 11067983 B2) in view of Leone et al (US 20190071067 A1). Hereafter referred to as Kentley and Leone respectively.
Regarding Claim 15, Kentley teaches all limitations of Claim 8 as set forth above. However, Kentley does not explicitly teach receiving, by the computing system and from the first vehicle, vehicle data; determining, by the computing system and based on the vehicle data, that the first vehicle is scheduled for or is in need of a particulate filter regeneration.
Leone, in the same field as the endeavor, teaches receiving, by the computing system and from the first vehicle, vehicle data; determining, by the computing system and based on the vehicle data, that the first vehicle is scheduled for or is in need of a particulate filter regeneration (see at least Leone [¶ 15-16, 67] The on-board controller may be configured to perform a control routine, such as the example routine of FIG. 3 controlling engine idle-stop based on the data received from the remote sources. The controller may also schedule regeneration of an exhaust particulate filter, such as via the control routine of FIG. 4, based on the data received from the remote sources...FIG. 1 shows example embodiment 100 of a vehicle system 110 in communication with a plurality of remote (external) sources via wireless communication 150. The remote sources may include a line of vehicles (also referred herein as fleet) 120 of vehicles travelling on a road directly ahead of the vehicle 110...The vehicles in the fleet 120 may also communicate with a network cloud 160 via wireless communication 150.... FIG. 4 shows an example method 400 that may be implemented for scheduling regeneration of an exhaust particulate filter (PF) based on traffic and road conditions data received from remote sources. The example method 400 may be part of the example method 300 as discussed in FIG. 3 and the method 400 may be carried out at step 334 of method 300).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for receiving, by the computing system and from the first vehicle, vehicle data; determining, by the computing system and based on the vehicle data, that the first vehicle is scheduled for or is in need of a particulate filter regeneration with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the health and operation of the vehicle by more quickly identifying when the filter needs regenerated.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Kentley-Klay et al (US 11067983 B2) in view of Leone et al (US 20190071067 A1), Leone et al (US 20190154453 A1), and Willis et al (EP 3640102 A1). Hereafter referred to as Kentley, Leone 067, Leone 453, and Willis respectively.
Regarding Claim 16, Kentley in view of Leone 067 teaches all limitations of Claim 15 as set forth above. However, Kentley does not explicitly teach wherein selecting the first vehicle of the plurality of vehicles for the transport request comprises:
determining that the transport request is a high load request; and
selecting the first vehicle responsive to determining that the transport request is the high load request and determining that the first vehicle is scheduled for or is in need of the particulate filter regeneration.
Willis, in the same field as the endeavor, teaches determining that the transport request is a high load request (see at least Willis [English Translation pg.9 para.5, pg.5 para.3, pg.3 para.6] an enterprise may operate a fleet of vehicles. There may be certain routes or types of routes (e.g. long haul, short haul, hot weather climate, cold weather climate, high altitude, low altitude or any combination of the same) that recur for the vehicles of the fleet. In some examples, the configuration management controller 304 is able to divide the fleet of vehicles into multiple subsets of vehicles, with different subsets of vehicles assigned to travel along respective different routes. For example, a first subset of vehicles can be assigned to travel a first route…a route (or route portion) is divided into the first route segment and the second route segment in response to the controller determining or predicting that the load condition of the vehicle in the first route segment differs from the load condition of the vehicle in the second route segment by greater than a specified load threshold (e.g., a weight of the load)...a route can be a predetermined route or a route that can change on the fly as the vehicle proceeds on its trip)
Leone 453, in the same field as the endeavor, teaches selecting the first vehicle responsive to determining that the transport request is the high load request and determining that the first vehicle is scheduled for or is in need of the particulate filter regeneration (see at least Leone [¶ 53, 58] With reference to a fourth example, shown in Table 2, the computer 110 may be programmed to identify an air filter of the vehicle 100 engine to replace, e.g., based on data received from the vehicle 100 sensor(s) 130. Upon identifying the air filter for replacement, the computer 110 may be programmed to, if possible, avoid dirt roads in the second route. In other words, the computer 110 may be programmed to determine the second route such that an amount of dust entering the air filter is minimized, e.g., selecting a route that compared to other possible routes has a shorter distance travelled on a dirt road...the computer 110 may be programmed to generate the second route based on a current time and expected vehicle 100 deployment time for a user (occupant) transportation. For example, the computer 110 may be programmed to determine an expected vehicle 100 deployment time on a first route based on historical data such as times and locations at which the vehicle 100 was used in last 30 days, e.g., a user typically requests a transportation using the vehicle 100 from a home address to the first destination (e.g., a place of work) on each workday of a week. In one example, if the computer 110 determines that navigating the vehicle 100 to the second destination may prevent the vehicle 100 from an expected deployment, then the computer 110 may be programmed to plan the vehicle 100 navigation to the second destination after the expected deployment).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for wherein selecting the first vehicle of the plurality of vehicles for the transport request comprises: determining that the transport request is a high load request; and selecting the first vehicle responsive to determining that the transport request is the high load request and determining that the first vehicle is scheduled for or is in need of the particulate filter regeneration with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of improving the operation of the vehicle by receiving and understand both its current operating parameters and its future task conditions.
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kentley-Klay et al (US 11067983 B2) in view of Abramson et al (US 20180356237 A1). Hereafter referred to as Kentley and Abramson respectively.
Regarding Claim 18, Kentley teaches all limitations of Claim 17 as set forth above. Kentley further teaches wherein generating the autonomous vehicle control signals comprises:
determining a location of the vehicle based on the map data (see at least Kentley [C6 L3-24] A localizer (not shown) of autonomous vehicle controller 147 can determine a local pose at the geographic location 111. As such, the localizer may use acquired sensor data, such as sensor data associated with surfaces of buildings 115 and 117, which can be compared against reference data, such as map data (e.g., 3D map data, including reflectance data) to determine a local pose).
However, Kentley does not explicitly teach determining a route for the vehicle based on the location of the vehicle, the first location, and the second location, wherein the route is selected based on at least one of: a distance of the route is less than a predefined distance threshold, a number of turns of the route between the first location and the second location is less than a predefined turning threshold, a load of the first route experienced between the first location and the second location is at or below a predefined maximum load threshold, or a load of the first route experience between the first location and the second location is at or above a predefined minimum load threshold.
Abramson, in the same field as the endeavor teaches determining a route for the vehicle based on the location of the vehicle, the first location, and the second location, wherein the route is selected based on at least one of: a distance of the route is less than a predefined distance threshold, a number of turns of the route between the first location and the second location is less than a predefined turning threshold, a load of the first route experienced between the first location and the second location is at or below a predefined maximum load threshold, or a load of the first route experience between the first location and the second location is at or above a predefined minimum load threshold (see at least Abramson [¶ 121] various metrics such as the determined distance and/or complexity (e.g., number of turns/instructions) and/or a lowest economic cost of the trip and/or an ecological cost of a trip can be used in lieu of or in addition to the referenced ‘shortest time’ metric in order to determine whether the increased utility is sufficiently high as compared to the decrease in familiarity (to the user) and/or increase in complexity to justify such a route choice (or re-routing choice), based upon default trade-off threshold or user threshold values provided by the user).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to have modified the system set forth in Kentley to contain a system for determining a route for the vehicle based on the location of the vehicle, the first location, and the second location, wherein the route is selected based on at least one of: a distance of the route is less than a predefined distance threshold, a number of turns of the route between the first location and the second location is less than a predefined turning threshold, a load of the first route experienced between the first location and the second location is at or below a predefined maximum load threshold, or a load of the first route experience between the first location and the second location is at or above a predefined minimum load threshold with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a modification for benefit of selecting a route that contains common characteristics of what is considered an optimal route in the art like distance and number of turns.
Regarding Claim 19, Kentley in view of Abramson teaches all limitations of Claim 18 as set forth above. Kentley further teaches wherein herein generating the autonomous vehicle control signals further comprises:
analyzing the sensor data by:
identifying one or more objects within a predetermined distance of the vehicle and performing an object recognition on the sensor data to determine one or more characteristics of the one or more objects (see at least Kentley [C6 L1-L24] As such, the localizer may use acquired sensor data, such as sensor data associated with surfaces of buildings 115 and 117, which can be compared against reference data, such as map data (e.g., 3D map data, including reflectance data) to determine a local pose. Further, a perception engine (not shown) of autonomous vehicle controller 147 may be configured to detect, classify, and predict the behavior of external objects, such as external object 112 (a “tree” and external object 114 (a “pedestrian”))
determining whether each of the one or more objects is moving and a trajectory of each of the one or more objects, and responsive to analyzing the sensor data, determining at least one correction to the route (see at least Kentley [C14 L24-65] data representing objects based on the least two subsets of sensor data may be derived at a processor. For example, data identifying static objects or dynamic objects may be derived (e.g., at a perception engine) from at least Lidar and camera data. At 508, a detected object is determined to affect a planned path, and a subset of trajectories are evaluated (e.g., at a planner) responsive to the detected object at 510…As such, a request for an alternate path may be transmitted to a teleoperator computing device at 514. Thereafter, the teleoperator computing device may provide a planner with an optimal trajectory over which an autonomous vehicle made travel. In situations, the vehicle may also determine that executing a safe-stop maneuver is the best course of action (e.g., safely and automatically causing an autonomous vehicle to a stop at a location of relatively low probabilities of danger))
the at least one correction causing the vehicle to:
change a speed of the vehicle or change a direction of the vehicle to avoid the one or more objects within the predetermined distance of the vehicle, change the speed of the vehicle or change the direction of the vehicle based on the one or more characteristics of the one or more objects, or change the speed of the vehicle or change the direction of the vehicle to avoid the trajectory of each of the one or more objects (see at least Kentley [C14 L66 to C15 L34] Perception process 666 is configured to generate static and dynamic object map data 667, which, in turn, may be transmitted to planner process 664. In some examples, static and dynamic object map data 667 may be transmitted with other data, such as semantic classification information and predicted object behavior. Planner process 664 is configured to generate trajectories data 665, which describes a number of trajectories generated by planner 664. Motion controller process uses trajectories data 665 to generate low-level commands or control signals for application to actuators 650 to cause changes in steering angles and/or velocity).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH A YANOSKA whose telephone number is (703)756-5891. The examiner can normally be reached M-F 9:00am to 5:00pm (Pacific Time).
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, Rachid Bendidi can be reached on (571) 272-4896. 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.
/JOSEPH ANDERSON YANOSKA/Examiner, Art Unit 3664
/RACHID BENDIDI/ Supervisory Patent Examiner, Art Unit 3664