Patent Description:
Autonomous vehicles, such as vehicles that do not require a human driver, can be used to aid in the transport of passengers or items from one location to another. Such vehicles may operate in a fully autonomous mode where passengers may provide some initial input, such as a pickup or destination location, and the vehicle maneuvers itself to that location.

When a person (or user) wants to be physically transported between two locations via a vehicle, they may use any number of transportation services. To date, these services typically involve a human driver who is given dispatch instructions to a location to pick up the user. In some cases, a person may inadvertently enter the wrong vehicle. When there is a human driver, he or she may quickly communicate with that person in order to confirm that the person is in the correct vehicle, for instance by confirming the passenger's destination. However, in some instances, the person may inadvertently confirm incorrect information. Correcting such mistakes in the case of autonomous vehicles which do not have a human driver can be particularly difficult.

<CIT> discloses technology for operating a fleet of autonomous vehicles. A request for a taxi service may be received from a mobile device. The request may include a current location of the mobile device. They request may indicate that the taxi service is to be performed at a current time. An autonomous vehicle may be selected from the fleet of autonomous vehicles to perform the taxi service based in part on an availability of the autonomous vehicle and a proximity between the autonomous vehicle and the current location of the mobile device. Instructions may be provided to the autonomous vehicle to perform the taxi service according to the request. The autonomous vehicle may be configured to provide commands to drive the autonomous vehicle to the current location of the mobile device in order to perform the taxi service.

As noted above, passenger pickup and drop off for self-driving vehicles can be challenging due to the difficulties involved in communicating information between people and the computing devices that control these vehicles. Moreover, in situations where there are multiple passengers waiting to be picked up by multiple vehicles, it can be difficult for those passengers to recognize their vehicle and for the computing devices of the vehicle to recognize an assigned passengers. In addition, people can make mistakes, for instance, sometimes entering a vehicle assigned to another passenger. Even with precautions, such as asking the passenger to confirm their destination once in the vehicle can fail given the tendency for people entering a vehicle to be in a rush to get where they were going and act impulsively. Thus, while it is important to be able to ensure that the assigned passenger enters the correct vehicle, the issue can become a challenge to address once a different passenger has entered the wrong vehicle by mistake.

Typically, a passenger would use his or her client computing device (for instance, mobile phone) to request a vehicle using an application on the client computing device. The request may include a pickup location as well as a destination location. In response, a central dispatching service or server would dispatch a vehicle to pick up that passenger at the pickup location. Once the vehicle is within a certain distance of that pickup location, the computing devices may look for an appropriate place to stop and allow the passenger to enter the vehicle. This pickup may also involve authenticating a client device of the passenger. Once the passenger enters, the computing devices may begin to maneuver the vehicle towards the destination.

Of course, once a passenger enters the vehicle, especially in situations where there are multiple passengers waiting for such vehicles in the same area (such as a train station, movie theater, airport, mall, etc.), the computing devices must determine whether the passenger who enters the vehicle is the passenger who was actually assigned to the vehicle. In order to do so, the vehicle's computing devices may use information from the client computing device of the passenger within the vehicle as well as that of the assigned passenger to determine whether the assigned passenger is actually within the vehicle. For instance, once the authentication of the assigned passenger's client computing device has taken place (typically before the passenger enters the vehicle), the assigned passenger's client computing device may begin sharing location information, such as GPS coordinates or other location coordinates, with the vehicle. Once the vehicle begins moving, the computing devices may confirm that the GPS coordinates and/or the change in the GPS coordinates over time is consistent with the location and movement of the vehicle over time. If so, this may confirm that the assigned passenger is in the vehicle. If not, this may indicate that the wrong passenger has entered the vehicle.

If the passenger within the vehicle is the assigned passenger, then the computing devices may continue moving the vehicle towards the destination. If the passenger within the vehicle is not the assigned passenger, the vehicle's computing devices may attempt to determine who is in the vehicle. This may involve attempting to communicate with a client computing device within the vehicle (i.e., one associated with the new passenger who is in the vehicle) in order to obtain sufficient information to authenticate the client computing device within the vehicle and/or request an updated destination from the dispatching server computing device. The dispatching server computing device may then reassign the vehicle to the new passenger and send authentication information to the vehicle's computing devices. In this regard, once the client computing device within the vehicle is authenticated, the computing devices may identify the passenger's actual destination and change the vehicle's destination from that of the previously assigned passenger to that of the newly assigned passenger.

The features described herein, may allow computing devices of an autonomous vehicle to quickly and easily confirm that a passenger who enters a vehicle was actually assigned to that vehicle without causing any additional delay to the passenger (if indeed it is the assigned passenger). In addition, these features allow the vehicle's computing devices to reroute the vehicle to a new destination in a way that reduces inconvenience (and in some cases embarrassment) to the passenger in the vehicle. By allowing the vehicle to change destinations and inform the passenger why, this may even provide the passenger with a greater sense of safety when using the vehicle.

As shown in <FIG>, a vehicle <NUM> in accordance with one aspect of the disclosure includes various components. While certain aspects of the disclosure are particularly useful in connection with specific types of vehicles, the vehicle may be any type of vehicle including, but not limited to, cars, trucks, motorcycles, busses, recreational vehicles, etc. The vehicle may have one or more computing devices, such as computing device <NUM> containing one or more processors <NUM>, memory <NUM> and other components typically present in general purpose computing devices.

As an example, data <NUM> of memory <NUM> may store predefined scenarios. A given scenario may identify a set of scenario requirements including a type of object, a range of locations of the object relative to the vehicle, as well as other factors such as whether the autonomous vehicle is able to maneuver around the object, whether the object is using a turn signal, the condition of a traffic light relevant to the current location of the object, whether the object is approaching a stop sign, etc. The requirements may include discrete values, such as "right turn signal is on" or "in a right turn only lane", or ranges of values such as "having an heading that is oriented at an angle that is <NUM> to <NUM> degrees offset from a current path of vehicle <NUM>. " In some examples, the predetermined scenarios may include similar information for multiple objects.

The one or more processor <NUM> may be any conventional processors, such as commercially available CPUs. Alternatively, the one or more processors may be a dedicated device such as an ASIC or other hardware-based processor. Although <FIG> functionally illustrates the processor, memory, and other elements of computing device <NUM> as being within the same block, it will be understood by those of ordinary skill in the art that the processor, computing device, or memory may actually include multiple processors, computing devices, or memories that may or may not be stored within the same physical housing. As an example, internal electronic display <NUM> may be controlled by a dedicated computing device having its own processor or central processing unit (CPU), memory, etc. which may interface with the computing device <NUM> via a high-bandwidth or other network connection. In some examples, this computing device may be a user interface computing device which can communicate with a user's client device. Similarly, the memory may be a hard drive or other storage media located in a housing different from that of computing device <NUM>. Accordingly, references to a processor or computing device will be understood to include references to a collection of processors or computing devices or memories that may or may not operate in parallel.

Computing device <NUM> may all of the components normally used in connection with a computing device such as the processor and memory described above as well as a user input <NUM> (e.g., a mouse, keyboard, touch screen and/or microphone) and various electronic displays (e.g., a monitor having a screen or any other electrical device that is operable to display information). In this example, the vehicle includes an internal electronic display <NUM> as well as one or more speakers <NUM> to provide information or audio visual experiences. In this regard, internal electronic display <NUM> may be located within a cabin of vehicle <NUM> and may be used by computing device <NUM> to provide information to passengers within the vehicle <NUM>. In addition to internal speakers, the one or more speakers <NUM> may include external speakers that are arranged at various locations on the vehicle in order to provide audible notifications to objects external to the vehicle <NUM>.

In one example, computing device <NUM> may be an autonomous driving computing system incorporated into vehicle <NUM>. The autonomous driving computing system may capable of communicating with various components of the vehicle. For example, returning to <FIG>, computing device <NUM> may be in communication with various systems of vehicle <NUM>, such as deceleration system <NUM> (for controlling braking of the vehicle), acceleration system <NUM> (for controlling acceleration of the vehicle), steering system <NUM> (for controlling the orientation of the wheels and direction of the vehicle), signaling system <NUM> (for controlling turn signals), navigation system <NUM> (for navigating the vehicle to a location or around objects), positioning system <NUM> (for determining the position of the vehicle), perception system <NUM> (for detecting objects in the vehicle's environment), and power system <NUM> (for example, a battery and/or gas or diesel powered engine) in order to control the movement, speed, etc. of vehicle <NUM> in accordance with the instructions <NUM> of memory <NUM> in an autonomous driving mode which does not require or need continuous or periodic input from a passenger of the vehicle. Again, although these systems are shown as external to computing device <NUM>, in actuality, these systems may also be incorporated into computing device <NUM>, again as an autonomous driving computing system for controlling vehicle <NUM>.

The computing device <NUM> may control the direction and speed of the vehicle by controlling various components. By way of example, computing device <NUM> may navigate the vehicle to a destination location completely autonomously using data from the map information and navigation system <NUM>. Computing devices <NUM> may use the positioning system <NUM> to determine the vehicle's location and perception system <NUM> to detect and respond to objects when needed to reach the location safely. In order to do so, computing devices <NUM> may cause the vehicle to accelerate (e.g., by increasing fuel or other energy provided to the engine by acceleration system <NUM>), decelerate (e.g., by decreasing the fuel supplied to the engine, changing gears, and/or by applying brakes by deceleration system <NUM>), change direction (e.g., by turning the front or rear wheels of vehicle <NUM> by steering system <NUM>), and signal such changes (e.g., by lighting turn signals of signaling system <NUM>). Thus, the acceleration system <NUM> and deceleration system <NUM> may be a part of a drivetrain that includes various components between an engine of the vehicle and the wheels of the vehicle. Again, by controlling these systems, computing devices <NUM> may also control the drivetrain of the vehicle in order to maneuver the vehicle autonomously.

As an example, computing device <NUM> may interact with deceleration system <NUM> and acceleration system <NUM> in order to control the speed of the vehicle. Similarly, steering system <NUM> may be used by computing device <NUM> in order to control the direction of vehicle <NUM>. For example, if vehicle <NUM> configured for use on a road, such as a car or truck, the steering system may include components to control the angle of wheels to turn the vehicle. Signaling system <NUM> may be used by computing device <NUM> in order to signal the vehicle's intent to other drivers or vehicles, for example, by lighting turn signals or brake lights when needed.

Navigation system <NUM> may be used by computing device <NUM> in order to determine and follow a route to a location. In this regard, the navigation system <NUM> and/or data <NUM> may store map information, e.g., highly detailed maps that computing devices <NUM> can use to navigate or control the vehicle. As an example, these maps may identify the shape and elevation of roadways, lane markers, intersections, crosswalks, speed limits, traffic signal lights, buildings, signs, real time traffic information, vegetation, or other such objects and information. The lane markers may include features such as solid or broken double or single lane lines, solid or broken lane lines, reflectors, etc. A given lane may be associated with left and right lane lines or other lane markers that define the boundary of the lane. Thus, most lanes may be bounded by a left edge of one lane line and a right edge of another lane line.

The perception system <NUM> also includes one or more components for detecting objects external to the vehicle such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc. For example, the perception system <NUM> may include one or more LIDAR sensors, sonar devices, radar units, cameras and/or any other detection devices that record data which may be processed by computing devices <NUM>. The sensors of the perception system may detect objects and their characteristics such as location, orientation, size, shape, type (for instance, vehicle, pedestrian, bicyclist, etc.), heading, and speed of movement, etc. The raw data from the sensors and/or the aforementioned characteristics can be quantified or arranged into a descriptive function, vector, and or bounding box and sent for further processing to the computing devices <NUM> periodically and continuously as it is generated by the perception system <NUM>. As discussed in further detail below, computing devices <NUM> may use the positioning system <NUM> to determine the vehicle's location and perception system <NUM> to detect and respond to objects when needed to reach the location safely.

<FIG> is an example of map information <NUM> for a section of roadway. The map information <NUM> includes information identifying the shape, location, and other characteristics of various road features. In this example, the map information includes three lanes <NUM>, <NUM>, <NUM> bounded by curb <NUM>, lane lines <NUM>, <NUM>, <NUM>, and curb <NUM>. Lanes <NUM> and <NUM> have the same direction of traffic flow (in an eastward direction), while lane <NUM> has a different traffic flow (in a westward direction). In addition, lane <NUM> is significantly wider than lane <NUM>, for instance to allow for vehicles to park adjacent to curb <NUM>. Although the example of map information includes only a few road features, for instance, curbs, lane lines, and lanes, given the nature of the roadway, the map information <NUM> may also identify various other road features such as traffic signal lights, crosswalks, sidewalks, stop signs, yield signs, speed limit signs, road signs, etc. Although not shown, the detailed map information may also include information identifying speed limits and other legal traffic requirements as well as historical information identifying typical and historical traffic conditions at various dates and times.

Although the detailed map information is depicted herein as an image-based map, the map information need not be entirely image based (for example, raster). For example, the detailed map information may include one or more roadgraphs or graph networks of information such as roads, lanes, intersections, and the connections between these features. 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 roadgraph to allow for efficient lookup of certain roadgraph features.

<FIG> are examples of external views of vehicle <NUM>. As can be seen, vehicle <NUM> includes many features of a typical vehicle such as headlights <NUM>, windshield <NUM>, taillights/turn signal lights <NUM>, rear windshield <NUM>, doors <NUM>, side view mirrors <NUM>, tires and wheels <NUM>, and turn signal/parking lights <NUM>. Headlights <NUM>, taillights/turn signal lights <NUM>, and turn signal/parking lights <NUM> may be associated the signaling system <NUM>. Light bar <NUM> may also be associated with the signaling system <NUM>. Housing <NUM> may house one or more sensors, such as LIDAR sensors, sonar devices, radar units, cameras, etc. of the perception system <NUM>, though such sensors may also be incorporated into other areas of the vehicle as well.

The one or more computing devices <NUM> of vehicle <NUM> may also receive or transfer information to and from other computing devices, for instance using wireless network connections <NUM>. The wireless network connections may include, for instance, BLUETOOTH (R), Bluetooth LE, LTE, cellular, near field communications, etc. and various combinations of the foregoing. <FIG> and <FIG> are pictorial and functional diagrams, respectively, of an example system <NUM> that includes a plurality of computing devices <NUM>, <NUM>, <NUM>, <NUM> and a storage system <NUM> connected via a network <NUM>. System <NUM> also includes vehicle <NUM>, and vehicle 100A which may be configured similarly to vehicle <NUM>. Although only a few vehicles and computing devices are depicted for simplicity, a typical system may include significantly more.

The network <NUM>, and intervening nodes, may include various configurations and protocols including short range communication protocols such as BLUETOOTH (R), Bluetooth LE, the Internet, World Wide Web, intranets, virtual private networks, wide area networks, local networks, private networks using communication protocols proprietary to one or more companies, Ethernet, WiFi and HTTP, and various combinations of the foregoing.

In one example, one or more computing devices <NUM> may include a server having a plurality of computing devices, e.g., a load balanced server farm, that exchange information with different nodes of a network for the purpose of receiving, processing and transmitting the data to and from other computing devices. For instance, one or more computing devices <NUM> may include one or more server computing devices that are capable of communicating with one or more computing devices <NUM> of vehicle <NUM> or a similar computing device of vehicle 100A as well as client computing devices <NUM>, <NUM>, <NUM> via the network <NUM>. For example, vehicles <NUM> and 100A may be a part of a fleet of vehicles that can be dispatched by server computing devices to various locations. In this regard, the vehicles of the fleet may periodically send the server computing devices location information provided by the vehicle's respective positioning systems and the one or more server computing devices may track the locations of the vehicles.

In addition, server computing devices <NUM> may use network <NUM> to transmit and present information to a user, such as user <NUM>, <NUM>, <NUM> on a display, such as displays <NUM>, <NUM>, <NUM> of computing devices <NUM>, <NUM>, <NUM>. In this regard, computing devices <NUM>, <NUM>, <NUM> may be considered client computing devices.

As shown in <FIG>, each client computing device <NUM>, <NUM>, <NUM> may be a personal computing device intended for use by a user <NUM>, <NUM>, <NUM>, and have all of the components normally used in connection with a personal computing device including a one or more processors (e.g., a central processing unit (CPU)), memory (e.g., RAM and internal hard drives) storing data and instructions, a display such as displays <NUM>, <NUM>, <NUM> (e.g., a monitor having a screen, a touch-screen, a projector, a television, or other device that is operable to display information), and user input devices <NUM>, <NUM>, <NUM> (e.g., a mouse, keyboard, touchscreen or microphone). The client computing devices may also include a camera for recording video streams, speakers, a network interface device, and all of the components used for connecting these elements to one another.

Although the client computing devices <NUM>, <NUM>, and <NUM> may each comprise a full-sized personal computing device, they may alternatively comprise mobile computing devices capable of wirelessly exchanging data with a server over a network such as the Internet. By way of example only, client computing device <NUM> may be a mobile phone or a device such as a wireless-enabled PDA, a tablet PC, a wearable computing device or system, or a netbook that is capable of obtaining information via the Internet or other networks. In another example, client computing device <NUM> may be a wearable computing system, shown as a wrist watch in <FIG>. As an example the user may input information using a small keyboard, a keypad, microphone, using visual signals with a camera, or a touch screen.

In some examples, client computing device <NUM> may be concierge work station used by an administrator to provide concierge services to users such as users <NUM> and <NUM>. For example, a concierge <NUM> may use the concierge work station <NUM> to communicate via a telephone call or audio connection with users through their respective client computing devices or vehicles <NUM> or 100A in order to ensure the safe operation of vehicles <NUM> and 100A and the safety of the users as described in further detail below. Although only a single concierge work station <NUM> is shown in <FIG> and <FIG>, any number of such work stations may be included in a typical system.

Storage system <NUM> may store various types of information as described in more detail below. This information may be retrieved or otherwise accessed by a server computing device, such as one or more server computing devices <NUM>, in order to perform some or all of the features described herein. For example, the information may include user account information such as credentials (e.g., a user name and password as in the case of a traditional single-factor authentication as well as other types of credentials typically used in multi-factor authentications such as random identifiers, biometrics, etc.) that can be used to identify a user to the one or more server computing devices. The user account information may also include personal information such as the user's name, contact information, identifying information of the user's client computing device (or devices if multiple devices are used with the same user account), as well as one or more unique signals for the user.

The storage system <NUM> may also store routing data for generating and evaluating routes between locations. For example, the routing information may be used to estimate how long it would take a vehicle at a first location to reach a second location. In this regard, the routing information may include map information, not necessarily as particular as the detailed map information described above, but including roads, as well as information about those road such as direction (one way, two way, etc.), orientation (North, South, etc.), speed limits, as well as traffic information identifying expected traffic conditions, etc..

The storage system <NUM> may also store information which can be provided to client computing devices for display to a user. For instance, the storage system <NUM> may store predetermined distance information for determining an area at which a vehicle is likely to stop for a given pickup or destination location. The storage system <NUM> may also store graphics, icons, and other items which may be displayed to a user as discussed below.

As with memory <NUM>, storage system <NUM> can be of any type of computerized storage capable of storing information accessible by the server computing devices <NUM>, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable, and read-only memories. In addition, storage system <NUM> may include a distributed storage system where data is stored on a plurality of different storage devices which may be physically located at the same or different geographic locations. Storage system <NUM> may be connected to the computing devices via the network <NUM> as shown in <FIG> and/or may be directly connected to or incorporated into any of the computing devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc..

In one aspect, a user may download an application for requesting a vehicle to a client computing device. For example, users <NUM> and <NUM> may download the application via a link in an email, directly from a website, or an application store to client computing devices <NUM> and <NUM>. For example, client computing device may transmit a request for the application over the network, for example, to one or more server computing devices <NUM>, and in response, receive the application. The application may be installed locally at the client computing device.

The user may then use his or her client computing device to access the application and request a vehicle. As an example, a user such as user <NUM> may use client computing device <NUM> to send a request to one or more server computing devices <NUM> for a vehicle. As part of this, the user may identify a pickup location, a destination location, and, in some cases, one or more intermediate stopping locations anywhere within a service area where a vehicle can stop.

These pickup and destination locations may be predefined (e.g., specific areas of a parking lot, etc.) or may simply be any location within a service area of the vehicles. As an example, a pickup location can be defaulted to the current location of the user's client computing device, or can be input by the user at the user's client device. For instance, the user may enter an address or other location information or select a location on a map to select a pickup location.

Once the user has selected one or more of a pickup and/or destination locations, the client computing device <NUM> may send the location or locations to one or more server computing devices of the centralized dispatching system. In response, one or more server computing devices, such as server computing device <NUM>, may select a vehicle, such as vehicle <NUM>, for instance based on availability and proximity to the user. The server computing device <NUM> may then assign the user as the passenger for the vehicle <NUM>, dispatch the selected vehicle (here vehicle <NUM>) to pick up to the assigned passenger. This may include by providing the vehicle's computing devices <NUM> with the pickup and/or destination locations specified by the assigned passenger as well as information that can be used by the computing devices <NUM> of vehicle <NUM> to authenticate the client computing device, such as client computing device <NUM>.

<FIG> is an example view of vehicle <NUM> driving along a roadway <NUM> corresponding to roadway <NUM> of <FIG>. In that regard, lanes <NUM>, <NUM>, <NUM> correspond to the shape and location of lanes <NUM>, <NUM>, <NUM>, curbs <NUM>, <NUM> correspond to the shape and location of curb <NUM>, and lane lines <NUM>, <NUM>, <NUM> correspond to the shape and location of lane lines <NUM>, <NUM>, <NUM>, and curb <NUM>. In this example, vehicle <NUM> is traveling in lane <NUM>. Vehicles <NUM>, <NUM>, and <NUM> are parked within lane <NUM> along curb <NUM>, while vehicle <NUM> is moving in lane <NUM>. Pedestrians <NUM>, <NUM>, <NUM>, <NUM> are located around roadway <NUM>, but within the range of the sensors of the perception system <NUM>.

As the vehicle moves along lane <NUM>, the perception system <NUM> provides the computing devices with sensor data regarding the shapes and location of objects, such as curbs <NUM>, <NUM>, lane lines <NUM>, <NUM>, <NUM>, as well as vehicles <NUM>, <NUM>, <NUM>, <NUM>. <FIG> depicts sensor data perceived by the various sensors of the perception system <NUM> when vehicle <NUM> is in the situation as depicted in <FIG> in combination with other information available to the computing devices <NUM>. In this example, vehicles <NUM>, <NUM>, <NUM>, <NUM>, are represented by bounding boxes <NUM>, <NUM>, <NUM>, <NUM> as provided by the perception system <NUM> to the computing devices <NUM>. Pedestrians <NUM>, <NUM>, <NUM>, <NUM> are also represented by bounding boxes <NUM>, <NUM>, <NUM>, <NUM>, of course the boundaries of objects such as pedestrians. Of course, these bounding boxes represent merely a volume of space within which data points corresponding to an object are at least approximately bounded within. In addition, the actual heading of vehicle <NUM> and estimated heading of bounding box <NUM> are represented by arrows <NUM> and <NUM>, respectively. As bounding boxes <NUM>, <NUM>, <NUM> appear to be moving very slowly or not at all, the computing devices <NUM> may determine that the objects represented by these bounding boxes are parked along curb <NUM>.

Once the vehicle is within a predetermined distance in time or space from the pickup location, such as sometime before or after the vehicle's computing devices should begin looking for a place to stop and/or park the vehicle and an assigned passenger's client devices has been authenticated by the vehicle. As an example, this distance may be <NUM> meters, <NUM> feet (<NUM> meter corresponding to <NUM>,<NUM> feet), or more or less from the pickup location. For instance, using near-field communication, BLUETOOTH (R) or other wireless protocols, the computing devices may attempt to communicate and establish a link with the client device. When this link is successfully established, the client device can be authenticated.

For instance, returning to <FIG>, vehicle <NUM> has just reached the predetermined distance <NUM> from pickup location <NUM>. At this point, vehicle <NUM> will attempt to authenticate the client computing device of the assigned passenger using the information received from the server computing devices <NUM>. In this regard, the computing devices <NUM> and <NUM> may create a direct communication link and therefore be capable of direct communication of information (i.e. without the need for the information to be relayed by the server computing devices <NUM>). As an example, the client computing device may begin to send location information, such as GPS coordinates or other location coordinates, to the computing devices <NUM>.

At the same time, the computing devices <NUM> may attempt to stop the vehicle at a location proximate to the pickup location <NUM> in order to allow the passenger to enter. For instance, the computing devices <NUM> may identify the area between bounding box <NUM> and bounding box <NUM> as an appropriate location (for instance, a parking spot) at which the vehicle may stop and wait for the assigned passenger. In this regard, the computing devices <NUM> may maneuver the vehicle to the parking spot between bounding boxes <NUM> and <NUM>, as shown in <FIG>.

Once the client computing device is authenticated and the vehicle is stopped and waiting, any pedestrian, including those other than the assigned passenger, may be able to enter the vehicle and, of course, become a passenger. For example, as shown in <FIG>, there are several bounding boxes corresponding to pedestrians including bounding boxes <NUM>, <NUM>, <NUM>, <NUM> which could possibly be the assigned pedestrian for the vehicle (i.e. the pedestrian associated with client computing device <NUM>). All of these pedestrians may be close enough to the vehicle to create a communication link and authenticate his or her client computing device, but given the close proximity to the vehicle, any of these pedestrians may enter the vehicle. This may be especially likely to occur in situations where there are multiple passengers waiting for such vehicles in the same area (such as a train station, movie theater, airport, mall, etc.).

Once the pedestrian (now passenger) enters the vehicle, he or she may be asked to perform some tasks such as buckle a seat belt, close a door, and/or confirm his or her destination as that of the assigned passenger. For instance, a request to confirm the destination may be displayed on internal electronic display <NUM>. A response may be spoken by the passenger if the vehicle uses a microphone to record audible input and/or entered using the user input <NUM>. Asking the passenger to confirm the destination may be a useful way to determine that the passenger is indeed the assigned passenger. However, in some cases, the passenger may inadvertently or purposefully confirm a destination which is incorrect. Once this confirmation is received, the computing devices <NUM> may begin to maneuver the vehicle <NUM> towards the destination.

Thus, the computing devices <NUM> must be able to determine whether the passenger is the assigned pedestrian beyond authenticating the client computing device of the assigned passenger and/or asking for the passenger to confirm the destination. This may include using facial recognition techniques and/or having a concierge or remote operator check in on the passenger and confirm his or her identity visually (using a camera or other imaging device) or using an audio and/or video connection to communicate with the passenger (e.g., using an internal display, speaker, and microphone).

However, to avoid unnecessary delays, when the passenger is safely situated within the vehicle, for instance with seat belt buckled and doors of the vehicle closed, the computing devices <NUM> may immediately begin maneuvering the vehicle to the destination (of the assigned passenger). Once the vehicle's computing devices begin maneuvering the vehicle towards the destination of the assigned passenger, the computing devices may use information received from the client computing device of the passenger within the vehicle as well as the assigned passenger to determine whether the assigned passenger is actually within the vehicle.

For instance, once the authentication has taken place as noted above (e.g.,. , before the assigned passenger has entered the vehicle), the assigned passenger's client computing device may begin sharing GPS coordinates with the vehicle's computing devices. In addition or alternatively, this information may be sent by the assigned passenger's client computing device to the server computing devices <NUM> and relayed to the computing devices <NUM>. As shown in <FIG>, the client computing device <NUM> may share GPS coordinates X1,Y1 at a time T1 immediately before or when the vehicle begins to move from the stopped position in <FIG> towards the destination of the assigned passenger. Thereafter, the client computing device may send updated GPS coordinates at times T2, T3, T4, T5 and so on. In addition, or alternatively, this information may be relayed from the client computing device by the server computing devices to the computing devices <NUM>.

If the communication link between the computing devices <NUM> and the client computing device continues over time, this may indicate that the client computing device is within and moving with the vehicle. Alternatively, if the assigned passenger is not in the vehicle, eventually the vehicle will move far enough away that the communication link between the computing devices <NUM> and the client computing device is terminated. However, this may not occur until the vehicle has moved quite a ways away from the client computing device, such as <NUM> or <NUM> feet, or more or less. To address this, the computing devices <NUM> may attempt to reduce the authentication radius (e.g., how far the computing devices <NUM> send signals or rather the strength of those signals) when the vehicle begins to move as the assigned passenger (and his or her client computing device) may be assumed to be within the vehicle. In addition or alternatively, if there are interior and exterior transceivers for receiving these signals, the computing devices <NUM> may switch from the exterior to the interior ones once a passenger has entered the vehicle.

Once the vehicle begins moving, the computing devices may confirm that the GPS coordinates of the client computing devices are consistent with the location of the vehicle. This may include simply comparing the location of the vehicle with the GPS coordinates received from the client computing device each time an update is received.

In addition or alternatively, the computing devices <NUM> may determine whether the change in the GPS coordinates over time is consistent with the movement of the vehicle or the vehicle's route (as determined by the navigation system) over time. This may involve first determining the distances between GPS coordinates of the client computing device each time the computing devices <NUM> receive updated GPS coordinates. For instance, turning to <FIG>, the distances D1-D5 between X1,Y1 and X2,Y2, X2,Y2 and X3,Y3, and so on may be determined. Direction or heading may be determined, for instance, from the slope of the lines between each of the GPS coordinates.

Velocity may be estimated by simply dividing the distances by the time between these updates. For example, the velocity V1 between time T1 and T2 would be the distance D1 divided by the difference in time between T1 and T2. Similarly, the velocity V2 between time T2 and T3 would be the distance D2 divided by the difference in time between T2 and T3.

Acceleration may also be determined by determining the change in velocity each time updated GPS coordinates are received. For instance, the acceleration may be determined from the difference between the velocity V1 and the velocity V2 divided by the difference in time between T3 and T2.

The computing devices may determine if the speed, heading, and/or acceleration are consistent by comparing the values determined from the GPS coordinates received from the client computing device to the actual speed, heading, and acceleration of the vehicle. This information may be retrieved from the navigation system and/or directly from the vehicle pose measurements at a GPS receiver and other measurement devices arranged around the vehicle. This measured motion may be compared to the estimated motion of the client computing device. This may then be combined with the measured error or variance of the GPS location for the client computing device and used compute a confidence value that the two motions are aligned. A minimum threshold value may then be used to determine if this likelihood is great enough to indicate that the assigned passenger (or really, the assigned passenger's client computing device) is within the vehicle. For instance, if a vehicle's motion and that of an assigned passenger's client computing device are aligned with a <NUM>% confidence level, and the minimum threshold value is <NUM>%, the computing devices <NUM> may determine that the assigned passenger is not within the vehicle. Similarly, if a vehicle's motion and that of an assigned passenger's client computing device are aligned at an <NUM>% confidence level, and the minimum threshold value is <NUM>%, the computing devices <NUM> may determine that the assigned passenger is within the vehicle.

This process may additionally incorporate a model of pedestrian motion. For instance, if the vehicle moved at a speed or acceleration that a pedestrian would have trouble matching, and similar movement was observed in the estimated velocity and/or acceleration, this may indicate a higher likelihood that the assigned pedestrian is in the vehicle. However, in some instances, this could also cause false positives if the assigned passenger is actually running after the vehicle in frustration, or if two passengers switched assigned vehicles accidentally, and both vehicles drove away at roughly the same time and in the same direction. In this regard, it may make sense to continue tracking the assigned passenger's location with respect to the location of the vehicle for some additional period of time or during the entire trip.

Although GPS coordinates determined by the client device may be somewhat inaccurate, looking at the change in this location over time may be a fair approximation of movement of the client computing device.

When the speed, heading, and/or acceleration are consistent, this may confirm that the assigned passenger is in the vehicle. In other words, the computing devices <NUM> may confirm the identity of the passenger in the vehicle using the comparisons described above and continue to maneuver the vehicle towards the destination of the assigned passenger.

If the speed, heading, and/or acceleration are not consistent, this may indicate that the assigned passenger is not in the vehicle and another passenger has entered the vehicle. At this point, the computing devices <NUM> may pull the vehicle over and stop to allow the incorrect passenger to exit the vehicle.

However, in order to reduce delays or unsafe situations for the passenger and vehicle, the vehicle's computing devices may continue to maneuver the vehicle towards the destination (rather than stopping) and attempt to determine who is in the vehicle. This may involve attempting to communicate with a client computing device within the vehicle in order to obtain sufficient information to authenticate the client computing device within the vehicle and/or request an updated destination from the dispatching server computing device. This may be achieved by the computing devices <NUM> sending a request to the server computing devices for assistance. In response, the server computing devices may send a request through the application to any client computing devices with the application within a short distance of the location of the vehicle and currently using the service (i.e., is active). The request may ask those client computing devices to broadcast a signal (such as a BLUETOOTH (R) signal). This may allow the computing devices <NUM> to query for such signals in order to identify which client device is currently in the vehicle. Information in the signals, such as an ID for the active client computing device, may then be sent to the server computing devices in a request for authentication information for that client computing device. If more than one signal and ID are identified, all of the IDs may be sent to the server. In response, the server could examine each nearby client computing device's motion, for instance by determining changes in GPS locations over time, and compare that information to the vehicle's motion. The active client computing device with the closest match may be assumed to be the client computing device of the new passenger within the vehicle.

In such cases, the dispatching server computing device may then reassign the vehicle to the new passenger and send authentication information to the vehicle's computing devices. In this regard, once the client computing device within the vehicle is authenticated, the computing devices may identify the passenger's actual destination and change the destination of the previously assigned passenger to that of the newly assigned passenger. The newly assigned passenger may then be notified, for instance on a display of the vehicle and/or on his or her client computing device, of the change in destination and why it has occurred. The newly assigned passenger may even be asked to confirm that the new destination is correct.

Of course, some passengers may attempt to take advantage of this by "jumping into" vehicles they know are assigned to other passengers. To reduce or prevent this, the passenger may be presented with a notification on his or her client device that he or she is in the wrong vehicle.

In addition or alternatively, the computing devices may attempt to communicate with any client computing devices that entered the vehicle with the passenger. This may include using multiple antennas of the vehicle to send a signal to any such devices requesting a response identifying the client computing device. As an example, the antennas may be near range antennas, WiFi antennas, and/or BLUETOOTH sensors. The application of a client computing device within the vehicle may receive the request and generate a response identifying the passenger, the client computing device, or both. If a response is received, the computing devices may confirm whether it came from the client computing device of the assigned passenger or a different passenger.

In addition or alternatively, the computing devices may send a request for the assigned passenger to confirm whether or not he or she is in the vehicle. This may allow the assigned passenger to confirm whether the assigned passenger allowed another passenger to enter the vehicle on purpose. At the same time, the server computing device may assign a new vehicle to the originally assigned passenger. In addition, this passenger may be notified via his or her client computing device that a new vehicle has been dispatched and offer some other compensation for the inconvenience of the delay (such as a discount, coupon, etc. for this or a future ride).

In some instances, a passenger may not have a client computing device when entering the vehicle. For instance, if the vehicle was requested for a third party not familiar with or able to use the application, the passenger's client computing device has lost power (e.g., the battery has died), or if the passenger who is handicapped. In such cases, the passenger may be required to display or otherwise use a badge or enter a pin or other code in order to identify his or herself to the vehicle's computing devices. This information may be generated by the application, the dispatching server computing device, or the person requesting the vehicle for the third party. The person requesting the vehicle can then share the information with the third party or enter it for them in the vehicle.

<FIG> is a flow diagram <NUM> that may be performed by one or more processors, such as one or more processors <NUM> of computing device <NUM> in order to identify a passenger of a vehicle. At block <NUM>, instructions to pick up an assigned passenger associated with a first client computing device are received from a server computing device. These instructions identify a first destination location. Location information generated by the first client computing device is received over time at block <NUM>. After a given passenger enters the vehicle, the vehicle is maneuvered towards the first destination location in an autonomous driving mode at block <NUM>. While maneuvering the vehicle towards the first destination location, a location of the vehicle is compared to the received location information at block <NUM>. Whether the given passenger is the assigned passenger is determined based on the comparison at block <NUM>.

<FIG> are a flow diagram <NUM> that may be performed by one or more processors such as one or more processors <NUM> of computing device <NUM> in order to change a destination of a driverless vehicle as discussed above. In this example, at block <NUM>, dispatching instructions to pick up a first passenger at a pickup location and to drop off the first passenger at a first destination location are received from a dispatching server. At block <NUM>, authentication information for authenticating a first client computing device associated with the first passenger is received. At block <NUM>, the vehicle is maneuvered towards the pickup location in an autonomous driving mode. At block <NUM>, the first client computing devices is authenticated. Location information from the first client computing device is received over time at block <NUM>. The vehicle is stopped and a second passenger is allowed to enter the vehicle at block <NUM>. After the second passenger enters the vehicle and the first client computing device is authenticated, the vehicle is maneuvered towards the first destination location in the autonomous driving mode at block <NUM>. While maneuvering the vehicle towards the first destination location, a location of the vehicle is compared to the received location information at block <NUM>. A notification is sent to the dispatching server based on the comparison at block <NUM>. A second destination location is received at block <NUM>. The vehicle is then maneuvered towards the second destination instead of the first destination at block <NUM>.

Claim 1:
A computer-implemented method of controlling an autonomous vehicle, the method comprising:
receiving (<NUM>), from a dispatching server, instructions to pick up an assigned passenger associated with a first client computing device, the instructions identifying a first destination location;
receiving (<NUM>) over time, location information generated by the first client computing device;
after a given passenger enters the vehicle, maneuvering (<NUM>) the vehicle towards the first destination location in an autonomous driving mode;
receiving a plurality of vehicle motion values generated by a plurality of measurement devices arranged around the vehicle, the vehicle motion values including location of the vehicle;
while maneuvering the vehicle towards the first destination location, determining (<NUM>) a confidence level based on comparing changes in the vehicle motion over time to changes in first client computing device motion estimated from the received location information;
determining (<NUM>) that the given passenger is the assigned passenger when the confidence level meets a threshold; and
when the given passenger is determined not to be the assigned passenger:
sending (<NUM>) a notification to the dispatching server indicating that the given passenger is determined not to be the assigned passenger;
receiving (<NUM>) a second destination location; and
maneuvering (<NUM>)the vehicle in the autonomous driving mode towards the second destination location instead of the first destination location.