US20230267187A1 - Autonomous vehicle authentication key delivery - Google Patents
Autonomous vehicle authentication key delivery Download PDFInfo
- Publication number
- US20230267187A1 US20230267187A1 US18/142,246 US202318142246A US2023267187A1 US 20230267187 A1 US20230267187 A1 US 20230267187A1 US 202318142246 A US202318142246 A US 202318142246A US 2023267187 A1 US2023267187 A1 US 2023267187A1
- Authority
- US
- United States
- Prior art keywords
- vehicle
- user
- pin
- server
- mobile device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 description 27
- 230000008569 process Effects 0.000 description 26
- 238000010586 diagram Methods 0.000 description 12
- 238000004891 communication Methods 0.000 description 9
- 238000012795 verification Methods 0.000 description 7
- 230000001815 facial effect Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000004913 activation Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000002485 combustion reaction Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000446 fuel Substances 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
- B60R25/20—Means to switch the anti-theft system on or off
- B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
- B60R25/20—Means to switch the anti-theft system on or off
- B60R25/25—Means to switch the anti-theft system on or off using biometry
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/041—Key generation or derivation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
- H04W12/0433—Key management protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
Definitions
- the present disclosure generally relates to vehicle authentications. More specifically, the present disclosure relates to vehicle authentication using a passcode.
- a user may hail a ride using a mobile device such as a mobile phone.
- a mobile device such as a mobile phone.
- a digital key may be generated and sent to both the vehicle and the mobile device for user authentication.
- a user may use a personal identification number (PIN) for quick access to the autonomous vehicle.
- PIN personal identification number
- a server includes one or more processors, programmed to responsive to receiving, from a mobile device of a user, a hailing request that identifies the user as requesting to schedule a ride, select a vehicle to respond to the hailing request based on a capacity to accept an encryption key of the vehicle, the hailing request including a user profile, generate an encryption key to authenticate the mobile device of the user with the vehicle, send the encryption key to both the vehicle and the mobile device to schedule the ride.
- a vehicle includes one or more wireless transceivers; a keypad external to the vehicle; and one or more controllers, programmed to responsive to receiving, via the one or more wireless transceivers, from a server, a mission payload message that identifies a user to schedule a ride, the mission payload message including a passcode and an encryption key, store the passcode and encryption key as an associated pair in a storage of the vehicle, responsive to receiving an input entered via the keypad matching the passcode, form a wireless connection between a mobile device and the one or more wireless transceivers, and authenticate the mobile device over the wireless connection using the encryption key.
- a method for a server includes responsive to receiving, from a mobile device, a hailing request including a user passcode, selecting a vehicle to respond to the hailing request based on a capacity to accept an encryption key of the vehicle; verifying the user passcode against an existing passcode of a different user scheduled to ride with the vehicle to detect a passcode collision; responsive to detecting a passcode collision, obtaining biometric information of the user from the mobile device; generating an encryption key to authenticate the mobile device with the vehicle; sending the passcode, the encryption key, and the biometric information of the user to the vehicle; and receiving a biometric data update collected by a sensor of the vehicle and store the biometric data update for future use.
- FIG. 1 illustrates an example block topology of a vehicle system of one embodiment of the present disclosure
- FIG. 2 illustrates an example schematic diagram of the vehicle system of one embodiment of the present disclosure
- FIG. 3 illustrates a flow diagram of the vehicle system of one embodiment of the present disclosure
- FIG. 4 illustrates a flow diagram for a process to resolve a PIN collision of one embodiment of the present disclosure
- FIG. 5 illustrates a flow diagram for a process to resolve a PIN collision of another embodiment of the present disclosure
- FIG. 6 illustrates a flow diagram for a process to resolve a PIN collision of yet another embodiment of the present disclosure.
- FIG. 7 illustrates a flow diagram for a process to resolve a PIN collision of yet another embodiment of the present disclosure.
- the present disclosure generally provides for a plurality of circuits or other electrical devices. All references to the circuits and other electrical devices, and the functionality provided by each, are not intended to be limited to encompassing only what is illustrated and described herein. While particular labels may be assigned to the various circuits or other electrical devices, such circuits and other electrical devices may be combined with each other and/or separated in any manner based on the particular type of electrical implementation that is desired.
- any circuit or other electrical device disclosed herein may include any number of microprocessors, integrated circuits, memory devices (e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants thereof) and software which co-act with one another to perform operation(s) disclosed herein.
- any one or more of the electric devices may be configured to execute a computer-program that is embodied in a non-transitory computer readable medium that is programed to perform any number of the functions as disclosed.
- the present disclosure proposes a system for ride hailing service authentications. More specifically, the present disclosure proposes a system for digital key and PIN authentication for shared ride hailing services.
- a hailing service user may use a mobile device application to place an order with an autonomous vehicle for a ride. Responsive to a hailing request from mobile device of the user, a server may identify and select one of multiple autonomous vehicles to respond, and issue a consumer access key (CAK) to both the vehicle and the mobile device for authentications.
- the CAK may be an encryption key configured for the vehicle and the mobile device to identify and authenticate each other for the scheduled ride.
- a PIN defined by the user may be used for quick identification and access. The PIN may consist of a limited digit of numbers (e.g. a 5-digit number) memorized by the user. Once at the vehicle, the user may manually input the PIN onto an exterior keypad of the vehicle for identification purposes.
- the PIN input may allow the vehicle to identify the user faster providing a better user experience.
- the CAK and the PIN may remain inactive until a given window prior to the ride pickup time.
- the CAK and PIN activation and usage may be controlled by an authentication manager implemented by a computer or controller of the vehicle.
- the authentication manager may keep track of an associated index of each digital key on the authentication device.
- the autonomous vehicle may be shared by multiple users. Each user may define his/her own PIN. If multiple users having the same PIN and are assigned to the same autonomous vehicle, the PIN collision may cause confusion on the vehicle side.
- a vehicle 102 may include various types of automobile, crossover utility vehicle (CUV), sport utility vehicle (SUV), truck, recreational vehicle (RV), boat, plane, or other mobile machine for transporting people or goods.
- CMV crossover utility vehicle
- SUV sport utility vehicle
- RV recreational vehicle
- boat plane, or other mobile machine for transporting people or goods.
- the vehicle 102 may be powered by an internal combustion engine.
- the vehicle 102 may be a battery electric vehicle (BEV), a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a plug-in hybrid electric vehicle (PHEV), or a parallel/series hybrid vehicle (PSHEV), a boat, a plane or other mobile machine for transporting people or goods.
- BEV battery electric vehicle
- HEV hybrid electric vehicle
- SHEV series hybrid electric vehicle
- PHEV plug-in hybrid electric vehicle
- PSHEV parallel/series hybrid vehicle
- boat a plane or other mobile machine for transporting people or goods.
- the system 100 may include the SYNC system manufactured by The Ford Motor Company of Dearborn, Michigan. It should be noted that the illustrated system 100 is merely an example, and more, fewer, and/or differently located elements may be used.
- a computing platform 104 may include one or more processors 106 configured to perform instructions, commands, and other routines in support of the processes described herein.
- the computing platform 104 may be configured to execute instructions of vehicle applications 108 to provide features such as navigation, digital key processing, and wireless communications.
- Such instructions and other data may be maintained in a non-volatile manner using a variety of types of computer-readable storage medium 110 .
- the computer-readable medium 110 also referred to as a processor-readable medium or storage
- Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL/SQL.
- the computing platform 104 may be provided with various features allowing the vehicle occupants/users to interface with the computing platform 104 .
- the computing platform 104 may receive input from human-machine interface (HMI) controls 112 configured to provide for occupant interaction with the vehicle 102 .
- HMI human-machine interface
- the computing platform 104 may interface with one or more buttons (not shown) or other HMI controls configured to invoke functions on the computing platform 104 (e.g., steering wheel audio buttons, a push-to-talk button, instrument panel controls, etc.).
- the computing platform 104 may also drive or otherwise communicate with one or more displays 114 configured to provide visual output to vehicle occupants by way of a video controller 116 .
- the display 114 may be a touch screen further configured to receive user touch input via the video controller 116 , while in other cases the display 114 may be a display only, without touch input capabilities.
- the computing platform 104 may also drive or otherwise communicate with one or more speakers 118 configured to provide audio output and input to vehicle occupants by way of an audio controller 120 .
- the computing platform 104 may also be provided with navigation and route planning features through a navigation controller 122 configured to calculate navigation routes responsive to user input via e.g., the HMI controls 112 , and output planned routes and instructions via the speaker 118 and the display 114 .
- Location data that is needed for navigation may be collected from a global navigation satellite system (GNSS) controller 124 configured to communicate with multiple satellites and calculate the location of the vehicle 102 .
- GNSS controller 124 may be configured to support various current and/or future global or regional location systems such as global positioning system (GPS), Galileo, Beidou, Global Navigation Satellite System (GLONASS) and the like.
- Map data used for route planning may be stored in the storage 110 as a part of the vehicle data 126 .
- Navigation software may be stored in the storage 110 as a part of the vehicle applications 108 .
- the computing platform 104 may be configured to wirelessly communicate with a mobile device 128 of the vehicle users/occupants via a wireless connection 130 .
- the mobile device 128 may be any of various types of portable computing devices, such as cellular phones, tablet computers, wearable devices, smart watches, smartfobs, laptop computers, portable music players, or other device capable of communication with the computing platform 104 .
- a wireless transceiver 132 may be in communication with a Wi-Fi controller 134 , a BLUETOOTH controller 136 , a radiofrequency identification (RFID) controller 138 , a near-field communication (NFC) controller 140 , and other controllers such as a Zigbee transceiver, an IrDA transceiver, an ultra-wide bandwidth (UWB) controller (not shown), and configured to communicate with a compatible wireless transceiver 142 of the mobile device 128 .
- RFID radiofrequency identification
- NFC near-field communication
- UWB ultra-wide bandwidth
- the mobile device 128 may be provided with a processor 144 configured to perform instructions, commands, and other routines in support of the processes such as navigation, telephone, wireless communication, and multi-media processing.
- the mobile device 128 may be provided with location and navigation functions via a navigation controller 146 and a GNSS controller 148 .
- the mobile device 128 may be provided with a wireless transceiver 142 in communication with a Wi-Fi controller 150 , a BLUETOOTH controller 152 , a RFID controller 154 , an NFC controller 156 , and other controllers (not shown), configured to communicate with the wireless transceiver 132 of the computing platform 104 .
- the mobile device 128 may be further provided with a non-volatile storage 158 to store various mobile application 160 and mobile data 162 .
- the computing platform 104 may be further configured to communicate with various components of the vehicle 102 via one or more in-vehicle network 166 .
- the in-vehicle network 166 may include, but is not limited to, one or more of a controller area network (CAN), an Ethernet network, and a media-oriented system transport (MOST), as some examples.
- CAN controller area network
- MOST media-oriented system transport
- the in-vehicle network 166 , or portions of the in-vehicle network 166 may be a wireless network accomplished via BLE, Wi-Fi, UWB, or the like.
- the computing platform 104 may be configured to communicate with various ECUs 168 of the vehicle 102 configured to perform various options.
- the computing platform may be configured to communicate with a TCU 170 configured to control telecommunication between vehicle 102 and a wireless network 172 through a wireless connection 174 using a modem 176 .
- the wireless connection 174 may be in the form of various communication network e.g. a cellular network.
- the vehicle may access one or more servers 178 to access various content for various purposes.
- the terms wireless network and server are used as general terms in the present disclosure and may include any computing network involving carriers, router, computers, controllers or the like configured to store data and perform data processing functions and facilitate communication between various entities.
- the ECUs 168 may further include an autonomous driving controller (ADC) 180 configured to provide autonomous driving features to the vehicle 102 .
- the ADC 180 may be remotely controlled via instructions from the server 178 received via the TCU 170 .
- the ECUs 168 may further include a biometric controller 182 configured to verify and authenticate biometric information of a user.
- the biometric controller 182 may be in communication with various biometric sensors configured to collect biometric data of the user.
- the biometric sensors may include a camera 184 configured to capture a facial image of the user.
- the biometric sensors may further include a fingerprint reader 186 configured to collect fingerprints of the user for authentications.
- the initial enrollment may be done automatically the first time a user rides an autonomous vehicle, where the user may be prompted to perform a series of gestures for biometric acquisition (or alternatively acquisition may happen passively if the sensors are integrated in a collaborative fashion).
- the ECUs 168 may further include a vehicle body control module (BCM) 188 configured to control various body operations of the vehicle 102 .
- BCM vehicle body control module
- the BCM 188 may be connected to a keypad 190 exterior to the vehicle body configured to receive a PIN input from the vehicle user for identification and authentication purposes.
- the keypad 190 include a device or touch interface configured to receive a user touch input.
- the keypad may be configured to support alphanumeric character inputs for more complex PINs.
- a user 202 may reserve a ride using the mobile device 128 with a hailing application as one of mobile applications 160 .
- the mobile device 128 may further have a user profile 204 associated with the user 202 stored on the storage 158 as a part of mobile data 162 .
- the user profile 204 may include various information related to the user 202 .
- the user profile 204 may include a PIN of the user 202 for identifications.
- the PIN may consist of a limited number of digits numeral or alphanumeric characters.
- the user 202 may manually input the PIN 206 onto the keypad 190 of the vehicle 102 to gain access to the vehicle 102 .
- the PIN 206 of preferably set by the user 202 for easy memorization. Alternatively, identifications such as user names may be used by the vehicle for quick access.
- the vehicle 102 may be programmed to display user names of reserved ride on a touch screen display 114 exterior to the vehicle 104 and ask the user to tap on the corresponding name to identify the user.
- the user profile 204 may further include biometric information 208 of the user 202 such as facial recognition and/or fingerprint data for further verifications.
- the user 202 may send a hailing request using the mobile device 128 to the server 178 via the wireless network 172 .
- the hailing request may include the ride information such as pickup location, destination or time, as well as the user profile 204 .
- the server 178 may determine which vehicle 102 is admissible to respond.
- the server 178 may verify, among multiple vehicles, which one is suitable for scheduling and has sufficient key access remaining. Each vehicle may have a limited capacity to accept CAKs at a given time, such that only a limited number of rides may be scheduled on a given vehicle at once.
- the server 178 selects the vehicle 102 to respond to the hailing request from the user 202 and sends a mission payload message to the vehicle 102 .
- the mission payload message may include the CAK generated for the scheduled ride, the ride information (e.g. time and location), as well as identification of the user 202 .
- the mission payload message may include the PIN of the user 202 to the vehicle for quick identifications.
- the mission payload message may further include a profile of the user indicative of a level of authorization to use the vehicle 102 .
- the TCU 170 Responsive to receiving the mission payload message from the server 178 , the TCU 170 may gateway the message to an authentication manager for processing and storage.
- the authentication manager may be implemented via various components of the vehicle 102 .
- the authentication manger may be implemented via the computing platform 104 or the ADC 180 . Taking the computing platform 104 for instance, if the computing platform 104 operating as the authentication manager accepts the mission payload, an acknowledgement is sent to the server 178 noting the key delivery is complete. Additionally, the computing platform 104 may store the CAK and PIN in the storage 110 . Additionally or alternatively, the computing platform 104 may map the CAK and PIN to each respective authentication module, i.e. the BLUETOOH controller and BCM 188 respectively, for storage where the authentication manager controls digital key activity.
- the CAK and PIN are kept inactive until the ride is initiated, where the activation (and eventual removal post ride) may be governed by a journey manager.
- the computing platform 104 may gateway the CAK 210 to the BLUETOOTH controller 136 , in case the wireless connection between the vehicle 102 and the mobile device 128 is a BLUETOOTH low energy (BLE) connection, and the PIN 206 to the BCM 188 for storage and easier access. If, however, the computing platform 104 decline the mission payload for some reasons (e.g. insufficient fuel), a response is sent to the server 178 and the server 178 may reselect another vehicle to respond the hailing request of the user 202 .
- BLE BLUETOOTH low energy
- the server 178 may send a mission message to the mobile device 128 to identify the vehicle 102 as selected. Additionally, the mission message may include the CAK 210 generated by the server for authentication with the vehicle 102 . Responsive to a successful receipt and storage of the CAK, the mobile device 128 may send an acknowledgement to the server 178 .
- the server 178 may be configured to perform a check against the PIN 206 a of a first party 202 a when scheduling additional parties 202 n onto a pooled ride before sending the mission payload message to the vehicle 102 .
- the server 178 may send a request for the second user 202 n to create a temporary PIN for the ride.
- the user may enter a new PIN to use for only this particular ride.
- the server 178 may be configured to issue the temporary PIN to the second user 202 n .
- the second user 202 n may be further provided with an option to permanently change the current PIN at this time.
- the server 178 may alternatively disallow the second user 202 n to be in the same vehicle 102 with the first user 202 a . Instead, the server 178 may search for another vehicle 102 to respond the hailing request of the second user 202 n . Alternatively, the server may require the second user 202 n to provide additional identification information such as a birth day or username. In this case, the vehicle 102 may ask the user 202 to input the additional identification information after receiving the PIN 206 from the keypad 190 .
- additional identifications may be performed using the biometric information 208 of the user profile 204 .
- the user profile 204 may be built and updated each time the user 202 successfully authenticates into the vehicle 102 by taking a photo of the face of the user via the camera 184 and uploading the photo to the server 178 .
- the photo may be processed such that a face profile of the user 202 is generated.
- the mobile device 128 may send the facial image of the user 202 to the server 178 for recognition to provide additional identification.
- the biometric profile may be locally authenticated if the biometric profile is deployed with mission delivery.
- CAK collisions may be rare.
- the server 178 may be configured to re-issue a new CAK 210 to the second user 202 n to avoid the CAK collision.
- the user 202 uses the mobile device 128 to send a hailing request to the server 178 to reserve a ride.
- the hailing request may include various information regarding the ride requirement such as pickup time and location, as well as information about the user 202 such as a user identification and/or the full or part of the user profile 204 stored in the mobile device 128 .
- the user profile 204 may be previously uploaded and stored in the server 178 and therefore does not be sent with the hailing request.
- the server 178 determines which vehicle is to respond based on the number of available CAKs of candidate vehicles. For instance, the server 178 determines the vehicle 102 should respond the hailing request of the user 202 .
- the server 178 verifies the PIN 206 of the user sent along with the hailing request against PINs for other rides already assigned to the vehicle 102 . If the answer is a yes, the process has various options A - E to choose from to resolve this collision. For instance, the process may return to operation 304 and the server 178 may chose another vehicle to pick up the user 202 (Option A). Options B - E will be described in detail below.
- the process proceeds to operation 308 and the server 178 generates a CAK 210 for authentications between the vehicle 102 and the mobile device 128 . Since the CAK 210 is computer-generated, chances for CAK collisions may be very rare. However, the server 178 may still verify the CAK 210 against existing CAKs for the vehicle 102 at operation 308 . If a CAK collision is detected, the process returns to operation 308 to regenerate a CAK for the scheduled ride. Otherwise, the process proceeds to operation 312 and the server 178 sends a mission message to the mobile device 128 confirming a success reservation of the ride.
- the mobile device 128 sends an acknowledgement to the server 178 acknowledging the successful receipt of the mission message.
- the server 178 sends a mission payload message to the vehicle 102 .
- the mission payload message may include the CAK 210 for the scheduled ride, trip information such as pickup time, location, as well as user information such as user identification, the PIN 206 , biometric profile and personal settings. Additionally, the mission payload message may further include driving preference of the user such as autonomous driving or manual driving as applicable.
- the vehicle 102 sends an acknowledgement to the server 178 responsive to a successful validation of the mission payload.
- vehicle 102 may send a notice to the server 178 to inform about the declination (not shown). In this case, the process returns to operation 304 to reselect a different vehicle.
- the user 202 inputs his/her PIN 206 via the keypad 190 for verification. Responsive to a successful verification of the PIN 206 , the vehicle 102 identifies the user 202 and unlock the vehicle doors. Furthermore, the vehicle 102 may further identify the CAK 210 previously received and stored in the storage based on the user identification.
- the vehicle 102 authenticates the CAK 210 as associated with user 202 with the mobile device 128 . Responsive to a successful authentication, the user 202 starts to ride with the vehicle 102 .
- the vehicle 102 deletes the PIN 206 , the CAK 210 as well as other information about the user 202 or the trip after reaching the destination of the ride.
- the process 400 illustrates option B following operation 306 .
- the server 178 Responsive to detecting a PIN collision at operation 306 , the server 178 generates a temporary PIN for the current ride of the user 202 at operation 402 .
- the server 178 sends the temporary PIN to the mobile device 128 .
- the user 202 may use the temporary PIN for the current ride.
- the mobile device 128 may delete the temporary PIN from the storage.
- the server 178 sends the temporary PIN instead of the user PIN 206 to the vehicle for verification.
- FIG. 5 an example flow diagram for a process 500 to resolve a PIN collision of another embodiment of the present disclosure is illustrated.
- the process 500 illustrates option C following operation 306 .
- the server 178 sends a request for PIN to the mobile device to ask the user to input another PIN.
- the mobile device 128 outputs a message to ask the user to manually input a new PIN via an interface.
- the mobile device 128 receives a new PIN by the user 202 .
- the mobile device 128 askes if the user wants to use the new PIN as a permanent PIN. If the user selects yes, the process proceeds to operation 510 and the mobile device 128 saves the new PIN as permanent to replace the old one. Otherwise, the process proceeds to operation 512 and the mobile device 128 only use the new PIN for the current ride. After the ride is complete, the new PIN is discarded.
- the process 600 illustrates option D following operation 306 .
- the server 178 adds user information to the mission payload message for the vehicle 102 to perform additional authentication in addition to the PIN.
- the user information may include additional information included associated with user profile, such as a birth day, a security question or the like.
- the vehicle 102 prompts questions to ask the user 202 to provide the additional user information for further authentication at operation 604 .
- the user 202 inputs the additional user information via the keypad 190 . Responsive to a successful verification and identification of the user 202 , the process proceeds to operation 322 to authenticate the CAK.
- the process 700 illustrates option E following operation 306 .
- the server 178 Responsive to detecting a PIN collision at operation 306 , at operation 702 , the server 178 sends a request for biometric information to the mobile device 128 .
- This operation may be optional as the server 178 may already have the biometric information 208 of the user 202 .
- biometric information 208 may be send to the server 178 along with the hailing request at operation 302 .
- the mobile device 128 Responsive to receiving the request for biometric information, at operation 704 , the mobile device 128 sends the biometric information 208 to the server 178 .
- the vehicle 102 collects the biometric data of the use 202 via sensors such as the fingerprint reader 186 and the camera 184 , and verifies the data via the biometric controller 182 . Responsive to a successful verification, the process proceeds to operation 322 to authenticate the CAK 210 .
- the vehicle 102 sends the collected biometric data of the user 202 as an update to the server 178 . For instance, the facial image of the user 202 captured by the vehicle camera may be have different characteristics compared with the version captured by the mobile device camera. The updated biometric information from the vehicle 102 may help the server 178 build a more comprehensive and robust database to verifications.
Abstract
A server includes one or more processors, programmed to responsive to receiving, from a mobile device of a user, a hailing request that identifies the user as requesting to schedule a ride, select a vehicle to respond to the hailing request based on a capacity to accept an encryption key of the vehicle, the hailing request including a user profile, generate an encryption key to authenticate the mobile device of the user with the vehicle, send the encryption key to both the vehicle and the mobile device to schedule the ride.
Description
- This application is a divisional of U.S. Application Serial No. 16/566,653 filed Sep. 10, 2019, the disclosure of which is hereby incorporated in its entirety by reference herein.
- The present disclosure generally relates to vehicle authentications. More specifically, the present disclosure relates to vehicle authentication using a passcode.
- Ride hailing services have become increasingly popular. A user may hail a ride using a mobile device such as a mobile phone. With the development of autonomous driving technology, a user may be able to hail an autonomous vehicle for a ride. A digital key may be generated and sent to both the vehicle and the mobile device for user authentication. Additionally, a user may use a personal identification number (PIN) for quick access to the autonomous vehicle.
- In one or more illustrative embodiments of the present disclosure, a server includes one or more processors, programmed to responsive to receiving, from a mobile device of a user, a hailing request that identifies the user as requesting to schedule a ride, select a vehicle to respond to the hailing request based on a capacity to accept an encryption key of the vehicle, the hailing request including a user profile, generate an encryption key to authenticate the mobile device of the user with the vehicle, send the encryption key to both the vehicle and the mobile device to schedule the ride.
- In one or more illustrative embodiments of the present disclosure, a vehicle includes one or more wireless transceivers; a keypad external to the vehicle; and one or more controllers, programmed to responsive to receiving, via the one or more wireless transceivers, from a server, a mission payload message that identifies a user to schedule a ride, the mission payload message including a passcode and an encryption key, store the passcode and encryption key as an associated pair in a storage of the vehicle, responsive to receiving an input entered via the keypad matching the passcode, form a wireless connection between a mobile device and the one or more wireless transceivers, and authenticate the mobile device over the wireless connection using the encryption key.
- In one or more illustrative embodiments of the present disclosure, a method for a server includes responsive to receiving, from a mobile device, a hailing request including a user passcode, selecting a vehicle to respond to the hailing request based on a capacity to accept an encryption key of the vehicle; verifying the user passcode against an existing passcode of a different user scheduled to ride with the vehicle to detect a passcode collision; responsive to detecting a passcode collision, obtaining biometric information of the user from the mobile device; generating an encryption key to authenticate the mobile device with the vehicle; sending the passcode, the encryption key, and the biometric information of the user to the vehicle; and receiving a biometric data update collected by a sensor of the vehicle and store the biometric data update for future use.
- For a better understanding of the invention and to show how it may be performed, embodiments thereof will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:
-
FIG. 1 illustrates an example block topology of a vehicle system of one embodiment of the present disclosure; -
FIG. 2 illustrates an example schematic diagram of the vehicle system of one embodiment of the present disclosure; -
FIG. 3 illustrates a flow diagram of the vehicle system of one embodiment of the present disclosure; -
FIG. 4 illustrates a flow diagram for a process to resolve a PIN collision of one embodiment of the present disclosure; -
FIG. 5 illustrates a flow diagram for a process to resolve a PIN collision of another embodiment of the present disclosure; -
FIG. 6 illustrates a flow diagram for a process to resolve a PIN collision of yet another embodiment of the present disclosure; and -
FIG. 7 illustrates a flow diagram for a process to resolve a PIN collision of yet another embodiment of the present disclosure. - As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
- The present disclosure generally provides for a plurality of circuits or other electrical devices. All references to the circuits and other electrical devices, and the functionality provided by each, are not intended to be limited to encompassing only what is illustrated and described herein. While particular labels may be assigned to the various circuits or other electrical devices, such circuits and other electrical devices may be combined with each other and/or separated in any manner based on the particular type of electrical implementation that is desired. It is recognized that any circuit or other electrical device disclosed herein may include any number of microprocessors, integrated circuits, memory devices (e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants thereof) and software which co-act with one another to perform operation(s) disclosed herein. In addition, any one or more of the electric devices may be configured to execute a computer-program that is embodied in a non-transitory computer readable medium that is programed to perform any number of the functions as disclosed.
- The present disclosure, among other things, proposes a system for ride hailing service authentications. More specifically, the present disclosure proposes a system for digital key and PIN authentication for shared ride hailing services.
- A hailing service user may use a mobile device application to place an order with an autonomous vehicle for a ride. Responsive to a hailing request from mobile device of the user, a server may identify and select one of multiple autonomous vehicles to respond, and issue a consumer access key (CAK) to both the vehicle and the mobile device for authentications. The CAK may be an encryption key configured for the vehicle and the mobile device to identify and authenticate each other for the scheduled ride. Additionally, a PIN defined by the user may be used for quick identification and access. The PIN may consist of a limited digit of numbers (e.g. a 5-digit number) memorized by the user. Once at the vehicle, the user may manually input the PIN onto an exterior keypad of the vehicle for identification purposes. Since the vehicle may process the PIN faster than authenticate the CAK, the PIN input may allow the vehicle to identify the user faster providing a better user experience. In one example, the CAK and the PIN may remain inactive until a given window prior to the ride pickup time. The CAK and PIN activation and usage may be controlled by an authentication manager implemented by a computer or controller of the vehicle. The authentication manager may keep track of an associated index of each digital key on the authentication device. However, due to the sharing nature of hailing services, the autonomous vehicle may be shared by multiple users. Each user may define his/her own PIN. If multiple users having the same PIN and are assigned to the same autonomous vehicle, the PIN collision may cause confusion on the vehicle side.
- Referring to
FIG. 1 , an example block topology of a vehicle system 100 of one embodiment of the present disclosure is illustrated. Avehicle 102 may include various types of automobile, crossover utility vehicle (CUV), sport utility vehicle (SUV), truck, recreational vehicle (RV), boat, plane, or other mobile machine for transporting people or goods. In many cases, thevehicle 102 may be powered by an internal combustion engine. As another possibility, thevehicle 102 may be a battery electric vehicle (BEV), a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a plug-in hybrid electric vehicle (PHEV), or a parallel/series hybrid vehicle (PSHEV), a boat, a plane or other mobile machine for transporting people or goods. As an example, the system 100 may include the SYNC system manufactured by The Ford Motor Company of Dearborn, Michigan. It should be noted that the illustrated system 100 is merely an example, and more, fewer, and/or differently located elements may be used. - As illustrated in
FIG. 1 , acomputing platform 104 may include one ormore processors 106 configured to perform instructions, commands, and other routines in support of the processes described herein. For instance, thecomputing platform 104 may be configured to execute instructions ofvehicle applications 108 to provide features such as navigation, digital key processing, and wireless communications. Such instructions and other data may be maintained in a non-volatile manner using a variety of types of computer-readable storage medium 110. The computer-readable medium 110 (also referred to as a processor-readable medium or storage) includes any non-transitory medium (e.g., tangible medium) that participates in providing instructions or other data that may be read by theprocessor 106 of thecomputing platform 104. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL/SQL. - The
computing platform 104 may be provided with various features allowing the vehicle occupants/users to interface with thecomputing platform 104. For example, thecomputing platform 104 may receive input from human-machine interface (HMI) controls 112 configured to provide for occupant interaction with thevehicle 102. As an example, thecomputing platform 104 may interface with one or more buttons (not shown) or other HMI controls configured to invoke functions on the computing platform 104 (e.g., steering wheel audio buttons, a push-to-talk button, instrument panel controls, etc.). - The
computing platform 104 may also drive or otherwise communicate with one ormore displays 114 configured to provide visual output to vehicle occupants by way of avideo controller 116. In some cases, thedisplay 114 may be a touch screen further configured to receive user touch input via thevideo controller 116, while in other cases thedisplay 114 may be a display only, without touch input capabilities. Thecomputing platform 104 may also drive or otherwise communicate with one ormore speakers 118 configured to provide audio output and input to vehicle occupants by way of anaudio controller 120. - The
computing platform 104 may also be provided with navigation and route planning features through anavigation controller 122 configured to calculate navigation routes responsive to user input via e.g., the HMI controls 112, and output planned routes and instructions via thespeaker 118 and thedisplay 114. Location data that is needed for navigation may be collected from a global navigation satellite system (GNSS)controller 124 configured to communicate with multiple satellites and calculate the location of thevehicle 102. TheGNSS controller 124 may be configured to support various current and/or future global or regional location systems such as global positioning system (GPS), Galileo, Beidou, Global Navigation Satellite System (GLONASS) and the like. Map data used for route planning may be stored in thestorage 110 as a part of thevehicle data 126. Navigation software may be stored in thestorage 110 as a part of thevehicle applications 108. - The
computing platform 104 may be configured to wirelessly communicate with amobile device 128 of the vehicle users/occupants via a wireless connection 130. Themobile device 128 may be any of various types of portable computing devices, such as cellular phones, tablet computers, wearable devices, smart watches, smartfobs, laptop computers, portable music players, or other device capable of communication with thecomputing platform 104. Awireless transceiver 132 may be in communication with a Wi-Fi controller 134, aBLUETOOTH controller 136, a radiofrequency identification (RFID)controller 138, a near-field communication (NFC)controller 140, and other controllers such as a Zigbee transceiver, an IrDA transceiver, an ultra-wide bandwidth (UWB) controller (not shown), and configured to communicate with acompatible wireless transceiver 142 of themobile device 128. - The
mobile device 128 may be provided with aprocessor 144 configured to perform instructions, commands, and other routines in support of the processes such as navigation, telephone, wireless communication, and multi-media processing. For instance, themobile device 128 may be provided with location and navigation functions via anavigation controller 146 and a GNSS controller 148. Themobile device 128 may be provided with awireless transceiver 142 in communication with a Wi-Fi controller 150, aBLUETOOTH controller 152, aRFID controller 154, anNFC controller 156, and other controllers (not shown), configured to communicate with thewireless transceiver 132 of thecomputing platform 104. Themobile device 128 may be further provided with anon-volatile storage 158 to store variousmobile application 160 andmobile data 162. - The
computing platform 104 may be further configured to communicate with various components of thevehicle 102 via one or more in-vehicle network 166. The in-vehicle network 166 may include, but is not limited to, one or more of a controller area network (CAN), an Ethernet network, and a media-oriented system transport (MOST), as some examples. Furthermore, the in-vehicle network 166, or portions of the in-vehicle network 166, may be a wireless network accomplished via BLE, Wi-Fi, UWB, or the like. - The
computing platform 104 may be configured to communicate withvarious ECUs 168 of thevehicle 102 configured to perform various options. For instance, the computing platform may be configured to communicate with aTCU 170 configured to control telecommunication betweenvehicle 102 and awireless network 172 through awireless connection 174 using amodem 176. Thewireless connection 174 may be in the form of various communication network e.g. a cellular network. Through thewireless network 172, the vehicle may access one ormore servers 178 to access various content for various purposes. It is noted that the terms wireless network and server are used as general terms in the present disclosure and may include any computing network involving carriers, router, computers, controllers or the like configured to store data and perform data processing functions and facilitate communication between various entities. TheECUs 168 may further include an autonomous driving controller (ADC) 180 configured to provide autonomous driving features to thevehicle 102. TheADC 180 may be remotely controlled via instructions from theserver 178 received via theTCU 170. - The
ECUs 168 may further include abiometric controller 182 configured to verify and authenticate biometric information of a user. Thebiometric controller 182 may be in communication with various biometric sensors configured to collect biometric data of the user. For instance, the biometric sensors may include acamera 184 configured to capture a facial image of the user. The biometric sensors may further include afingerprint reader 186 configured to collect fingerprints of the user for authentications. The initial enrollment may be done automatically the first time a user rides an autonomous vehicle, where the user may be prompted to perform a series of gestures for biometric acquisition (or alternatively acquisition may happen passively if the sensors are integrated in a collaborative fashion). TheECUs 168 may further include a vehicle body control module (BCM) 188 configured to control various body operations of thevehicle 102. For instance, theBCM 188 may be connected to akeypad 190 exterior to the vehicle body configured to receive a PIN input from the vehicle user for identification and authentication purposes. Thekeypad 190 include a device or touch interface configured to receive a user touch input. Alternatively, the keypad may be configured to support alphanumeric character inputs for more complex PINs. - Referring to
FIG. 2 , a schematic diagram 200 of one embodiment of the present disclosure is illustrated. With continuing reference toFIG. 1 , in the present example, auser 202 may reserve a ride using themobile device 128 with a hailing application as one ofmobile applications 160. Themobile device 128 may further have auser profile 204 associated with theuser 202 stored on thestorage 158 as a part ofmobile data 162. Theuser profile 204 may include various information related to theuser 202. For instance, theuser profile 204 may include a PIN of theuser 202 for identifications. The PIN may consist of a limited number of digits numeral or alphanumeric characters. Upon approaching avehicle 102 that is reserved, theuser 202 may manually input thePIN 206 onto thekeypad 190 of thevehicle 102 to gain access to thevehicle 102. ThePIN 206 of preferably set by theuser 202 for easy memorization. Alternatively, identifications such as user names may be used by the vehicle for quick access. Thevehicle 102 may be programmed to display user names of reserved ride on atouch screen display 114 exterior to thevehicle 104 and ask the user to tap on the corresponding name to identify the user. Theuser profile 204 may further includebiometric information 208 of theuser 202 such as facial recognition and/or fingerprint data for further verifications. - To hail a ride, the
user 202 may send a hailing request using themobile device 128 to theserver 178 via thewireless network 172. The hailing request may include the ride information such as pickup location, destination or time, as well as theuser profile 204. Responsive to receiving the hailing request, theserver 178 may determine whichvehicle 102 is admissible to respond. Theserver 178 may verify, among multiple vehicles, which one is suitable for scheduling and has sufficient key access remaining. Each vehicle may have a limited capacity to accept CAKs at a given time, such that only a limited number of rides may be scheduled on a given vehicle at once. In the present example, assuming thevehicle 102 qualifies the above conditions, theserver 178 selects thevehicle 102 to respond to the hailing request from theuser 202 and sends a mission payload message to thevehicle 102. The mission payload message may include the CAK generated for the scheduled ride, the ride information (e.g. time and location), as well as identification of theuser 202. For instance, the mission payload message may include the PIN of theuser 202 to the vehicle for quick identifications. The mission payload message may further include a profile of the user indicative of a level of authorization to use thevehicle 102. Responsive to receiving the mission payload message from theserver 178, theTCU 170 may gateway the message to an authentication manager for processing and storage. The authentication manager may be implemented via various components of thevehicle 102. For instance, the authentication manger may be implemented via thecomputing platform 104 or theADC 180. Taking thecomputing platform 104 for instance, if thecomputing platform 104 operating as the authentication manager accepts the mission payload, an acknowledgement is sent to theserver 178 noting the key delivery is complete. Additionally, thecomputing platform 104 may store the CAK and PIN in thestorage 110. Additionally or alternatively, thecomputing platform 104 may map the CAK and PIN to each respective authentication module, i.e. the BLUETOOH controller andBCM 188 respectively, for storage where the authentication manager controls digital key activity. The CAK and PIN are kept inactive until the ride is initiated, where the activation (and eventual removal post ride) may be governed by a journey manager. Alternatively, thecomputing platform 104 may gateway theCAK 210 to theBLUETOOTH controller 136, in case the wireless connection between thevehicle 102 and themobile device 128 is a BLUETOOTH low energy (BLE) connection, and thePIN 206 to theBCM 188 for storage and easier access. If, however, thecomputing platform 104 decline the mission payload for some reasons (e.g. insufficient fuel), a response is sent to theserver 178 and theserver 178 may reselect another vehicle to respond the hailing request of theuser 202. In addition to sending the mission payload message to the vehicle, theserver 178 may send a mission message to themobile device 128 to identify thevehicle 102 as selected. Additionally, the mission message may include theCAK 210 generated by the server for authentication with thevehicle 102. Responsive to a successful receipt and storage of the CAK, themobile device 128 may send an acknowledgement to theserver 178. - Since the
PIN 206 used to access thevehicle 102 is defined by theuser 202, there may be situations that twousers 202 riding asingle vehicle 102 have thesame PIN 206. In this case, it may not be possible to identify theusers 202 upon entering thePIN 206 alone. To prevent such confusion, theserver 178 may be configured to perform a check against thePIN 206 a of afirst party 202 a when scheduling additional parties 202 n onto a pooled ride before sending the mission payload message to thevehicle 102. If thePIN 206 n of the second user 202 n is the same as thePIN 206 a of thefirst user 202 a, theserver 178 may send a request for the second user 202 n to create a temporary PIN for the ride. The user may enter a new PIN to use for only this particular ride. Alternatively, theserver 178 may be configured to issue the temporary PIN to the second user 202 n. The second user 202 n may be further provided with an option to permanently change the current PIN at this time. - Since changing the PIN, either temporarily or permanently, may cause confusion to the second user 202 n, the
server 178 may alternatively disallow the second user 202 n to be in thesame vehicle 102 with thefirst user 202 a. Instead, theserver 178 may search for anothervehicle 102 to respond the hailing request of the second user 202 n. Alternatively, the server may require the second user 202 n to provide additional identification information such as a birth day or username. In this case, thevehicle 102 may ask theuser 202 to input the additional identification information after receiving thePIN 206 from thekeypad 190. - Alternatively, additional identifications may be performed using the
biometric information 208 of theuser profile 204. Theuser profile 204 may be built and updated each time theuser 202 successfully authenticates into thevehicle 102 by taking a photo of the face of the user via thecamera 184 and uploading the photo to theserver 178. The photo may be processed such that a face profile of theuser 202 is generated. In the event that theuser 202 encounters a PIN collision, themobile device 128 may send the facial image of theuser 202 to theserver 178 for recognition to provide additional identification. Alternatively the biometric profile may be locally authenticated if the biometric profile is deployed with mission delivery. - Since the
CAK 210 is generated by theserver 178, CAK collisions may be rare. In case the CAK collision does happen, theserver 178 may be configured to re-issue anew CAK 210 to the second user 202 n to avoid the CAK collision. - Referring to
FIG. 3 , an example flow diagram for aride hailing process 300 of one embodiment of the present disclosure is illustrated. With continuing reference toFIGS. 1 and 2 , atoperation 302, theuser 202 uses themobile device 128 to send a hailing request to theserver 178 to reserve a ride. The hailing request may include various information regarding the ride requirement such as pickup time and location, as well as information about theuser 202 such as a user identification and/or the full or part of theuser profile 204 stored in themobile device 128. Alternatively, theuser profile 204 may be previously uploaded and stored in theserver 178 and therefore does not be sent with the hailing request. Responsive to receiving the hailing request, theserver 178 determines which vehicle is to respond based on the number of available CAKs of candidate vehicles. For instance, theserver 178 determines thevehicle 102 should respond the hailing request of theuser 202. Atoperation 306, theserver 178 verifies thePIN 206 of the user sent along with the hailing request against PINs for other rides already assigned to thevehicle 102. If the answer is a yes, the process has various options A - E to choose from to resolve this collision. For instance, the process may return tooperation 304 and theserver 178 may chose another vehicle to pick up the user 202 (Option A). Options B - E will be described in detail below. - If at
operation 306, theserver 178 verifies there is no PIN collision, the process proceeds tooperation 308 and theserver 178 generates aCAK 210 for authentications between thevehicle 102 and themobile device 128. Since theCAK 210 is computer-generated, chances for CAK collisions may be very rare. However, theserver 178 may still verify theCAK 210 against existing CAKs for thevehicle 102 atoperation 308. If a CAK collision is detected, the process returns tooperation 308 to regenerate a CAK for the scheduled ride. Otherwise, the process proceeds tooperation 312 and theserver 178 sends a mission message to themobile device 128 confirming a success reservation of the ride. Atoperation 314, themobile device 128 sends an acknowledgement to theserver 178 acknowledging the successful receipt of the mission message. Atoperation 316, theserver 178 sends a mission payload message to thevehicle 102. The mission payload message may include theCAK 210 for the scheduled ride, trip information such as pickup time, location, as well as user information such as user identification, thePIN 206, biometric profile and personal settings. Additionally, the mission payload message may further include driving preference of the user such as autonomous driving or manual driving as applicable. Atoperation 318, thevehicle 102 sends an acknowledgement to theserver 178 responsive to a successful validation of the mission payload. In case thatvehicle 102 cannot accept the mission payload due to various reasons such as insufficient fuel, thevehicle 102 may send a notice to theserver 178 to inform about the declination (not shown). In this case, the process returns tooperation 304 to reselect a different vehicle. - Once at the
vehicle 102, atoperation 320, theuser 202 inputs his/herPIN 206 via thekeypad 190 for verification. Responsive to a successful verification of thePIN 206, thevehicle 102 identifies theuser 202 and unlock the vehicle doors. Furthermore, thevehicle 102 may further identify theCAK 210 previously received and stored in the storage based on the user identification. Atoperation 322, thevehicle 102 authenticates theCAK 210 as associated withuser 202 with themobile device 128. Responsive to a successful authentication, theuser 202 starts to ride with thevehicle 102. Atoperation 324, thevehicle 102 deletes thePIN 206, theCAK 210 as well as other information about theuser 202 or the trip after reaching the destination of the ride. - Referring to
FIG. 4 , an example flow diagram for aprocess 400 to resolve a PIN collision of one embodiment of the present disclosure is illustrated. With continuing reference toFIG. 3 , theprocess 400 illustrates optionB following operation 306. Responsive to detecting a PIN collision atoperation 306, theserver 178 generates a temporary PIN for the current ride of theuser 202 atoperation 402. Atoperation 404, theserver 178 sends the temporary PIN to themobile device 128. Theuser 202 may use the temporary PIN for the current ride. After the ride is complete, themobile device 128 may delete the temporary PIN from the storage. Additionally, theserver 178 sends the temporary PIN instead of theuser PIN 206 to the vehicle for verification. - Referring to
FIG. 5 , an example flow diagram for aprocess 500 to resolve a PIN collision of another embodiment of the present disclosure is illustrated. With continuing reference toFIG. 3 , theprocess 500 illustrates optionC following operation 306. Responsive to detecting a PIN collision atoperation 306, theserver 178 sends a request for PIN to the mobile device to ask the user to input another PIN. Responsive to receiving the request, atoperation 504, themobile device 128 outputs a message to ask the user to manually input a new PIN via an interface. At operation 506, themobile device 128 receives a new PIN by theuser 202. Atoperation 508, themobile device 128 askes if the user wants to use the new PIN as a permanent PIN. If the user selects yes, the process proceeds to operation 510 and themobile device 128 saves the new PIN as permanent to replace the old one. Otherwise, the process proceeds tooperation 512 and themobile device 128 only use the new PIN for the current ride. After the ride is complete, the new PIN is discarded. - Referring to
FIG. 6 , an example flow diagram for aprocess 600 to resolve a PIN collision of another embodiment of the present disclosure is illustrated. With continuing reference toFIG. 3 , theprocess 600 illustrates optionD following operation 306. Responsive to detecting a PIN collision atoperation 306, theserver 178 adds user information to the mission payload message for thevehicle 102 to perform additional authentication in addition to the PIN. The user information may include additional information included associated with user profile, such as a birth day, a security question or the like. After the user inputting thePIN 206 atoperation 320, thevehicle 102 prompts questions to ask theuser 202 to provide the additional user information for further authentication at operation 604. Atoperation 606, theuser 202 inputs the additional user information via thekeypad 190. Responsive to a successful verification and identification of theuser 202, the process proceeds tooperation 322 to authenticate the CAK. - Referring to
FIG. 7 , an example flow diagram for aprocess 700 to resolve a PIN collision of another embodiment of the present disclosure is illustrated. With continuing reference toFIG. 3 , theprocess 700 illustrates optionE following operation 306. Responsive to detecting a PIN collision atoperation 306, atoperation 702, theserver 178 sends a request for biometric information to themobile device 128. This operation may be optional as theserver 178 may already have thebiometric information 208 of theuser 202. Alternatively,biometric information 208 may be send to theserver 178 along with the hailing request atoperation 302. Responsive to receiving the request for biometric information, at operation 704, themobile device 128 sends thebiometric information 208 to theserver 178. After the user entering thePIN 206, atoperation 706, thevehicle 102 collects the biometric data of theuse 202 via sensors such as thefingerprint reader 186 and thecamera 184, and verifies the data via thebiometric controller 182. Responsive to a successful verification, the process proceeds tooperation 322 to authenticate theCAK 210. Additionally, atoperation 708, thevehicle 102 sends the collected biometric data of theuser 202 as an update to theserver 178. For instance, the facial image of theuser 202 captured by the vehicle camera may be have different characteristics compared with the version captured by the mobile device camera. The updated biometric information from thevehicle 102 may help theserver 178 build a more comprehensive and robust database to verifications. - While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.
Claims (7)
1. A vehicle, comprising:
one or more wireless transceivers;
a keypad external to the vehicle; and
one or more controllers, programmed to
responsive to receiving, via the one or more wireless transceivers, from a server, a mission payload message that identifies a user to schedule a ride, the mission payload message including a passcode and an encryption key, store the passcode and encryption key as an associated pair in a storage of the vehicle,
responsive to receiving an input entered via the keypad matching the passcode, form a wireless connection between a mobile device and the one or more wireless transceivers, and
authenticate the mobile device over the wireless connection using the encryption key.
2. The vehicle of claim 1 , further comprising a biometric information sensor, wherein the mission payload message further includes biometric information of the user, and
the one or more controllers are further programmed to:
responsive to the input entered via the keypad matching the passcode, activate the biometric information sensor to collect user biometric data, and
verify the user biometric data collected by the biometric information sensor matches the biometric information received in the mission payload message.
3. The vehicle of claim 2 , wherein the one or more controllers are further programmed to:
upload the user biometric data collected by the biometric information sensor to the server to update the biometric information of the user.
4. The vehicle of claim 2 , wherein the biometric information sensor includes at least one of: a fingerprint reader, or a camera.
5. The vehicle of claim 1 , wherein the mission payload message further includes additional authentication information of the user,
the one or more controllers are further programmed to:
responsive detecting the matching passcode, prompt a message inviting the user to enter the additional authentication information to verify an identity of the user.
6. The vehicle of claim 1 , wherein the one or more controllers are further programmed to:
responsive to a completion of the ride as scheduled, delete the passcode and the encryption key from the storage of the vehicle.
7. The vehicle of claim 1 , wherein the one or more wireless transceivers include a telematics control unit.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/142,246 US20230267187A1 (en) | 2019-09-10 | 2023-05-02 | Autonomous vehicle authentication key delivery |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/566,653 US11681788B2 (en) | 2019-09-10 | 2019-09-10 | Autonomous vehicle authentication key delivery |
US18/142,246 US20230267187A1 (en) | 2019-09-10 | 2023-05-02 | Autonomous vehicle authentication key delivery |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/566,653 Division US11681788B2 (en) | 2019-09-10 | 2019-09-10 | Autonomous vehicle authentication key delivery |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230267187A1 true US20230267187A1 (en) | 2023-08-24 |
Family
ID=74645092
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/566,653 Active 2041-08-22 US11681788B2 (en) | 2019-09-10 | 2019-09-10 | Autonomous vehicle authentication key delivery |
US18/142,246 Pending US20230267187A1 (en) | 2019-09-10 | 2023-05-02 | Autonomous vehicle authentication key delivery |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/566,653 Active 2041-08-22 US11681788B2 (en) | 2019-09-10 | 2019-09-10 | Autonomous vehicle authentication key delivery |
Country Status (3)
Country | Link |
---|---|
US (2) | US11681788B2 (en) |
CN (1) | CN112492542A (en) |
DE (1) | DE102020123237A1 (en) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20210031267A (en) * | 2019-09-11 | 2021-03-19 | 삼성전자주식회사 | Vehicle electronic device for performing authentication, mobile device for vehicle authentication, vehicle authentication system, and authentication method for vehicle |
US11537701B2 (en) * | 2020-04-01 | 2022-12-27 | Toyota Motor North America, Inc. | Transport related n-factor authentication |
US20220176997A1 (en) * | 2020-12-07 | 2022-06-09 | Waymo Llc | Enabling content playing in autonomous vehicles of a transportation service |
US11843946B2 (en) * | 2021-04-01 | 2023-12-12 | Cujo LLC | Device-specific wireless access point password authentication |
US20220408245A1 (en) * | 2021-06-21 | 2022-12-22 | Motional Ad Llc | Session key generation for autonomous vehicle operation |
US11792644B2 (en) | 2021-06-21 | 2023-10-17 | Motional Ad Llc | Session key generation for autonomous vehicle operation |
US11820330B2 (en) * | 2021-09-28 | 2023-11-21 | Capital One Services, Llc | Provisioning a vehicle experience according to an authentication of a driver for the vehicle experience |
US11884238B2 (en) * | 2021-10-21 | 2024-01-30 | Zoox, Inc. | Vehicle door interface interactions |
WO2023076858A1 (en) * | 2021-10-27 | 2023-05-04 | Atieva, Inc. | Authentication mechanism for vehicle mode or vehicle function |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150161832A1 (en) * | 2013-12-05 | 2015-06-11 | Ford Global Technologies, Llc | Method and Apparatus for Virtual Key Delivery |
US20210329461A1 (en) * | 2018-08-30 | 2021-10-21 | Koninklijke Philips N.V. | Non-3gpp device access to core network |
US20220198863A1 (en) * | 2019-05-31 | 2022-06-23 | Igloocompany Pte. Ltd. | Authentication input device |
US20220292411A1 (en) * | 2009-10-08 | 2022-09-15 | Unho Choi | Method and system for providing equipment rental service using biometric id card |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9436816B2 (en) * | 2010-12-16 | 2016-09-06 | Microsoft Technology Licensing, Llc | Supplementing biometric identification with device identification |
US9365188B1 (en) * | 2011-04-22 | 2016-06-14 | Angel A. Penilla | Methods and systems for using cloud services to assign e-keys to access vehicles |
US11580562B2 (en) * | 2011-10-25 | 2023-02-14 | Alexander Song | Anti-fraud financial transactions system |
US10223719B2 (en) * | 2013-03-25 | 2019-03-05 | Steven B. Schoeffler | Identity authentication and verification |
US10700856B2 (en) * | 2013-11-19 | 2020-06-30 | Network-1 Technologies, Inc. | Key derivation for a module using an embedded universal integrated circuit card |
US9691204B2 (en) | 2014-02-04 | 2017-06-27 | Ford Global Technologies, Llc | Method and apparatus for secure vehicle system access from a remote system |
KR101675728B1 (en) * | 2015-01-05 | 2016-11-14 | 주식회사 슈프리마 | Method and apparatus for processing user authentification using information processing device |
US9961076B2 (en) * | 2015-05-11 | 2018-05-01 | Genesys Telecommunications Laboratoreis, Inc. | System and method for identity authentication |
WO2017136725A1 (en) * | 2016-02-04 | 2017-08-10 | Wenasont Dynamics Llc | System and method for vehicle authorization |
US10600040B1 (en) * | 2016-03-18 | 2020-03-24 | Wells Fargo Bank, N.A. | Automatic teller machine game-based transaction functionality |
US11412357B2 (en) * | 2019-04-30 | 2022-08-09 | Toyota Motor Engineering & Manufacturing North America, Inc. | System and method for providing services to vehicles |
US10589719B1 (en) * | 2019-05-30 | 2020-03-17 | Hyundai Autoever | Method for managing digital key of mobile device for vehicle-sharing and key server using the same |
-
2019
- 2019-09-10 US US16/566,653 patent/US11681788B2/en active Active
-
2020
- 2020-09-04 DE DE102020123237.3A patent/DE102020123237A1/en active Pending
- 2020-09-07 CN CN202010929685.3A patent/CN112492542A/en active Pending
-
2023
- 2023-05-02 US US18/142,246 patent/US20230267187A1/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220292411A1 (en) * | 2009-10-08 | 2022-09-15 | Unho Choi | Method and system for providing equipment rental service using biometric id card |
US20150161832A1 (en) * | 2013-12-05 | 2015-06-11 | Ford Global Technologies, Llc | Method and Apparatus for Virtual Key Delivery |
US20210329461A1 (en) * | 2018-08-30 | 2021-10-21 | Koninklijke Philips N.V. | Non-3gpp device access to core network |
US20220198863A1 (en) * | 2019-05-31 | 2022-06-23 | Igloocompany Pte. Ltd. | Authentication input device |
Also Published As
Publication number | Publication date |
---|---|
DE102020123237A1 (en) | 2021-03-11 |
US11681788B2 (en) | 2023-06-20 |
US20210073363A1 (en) | 2021-03-11 |
CN112492542A (en) | 2021-03-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230267187A1 (en) | Autonomous vehicle authentication key delivery | |
US9283856B2 (en) | Methods, systems and apparatus for authorizing operation of an electric vehicle that is being charged at a charging station | |
US9729707B2 (en) | Method and system to manage personalized vehicle user information | |
CN107872508B (en) | Relationship management for vehicle sharing systems | |
US10988044B2 (en) | Automatic plug-and-pay with multi-factor authentication for fueling vehicles | |
US10078924B2 (en) | Maintenance management for vehicle-share systems | |
US10939296B2 (en) | Vehicle smart connection | |
US11613217B2 (en) | Vehicle identity access management | |
US10229601B2 (en) | System and method to exhibit vehicle information | |
CN102156941A (en) | Urban convenient carpooling system and method thereof | |
US20180285846A1 (en) | System and method for parking violation risk management | |
JP7082536B2 (en) | Electric vehicle support system | |
US11094027B2 (en) | System and method to establish primary and secondary control of rideshare experience features | |
US10402212B2 (en) | Method and system for making available an assistance suggestion for a user of a motor vehicle | |
US11521442B2 (en) | System for preventing vehicle key fob relay attacks | |
CN113762553B (en) | Information processing apparatus, authentication system, information processing method, and non-transitory storage medium | |
JP7056370B2 (en) | Authentication information issuing device and delivery system | |
CN114266026A (en) | Biometric wireless vehicle entry system | |
US20200262393A1 (en) | Vehicle data protection | |
US10694488B2 (en) | Device location detection for enhanced device connection for vehicles | |
US20220258773A1 (en) | Autonomous Vehicle Rider Authentication, Boarding, And Drop Off Confirmation | |
US11569983B2 (en) | Vehicle digital key cloud storage | |
US20190318352A1 (en) | Wireless Digital Payment For Vehicles | |
US11563732B2 (en) | Systems and methods of multiple party authentication in autonomous vehicles | |
JP2021170296A (en) | Authentication system and authentication method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |