DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This office action is in response to the most recently filed responses by applicants on 10/28/25.
Claims 1-6, 8-11, 14-20 are amended
Claim 18 is cancelled
Claims 21-25 are added
Claims 1-17 and 20-25 are pending
Note:
In the most recent amendment, applicants claim limitation in claim 1 recites: “identifying, by one or more processors, a number of clusters based on a number of roadside assistance vehicles; determining, by the one or more processors, cluster centers by iteratively adjusting an initial set of cluster centers corresponding to the number of clusters until sums of distances from the tracked location of each autonomous vehicle to a closest cluster center converge to a stable set of cluster centers”.
Here, the limitations are recited at such a high level of generality that are unclear. For instance, how are the number of clusters identified? Is each roadside assistance vehicle a cluster? If not how are you grouping certain vehicles in one cluster and others in another? Are you using thresholds to separate? Are you using colors of the vehicles? Are you using some other criteria to make up these groups?
Secondly, how are you determining an initial set of cluster centers? Are the initial set of cluster centers also related to the number of clusters or is there a different calculation that allows the calculation of that number? What is a stable set of cluster centers? How are you calculating that?
As such, in the amended independent claims 1, 16 and 21, the claim limitations discussed are broad and the specification does not provide enough detailed support to show to one of ordinary skill in the art what certain terms in the claim limitations mean.
In light of these notes, the amended claims, do not overcome previously presented rejections under 101 and 103. As is discussed below. This note is intended as a conversation starter to help applicants understand the examiner’s perspective. Applicants are welcome to call the examiner to discuss this further.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-17 and 20-25 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 1-15 and 22-25 is/are directed to a method which is a statutory category.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 16-17 and 19-20 is/are directed to a system which is a statutory category.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claim 21 is/are directed to a non-transitory computer readable medium which is a statutory category.
Under the 2019 PEG, Step 2A under which a claim is not “directed to” a judicial exception unless the claim satisfies a two-prong inquiry. Further, particular groupings of abstract ideas are consistent with judicial precedent and are based on an extraction and synthesis of the key concepts identified by the courts as being abstract.
With respect to the Step 2A, Prong One, the claims as drafted, and given their broadest reasonable interpretation, fall within the Abstract idea grouping of “certain methods of organizing human activity” (business relations; relationships or interactions between people). For instance, independent Claim 1 is directed to an abstract idea, as evidenced by claim limitations “tracking, a location for each autonomous vehicle of the fleet of autonomous vehicles using information received from the autonomous vehicles over time; identifying, a number of clusters based on a number of roadside assistance vehicles; determining, cluster centers by iteratively adjusting an initial set of cluster centers corresponding to the number of clusters until sums of distances from the tracked location of each autonomous vehicle to a closest cluster center converge to a stable set of cluster centers; determining, an assignment assigning respective ones of the roadside assistance vehicles to a cluster center of the stable set of cluster centers; based on the determined assignment, sending, distribution information associated with technicians of the respective ones of the roadside assistance vehicles, the distribution information enabling the technicians of the respective ones of the roadside assistance vehicles to proceed towards an assigned cluster center in order to pre-position the roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet.”
These claim limitations belong to the grouping of “certain methods of organizing human activity” because the claims are related to pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles. Managing assistance and service on the roadside for autonomous vehicles for one or more human entities involves organizing human activity based on the description of “certain methods of organizing human activity” provided by the courts. The court have used the phrase “Certain methods of organizing human activity” as —fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Independent Claims 16 and 21 is/are recite substantially similar limitations to independent claim 1 and is/are rejected under 2A for similar reasons to claim 1 above.
With respect to the Step 2A, Prong Two - This judicial exception is not integrated into a practical application. In particular, the claim recites additional elements: “A method of pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles, the method comprising: by one or more processors, to computing devices, A system for pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles, the system comprising one or more processors configured to: by one or more processors, via a network, by one or more processors, to computing devices” at a high level of generality such that it amounts to no more than: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f).
Thus, the additional elements do not integrate the abstract idea into practical application because they do not impose any meaningful limitations on practicing the abstract idea. As a result, claims 1, 16 and 21 do not provide any specifics regarding the integration into a practical application when recited in a claim with a judicial exception. See MPEP 2106.05(f).
Similarly dependent claims 2-15, 17, and 19-25 are also directed to an abstract idea under 2A, first and second prong. In the present application, all of the dependent claims have been evaluated and it was found that they all inherit the deficiencies set forth with respect to the independent claims. For instance, dependent claim 2 recite “further comprising: periodically determining an updated assignment identifying an updated stable set of cluster centers and assigning respective ones of the roadside assistance vehicles to the updated stable set of cluster centers; and sending updated distribution information to the computing devices based on the updated assignments, the updated distribution information enabling the technicians of the respective ones of the roadside assistance vehicles to proceed towards an updated assigned cluster center in order to reposition the roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet”. Dependent claims 3 recite “wherein the clustering approach involves initially setting the initial set of cluster centers to current locations of the roadside assistance vehicles” and dependent claims 4 recite “wherein the clustering approach involves determining a score based on distances between each of the autonomous vehicles and a closest one of the stable set of cluster centers”. Here, these claims offer further descriptive limitations of elements found in the independent claims which are similar to the abstract idea noted in the independent claim above.
Dependent claims 12 recites “further comprising, reassigning a roadside assistance vehicle of the second set of roadside assistance vehicles to the primary layer” in the claim limitations “roadside assistance vehicles to the primary layer”. Dependent claims 7 recites “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances” in the claim limitations “Euclidean distances, or Manhattan distances”. In the above claims, “roadside assistance vehicles to the primary layer” and “Euclidean distances, or Manhattan distances” are an additional element, but it is still being recited such that it amounts to no more than: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). As a result, Examiner asserts that dependent claims, such as dependent claims 2-15, 17, and 19-25 are also directed to the abstract idea identified above.
With respect to Step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. First, the invention lacks improvements to another technology or technical field [see Alice at 2351; 2019 IEG at 55], and lacks meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment [Alice at 2360, 2019 IEG at 55], and fails to effect a transformation or reduction of a particular article to a different state or thing [2019 IEG, 55]. For the reasons articulated above, the claims recite an abstract idea that is limited to a particular field of endeavor (MPEP § 2106.05(h)) and recites insignificant extra-solution activity (MPEP § 2106.05(g)). By the factors and rationale provided above with respect to these MPEP sections, the additional elements of the claims that fail to integrate the abstract idea into a practical application also fail to amount to “significantly more” than the abstract idea.
As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) of “A method of pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles, the method comprising: by one or more processors, to computing devices, A system for pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles, the system comprising one or more processors configured to: by one or more processors, via a network, by one or more processors, to computing devices” are insufficient to amount to significantly more. Applicants originally submitted specification describes the computer components above at least in page/ paragraph [0028]-[0035]. In light of the specification, it should be noted that the components discussed above did not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers"). In light of the specification, it should be noted that the claim limitations discussed above are merely instructions to implement the abstract idea on a computer. See MPEP 2106.05(f). (See MPEP 2106.05(f) - Mere Instructions to Apply an Exception - “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235). Mere instructions to apply an exception using computer component cannot provide an inventive concept.). The additional elements amount to no more than a recitation of generic computer elements utilized to perform generic computer functions, such as performing repetitive calculations, Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); and storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; see MPEP 2106.05(d)(II).
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent Claims 16 and 21 is/are recite substantially similar limitations to independent claim 1 and is/are rejected under 2B for similar reasons to claim 1 above.
Further, it should be noted that additional elements of the claimed invention such as claim limitations when considered individually or as an ordered combination along with the other limitations discussed above in method claim 1 also do not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers"). In light of the specification, it should be noted that the claim limitations discussed above are merely instructions to implement the abstract idea on a computer. See MPEP 2106.
Similarly, dependent claims 2-15, 17, and 19-25 also do not include limitations amounting to significantly more than the abstract idea under the second prong or 2B of the Alice framework. In the present application, all of the dependent claims have been evaluated and it was found that they all inherit the deficiencies set forth with respect to the independent claims. Further, it should be noted that the dependent claims do not include limitations that overcome the stated assertions. Here, the dependent claims recite features/limitations that include computer components identified above in part 2B of analysis of independent claims 1, 16 and 21. As a result, Examiner asserts that dependent claims, such as dependent claims 2-15, 17, and 19-25 are also directed to the abstract idea identified above.
For more information on 101 rejections, see MPEP 2106, January 2019 Guidance at https://www.govinfo.gov/content/pkg/FR-2019-01 -07/pdf/2018-28282.pdf
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-17 and 19-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nguyen et al. (US 11,285,968 B2), and further in view of Plascencia-Vega (US 2022/0319337 A1).
As per claims 1, 16 and 21: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
A method of pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles, the method comprising (Nguyen shows: col. 2, lines 30-45: The technology relates to enabling roadside assistance for autonomous vehicles, especially in situations in which such vehicles may no longer be able to make forward progress towards a destination of the vehicle and thus may require human intervention or assistance. In addition, such vehicles may not have a “driver” who is able to take control of the vehicle and/or address the reason why the vehicle requires assistance. As used herein, the phrases “requires human intervention” and “requires assistance” may refer to situations in which a vehicle's computing device or operator decides that the optimal action is to bring the vehicle to a stop despite the ability to continue making forward progress, situations where a hardware or software issue may cause the vehicle to come to a stop, or a combination thereof. Col. 3, lines 10-25: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode):
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
A system for pre-positioning roadside assistance vehicles within a service area for a fleet of autonomous vehicles, the system comprising one or more processors configured to: (Nguyen shows: col. 2, lines 30-45: The technology relates to enabling roadside assistance for autonomous vehicles, especially in situations in which such vehicles may no longer be able to make forward progress towards a destination of the vehicle and thus may require human intervention or assistance. In addition, such vehicles may not have a “driver” who is able to take control of the vehicle and/or address the reason why the vehicle requires assistance. As used herein, the phrases “requires human intervention” and “requires assistance” may refer to situations in which a vehicle's computing device or operator decides that the optimal action is to bring the vehicle to a stop despite the ability to continue making forward progress, situations where a hardware or software issue may cause the vehicle to come to a stop, or a combination thereof. Col. 3, lines 10-25: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode):
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
A non-transitory computer-readable medium storing instructions, which when executed by one or more processors of an autonomous vehicle, cause the autonomous vehicle to:
(Nguyen shows: col. 2, lines 30-45: The technology relates to enabling roadside assistance for autonomous vehicles, especially in situations in which such vehicles may no longer be able to make forward progress towards a destination of the vehicle and thus may require human intervention or assistance. In addition, such vehicles may not have a “driver” who is able to take control of the vehicle and/or address the reason why the vehicle requires assistance. As used herein, the phrases “requires human intervention” and “requires assistance” may refer to situations in which a vehicle's computing device or operator decides that the optimal action is to bring the vehicle to a stop despite the ability to continue making forward progress, situations where a hardware or software issue may cause the vehicle to come to a stop, or a combination thereof. Col. 3, lines 10-25: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode):
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
tracking, by one or more processors, a location for each autonomous vehicle of the fleet of autonomous vehicles using information received from the autonomous vehicles over time via a network
(Nguyen shows in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location;
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
identifying, by one or more processors, a number of clusters based on a number of roadside assistance vehicles
(Nguyen shows “identifying, by one or more processors, a number of … based on a number of roadside assistance vehicles” in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.
However, Reference Nguyen does not explicitly show “clustering”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
determining, by the one or more processors, cluster centers by iteratively adjusting an initial set of cluster centers corresponding to the number of clusters until sums of distances from the tracked location of each autonomous vehicle to a closest cluster center converge to a stable set of cluster centers
(Nguyen shows “determining, by the one or more processors, … centers by iteratively adjusting an initial set of … centers corresponding to the number of … until sums of … from the tracked location of each autonomous vehicle to a closest … center converge to a stable set of … centers” in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.
However, Reference Nguyen does not explicitly show “clustering” and “distances”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Plascencia-Vega shows “distances” in [0017]: In other aspects, edge vehicle designation may be based on route planning, for example, whereby vehicles leaving cluster 102 to follow alternative navigation routes may not (or may be less likely to be) designated as edge vehicles. In other some aspects, edge vehicle designations may be performed on an ad hoc basis, for example, based on individual vehicle routing and/or navigation goals, and/or environmental perceptions. In some aspects, edge vehicle designations can depend on how long a given vehicle is to remain in the platoon. For example, vehicles traveling further distances in a platoon formation may be prioritized as edge vehicles. Similarly, vehicles predicted to remain in the platoon for shorter durations (e.g., based on their routing intent) may be less likely to be designated as edge vehicles, and more likely to be placed in a rearward location in the platoon formation. In this way, edge-vehicle and platoon-position designations can reduce the frequency of edge vehicle re-assignment, as well as ensure that platoon formations are less affected as vehicles leave or depart the formation. [0037]: The perception stack 512 can detect and classify objects and determine their current and predicted locations, speeds, directions, and the like. In addition, the perception stack 512 can determine the free space around the AV 502 (e.g., to maintain a safe distance from other objects, change lanes, park the AV, etc.). The perception stack 512 can also identify environmental uncertainties, such as where to look for moving objects, flag areas that may be obscured or blocked from view, and so forth.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A); and
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
determining, by the one or more processors, an assignment assigning respective ones of the roadside assistance vehicles to a … center of the stable set of … centers
(Reference Nguyen shows in col. 3, lines 42-50: Once validation or verification is completed, the one or more server computing devices may either send an error message to the technician's client computing device or may send a confirmation to the client computing device. If a confirmation is sent, the one or more server computing devices may also send an instruction to the vehicle that requires assistance to cause the vehicle to respond according to the technician's input. Col. 10, lines 50-67 – col. 11, lines 1-5: generating simulated degraded sensor data, which may be performed by one or more processors such as the processors of one or more server computing devices 410 in order to enable roadside assistance. For instance, at block 710, a technician is assigned to a vehicle that requires assistance. In response to a report that a vehicle requires assistance, the one or more server computing devices 410 may assign a human technician to the vehicle that requires assistance again, in order to provide roadside assistance to the vehicle that requires assistance. Such assignments may be done on the basis of current availability, future availability, location, training (e.g. can this technician address this type of problem or provide this type of assistance to the vehicle), etc. for technicians which are currently working.
However, Reference Nguyen does not explicitly show “clustering.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A));
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
based on the determined assignment, sending, by the one or more processors, distribution information to computing devices associated with technicians of the respective ones of the roadside assistance vehicles, the distribution information enabling the technicians of the respective ones of the roadside assistance vehicles to proceed towards an assigned … center in order to pre-position the roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet.
(Reference Nguyen shows in col. 3, lines 42-50: Once validation or verification is completed, the one or more server computing devices may either send an error message to the technician's client computing device or may send a confirmation to the client computing device. If a confirmation is sent, the one or more server computing devices may also send an instruction to the vehicle that requires assistance to cause the vehicle to respond according to the technician's input. Col. 10, lines 50-67 – col. 11, lines 1-5: generating simulated degraded sensor data, which may be performed by one or more processors such as the processors of one or more server computing devices 410 in order to enable roadside assistance. For instance, at block 710, a technician is assigned to a vehicle that requires assistance. In response to a report that a vehicle requires assistance, the one or more server computing devices 410 may assign a human technician to the vehicle that requires assistance again, in order to provide roadside assistance to the vehicle that requires assistance. Such assignments may be done on the basis of current availability, future availability, location, training (e.g. can this technician address this type of problem or provide this type of assistance to the vehicle), etc. for technicians which are currently working.
However, Reference Nguyen does not explicitly show “clustering”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A).
As per claims 2 and 17: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
further comprising: periodically determining an updated assignment identifying an updated stable set of cluster centers and assigning respective ones of the roadside assistance vehicles to the updated stable set of cluster centers
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows the above limitations in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.
However, Reference Nguyen does not explicitly show “clustering”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)); and
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
and sending updated distribution information to the computing devices based on the updated assignments, the updated distribution information enabling the technicians of the respective ones of the roadside assistance vehicles to proceed towards an updated assigned cluster center in order to reposition the roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet.
(Reference Nguyen shows in col. 3, lines 42-50: Once validation or verification is completed, the one or more server computing devices may either send an error message to the technician's client computing device or may send a confirmation to the client computing device. If a confirmation is sent, the one or more server computing devices may also send an instruction to the vehicle that requires assistance to cause the vehicle to respond according to the technician's input. Col. 10, lines 50-67 – col. 11, lines 1-5: generating simulated degraded sensor data, which may be performed by one or more processors such as the processors of one or more server computing devices 410 in order to enable roadside assistance. For instance, at block 710, a technician is assigned to a vehicle that requires assistance. In response to a report that a vehicle requires assistance, the one or more server computing devices 410 may assign a human technician to the vehicle that requires assistance again, in order to provide roadside assistance to the vehicle that requires assistance. Such assignments may be done on the basis of current availability, future availability, location, training (e.g. can this technician address this type of problem or provide this type of assistance to the vehicle), etc. for technicians which are currently working.)
As per claim 3: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the clustering approach involves initially setting the initial set of cluster centers to current locations of the roadside assistance vehicles.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination.
However, Reference Nguyen does not explicitly show “clustering”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 4: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the clustering approach involves determining a score based on distances between each of the autonomous vehicles and a closest one of the stable set of cluster centers.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 5: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
“wherein the clustering approach includes:
iteratively determining sets of cluster centers;
scoring each set of cluster centers; and
selecting one set of cluster centers based on the scoring wherein the stable set of cluster centers corresponds to the selected one.”
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 6: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the scoring is based on distances between current locations of the autonomous vehicles and respective closest ones of the stable set of cluster centers.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 7: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances.
Reference Nguyen shows in col. 3, lines 10-22: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”. Reference Nguyen also does not show “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances.”
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. Further, Reference Plascencia-Vega shows “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances” [0062] Machine learning classification models can also be based on clustering algorithms (e.g., a Mini-batch K-means clustering algorithm), a recommendation algorithm (e.g., a Miniwise Hashing algorithm, or Euclidean Locality-Sensitive Hashing (LSH) algorithm), and/or an anomaly detection algorithm, such as a Local outlier factor. Additionally, machine-learning models can employ a dimensionality reduction approach, such as, one or more of: a Mini-batch Dictionary Learning algorithm, an Incremental Principal Component Analysis (PCA) algorithm, a Latent Dirichlet Allocation algorithm, and/or a Mini-batch K-means algorithm, etc.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 8: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
further comprising:
generating a plurality of assignments for the selected one by assigning the roadside assistance vehicles to respective cluster centers of the selected one
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 3, lines 10-22: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode.
However, Reference Nguyen does not explicitly show “clustering”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. Further, Reference Plascencia-Vega shows “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances” [0062] Machine learning classification models can also be based on clustering algorithms (e.g., a Mini-batch K-means clustering algorithm), a recommendation algorithm (e.g., a Miniwise Hashing algorithm, or Euclidean Locality-Sensitive Hashing (LSH) algorithm), and/or an anomaly detection algorithm, such as a Local outlier factor. Additionally, machine-learning models can employ a dimensionality reduction approach, such as, one or more of: a Mini-batch Dictionary Learning algorithm, an Incremental Principal Component Analysis (PCA) algorithm, a Latent Dirichlet Allocation algorithm, and/or a Mini-batch K-means algorithm, etc.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A));
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
scoring, by the one or more processors, each of the plurality of assignments
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 3, lines 10-22: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”. Reference Nguyen also does not show “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances.”
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. Further, Reference Plascencia-Vega shows “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances” [0062] Machine learning classification models can also be based on clustering algorithms (e.g., a Mini-batch K-means clustering algorithm), a recommendation algorithm (e.g., a Miniwise Hashing algorithm, or Euclidean Locality-Sensitive Hashing (LSH) algorithm), and/or an anomaly detection algorithm, such as a Local outlier factor. Additionally, machine-learning models can employ a dimensionality reduction approach, such as, one or more of: a Mini-batch Dictionary Learning algorithm, an Incremental Principal Component Analysis (PCA) algorithm, a Latent Dirichlet Allocation algorithm, and/or a Mini-batch K-means algorithm, etc.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)); and
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
selecting, by the one or more processors, one of the plurality of assignments is based on the scoring, wherein the determined assignment is the selected one of the plurality of assignments
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 9: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the scoring for a given one of the plurality of assignments is based on distances between current locations of the roadside assistance vehicles and the assigned respective ones of the cluster centers for that given one of the assignments
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 3, lines 10-22: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”. Reference Nguyen also does not show “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances.”
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. Further, Reference Plascencia-Vega shows “wherein the distances are one of driving distances, Euclidean distances, or Manhattan distances” [0062] Machine learning classification models can also be based on clustering algorithms (e.g., a Mini-batch K-means clustering algorithm), a recommendation algorithm (e.g., a Miniwise Hashing algorithm, or Euclidean Locality-Sensitive Hashing (LSH) algorithm), and/or an anomaly detection algorithm, such as a Local outlier factor. Additionally, machine-learning models can employ a dimensionality reduction approach, such as, one or more of: a Mini-batch Dictionary Learning algorithm, an Incremental Principal Component Analysis (PCA) algorithm, a Latent Dirichlet Allocation algorithm, and/or a Mini-batch K-means algorithm, etc.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 10: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the scoring involves determining whether a distance between a given one of the roadside assistance vehicles and a clustering center assigned to the given one of the roadside assistance vehicles is greater than a threshold distance
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 3, lines 10-22: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”. Reference Nguyen also does not show “threshold.”
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. Further, Reference Plascencia-Vega shows “threshold” [0039] The planning stack 516 can determine how to maneuver or operate the AV 502 safely and efficiently in its environment. For example, the planning stack 516 can receive the location, speed, and direction of the AV 502, geospatial data, data regarding objects sharing the road with the AV 502 (e.g., pedestrians, bicycles, vehicles, ambulances, buses, cable cars, trains, traffic lights, lanes, road markings, etc.) or certain events occurring during a trip (e.g., emergency vehicle blaring a siren, intersections, occluded areas, street closures for construction or street repairs, double-parked cars, etc.), traffic rules and other safety standards or practices for the road, user input, and other relevant data for directing the AV 502 from one point to another. The planning stack 516 can determine multiple sets of one or more mechanical operations that the AV 502 can perform (e.g., go straight at a specified rate of acceleration, including maintaining the same speed or decelerating; turn on the left blinker, decelerate if the AV is above a threshold range for turning, and turn left; turn on the right blinker, accelerate if the AV is stopped or below the threshold range for turning, and turn right; decelerate until completely stopped and reverse; etc.), and select the best one to meet changing road conditions and events. If something unexpected happens, the planning stack 516 can select from multiple backup plans to carry out. For example, while preparing to change lanes to turn right at an intersection, another vehicle may aggressively cut into the destination lane, making the lane change unsafe. The planning stack 516 could have already determined an alternative plan for such an event, and upon its occurrence, help to direct the AV 502 to go around the block instead of blocking a current lane while waiting for an opening to change lanes.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claims 11 and 19: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
using, by the one or more processors, the clustering approach to determine a second assignment identifying a plurality of second cluster centers and respective ones of a second set of roadside assistance vehicles assigned to a secondary layer, wherein the clustering approach iteratively adjusts a second initial set of cluster centers corresponding to a number of roadside assistance vehicles in the second set until sums of distances from the tracked location of each autonomous vehicle to a closest cluster center converge to a second stable set of cluster centers; and
(Nguyen shows: col. 2, lines 30-45: The technology relates to enabling roadside assistance for autonomous vehicles, especially in situations in which such vehicles may no longer be able to make forward progress towards a destination of the vehicle and thus may require human intervention or assistance. In addition, such vehicles may not have a “driver” who is able to take control of the vehicle and/or address the reason why the vehicle requires assistance. As used herein, the phrases “requires human intervention” and “requires assistance” may refer to situations in which a vehicle's computing device or operator decides that the optimal action is to bring the vehicle to a stop despite the ability to continue making forward progress, situations where a hardware or software issue may cause the vehicle to come to a stop, or a combination thereof. Col. 3, lines 10-25: When a vehicle requires assistance, this may be referred to as a “service interruption.” In such cases, one or more server computing devices which monitor the state of a fleet of vehicles may assign a human technician to the vehicle that requires assistance in order to provide roadside assistance. Such assignments may be done on the basis of current availability, future availability, location, training, etc. for technicians which are currently working. Once a technician is assigned to a vehicle that requires assistance, the technician must be able to navigate to the vehicle that requires assistance, enter the vehicle, disengage the autonomous driving mode of the vehicle, and control the vehicle manually and/or reengage the autonomous driving mode). (Nguyen shows the above limitations in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.
However, Reference Nguyen does not explicitly show “clustering”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A); and
Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
sending, by the one or more processors, second distribution information to computing devices associated with technicians of the second set of roadside assistance vehicles, the second distribution information enabling the technicians of the second set of roadside assistance vehicles to proceed towards an assigned cluster center of the second stable set of cluster centers in order to pre-position the second set of roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
(Reference Nguyen shows in col. 3, lines 42-50: Once validation or verification is completed, the one or more server computing devices may either send an error message to the technician's client computing device or may send a confirmation to the client computing device. If a confirmation is sent, the one or more server computing devices may also send an instruction to the vehicle that requires assistance to cause the vehicle to respond according to the technician's input. Col. 10, lines 50-67 – col. 11, lines 1-5: generating simulated degraded sensor data, which may be performed by one or more processors such as the processors of one or more server computing devices 410 in order to enable roadside assistance. For instance, at block 710, a technician is assigned to a vehicle that requires assistance. In response to a report that a vehicle requires assistance, the one or more server computing devices 410 may assign a human technician to the vehicle that requires assistance again, in order to provide roadside assistance to the vehicle that requires assistance. Such assignments may be done on the basis of current availability, future availability, location, training (e.g. can this technician address this type of problem or provide this type of assistance to the vehicle), etc. for technicians which are currently working.).
As per claims 12 and 13: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
“reassigning a roadside assistance vehicle of the second set of roadside assistance vehicles to the primary layer.
further comprising, reassigning a roadside assistance vehicle of the first set of roadside assistance vehicles to the secondary layer.”
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Regarding the claim limitations above, Reference Nguyen shows in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.
However, Reference Nguyen does not explicitly show “re-assigning”. Reference Plascencia-Vega shows “re-assigning” at least in [0017] In some approaches, edge-vehicle designations and processing responsibilities can be planned by a fleet coordinator or fleet management system, for example, based on perceived traffic dynamics, such as based on the position and/or behavior of non-cluster vehicles 106. Edge vehicle designations may also be determined on an ad hoc basis, for example, based on negotiation/consensus process performed between one or more vehicles comprising AV cluster 102. Irrespective of the coordinating entity, edge vehicles 104A may be designated based on their location within cluster 102 upon cluster formation. Additionally, vehicles 104A be designated as edge vehicles based on their sensor and/or computing abilities; for example, AVs with better or more capable sensing capabilities may be designated as edge vehicles 104A, and thereby provisioned with some or all of the perception and/or planning functions required by one or more other vehicles (e.g., AVs 104B). In other aspects, edge vehicle designation may be based on route planning, for example, whereby vehicles leaving cluster 102 to follow alternative navigation routes may not (or may be less likely to be) designated as edge vehicles. In other some aspects, edge vehicle designations may be performed on an ad hoc basis, for example, based on individual vehicle routing and/or navigation goals, and/or environmental perceptions. In some aspects, edge vehicle designations can depend on how long a given vehicle is to remain in the platoon. For example, vehicles traveling further distances in a platoon formation may be prioritized as edge vehicles. Similarly, vehicles predicted to remain in the platoon for shorter durations (e.g., based on their routing intent) may be less likely to be designated as edge vehicles, and more likely to be placed in a rearward location in the platoon formation. In this way, edge-vehicle and platoon-position designations can reduce the frequency of edge vehicle re-assignment, as well as ensure that platoon formations are less affected as vehicles leave or depart the formation.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)
As per claim 14: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
wherein the distribution information for a particular roadside assistance vehicle includes instructions to display a map and turn-by-turn directions to an area corresponding to the assigned cluster center for that particular roadside assistance vehicle.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 1, lines 52-62: In one example, the method also includes sending a notification to the remote computing device indicating that the technician has been assigned to the vehicle. In another example, the method also includes sending information to the remote computing device identifying a location of the vehicle. In another example, the method also includes sending information to the remote computing device including a route and driving instructions for the remote computing device to reach a location of the vehicle. In this example, the method also includes sending to the remote computing device an estimated time of arrival for the remote computing device to reach the location of the vehicle. Col. 2, lines 62-67 – col. 3, lines 1-10: As another instance, if the computing devices detect input of a particular force at certain user inputs of the vehicle (e.g. brake pedal, accelerator pedal, steering wheel, pullover button, emergency stopping button etc.), devices may stop the vehicle (e.g. pull the vehicle over or stop immediately), causing the vehicle to require assistance. As another instance, the vehicle's computing devices receive instructions from a remote computing device to stop or pull over. For example, in certain circumstances, a human operator may determine that it is no longer safe or practical for a vehicle to continue operating in an autonomous driving mode. This may occur for any number of reasons, such as if the passenger requests assistance (via a user input of the vehicle and/or his or her mobile phone), etc.
As per claims 15 and 20: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
further comprising:
assigning one of the roadside assistance vehicles to provide assistance to one of the autonomous vehicles
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 1, lines 52-62: In one example, the method also includes sending a notification to the remote computing device indicating that the technician has been assigned to the vehicle. In another example, the method also includes sending information to the remote computing device identifying a location of the vehicle. In another example, the method also includes sending information to the remote computing device including a route and driving instructions for the remote computing device to reach a location of the vehicle. In this example, the method also includes sending to the remote computing device an estimated time of arrival for the remote computing device to reach the location of the vehicle. Col. 2, lines 62-67 – col. 3, lines 1-10: As another instance, if the computing devices detect input of a particular force at certain user inputs of the vehicle (e.g. brake pedal, accelerator pedal, steering wheel, pullover button, emergency stopping button etc.), devices may stop the vehicle (e.g. pull the vehicle over or stop immediately), causing the vehicle to require assistance. As another instance, the vehicle's computing devices receive instructions from a remote computing device to stop or pull over. For example, in certain circumstances, a human operator may determine that it is no longer safe or practical for a vehicle to continue operating in an autonomous driving mode. This may occur for any number of reasons, such as if the passenger requests assistance (via a user input of the vehicle and/or his or her mobile phone), etc.;
Regarding the claim limitations below, Reference Nguyen shows:
“removing the one of the autonomous vehicles from a set of the autonomous vehicles; and
after removing the one of the autonomous vehicles from the set of autonomous vehicles, updating the assignments by determining a new stable set of cluster centers based on updated locations of any autonomous vehicles remaining in the set of autonomous vehicles.”
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Regarding the claim limitations above, Reference Nguyen does not explicitly show “removing” in the claim limitations above. Reference Plascencia-Vega in [0017] In some approaches, edge-vehicle designations and processing responsibilities can be planned by a fleet coordinator or fleet management system, for example, based on perceived traffic dynamics, such as based on the position and/or behavior of non-cluster vehicles 106. Edge vehicle designations may also be determined on an ad hoc basis, for example, based on negotiation/consensus process performed between one or more vehicles comprising AV cluster 102. Irrespective of the coordinating entity, edge vehicles 104A may be designated based on their location within cluster 102 upon cluster formation. Additionally, vehicles 104A be designated as edge vehicles based on their sensor and/or computing abilities; for example, AVs with better or more capable sensing capabilities may be designated as edge vehicles 104A, and thereby provisioned with some or all of the perception and/or planning functions required by one or more other vehicles (e.g., AVs 104B). In other aspects, edge vehicle designation may be based on route planning, for example, whereby vehicles leaving cluster 102 to follow alternative navigation routes may not (or may be less likely to be) designated as edge vehicles. In other some aspects, edge vehicle designations may be performed on an ad hoc basis, for example, based on individual vehicle routing and/or navigation goals, and/or environmental perceptions. In some aspects, edge vehicle designations can depend on how long a given vehicle is to remain in the platoon. For example, vehicles traveling further distances in a platoon formation may be prioritized as edge vehicles. Similarly, vehicles predicted to remain in the platoon for shorter durations (e.g., based on their routing intent) may be less likely to be designated as edge vehicles, and more likely to be placed in a rearward location in the platoon formation. In this way, edge-vehicle and platoon-position designations can reduce the frequency of edge vehicle re-assignment, as well as ensure that platoon formations are less affected as vehicles leave or depart the formation. [0018] As discussed in further detail below, the dissolution of clusters (e.g., cluster 102) can also be facilitated by a remote fleet management system, and/or based on a consensus reached by AVs in cluster. In some aspects, behaviors of non-cluster participant vehicles 106 may cause one or more AVs to leave cluster 102, for example, to ensure that safety and/or routing objectives remain uncompromised. For example, one or more of clustering AVs 104 may become detached or separated from cluster 102 if a non-cluster participant 106 interferes with the traffic flow of cluster 102 and the detachment of one or more vehicles 104 is necessary to ensure safety and/or navigation efficiency. [0019] FIGS. 2A-2B conceptually illustrates an example system 200 for coordinating AV platooning, according to some aspects of the disclosed technology. At block 202 rider/user driving habits are collected for analysis by a fleet coordination system (block 204). The driving habits can include historic ride data associated with various user profiles of a ride hailing system. By way of example, the historic ride data can include pick-up location information, drop-off location information, route information, and/or timestamp information for various rides taken by one or more users (e.g., departure time information). The historic ride data can be used by a fleet coordination system to identify current or future times for which AV platooning/clustering may be implemented. [0037] Perception stack 512 can enable the AV 502 to “see” (e.g., via cameras, LIDAR sensors, infrared sensors, etc.), “hear” (e.g., via microphones, ultrasonic sensors, RADAR, etc.), and “feel” (e.g., pressure sensors, force sensors, impact sensors, etc.) its environment using information from the sensor systems 504-508, the mapping and localization stack 514, the HD geospatial database 522, other components of the AV, and other data sources (e.g., the data center 550, the client computing device 570, third-party data sources, etc.). The perception stack 512 can detect and classify objects and determine their current and predicted locations, speeds, directions, and the like. In addition, the perception stack 512 can determine the free space around the AV 502 (e.g., to maintain a safe distance from other objects, change lanes, park the AV, etc.). The perception stack 512 can also identify environmental uncertainties, such as where to look for moving objects, flag areas that may be obscured or blocked from view, and so forth.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A).
As per claim 22: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
snapping, by the one or more processors, each determined cluster center to a drivable location based on map information
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows the above limitations in col. 5, lines 33-67 – col. 6, lines 1-20: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. In this regard, the planning system 168, routing system 166, and/or data 134 may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, vegetation, or other such objects and information. In addition, the map information may identify area types such as constructions zones, school zones, residential areas, parking lots, etc. The map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. While the map information may be an image-based map, the map information need not be entirely image based (for example, raster). For example, the map information may include one or more road graphs or graph networks of information such as roads, lanes, intersections, and the connections between these features which may be represented by road segments. Each feature may be stored as graph data and may be associated with information such as a geographic location and whether or not it is linked to other related features, for example, a stop sign may be linked to a road and an intersection, etc. In some examples, the associated data may include grid-based indices of a road graph to allow for efficient lookup of certain road graph features. Positioning system 170 may be used by computing devices 110 in order to determine the vehicle's relative or absolute position on a map and/or on the earth. The positioning system 170 may also include a GPS receiver to determine the device's latitude, longitude and/or altitude position relative to the Earth. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.
However, Reference Nguyen does not explicitly show “clustering”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Nguyen shows in col. 3, lines 42-50: Once validation or verification is completed, the one or more server computing devices may either send an error message to the technician's client computing device or may send a confirmation to the client computing device. If a confirmation is sent, the one or more server computing devices may also send an instruction to the vehicle that requires assistance to cause the vehicle to respond according to the technician's input. Col. 10, lines 50-67 – col. 11, lines 1-5: generating simulated degraded sensor data, which may be performed by one or more processors such as the processors of one or more server computing devices 410 in order to enable roadside assistance. For instance, at block 710, a technician is assigned to a vehicle that requires assistance. In response to a report that a vehicle requires assistance, the one or more server computing devices 410 may assign a human technician to the vehicle that requires assistance again, in order to provide roadside assistance to the vehicle that requires assistance. Such assignments may be done on the basis of current availability, future availability, location, training (e.g. can this technician address this type of problem or provide this type of assistance to the vehicle), etc. for technicians which are currently working.)
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A).
As per claim 23: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
determining, by the one or more processors, a compliance metric that scores how well each technician meets expectations for proceeding to respective assigned cluster centers by tracking a location of the computing devices or the roadside assistance vehicles.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination.
However, Reference Nguyen does not explicitly show “clustering”. Nguyen does not explicitly show “metric”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources.
Reference Plascencia-Vega shows “metric” in the claim above at least in [0036] AV 502 can additionally include a local computing device 510 that is in communication with the sensor systems 504-508, the mechanical systems 530-538, the data center 550, and the client computing device 570, among other systems. The local computing device 510 can include one or more processors and memory, including instructions that can be executed by the one or more processors. The instructions can make up one or more software stacks or components responsible for controlling the AV 502; communicating with the data center 550, the client computing device 570, and other systems; receiving inputs from riders, passengers, and other entities within the AVs environment; logging metrics collected by the sensor systems 504-508; and so forth. In this example, the local computing device 510 includes a perception stack 512, a mapping and localization stack 514, a planning stack 516, a control stack 518, a communications stack 520, an HD geospatial database 522, and an AV operational database 524, among other stacks and systems.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claims 24: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
tracking, by the one or more processors, a location of each roadside assistance vehicles; and in response to detecting a roadside assistance vehicle has deviated from a route towards a respective assigned cluster center, transferring a notification to a respective computing device associated with a respective technician, wherein the notification instructs the respective technician back to the route.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. Col. 7, lines 17-54: In other instances, the features may be input into one or more detection system software modules, such as a traffic light detection system software module configured to detect the states of known traffic signals, a school bus detection system software module configured to detect school busses, construction zone detection system software module configured to detect construction zones, a detection system software module configured to detect one or more persons (e.g. pedestrians) directing traffic, a traffic accident detection system software module configured to detect a traffic accident, an emergency vehicle detection system software module configured to detect emergency vehicles, etc. Each of these detection system software modules may input sensor data generated by the perception system 172 and/or one or more sensors (and in some instances, map information for an area around the vehicle) into various models which may output a likelihood of a certain traffic light state, a likelihood of an object being a school bus, an area of a construction zone, a likelihood of an object being a person directing traffic, an area of a traffic accident, a likelihood of an object being an emergency vehicle, etc., respectively … Detected objects, predicted future behaviors, various likelihoods from detection system software modules, the map information identifying the vehicle's environment, position information from the positioning system 170 identifying the location and orientation of the vehicle, a destination for the vehicle as well as feedback from various other systems of the vehicle may be input into a planning system software module of the planning system 168. The planning system may use this input to generate trajectories for the vehicle to follow for some brief period of time into the future based on a current route of the vehicle generated by a routing module of the routing system 166. A control system software module of the computing devices 110 may be configured to control movement of the vehicle, for instance by controlling braking, acceleration and steering of the vehicle, in order to follow a trajectory.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
As per claim 25: Regarding the claim limitations below, Reference Nguyen in view of Plascencia-Vega shows:
authenticating, by the one or more processors, each technician with a server via an application on respective computing devices associated with each technician or another client computing device of a respective roadside assistance vehicle associated with each technician.
(*”Clustering” in the above claims has been shown using the combination of Reference Nguyen in view of Plascencia-Vega and is incorporated in this dependent claim from the independent claim above.
Reference Nguyen shows in col. 5, lines 32 – 40: Planning system 168 may be used by computing devices 110 in order to determine and follow a route generated by a routing system 166 to a location. For instance, the routing system 166 may use map information to determine a route from a current location of the vehicle to a drop off location. The planning system 168 may periodically generate trajectories, or short-term plans for controlling the vehicle for some period of time into the future, in order to follow the route (a current route of the vehicle) to the destination. Col. 3, lines 22-40: A technician may receive information at the client computing device via an application or web portal. For instance, the technician may be required to login to the application and/or otherwise authenticate his or herself Thereafter, the application may provide notifications and information to the technician about assigned vehicles. This information may be provided to the client computing device by the one or more server computing devices as push notifications. Col. 11, lines 20-42: A technician may receive information at the client computing device via an application or web portal. For instance, the technician may be required to login to the application and/or otherwise authenticate himself or herself. Thereafter, the application may provide notifications (e.g. “You have been assigned to respond to a vehicle”) and information to the technician about the state of assigned vehicles for which the technician can provide roadside assistance. The information may include the reason that a vehicle requires assistance (e.g., a stationary obstacle, low tire pressure, software or hardware issue, pullover initiated by passenger, pullover initiated by a remote computing device), location of the vehicle, details about the location, a route and driving directions from the client computing device's current location to the vehicle, an estimated time of arrival for the client computing device to reach the vehicle, the passenger state of the vehicle (whether there are passengers and if the car can be hailed for another trip, though the default may be “not hailable” when a vehicle requires assistance), the current gear of the vehicle (e.g. park, drive, reverse), as well as the driving mode or other state of the vehicle (e.g. whether the vehicle is still operating autonomously, etc.), as well as instructions for actions to take upon arrival at the vehicle. Col. 13, lines 34-43: The “authorize” option 632 may enable the technician to request that the vehicle enter a state in which the technician may disengage the autonomous driving mode, or rather, switch from the autonomous driving mode to a manual driving mode. Having this option in the application eliminates the need for the technician to physically connect another device to the vehicle in order to disengage the autonomous driving mode which can add several minutes onto a service interruption, which can be annoying to any passengers.
However, Reference Nguyen does not explicitly show “clustering”. Reference Nguyen also does not show “closest”. Reference Nguyen also does not show “scoring”.
Reference Plascencia-Vega shows clustering at least in [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026]: the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV. [0038] Mapping and localization stack 514 can determine the AVs position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 522, etc.). For example, in some embodiments, the AV 502 can compare sensor data captured in real-time by the sensor systems 504-508 to data in the HD geospatial database 522 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 502 can focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 502 can use mapping and localization information from a redundant system and/or from remote data sources. Reference Plascencia-Vega shows “closest” at least in [0020] At block 206, the fleet coordination system identifies one or more AV platooning candidates, for example, based on similarities (overlaps) in routes taken between pick-up and drop-off destinations. By way of example, if two or more AVs are identified by the coordination system to be proximately located on a similar roadway, and traveling in the same direction, then the fleet coordination system can generate and send commands necessary to initiate platooning (block 206). As illustrated in the example of FIG. 2A, fleet coordination activities can also take into account the clustering intent of individual AVs 208 (e.g., AV1 208A, AV2 208B, and AV3 208C). For example, planning and sensory information generated/gathered by each AV can be used by the fleet coordination system to determine if and when platooning can be safely and efficiently executed. Depending on the desired implementation, portions of the platoon coordination process may be performed on or at individual AVs, and/or shared with the fleet coordination system. Additional aspects relating to platooning/clustering operations are discussed in further detail with respect to FIGS. 3A and 3B, below. Reference Plascencia-Vega shows “scoring” at least in [0023] FIGS. 3A-B illustrates steps of a process 300 for implementing an AV platooning process, according to some aspects of the disclosed technology. Process 300 begins with step 302 in which one or more virtual/potential AV clusters are determined (predicted) based on historic AV route data. Potential AV clusters may be calculated/predicted (e.g., by a fleet management system) based on historic ride patterns associated with various map regions and/or ride service users (block 304). For example, if AV routing patterns indicate that multiple AVs are likely to be traveling along a common route the same time (or approximately the same time), potential AV clusters can be computed to provide associations between two or more AV members of the potential cluster/platoon. [0024] Pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons. By way of example, pre-calculations of AV clusters can be used to help geographically disperse AVs in a manner that will facilitate ride pick-up and platooning. [0026] Subsequently, the fleet management system can poll individual AVs for clustering intent (block 306). As illustrated, polling can also be performed based on the pre-calculated clusters (block 304). For example, specific AVs associated with a predicted AV cluster may be polled more frequently, or may be polled more (or less) frequently at specific times based on historic routing data and/or the location/navigational operations of the specific AV.
Reference Nguyen and Reference Plascencia-Vega are analogous prior art to the claimed invention because the references generally relate to field of managing autonomous vehicles. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Plascencia-Vega, particularly the ability to cluster location information as is discussed in [0024]-[0026], [0038], in the disclosure of Reference Nguyen, particularly in the determining an assignment location as is discussed in col. 5, lines 33-67 – col. 6, lines 1-20, in order to provide for a system that pre-calculating cluster potentials can help prepare the fleet management system to perform tasks necessary to assemble AV clusters/platoons [0024] so that the process of managing autonomous vehicles can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar managing autonomous vehicles field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Nguyen in view of Reference Plascencia-Vega, the results of the combination were predictable (MPEP 2143 A)).
Response to Arguments
Applicants’ arguments are moot in view of the new grounds of rejection necessitated by the amendments made to previously presented claims.
Applicant’s Argument #1
Applicants argue on page(s) 9-11 of applicants remarks that “The claimed invention, as presently amended, is not a mental process and cannot, as a practical matter, be performed by the human mind. "The mental process grouping is not without limits. Examiners are reminded not to expand this grouping in a manner that encompasses claim limitations that cannot practically be performed in the human mind." (See U.S. Patent and Trademark Office, Deputy Commissioner Charles Kim, Reminders on Evaluating Subject Matter Eligibility of Claims under 35 U.S.C. § 101 (Aug. 4, 2025)) …. Real-time tracking of autonomous vehicles is inherently rooted in computer and sensor technology and has no counterpart in human mental processes.” (see applicants remarks for more details).
Response to Argument #1
Applicants' arguments have been fully considered; however, the examiner respectfully disagrees.
The claims are directed to certain methods of organizing human activity (see 101 rejection above, 2A prong 1) and merely use a computer to improve the performance of that determination—not the performance of a computer. (See MPEP 2106.05(a)(II)(i); A commonplace business method or mathematical algorithm being applied on a general-purpose computer, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)).
Applicants are arguing that the amended claims are not mental processes. However, it should be noted that the claim limitations are simply performing steps, for instance, the “tracking, by one or more processors,….”. Here, the tracking is being performed “by one or more processors” but this limitation is recited at a very high level of generality. The limitation is so broad that it can be easily interpreted to be a human using his gaze to track and then enter it into a computer processor.
MPEP 2106.05f - Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363
MPEP 2106.05(f) iii. A process for monitoring audit log data that is executed on a general-purpose computer where the increased speed in the process comes solely from the capabilities of the general-purpose computer, FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016).
Applicant’s Argument #2
Applicants argue on page(s) 11-13 of applicants remarks that “The Examiner's assertion that the claims are directed to "organizing human activity" also mischaracterizes the invention. The claims are not focused on scheduling or managing people, but rather on technically determining where to locate roadside assistance vehicles based on real-time machine-generated data from a fleet of autonomous vehicles. The claimed method operates autonomously and algorithmically-using processors, clustering algorithms, and network communications-to solve a technological problem: how to efficiently pre-position support vehicles in response to continuous, dynamic changes in vehicle locations. This stands in contrast to cases involving "fundamental economic practices" or "managing interpersonal relationships." Here, any human involvement (e.g., technicians receiving distribution data) occurs after the claimed computing process and merely reflects the use of the system's output-not the focus of the claims themselves. The invention's focus is on how the computer system performs the data processing and clustering, not on how humans are managed or organized.” (see applicants remarks for more details).
Response to Argument #2
Applicants' arguments have been fully considered; however, the examiner respectfully disagrees.
Applicants recite in claim 1: “tracking…., identifying…., determining…., and sending..” The sending limitation recites:” based on the determined assignment, sending, by the one or more processors, distribution information to computing devices associated with technicians of the respective ones of the roadside assistance vehicles, the distribution information enabling the technicians of the respective ones of the roadside assistance vehicles to proceed towards an assigned cluster center in order to pre-position the roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet.”
As is recited in the claim, the claim is simply inputting information, processing information and then sending the information to a human technician to perform a task.
Applicant’s Argument #3
Applicants argue on page(s) 11-13 of applicants remarks that “The claimed method further improves computer and network functionality by enabling a computing system to determine optimal pre-positioning of roadside assistance vehicles based on real-time autonomous vehicle movement, thus reducing response times and increasing system efficiency. This is a technological improvement in the field of autonomous fleet management, and not merely an abstract idea applied on a computer. (See DDR Holdings, LLC V. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014)).” (see applicants remarks for more details).
Response to Argument #3
Applicants' arguments have been fully considered; however, the examiner respectfully disagrees.
Applicants recite in claim 1: “tracking…., identifying…., determining…., and sending..” The sending limitation recites:” based on the determined assignment, sending, by the one or more processors, distribution information to computing devices associated with technicians of the respective ones of the roadside assistance vehicles, the distribution information enabling the technicians of the respective ones of the roadside assistance vehicles to proceed towards an assigned cluster center in order to pre-position the roadside assistance vehicles to be ready to provide roadside assistance as needed to the autonomous vehicles of the fleet.”
As is recited in the claim, the claim is simply inputting information, processing information and then sending the information to a human technician to perform a task.
It is unclear how this is providing an improvement to technology? Applicants are simply solving a business problem of assigning tasks to technicians of servicing autonomous vehicles by telling them where to go.
Applicant’s Argument #4
Applicants argue on page(s) 13-16 of applicants remarks that “The Office Action states that Nguyen "does not explicitly show "clustering" and cites to Plascenica-Vega. (See Office Action, pg. 13). Although Plascenica-Vega discusses clustering or platooning autonomous vehicles, the clustering discussed in Plascenica-Vega is distinct from the clustering approach recited in claim 1. For example, in Plascenica-Vega "autonomous vehicles traveling overlapping routes" may form "closely spaced vehicle clusters," to "improve fuel improv[e] aerodynamic performance promote greater energy efficiency by economy enabling the distribution of certain AV computational tasks (e.g., perception and/or planning processes) between cluster members." (See Plascenica-Vega, [0012]). In contrast, the clustering approach recited in the claims identifies cluster centers for the roadside assistance vehicles "based on distances between each of the autonomous vehicles and a closest one of the cluster locations," to optimize "response times for roadside assistance if a particular autonomous vehicle of the fleet requires assistance," (See Specification, as published [0004] and [0033]). Furthermore, Plascenica-Vega clusters are identified based on overlapping routes and does not involve "identifying a number of clusters corresponding to a number of the roadside assistance vehicles" as claimed.” (see applicants remarks for more details).
Response to Argument #4
Applicants' arguments have been fully considered; however, the examiner respectfully disagrees.
Applicants claim limitation in claim 1 recites: “identifying, by one or more processors, a number of clusters based on a number of roadside assistance vehicles; determining, by the one or more processors, cluster centers by iteratively adjusting an initial set of cluster centers corresponding to the number of clusters until sums of distances from the tracked location of each autonomous vehicle to a closest cluster center converge to a stable set of cluster centers”.
Here, the limitations are recited at such a high level of generality that are unclear. For instance, how are the number of clusters identified? Is each roadside assistance vehicle a cluster? If not how are you grouping certain vehicles in one cluster and others in another? Are you using thresholds to separate? Are you using colors of the vehicles? Are you using some other criteria to make up these groups?
Secondly, how are you determining an initial set of cluster centers? Are the initial set of cluster centers also related to the number of clusters or is there a different calculation that allows the calculation of that number? What is a stable set of cluster centers? How are you calculating that?
These are just a few of the many questions that are unanswered in the above limitation. The limitation is so broadly recited that the currently cited prior art still reads on the amended claims, because as admitted by applicants Plascenica-Vega is performing the step of clustering and as far as one of ordinary skill in the art can tell based on the broad claims that is what the current claims are doing as well.
Additionally, the difference identified by applicants, particularly the argument that “In contrast, the clustering approach recited in the claims identifies cluster centers for the roadside assistance vehicles "based on distances between each of the autonomous vehicles and a closest one of the cluster locations," to optimize "response times for roadside assistance if a particular autonomous vehicle of the fleet requires assistance,"” is not recited in the claim. Also, the difference that applicants are arguing can simply be argued as an intended use for the clustering task performed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NPL Reference:
M. A. Hoque, R. Hasan and R. Hasan, "R-CAV: On-Demand Edge Computing Platform for Connected Autonomous Vehicles," 2021 IEEE 7th World Forum on Internet of Things (WF-IoT), New Orleans, LA, USA, 2021, pp. 65-70, Doi: 10.1109/WF-IoT51360.2021.9595160.
Connected Autonomous Vehicles (CAVs) have achieved significant improvements in recent years. The CAVs can share sensor data to improve autonomous driving performance and enhance road safety. CAV architecture depends on roadside edge servers for latency-sensitive applications. The roadside edge servers are equipped with high-performance embedded edge computing devices that perform calculations with low power requirements. As the number of vehicles varies over different times of the day and vehicles can request for different CAV applications, the computation requirements for roadside edge computing platform can also vary. Hence, a framework for dynamic deployment of edge computing platforms can ensure CAV applications’ performance and proper usage of the devices. In this paper, we propose R-CAV – a framework for drone-based roadside edge server deployment that provides roadside units (RSUs) based on the computation requirement. Our proof-of-concept implementation for object detection algorithm using Nvidia Jetson nano demonstrates the proposed framework's feasibility. We posit that the framework will enhance the intelligent transport system vision by ensuring CAV applications’ quality of service.
Foreign Reference:
(JP 7116164 B2) This reference discloses a user (e.g., passenger) may request vehicle service from an entity such as a service provider that maintains a fleet of vehicles, including autonomous vehicles. The service provider obtains information about the passenger's current location and allows the passenger to be within proximity of a location where multiple autonomous vehicles will stop to provide services to the passenger (e.g., a location or event venue). within an offense, near a vehicle queue location, etc.). If the passenger is within proximity of such a location, the service provider can initiate a passenger matching service for the passenger rather than going through the typical dispatch process. In the passenger matching service, passengers can be directed to select an available autonomous vehicle. After a passenger selects an available autonomous vehicle (e.g., approaches or enters an available vehicle), the autonomous vehicle can then be matched to the passenger, which then responds to the request Passenger service request data can be provided to provide the requested service. Enabling such rider-initiated matching in areas with high rider density, such as after events, during peak passenger hours, and/or equivalent, provides improved vehicle utilization and passenger experience can do.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NANCY PRASAD whose telephone number is (571)270-3265. The examiner can normally be reached M-F: 8:00 AM - 4:30 PM EST.
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, Patricia Munson can be reached at (571)270-5396. 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.
/N.N.P/Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624