TECHNICAL FIELD

[0001] The present disclosure relates to systems and methods that allow a vehicle to detect and locate a passenger.

BACKGROUND

[0002] Automobiles and other vehicles provide a significant portion of transportation for commercial, government, and private entities. Autonomous vehicles and driving assistance systems are currently being developed and deployed to provide safety features, reduce an amount of user input required, or even eliminate user involvement entirely. For example, some driving assistance systems, such as crash avoidance systems, may monitor driving, positions, and a velocity of the vehicle and other objects while a human is driving. When the system detects that a crash or impact is imminent the crash avoidance system may intervene and apply a brake, steer the vehicle, or perform other avoidance or safety maneuvers. As another example, autonomous vehicles may drive, navigate, and/or park a vehicle with little or no user input. In some situations, autonomous vehicles are used to provide transportation services by transporting a passenger from a current location to a destination. When preparing to transport a passenger, the autonomous vehicle needs to locate the passenger in a pickup location at a particular time, or during a particular time window. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various figures unless otherwise specified.

[0004] FIG. 1 is a block diagram illustrating an embodiment of a vehicle control system.

[0005] FIG. 2 is a block diagram illustrating an embodiment of a passenger detection system.

[0006] FIG. 3 illustrates an embodiment of a user communicating with a vehicle and a server through a mobile device.

[0007] FIG. 4 illustrates an embodiment of a method for initiating a user transportation request.

[0008] FIG. 5 illustrates an embodiment of a method for locating a user who initiated the transportation request.

[0009] FIG. 6 illustrates a diagram of a mobile device broadcasting a Wi-Fi beacon and a Bluetooth beacon, according to one embodiment.

[0010] FIG. 7 A illustrates a Wi-Fi beacon structure, according to one embodiment.

[0011] FIG. 7B illustrates a Bluetooth beacon structure, according to one embodiment.

DETAILED DESCRIPTION

[0012] In the following disclosure, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific implementations in which the disclosure may be practiced. It is understood that other implementations may be utilized and structural changes may be made without departing from the scope of the present disclosure. References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0013] Implementations of the systems, devices, and methods disclosed herein may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed herein.

Implementations within the scope of the present disclosure may also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are computer storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, implementations of the disclosure can comprise at least two distinctly different kinds of computer-readable media: computer storage media (devices) and transmission media.

[0014] Computer storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives ("SSDs") (e.g., based on RAM), Flash memory, phase-change memory ("PCM"), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

[0015] An implementation of the devices, systems, and methods disclosed herein may communicate over a computer network. A "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links, which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

[0016] Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter is described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described herein. Rather, the described features and acts are disclosed as example forms of implementing the claims. [0017] Those skilled in the art will appreciate that the disclosure may be practiced in network computing environments with many types of computer system configurations, including, an in-dash vehicle computer, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor- based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, various storage devices, and the like. The disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0018] Further, where appropriate, functions described herein can be performed in one or more of: hardware, software, firmware, digital components, or analog components. For example, one or more application specific integrated circuits (ASICs) can be programmed to carry out one or more of the systems and procedures described herein. Certain terms are used throughout the description and claims to refer to particular system components. As one skilled in the art will appreciate, components may be referred to by different names. This document does not intend to distinguish between components that differ in name, but not function.

[0019] It should be noted that the sensor embodiments discussed herein may comprise computer hardware, software, firmware, or any combination thereof to perform at least a portion of their functions. For example, a sensor may include computer code configured to be executed in one or more processors, and may include hardware logic/electrical circuitry controlled by the computer code. These example devices are provided herein for purposes of illustration, and are not intended to be limiting. Embodiments of the present disclosure may be implemented in further types of devices, as would be known to persons skilled in the relevant art(s).

[0020] At least some embodiments of the disclosure are directed to computer program products comprising such logic (e.g., in the form of software) stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a device to operate as described herein.

[0021] FIG. 1 is a block diagram illustrating an embodiment of a vehicle control system 100 within a vehicle that includes a passenger detection system 104. An automated

driving/assistance system 102 may be used to automate or control operation of a vehicle or to provide assistance to a human driver. For example, the automated driving/assistance system 102 may control one or more of braking, steering, seat belt tension, acceleration, lights, alerts, driver notifications, radio, vehicle locks, or any other auxiliary systems of the vehicle. In another example, the automated driving/assi stance system 102 may not be able to provide any control of the driving (e.g., steering, acceleration, or braking), but may provide notifications and alerts to assist a human driver in driving safely.

[0022] Vehicle control system 100 includes passenger detection system 104 that interacts with various components and systems (including vehicle-based systems and remote systems) to identify a passenger being picked up in response to a transportation request. In one embodiment, passenger detection system 104 detects the location of a user (e.g., passenger) based on one or more beacons received from a mobile device operated by the user. Although passenger detection system 104 is shown as a separate component in FIG. 1, in alternate embodiments, obstacle detection system 104 may be incorporated into automated driving/assi stance system 102 or any other vehicle component. [0023] The vehicle control system 100 also includes one or more sensor systems/devices for detecting a presence of nearby objects (or obstacles) or determining a location of a parent vehicle (e.g., a vehicle that includes the vehicle control system 100). For example, the vehicle control system 100 may include one or more radar systems 106, one or more LIDAR systems 108, one or more camera systems 110, a global positioning system (GPS) 112, and/or ultrasound systems 114. The one or more camera systems 110 may include a rear-facing camera mounted to the vehicle (e.g., a rear portion of the vehicle), a front-facing camera, and a side-facing camera. Camera systems 110 may also include one or more interior cameras that capture images of passengers and other objects inside the vehicle. The vehicle control system 100 may include a data store 116 for storing relevant or useful data for navigation and safety, such as map data, driving history, or other data. The vehicle control system 100 may also include a transceiver 118 for wireless communication with a mobile or wireless network, other vehicles, infrastructure, or any other communication system.

[0024] The vehicle control system 100 may include vehicle control actuators 120 to control various aspects of the driving of the vehicle such as electric motors, switches or other actuators, to control braking, acceleration, steering, seat belt tension, door locks, or the like. The vehicle control system 100 may also include one or more displays 122, speakers 124, or other devices so that notifications to a human driver or passenger may be provided. A display 122 may include a heads-up display, dashboard display or indicator, a display screen, or any other visual indicator, which may be seen by a driver or passenger of a vehicle. The speakers 124 may include one or more speakers of a sound system of a vehicle or may include a speaker dedicated to driver or passenger notification. [0025] It will be appreciated that the embodiment of FIG. 1 is given by way of example only. Other embodiments may include fewer or additional components without departing from the scope of the disclosure. Additionally, illustrated components may be combined or included within other components without limitation.

[0026] In one embodiment, the automated driving/assi stance system 102 is configured to control driving or navigation of a parent vehicle. For example, the automated driving/assi stance system 102 may control the vehicle control actuators 120 to drive a path on a road, parking lot, driveway or other location. For example, the automated driving/assi stance system 102 may determine a path based on information or perception data provided by any of the components 106-118. A path may also be determined based on a route that maneuvers the vehicle to avoid or mitigate a potential collision with another vehicle or object. The sensor systems/devices 106-110 and 114 may be used to obtain real-time sensor data so that the automated driving/assistance system 102 can assist a driver or drive a vehicle in real-time.

[0027] FIG. 2 is a block diagram illustrating an embodiment of passenger detection system 104. As shown in FIG. 2, passenger detection system 104 includes a communication manager 202, a processor 204, and a memory 206. Communication manager 202 allows passenger detection system 104 to communicate with other systems, such as automated driving/assistance system 102 and data sources providing virtual training data. Additionally, communication manager allows passenger detection system 104 to communicate with remote systems, such as remote servers and mobile devices, as discussed herein. Processor 204 executes various instructions to implement the functionality provided by passenger detection system 104, as discussed herein. Memory 206 stores these instructions as well as other data used by processor 204 and other modules and components contained in passenger detection system 104. [0028] Additionally, passenger detection system 104 includes a cellular network manager 208 that supports the communication of data to one or more remote devices via a cellular communication network. As discussed herein, passenger detection system 104 may

communicate with servers, mobile devices, and other systems via a cellular communication network. A Wi-Fi manager 210 supports the communication of data between passenger detection system 104 and other systems via one or more Wi-Fi communication networks. Wi-Fi is also referred to as the IEEE 802.11 standard. A Bluetooth manager 212 supports the communication of data between passenger detection system 104 and other systems via one or more Bluetooth communication links. In some embodiments, Bluetooth manager 212 supports communication using Bluetooth Low Energy (BLE).

[0029] Passenger detection system 104 also includes a pseudonym manager 214 that receives and handles one or more pseudonyms received from a remote server. As discussed herein, the pseudonyms are provided from the server to the passenger detection system 104 and a mobile device to temporarily identify the mobile device without exposing the actual mobile device identity to passenger detection system 104. A passenger location module 216 allows passenger detection system 104 to determine whether a passenger (e.g., a user of a mobile device requesting transport) is near passenger detection system 104 and determine an approximate distance from passenger detection system 104 to the passenger. A passenger validation module 218 confirms that a signal received from a user's mobile device matches the data associated with a particular transportation request. Additional details regarding the operation of the components and systems within passenger detection system 104 are provided below.

[0030] FIG. 3 illustrates an embodiment of a user 302 communicating with a vehicle 306 and a server 308 through a mobile device 304. In a particular situation, user 302 needs transportation from a current location to a destination. User 302 generates a transportation request using mobile device 304 (e.g., using an application on mobile device 304 or accessing a transportation request website using mobile device 304). Mobile device 304 includes any type of device carried by or operated by user 302 and capable of interacting with the systems described herein. Example mobile devices 304 include cellular phones, smartphones, laptop computers, tablet computers, wearable devices, and the like. As discussed herein, mobile device 304 typically includes Wi-Fi or Bluetooth capability. In some embodiments, mobile device 304 includes both Wi-Fi and Bluetooth capability.

[0031] The transportation request generated by the user is provided to server 308. In some embodiments, server 308 is a cloud-based server accessible by any number of devices via the Internet. Upon receiving the transportation request, server 308 identifies a vehicle capable of fulfilling the transportation request. In the example of FIG. 3, vehicle 306 is the identified vehicle. Server 308 communicates the transportation request to vehicle 306. Passenger detection system 104 in vehicle 306 receives and processes the transportation request as discussed herein. Vehicle 306 and mobile device 304 may then communicate in a manner that allows vehicle 306 to detect the location (or approximate location) of mobile device 304.

[0032] In some embodiments, mobile device 304 communicates with server 308 via a cellular communication network, a Wi-Fi communication network, or any other data

communication network (or combination of data communication networks). Similarly, passenger detection system 104 in vehicle 306 communicates with server 308 via a cellular communication network, a Wi-Fi communication network, or any other data communication network (or combination of data communication networks). Additionally, mobile device 304 may communicate with passenger detection system 104 in vehicle 306 via a cellular communication network, a Wi-Fi communication network, or any other data communication network (or combination of data communication networks).

[0033] In some embodiments, mobile device 304 and passenger detection system 104 in vehicle 306 communicate with one another via server 308. Mobile device 304 transmits a Wi-Fi beacon and/or a Bluetooth beacon which may be received by passenger detection system 104 in vehicle 306. Other than the one or more beacons, mobile device 304 and passenger detection system 104 in vehicle 306 do not communicate with one another directly.

[0034] FIG. 4 illustrates an embodiment of a method 400 for initiating a user

transportation request. Initially, a user requests 402, via a mobile device (e.g., mobile device 304), transportation from a current location to a destination. In some embodiments, the user's transportation request may describe a specific pickup location that is different from the user's current location. The mobile device communicates 404 the user's transportation request to a server (e.g., server 308). In some embodiments, the mobile device communicates additional information to the server, such as the mobile device's current location, a desired pickup location, a mobile device type, a mobile device model number, a mobile device MAC (Media Access Control) address (e.g., the MAC address of the mobile device's Wi-Fi interface and/or Bluetooth interface), whether the mobile device has Wi-Fi capability, whether the mobile device has Bluetooth capability, and the like.

[0035] Method 400 continues as the server creates 406 a pseudonym associated with the user's transportation request. The pseudonym is used to temporarily identify the mobile device without exposing the actual mobile device identity to passenger detection system 104. For example, the pseudonym is used as a temporal identity of the mobile device for the purpose of a single transportation request. After the transportation request is completed, the pseudonym is deleted. A new pseudonym is generated for each future transportation request generated via the mobile device. Using the pseudonym as a temporal identity of the mobile device prevents tracking of the mobile device (and the user) by an external entity and protects against device identity spoofing.

[0036] The server also selects 408 a vehicle to fulfill the user's transportation request. The pseudonym is communicated 410 from the server to the mobile device and to the passenger detection system in the selected vehicle. Thus, both the mobile device and the passenger detection system are operating with the same pseudonym, which is associated with the particular transportation request. The server also communicates 412 a user location and other mobile device information to the passenger detection system. The other mobile device information communicated to the passenger detection system includes, for example, the mobile device's current location, a desired pickup location, a mobile device type, a mobile device model number, a mobile device MAC address, whether the mobile device has Wi-Fi capability, whether the mobile device has Bluetooth capability, and the like.

[0037] Method 400 continues as the server communicates 414 information associated with the selected vehicle to the mobile device. This information associated with the selected vehicle includes, for example, a location of the vehicle, the estimated arrival time of the vehicle at the pickup location, the type of vehicle, the color of the vehicle, a license plate number of the vehicle, and the like.

[0038] The selected vehicle then begins driving 416 toward the user's current location or the identified pickup location. Additionally, the mobile device begins broadcasting 418 a Wi-Fi beacon and/or a Bluetooth beacon at an expected pickup time. In some embodiments, the mobile device begins broadcasting one or more beacons at a predetermined time prior to the expected pickup time, such as 2-5 minutes before the expected pickup time. In other embodiments, the mobile device begins broadcasting one or more beacons as soon as the transportation request is confirmed by the server (e.g., as soon as the mobile device receives the pseudonym from the server). In particular implementations, a Wi-Fi beacon is a WLAN (Wireless Local Area Network) probe request message with a pseudonym in the SSID (Service Set Identifier) field.

[0039] A Wi-Fi beacon uses Wi-Fi communication techniques to transmit small amounts of data a short distance, such as several thousand feet. In some implementations, a typical Wi-Fi range is 600-1000 feet with a typical smartphone. The effective Wi-Fi range can be increased by using a high-gain antenna, a low frequency band, or increasing the transmitting power. In some embodiments, a Wi-Fi beacon includes the information needed for passenger detection system 104 to identify mobile device 304 as the source of the beacon, such as SSID, supporting rates, and network capability information. In a particular implementation, mobile device 304 operates as a Wi-Fi beacon by using a WLAN probe request frame. As noted herein, the WLAN probe request frame includes the pseudonym, such that only passenger detection system 104 (which received the same pseudonym) can interpret the WLAN probe request frame. This

implementation eliminates the need for a direct Wi-Fi connection between passenger detection system 104 and mobile device 304.

[0040] Similarly, a Bluetooth beacon uses Bluetooth (or BLE) communication techniques to transmit small amounts of data a short distance, such as several hundred feet. In some implementations, a typical Bluetooth range is 30-300 feet. The effective Bluetooth range can be increased by using a high-gain antenna, a low frequency band, or increasing the transmitting power. In some embodiments, a Bluetooth beacon includes the information needed for passenger detection system 104 to identify mobile device 304 as a source of the beacon. [0041] As discussed in greater detail below, the range of a Bluetooth beacon is typically shorter than a Wi-Fi beacon. If a particular mobile device only has Wi-Fi or Bluetooth capabilities, the mobile device generates a beacon using the capability supported by the mobile device. If a mobile device has both Wi-Fi and Bluetooth capabilities, the mobile device may broadcast both a Wi-Fi beacon and a Bluetooth beacon. If the mobile device generates both a Wi-Fi beacon and a Bluetooth beacon, both beacons may contain the same information (and the same pseudonym) or they may contain different information. In some embodiments, the same information (including the same pseudonym) is contained in both the Wi-Fi beacon and the Bluetooth beacon to make it easier for the passenger detection system to identify the passenger with the same pseudonym observed from different network protocols.

[0042] FIG. 5 illustrates an embodiment of a method 500 for locating a user who initiated the transportation request. Initially, the selected vehicle drives 502 toward the user's current location (or the pickup location). The passenger detection system in the selected vehicle periodically determines whether the vehicle is within 504 a predetermined distance of the pickup location. When the vehicle is within the predetermined distance, the passenger detection system in the selected vehicle begins searching 506 for a Wi-Fi beacon or a Bluetooth beacon from the user's mobile device. When the passenger detection system in the selected vehicle identifies a beacon, the passenger detection system validates 508 the received beacon to confirm that the beacon is from the mobile device associated with the specific transportation request. For example, the validation 508 may include determining that the received beacon has a pseudonym that matches the pseudonym provided by the server for the transportation request. Additionally, the validation 508 may include confirming the MAC address data in the beacon and other data identifying the source of the beacon. In some embodiments, a hashed value of the beacon message is included in the message using a pre-shared key. This is useful in preventing beacon forgery or replay attacks.

[0043] Method 500 continues as the passenger detection system determines 510 a signal strength of the received Wi-Fi or Bluetooth beacon. For example, the passenger detection system may measure the strength of the received beacon signal. If both a Wi-Fi beacon and a Bluetooth beacon are received, the passenger detection system determines 510 a signal strength of each beacon. Next, the passenger detection system determines 512 a distance from the selected vehicle to the mobile device (i.e., the device broadcasting the beacon) based on the signal strength of the beacon and information associated with the mobile device. The signal strength of the beacon diminishes as the beacon moves farther away from the mobile device. The information associated with the mobile device lets the passenger detection system determine the initial broadcasting strength of the particular mobile device. Thus, based on the measured strength of the received beacon signal and the known broadcasting strength of the particular mobile device, the passenger detection system can determine a distance from the selected vehicle based on how much the beacon signal has diminished. In some embodiments, the strength of the beacon signal is proportional to l/d ^A n, where d is the distance between the transmitter and the receiver, and n is a path-loss exponent varying with the surrounding environment. However, the random nature of wireless signals makes distance estimation somewhat inaccurate. To overcome this inaccuracy, various signal distance estimations may be used. For example, signal strength fingerprinting is a particular estimation technique for distance estimations with wireless signals.

[0044] The selected vehicle continues driving 514 toward the user's current location (or the designated pickup location) until the user is identified. In some embodiments, the vehicle searches for a parking location or a temporary stopping zone that allows the user to easily access the vehicle.

[0045] FIG. 6 illustrates a diagram of mobile device 304 broadcasting a Bluetooth beacon 606 and a Wi-Fi beacon 608 in an environment 600, according to one embodiment. Typically, the range of a Bluetooth beacon is less than the range of a Wi-Fi beacon. Circle 602 shows an approximate Bluetooth beacon range when broadcasting a Bluetooth beacon from mobile device 304. Circle 604 shows an approximate Wi-Fi beacon range when broadcasting a Wi-Fi beacon from mobile device 304. In the example of FIG. 6, vehicle 306 is outside

Bluetooth range (indicated by circle 602), but vehicle 306 is within Wi-Fi range (indicated by circle 604). Thus, at its present location, vehicle 306 receives Wi-Fi beacon 608 from mobile device 304. If vehicle 306 moves closer to mobile device 304 such that the vehicle is within the Bluetooth range, then vehicle 306 may also receive Bluetooth beacon 606. When mobile device 304 transmits both Bluetooth beacon 606 and Wi-Fi beacon 608, the passenger detection system in vehicle 306 can provide a better distance estimate by analyzing the signal strength of both beacons.

[0046] FIG. 7 A illustrates an example Wi-Fi beacon structure 700 that includes an 802.11 MAC header 702, an MSDU (MAC-layer Service Data Unit) 704, and an FCS (Frame Check Sequence). MSDU 704 may include the pseudonym (also referred to as an SSID (Service Set Identifier)) 710 and other data elements 708 and 712. In some embodiments, the Wi-Fi beacon is sent using conventional WLAN broadcast probing, which allows the mobile device to send out a Wi-Fi beacon regardless of its current Wi-Fi connection status.

[0047] FIG. 7B illustrates an example Bluetooth beacon structure 720 that includes a BLE PDU (Protocol Data Unit) header 722 and a BLE PDU payload 724. BLE PDU payload 724 may include the pseudonym 728 and other data elements 726 and 730. In some embodiments, the BLE beacon contains a pseudonym in the payload of a BLE advertising channel PDU using existing message formats and protocols for the BLE standard. Although FIG. 7B illustrates the use of a BLE beacon, a similar beacon structure may be used with a Bluetooth beacon or any other type of beacon.

[0048] While various embodiments of the present disclosure are described herein, it should be understood that they are presented by way of example only, and not limitation. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the spirit and scope of the disclosure. Thus, the breadth and scope of the present disclosure should not be limited by any of the described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. The description herein is presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of the disclosed teaching. Further, it should be noted that any or all of the alternate implementations discussed herein may be used in any combination desired to form additional hybrid implementations of the disclosure.