EP3463994A1 - Appareil, système et procédé d'accès à un véhicule et de commande de fonction en utilisant un dispositif portable - Google Patents
Appareil, système et procédé d'accès à un véhicule et de commande de fonction en utilisant un dispositif portableInfo
- Publication number
- EP3463994A1 EP3463994A1 EP17728494.0A EP17728494A EP3463994A1 EP 3463994 A1 EP3463994 A1 EP 3463994A1 EP 17728494 A EP17728494 A EP 17728494A EP 3463994 A1 EP3463994 A1 EP 3463994A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- vehicle
- access
- data
- fob
- function control
- 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
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/20—Individual registration on entry or exit involving the use of a pass
- G07C9/27—Individual registration on entry or exit involving the use of a pass with central registration
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00857—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- 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
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/40—Security arrangements using identity modules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
-
- 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]
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
- G07C2009/00388—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks code verification carried out according to the challenge/response method
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
- G07C2009/0042—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks the transmitted data signal containing a code which is changed
- G07C2009/00428—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks the transmitted data signal containing a code which is changed periodically after a time period
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00857—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed
- G07C2009/00865—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed remotely by wireless communication
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00857—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed
- G07C2009/00873—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the data carrier can be programmed by code input from the lock
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
- G07C9/00571—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated by interacting with a central unit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/84—Vehicles
Definitions
- the present disclosure is directed to vehicle security and access. More specifically, the present disclosure is directed to authenticating and/or authorizing users and dynamically identifying authorized users for one or more vehicles to allow access to vehicle functions such as door locks, ignition and the like. Additionally, the present disclosure is directed to providing customizable access and control of vehicle functions for authorized users.
- a keyless entry system is an electronic lock that controls access to a building or vehicle without using a traditional mechanical key.
- keyless entry system originally meant a lock controlled by a keypad located at or near the driver's door, that required pressing a predetermined (or self-programmed) numeric code for entry.
- remote keyless system also called keyless entry or remote central locking, refers to a lock that uses an electronic remote control as a key which is activated by a handheld device or automatically by proximity. Widely used in automobiles, an RKS performs the functions of a standard car key without physical contact. When within a few yards of the car, pressing a button on the remote can lock or unlock the doors, and may perform other functions.
- a remote keyless system can include both a remote keyless entry system (RKE), which unlocks the doors, and a remote keyless ignition system (RKI), which starts the engine.
- RKE remote keyless entry system
- RKI remote keyless ignition system
- Keyless remotes contain a short-range radio transmitter, and must be within a certain range, usually 5-20 meters, of the car to work. When a button is pushed, it sends a coded signal by radio waves to a receiver unit in the car, which locks or unlocks the door.
- Most RKEs operate at a frequency of 315 MHz for North America-made cars and at 433.92 MHz for European, Japanese and Asian cars. Modern systems implement encryption to prevent car thieves from intercepting and spoofing the signal.
- the functions of a remote keyless entry system are contained on a key fob or built into the ignition key handle itself. Buttons are dedicated to locking or unlocking the doors and opening the trunk or tailgate.
- trunks or tailgates may have a motorized assist that can both open and close the tailgate for easy access and remote operation.
- a smart key is an electronic access and authorization system that allows the driver to keep the key fob pocketed when unlocking, locking and starting the vehicle.
- the key is identified via one of several antennas in a car's bodywork and a radio pulse generator in the key housing.
- the vehicle is automatically unlocked when a button or sensor on the door handle or trunk release is pressed.
- Vehicles with a smart key system may be fitted with a mechanical backup, usually in the form of a spare key blade supplied with the vehicle.
- Technologies and techniques are needed to provide dynamic user access, among a plurality of users via secure communications while providing a positive user experience for access through passive keyless entry (PKE) and other similar devices. Furthermore, technologies and techniques are needed to provide customizable vehicle access and function control.
- PKE passive keyless entry
- a system for authorizing access to vehicle functions for a vehicle, comprising a processor; data storage, operatively coupled to the processor, the data storage configured to store (i) fob data relating to a key fob linked to the vehicle, (i) device data comprising data relating to one or more devices that are authorized to access the vehicle, and (iii) vehicle access and/or function control data; and communications circuitry, operatively coupled to the processor, the communications circuitry configured to communicate with a new device is requesting access to the vehicle, wherein the processor is configured to generate a secure fob key based on the fob data and the device data, and wherein the processor is configured to generate a vehicle function control file based on the vehicle access and/or function control data and the secure fob key, wherein the vehicle function control file is configured to authenticate the
- a method for authorizing access to vehicle functions for a vehicle comprising receiving, in a storage, fob data relating to a key fob linked to the vehicle; receiving, in the storage, device data comprising data relating to one or more devices that are authorized to access the vehicle; receiving, in the storage vehicle access and/or function control data; establishing communications, via communications circuitry, with a new device that is requesting access to the vehicle, generating, via a processor, a secure fob key based on the fob data and the device data; and generating, via the processor, a vehicle function control file based on the vehicle access and/or function control data and the secure fob key, wherein the vehicle function control file is configured to authenticate the new device with the vehicle via the secure fob key and to at least one of (i) limit access of the new device to the vehicle, (ii) limit an operational function of the vehicle, and (iii) provide alerts for the vehicle based on the vehicle access and/or function
- a vehicle for authorizing access for vehicle functions for a new device, comprising a processor; communications circuitry, operatively coupled to the processor, the communications circuitry configured to
- a new device is requesting access to the vehicle to receive a vehicle function control file comprising a secure fob key and vehicle access and/or function control data; wherein the processor is configured to authenticate the new device via the secure fob key, and, based on the authentication, apply the vehicle function control file to a vehicle system of the vehicle to at least one of (i) limit access of the new device to the vehicle, (ii) limit an operational function of the vehicle, and (iii) provide alerts for the vehicle based on the vehicle access and/or function control data.
- FIG. 1 illustrates a systematic overview of a vehicle system to provide access to a vehicle including a plurality of receivers to activate one or more vehicle functions;
- FIG. 2 schematically illustrates an approach of a vehicle user to a vehicle from different directions carrying an electronic device and a vehicle key
- FIG. 3 is an exemplary system illustrating vehicles paired with one or more portable devices and/or key fobs, wherein the portable devices are configured to
- FIG. 4 is an exemplary block diagram illustrating hardware components in a vehicle's electronics system, where a processor communicates and controls operation of door entry and ignition of a vehicle, and includes communications to send and receive data and/or instructions to the vehicle under an embodiment;
- FIG. 5 is an exemplary illustration of a wireless pairing/bonding configuration that further includes protocols for securely pairing/bonding devices and vehicles under an embodiment
- FIG. 6 shows an illustrative method for registering fob keys for a particular vehicle and/or user, along with user device data and identification for network storage to allow dynamically managing vehicle access under an illustrative embodiment
- FIG. 7 shows an operating environment for the server of FIG. 3 for securing dynamic access authentication for transmission to one or more devices under an illustrative embodiment
- FIG. 8 shows an operating environment for the processing device of FIG. 3 for authenticating vehicle access challenges under an illustrative embodiment
- FIG. 9 shows a process flow for registering and authenticating a user fob and device for authorizing access for at least one user under an illustrative embodiment
- FIG. 10 shows an example of an authorization table that indicates authorized users and fobs for a plurality of vehicles under an illustrative embodiment
- FIG. 11A shows an example of an authorization table for a plurality of users where device identification (ID) data, passwords and/or trusted fobs are registered for vehicle access under an illustrative embodiment
- FIG. 1 IB shows an example of an authorization table for a plurality of users where device identification (ID) data, passwords and/or trusted fobs, together with paired fobs and devices for specific users, are registered for vehicle access under an illustrative embodiment
- FIG. 12 shows a process for a vehicle to detect authorized fobs and devices and to transmit one or more challenges to authorized devices, and to activate a security function and/or transmit notifications to authorized devices if a proper response is not received under an illustrative embodiment
- FIGS. 13A-13C show various simplified examples of user devices, with and without an associated fob, approaching a vehicle and requesting access to a vehicle under illustrative embodiments;
- FIG. 14 shows a process flow for dynamically providing access and authentication from one device to another, where a registered and authenticated device allows recognition and access of other devices, along with access permissions under an illustrative embodiment
- FIG. 15 shows a system that includes a processing device and a server communicating via a network, wherein the system is configured to generate and manage fob keys between a device and a server for vehicle access and functions under an illustrative embodiment
- FIG. 16 shows a system for generating user profiles for creating customizable vehicle access and/or function control for fob keys under an illustrative embodiment
- FIG. 17 shows an example of a vehicle function control file that includes a fob key and vehicle access and/or function control data that may include vehicle access control data, vehicle function control data, alerts/messaging data and/or entertainment system control data under an illustrative embodiment
- FIG. 18 shows an interface for entering data for vehicle access and function control, wherein the data may be used for a vehicle function control file under an illustrative embodiment
- FIG. 19 shows illustrates a vehicle system block diagram showing multiple components and modules, for processing and executing vehicle function control files under one embodiment
- FIG. 20 shows a process flow for generating a fob key and vehicle function control file from associated control data and processing the vehicle function control data for application and execution on a vehicle under an illustrative embodiment.
- a computer program product in accordance with one embodiment comprises a tangible computer usable medium (e.g., hard drive, standard RAM, an optical disc, a USB drive, or the like) having computer- readable program code embodied therein, wherein the computer-readable program code is adapted to be executed by a processor (working in connection with an operating system) to implement one or more functions and methods as described below.
- a tangible computer usable medium e.g., hard drive, standard RAM, an optical disc, a USB drive, or the like
- the computer-readable program code is adapted to be executed by a processor (working in connection with an operating system) to implement one or more functions and methods as described below.
- the program code may be implemented in any desired language, and may be implemented as machine code, assembly code, byte code, interpretable source code or the like (e.g., via Scala Programming Language (Scala), C, C++, C#, Java, Actionscript, Objective-C, Javascript, CSS, XML, etc.).
- Scala Scala Programming Language
- C++ C++
- C# Java
- Java Actionscript
- Objective-C Javascript
- CSS XML
- XML XML
- the term "information” as used herein is to be understood as meaning digital information and/or digital data, and that the term “information” and “data” are to be interpreted as synonymous.
- a vehicle 200 may comprise a vehicle system 100 for activating at least one vehicle component 116.
- a vehicle component 116 can be any component at the vehicle that can be activated by at least another component inside or outside the vehicle 200. Further details of this configuration may be found in U.S. Pat. App. No. 14/065,996 to Akay, et al., titled “Vehicle System for Activating a Vehicle Component," filed Oct. 29, 2013, the contents of which are incorporated by reference in their entirety herein.
- the vehicle component 116 may be activated electrically either directly or indirectly through other components, for example, by components operative to switch or regulate electronic current or voltage, such as, but not limited to, mechanical or solid-state relays, semiconductor switches (silicon controlled rectifiers, transistors, MOSFET, CMOS devices, Insulated Gate Bipolar Transistors (IGBT) etc.).
- components operative to switch or regulate electronic current or voltage such as, but not limited to, mechanical or solid-state relays, semiconductor switches (silicon controlled rectifiers, transistors, MOSFET, CMOS devices, Insulated Gate Bipolar Transistors (IGBT) etc.).
- IGBT Insulated Gate Bipolar Transistors
- This signal processing procedure may apply to any other vehicle component 116 as well.
- FIG. 1 provides a systematic overview of a vehicle system 100 including a first and second receiver 112, 114 to activate a vehicle component 116 or function.
- a vehicle user is approaching a vehicle 200 with at least one electronic device 102 and a matching vehicle access key 104.
- the electronic device 102 is able to send out a wireless signal 106 to communicate with the first receiver 112 if the electronic device 102 is in a reception range 204 of the first receiver or other suitable signal.
- this signal can be a Bluetooth low energy signal or other suitable signal.
- Bluetooth low energy is specifically designed to draw very low amounts of power and therefore these sending and receiving devices are very energy efficient. Especially when used in a vehicle , these devices can receive wireless signals 106 for a long time without the need to be shut down due to their quiescent current demand when the vehicle 200 is parked.
- the first receiver 112 obtains a wireless signal 106 from the electronic device 102, when the device 102 is in the reception range 204 of the first receiver 112.
- the wireless signal 106 of the electronic device 102 may comprise first identification data.
- This identification data may comprise a Unique Device Identifier (UDID), an Android ID, an international mobile equipment identity (IMEI), an international mobile subscriber identity (IMSI), and/or a user-created ID that resides on device memory and/or firmware.
- the identification data comprises an identification code so that the vehicle system 100 can verify that a specific vehicle user carrying the electronic device 102 is in the reception range 204.
- the vehicle system 100 comprises a memory 110 or memory device in which second identification data is stored.
- the memory 110 is able to store more than one set of second identification data, including a reference identification data for authentication. This is beneficial in the case when more than one user uses the vehicle 200.
- the vehicle 200 By storing multiple sets of identification data the vehicle 200 is able to distinguish between the users and their preferences if the users each use a different set of first identification data.
- the identification data can also be dynamically generated and dynamically checked according to a predefined method to provide a higher level of safety when accessing the vehicle 200.
- the identification data can also be encrypted by the electronic device 102 and decrypted by the vehicle system 100.
- the first receiver 112 may send a control signal to the second receiver 114 to access a matching vehicle access key 104 by a wireless signal 108. If the second receiver 114 correctly identifies the vehicle key as a matching vehicle access key 104, at least one vehicle component 116 is activated or operated.
- Vehicle components 116 include but are not limited to an ignition system, immobilizer, a central locking system, a vehicle door, a vehicle trunk lid, an automatic tailgate, a fuel filler door, an electrical charging port door release, an electrical charging plug release, a window opener, a sunroof, a convertible roof system, a vehicle infotainment system, a navigation system, a radio system, a climate control, a seat or mirror adjustment, a steering wheel adjustment, a pedal adjustment, an exterior or interior vehicle light, a driver assistance system or a vehicle camera.
- a vehicle user can also activate at least one vehicle component 116 by directly sending the wireless signal 108 from the matching vehicle access key 104.
- capacitive sensors may detect such contact, and a keyless entry system may be activated and a receiver may detect the presence of a matching vehicle access key 104.
- the user interaction in vehicle system 100 may be advantageously more simplified. Not only can the central door locking system be activated at an earlier stage without the need of the user to touch a sensor but also the whole vehicle 200 or selected vehicle components 116 can be activated earlier. If the user does not have to touch a vehicle sensor to open the vehicle this is especially helpful if he is carrying something and returns to the vehicle. In this situation, the vehicle can additionally open the automatic tailgate.
- FIG. 2 schematically illustrates an approach of a vehicle user to a vehicle 200 from a plurality of directions carrying an electronic device 102 as well as a vehicle access key 104 according to an illustrative embodiment.
- the vehicle user is approaching the vehicle 200 from the rear.
- a dashed circle 204 schematically represents the reception range 204 of the first receiver 112.
- the vehicle user enters the reception range 204 of the first receiver 112.
- the first identification data of the electronic device 102 can now be received by the first receiver 112. If positively verified, the first receiver 112 wakes up the second receiver 114 and checks for a matching vehicle access key 104. If the matching vehicle access key 104 is detected, all vehicle doors are unlocked.
- the electronic device 102 stores the parking position and heading of the vehicle 200.
- the electronic device 102 is a smartphone with a global positioning system (GPS), along with motion or acceleration sensors.
- GPS global positioning system
- the electronic device 102 or a computer executable program on a server can determine the current position of the smart phone and the direction the user is approaching the vehicle position. If the user approaches the vehicle from the rear and enters the reception range 204 at point 202, the smart phone and the first receiver 112 start communicating with each other.
- the smart phone is identified as a device that has been successfully paired to exchange first identification data with the vehicle 200.
- a vehicle control command to activate a rear view camera 206 is sent to the vehicle 200.
- the vehicle system 100 notices that the user is waiting, for example more than a predefined time, e.g. more than 2 seconds, in the rear of the vehicle 200 and subsequently opens the trunk lid and activates an automatic trunk lid opener.
- the user enters the reception range 204 at a location 208 on the driver's side of the vehicle 200.
- the electronic device 102 or a remote server program analyses the GPS or motion data of the electronic device 102 and compares that to the direction and position of the vehicle 200. It is determined, that the user is approaching the vehicle 200 from the driver's side and subsequently unlocks the door on the driver's side.
- FIG. 3 discloses an exemplary embodiment of a vehicle authentication system
- key fobs may be distinguished from “fob keys” in that key fobs are specifically- designed hardware devices that are configured to operate exclusively or primarily with dedicated vehicle communications.
- fob keys are dedicated software components or modules that may be implemented on key fobs, and also on general-purpose processing devices (e.g., smart phone) as well.
- Servers 318 may comprise wired and/or wireless communication interfaces to receive vehicle data, portable device data and other data from portable devices 310, 312 as well as vehicles 302, 304. Additional data or instructions from computer 316 may be received via wired or wireless interface through network 314. While not explicitly shown in FIG. 3, servers 318 further comprise processors, storage and other peripheral devices known in the art to enable data processing and communication.
- portable devices 310, 312 may include any portable computing device capable of providing data communication over a wireless medium, including, but not limited to, a cellular phone, smart phone, tablet, laptop or PDA.
- vehicle 302 is linked to key fob 306, which may be configured to open or start vehicle 302.
- Key fob 302 may additionally be equipped with buttons (which may be luminous), other lights, and/or a keypad.
- Vehicle 302 may also be configured to be independently linked or paired with portable device 310 (i.e., without requiring an initial direct linking with a key fob), belonging to a first user. After being paired with vehicle 302 (discussed in greater detail below in FIG. 9), portable device 310 will be able to receive and transmit data and/or instructions to vehicle 302.
- the pairing of device 310 with vehicle 302 may be accomplished using any of a number of wireless communication protocols, including IEEE 802.15.4, Bluetooth, Wi-Fi, and NFC.
- portable device 310 may also be linked with key fob 306 to provide a path for wireless data communication as well.
- Vehicle 304 is linked to key fob 308 and device 312 belonging to a second user, similarly as described above.
- vehicles 302 and 304 may each be considered part of authenticated group 330, 340 linked to users of portable devices 310, 312, which may be family members, co-workers, drive-share groups and the like.
- portable devices 310, 312 may be family members, co-workers, drive-share groups and the like.
- devices 310, 312 may exchange data and/or instructions with each other (indicated by connecting arrow in FIG. 3), as well as vehicles 302, 304 of the authenticated group.
- portable device 310 would be configured to communicate with vehicles 302 and 304 as well as portable device 312, while portable device 312 would similarly be configured to communicate with vehicle 304 and 302, as well as portable device 310.
- This embodiment may be advantageously used to allow multiple members to communicate with and/or control multiple vehicles within their authentication group, and further allowing data to be communicated to or from portable devices in a group 101 independently, in parallel, or in a "daisy-chain" fashion.
- one authenticated device 310 may be used to provide authentication to one or more other devices .
- computer 316 may be used to authenticate and/or manage authentication of registered devices
- Portable devices 310, 312 may also be communicatively coupled to local computer 316, which may be located at a user's home, place of work, etc.
- Local computer 316 may be a personal computer, laptop, or any other computing device capable of performing processing operations as well as sending and receiving data communication.
- portable devices 310, 312 communicates with local computer 316 wirelessly.
- portable devices 310, 312 communicate with local computer 316 via a wired connection, which may include a dock or docking station (not shown).
- Local computer 316 may be suitably equipped with software allowing computer 316 to communicate with authentication network 314, which may include one or more servers 318.
- local computer 316 communicates to authentication network 314 via HTTP over TCP/IP using a web browser interface using Java, JavaScript, DHTML, HTML5, Flash, Silverlight or any other suitable language or platform.
- Portable devices 310, 312 may also be configured to directly communicate with authentication network 314 via wireless and/or cellular connection as shown in FIG. 3 utilizing an on-device software application (or "app"), or through a web-based or mobile browser.
- vehicles 302, 304 may be equipped with wireless communication to enable vehicles 302, 304 to also communicate wirelessly with authentication network 314, similar to portable devices 310, 312.
- vehicle authentication system 300 is configured to provide two-step or multi-step authentication for allowing entry and/or operation of vehicles 302 and/or 304.
- Two-step authentication also known as two-step verification
- multi-factor authentication which involves the presentation of two or more of three authentication factors: a possession factor, a knowledge factor and an inheritance factor.
- system 300 may execute a form of two-step verification. To determine who the individual is when accessing vehicle 302, system may require the detection of a key fob 306 to show the individual has possession of a required item.
- the system may alternately, or in addition, require the presence ("possession") of portable device 310 that is registered in the system.
- the individual may be required to enter a personal identification number (PIN) ("knowledge factor") on a door lock keypad on the surface of the vehicle door.
- PIN personal identification number
- the individual may be required to enter a PIN on the portable device 310, which is then communicated to vehicle 302 and/or authentication network 314.
- the individual may be required to physically press a button or series of buttons on key fob 306 for entering a PIN or authentication input.
- the vehicle may
- FIG. 4 an exemplary embodiment is provided illustrating components within a vehicle 302-304 for authentication, which may be incorporated into the embodiment of FIG. 1, or may be configured as a stand-alone system.
- Processor 402 is responsible for operating and controlling doors 202 and associated locking mechanisms, as well as engine 408 operations and control.
- processor 402 may be a stand-alone processor that communicates and controls a body controller in the vehicle to lock and unlock the doors 406, and further communicates with an immobilizer or engine control unit (ECU) for controlling operation of the vehicle.
- processor 402 may be two or more processors performing the same functions.
- the processors may be distributed among different units in the vehicle.
- the immobilizer may be embodied as static codes or rolling codes in a key fob or portable device that are recognized by an RFID loop around the lock barrel and checked against the vehicle's ECU for a match. If the code is not recognized, the ECU will not allow fuel to flow and ignition to take place.
- a circuit inside the key fob or portable device is activated by a small electromagnetic field which induces current to flow, which in turn broadcasts a unique binary code which is read by the vehicle's ECU.
- the ECU determines that the coded key is both current and valid, the ECU activates the fuel-injection sequence.
- Processor 402 is communicatively coupled to communications 412, which may comprise one or more communication interfaces and associated circuitry for sending and receiving data and/or instructions from one or more portable devices and/or an authentication network.
- Communications 412 may include wired interfaces, such as USB or Firewire, as well as wireless interfaces, such as Bluetooth, Wi-Fi or cellular communication.
- Antennas 414 may comprise one or more antennas for detecting the presence of key fobs and/or portable devices , and may be equipped with sensor technology (e.g., proximity sensors) for detecting a physical presence of a user.
- Antennas 414 may be integrated with
- Processor 402 is also coupled to storage 404 that may be configured to store software for executing authentication described herein, and also store data generated and/or received for authentication processing.
- Display/keypad 410 may be further provided to display information from processor 402 and to provide data entry capabilities for a user.
- the keypad may comprise a physical keypad, or may alternately be configured as a virtual keypad within the display as is known in the art.
- FIG. 5 the figure illustrates an exemplary configuration 500 for communication among portable device(s) 310, 312 and vehicle 302, 304 utilizing a Bluetooth protocol. The configuration is particularly useful for pairing and bonding portable devices to vehicles and to each other.
- two entities may become paired when they start with the same PIN and generate the same link key, and then use this key for authenticating at least a present communication session.
- the session can exist for the life of a L2CAP link or the life of an ACL link. Pairing can occur through an automatic authentication process if both devices already have the same stored PIN from which they can derive the same link keys for authentication. Alternatively, either or both applications can ask their respective users for manual PIN entry.
- Once entities are paired they can either store their link keys for use in subsequent authentications or discard them and repeat the pairing process each time they connect.
- Link keys are stored, then the devices are bonded, enabling future authentications to occur using the same link keys and without requiring the user to input the PIN again. Bonding can expire immediately after the link is disconnected, after a certain time period expires, or never (permanently bonded). When bonding expires, the entities must repeat the pairing process again.
- Users may generate, receive and/or send data, including identification data and/or authentication data via user interface module 502 coupled one or more applications 504, 506 that may communicate via transport protocols RFCOMM 510 coupled to L2CAP 512.
- Each of the user interface 502 applications 504, 506, RFCOMM 510 and L2CAP 512 may communicate with security manager 508.
- FIG. 5 an exemplary security management configuration is illustrated, that may be incorporated into a host software package on device(s) 310, 312 and vehicle(s) 302, 304.
- authentication and authorization can occur after determining the security level of the requested authentication service; in this case, authentication occurs after the ACL link is established. Of course, other authentication can occur with initial establishment of the ACL link.
- security manager 508 resides on the Bluetooth host and communicates with L2CAP 512 and with link manager/controller 516 through host control interface (HCI) 514.
- HCI host control interface
- a connect request from a portable device to a vehicle arrives at L2CAP 512, where the L2CAP 512 requests evaluation from security manager 508.
- Security manager 508 looks up the requested service in database 522 for security information, and looks the requesting device's BD ADDR or International Mobile Equipment Identity (IMEI) number in database 520 for access authorizations. Security manager 508 then begins the necessary authentication and (if needed) encryption procedures with the link manager 516 through HCI 514. If authentication is determined to be positive, link manager 512 provides a response through HCI 514, and L2CAP 512 finishes the connection setup process.
- the security manager architecture in FIG. 5 could be used to implement link-level (Mode 3) security as well.
- the configuration of FIG.5 may implement basic security operations primarily at the link manager/controller 516 levels.
- Link controller 516 can implement key-generating algorithms, random number processes, and basic communication of the various security parameters between a vehicle and a portable device .
- Link manager 516 provides a set of commands that enable the formation of link management protocol packets containing the security parameters.
- HCI 514 provides a means for the host to communicate security items to the Bluetooth module for use by the link manager controller 516.
- a PIN can be used as either a fixed number, preprogrammed into the Bluetooth unit, or a number that's entered by the user at the beginning of each secure session.
- a portable device and a vehicle can be provided the same PIN: if the portable device and vehicle are being set up to exchange files and/or data, then each can ask for a password, in which a common PIN is derived from the link keys.
- a vehicle may be set up with user authentication profiles comprising a database of BD ADDR/IMEI values and associated PIN codes.
- the security manager 508 can enter these via an encrypted Bluetooth link or through an ordinary cable connection.
- the application asks for a PIN (or retrieves one that was previously stored), from which the link keys are derived. If the user's PIN matches, then both devices create the same link key and authentication and, if needed, encryption can proceed successfully.
- the PIN may be associated with a user rather than with the device.
- An authentication key which also may operate as a link key, may be configured as 128 bits long and may be used by one device to insure that the other device is who it claims to be.
- the link key can either be temporary, where it is used for one session only (i.e., devices not bonded), or semi-permanent in which it is stored and used for several sessions or over a time period (i.e., devices bonded). Stored link keys are semi-permanent because they can be either changed or removed at a later time. As a result, paired and/or bonded devices can derive and store a new link key during each session if desired.
- the link key may be used to generate encryption keys, such as initialization keys, unit keys, combination keys and master keys.
- An initialization key is used as a link key when two devices first connect. It is normally created only once and used to protect the generation and transfer of other keys that are more secure than the initialization key.
- a unit key is on that is associated with a single Bluetooth device that has limited resources and can't store a large number of keys. This key is typically generated once and is not changed.
- a combination key is derived from inputs provided by both devices on a Bluetooth link and is considered more secure than a unit key. Unlike unit keys, a combination key is unique to a pair of devices, and not just one device.
- a master key is temporary and is used for the generation of an encryption key for broadcasting packets to multiple slaves.
- An encryption key may be used in a streaming algorithm to change plain text into cipher text and vice versa. The key can be as short as 8 bits and as long as 128 bits.
- the system may be configured to dynamically assign authentication and vehicle access and permissions.
- user devices may be configured to allow them to access and operate vehicle using their device, with or without a key fob.
- vehicle operations and functions e.g., comfort settings, infotainment preferences, on-demand purchased options, etc.
- vehicle operations and functions may also be enabled via a user's device.
- FIG. 6 shows a simplified flow diagram 600 for configuring a vehicle system for dynamic vehicle identification and access under an illustrative embodiment.
- one or more fob keys e.g., from key fob 306 and/or 308 are registered with a vehicle. Once registered, the fob keys may provide access to a vehicle and/or activate predetermined functions within the vehicle.
- one or more devices are registered to the vehicle. In one example, the first device registered to the vehicle should be associated with the key fob registered with the vehicle. Subsequent devices registered to the vehicle may be based on the key fob, or from authenticated permissions provided from a previously registered device.
- a vehicle may be configured to have a key fob that has two or more devices associated with it.
- a device associated with a key fob may grant authentication permission to another device.
- the system may register user and/or device identification (ID) which may include passwords and the like.
- the identification may include a UDID, an Android ID, an IMEI, an IMSI, and/or a user-created ID, where the identification and passwords may occur concurrently with device registration in block 604.
- an initial device registration may occur by pairing the device with the vehicle, whereupon a unique ID (e.g., IMEI) is transmitted from the device to the vehicle and securely stored.
- a unique ID e.g., IMEI
- the device may transmit a secondary ID (e.g., IMSI), which may be used to further secure/strengthen the first ID.
- IMSI secondary ID
- the device may be asked to provide a password that may be used to provide dynamic permissions to other users.
- the password may be an alphanumeric password, a key, a voice-recognition password, and/or a fingerprint password.
- voice-recognition and fingerprint technology is conventionally offered by manufacturers of devices (e.g., smart phones), these may be conveniently entered by users without requiring vehicle manufacturers to incorporate such technologies directly into the vehicle.
- the keys, IDs and/or passwords may be stored in storage in the vehicle and may further be stored in a network storage.
- the transmissions to the network storage may be performed from the vehicle equipped with wireless communication, from the device, or a combination of both.
- a security key may be used between the vehicle and the one or more devices to authenticate and authorize devices for accessing a vehicle and/or activating vehicle functions.
- an operating environment 700 may be executed on the server 318 and/or a vehicle for securing vehicle access codes under an illustrative embodiment. It should be understood by those skilled in the art that the operating environment 700 may be incorporated on other servers or devices, and that the present disclosure is not limited only to the server 318 or vehicle 302.
- a hash 712 may be created using security parameters 706 that may include a security header (HDR) for indicating payload encryption, and an associated key blob.
- a key blob may be configured to store encrypted keys to protect them when they are outside of a security boundary.
- a signature 714 may be created from the hash 712 and a private key 716, where the signature is associated 710 with the specific access code 708.
- a public key 718 may be used to create a root of trust 720.
- the operating environment 700 may be used to define a security boundary (or
- the root of trust 720 may be configured to store private (secret) data for the system, provide trusted functions and extend trust to other devices or entities via the functions and secrets.
- the root of trust may be configured as a hardware root of trust, which is typically more secure than a software-based root of trust.
- Data stored in the root of trust 720 includes, but is not limited to, chip master key or root key, authentication key(s), secure data storage key(s) and other system-specific parameters used to describe or control the behavior of the system.
- FIG. 8 shows an operating environment 800 for the device 310 under an illustrative embodiment, where the device 102 may be configured to authenticate an access code received from the server 318 or vehicle and generate an access signal 820.
- the access code may be integrity checked, to ensure that it has not been altered, and authenticated to determine that the access was created by the correct party.
- the received access code 808, along with security parameters 806 and signature 810 are received in processing device 310, wherein the hash 812 is obtained and used with the root of trust and public key 814 and signature 816 to perform integrity checking and authentication in 816. If the integrity checking and authentication pass, the processing device 102 may generate an access signal 820 for accessing or activating one or more functions in the vehicle.
- FIGS. 3-4 are merely illustrative, and that other suitable authentication processes may be used.
- both the vehicle processor and the transponder may be configured know a secret number ("private key” or "secret key”) that may be unique to that car.
- Both the car computer and the transponder also know an authenticating, secret, or secure algorithm (e.g., Advanced Encryption Standard (AES) algorithm utilizing Electronic Code Books (ECB) and/or Cipher Block Chaining (CBC), Cipher Feedback (CFB), and the like).
- AES Advanced Encryption Standard
- EBC Electronic Code Books
- CBC Cipher Block Chaining
- CFB Cipher Feedback
- the car may generate a random number and transmits it to the transponder. Utilizing the random number and the secret key, they each produce a third number, which may be split out into two parts, A and B, which both the transponder and vehicle now know.
- the vehicle may send its B to the transponder, where the transponder can determine if the vehicle has correctly calculated B, authenticating that the vehicle has the correct secret key and correctly processed the authenticating algorithm.
- the transponder sends A to the vehicle, where the vehicle similarly determines if A is correct.
- both the transponder and the vehicle can confirm or authenticate each other's without actually revealing the secret key or the authenticating algorithm.
- an authentication algorithm may be configured as follows.
- PRF may output a bitstring that is split into two parts, A and B.
- FIG. 9 is an exemplary flow diagram illustrating a registration process for a fob and a portable device with an authentication network and a vehicle.
- registration of portable device 310 may further include the incorporation of local computer 304.
- the configuration of FIG. 9 may be advantageous in cases where vehicle 302 is equipped with short-range wireless communication (e.g., NFC, Bluetooth, Wi-Fi), and may have long-range wireless communication (e.g., cellular) that would allow vehicle 302 to directly communicate with authentication network 314.
- short-range wireless communication e.g., NFC, Bluetooth, Wi-Fi
- long-range wireless communication e.g., cellular
- the registration process of FIG. 9 allows users to register and authenticate themselves and their portable devices with authentication network 314, and to provide authentication permissions to other users.
- a key fob 306 is registered with the vehicle 302, whereupon data relating to authentication for the fob described above is exchanged.
- the vehicle and fob data including authentication data, may be transmitted to authentication network 314, where authentication network 314 may store and process the received data in a server or similar device(s) associated with the network 314.
- the portable device 310 may register with local computer 316, whereupon device ID and/or any other device and/or user data/information is registered and stored.
- Such data/information may include, but is not limited to, SIM card ID number, an IMEI number, and/or Bluetooth address (BD ADDR). This information may then be stored in computer 316 (or send directly to the network 314, discussed below) as an authentication profile for the registering user. In this embodiment, users may manually change or augment the
- authentication profile at computer 316 using software specifically configured for interaction with device 310 and authentication network 314. For example, users may add or configure devices to be part of an authentication group, or to allow users to manually enter
- the device/user identification and authentication profile are then transmitted from computer 316 to authentication network 314 to initialize system registration.
- the registration between device 310 and computer 316 may be configured via a dedicated wired connection. In other illustrative embodiments, the registration between device 310 and computer 316 may be done via a wireless (e.g., Wi-Fi, Bluetooth) connection.
- computer 316 may transmit the information to authentication network 314 in step 908 A, where one or more network servers may associate the device information with the registered fob.
- registration of a device may occur directly with authentication network 314 in step 908B, instead of through computer 316, where the device 310 transmits device ID and/or any other device and/or user information to authentication network 314, where it is processed and stored in one or more network servers.
- device 310 may perform the functions of computer 316 without requiring a separate device or apparatus.
- the authentication network 314 may then process the device and fob information in order to associate them together for the vehicle 302.
- the authentication network 314 registers the device 310 for use with the authentication network 314, and in step 912A the authentication network 314 provides a fob key for associating the device 310 with fob 306.
- the fob key provided in step 912A is not the same secret key used by the fob 306 when authenticating with the vehicle 302, but is a separate and distinct public/private key utilized by the device 302 to securely communicate with the authentication network 314 and/or the vehicle 302.
- the network 314 also provides the same fob key to the vehicle 302 in step 912B, together with the device data/information in order for the vehicle 302 to recognize device 310 and to allow the device 310 to securely communicate with vehicle 302.
- the network 314 may perform step 912A before step 912B.
- the network may perform step 912B before step 912A.
- the device 310 requests device registration. In some illustrative embodiments, this is performed when the device 310 is in proximity to the vehicle 302 and communicating via a wireless protocol (e.g., Bluetooth, NFC).
- a wireless protocol e.g., Bluetooth, NFC
- the vehicle 302 performs device/vehicle pairing, which may include a challenge to device 310 for authentication.
- the device 310 responds with authentication data that includes device information and the fob key received from the authentication network 314.
- the vehicle 302 may authenticate the device to communicate with vehicle 302 to allow the device 302 to send commands for accessing the vehicle 302 and/or to activate or control vehicle functions (e.g., start vehicle, control entertainment system, roll down windows, etc.).
- Device 310 may be equipped with special software providing a user interface for communicating commands to the vehicle 302 and for interfacing with other software and/or hardware on the device to provide further features (e.g., loading music playlist, activating telephone call) that may be utilized as commands when communicating with the vehicle 302.
- the user interface may provide capabilities for further enhancing security by providing access to device components (e.g., keyboard, fingerprint sensor, voice recognition, etc.) that may be used in addition to the authentication data.
- the vehicle 302 may be configured to send a second challenge to the device 310 that requires the user to provide a second entry to complete the authentication.
- the second challenge may include, but is not limited to, a password entry via the device keyboard, a fingerprint entry, and a voice recognition entry.
- multiple challenges may be configured to be transmitted as a multi-layer, single challenge.
- the vehicle 302 may confirm authentication to network 312 in step 918B.
- device 310 may confirm authentication directly to network 314.
- the network 314 may associate the device 310 with the registered fob from step 904 as an authorized fob/device for communicating with vehicle 30.
- the network may preliminarily associate the device 310 with fob 306 in any of steps 908A-B and confirm the association once authentication is confirmed in steps 918A-B.
- FIGS. 10-1 IB various illustrative tables 1000, 1100, 1102 are shown that may be used as reference tables in an authentication network to track authorized users, user devices and fobs for one or more vehicles.
- FIG. 10 shows an example of an authorization table that indicates authorized users and fobs for a plurality of vehicles under an illustrative embodiment.
- two vehicles (Vehicle l, Vehicle_2) are associated with authorized users and fobs as shown, and may be associated together as a vehicle group comprising Vehicle l and Vehicle_2.
- the first vehicle has one authorized user (User l) and one authorized fob (FOB A).
- the second vehicle has three authorized users (User l, User_2, User_3) and one authorized fob (FOB B).
- users may be identified and authorized via their device, where one device is associated with one user.
- multiple users may be associated with one device.
- a device configured with a plurality of SIM cards may be utilized with a plurality of respective users, where each user may authenticate themselves using a device fob key and a SIM card ID (ICCID).
- ICCID SIM card ID
- a plurality of users may be registered/authenticated with a vehicle using the same fob key along with their respective ID information. Alternately different fob keys may be provided for each user at the time of registration/authentication discussed above in connection with FIG. 9.
- FIG. 11A shows an example of an authorization table 1100 for a plurality of users (User_l, User_2, User_3) where device identification (ID) data, passwords and/or trusted (authenticated) fobs are registered for vehicle access under an illustrative embodiment.
- a first user (User l) is authenticated with a device having a respective device ID (Dev i), a registered password (Pass l) and a trusted (authenticated) fob (FOB A).
- a second user (User_2) is authenticated with a device having a respective device ID (Dev_2), and a device password (Pass_2), but does not have an associated fob.
- a third user (User_3) is authenticated with a device having a respective device ID (Dev_3), a registered password (Pass_3) and a trusted (authenticated) fob
- the authentication tables may be referenced by the vehicle and/or authentication network to grant/deny permissions for accessing vehicles and/or activating function(s).
- the authentication tables may be referenced by the vehicle and/or authentication network to grant/deny permissions for accessing vehicles and/or activating function(s).
- FIG. 1 IB shows an example of an authorization table for a plurality of users
- a first user (User l) is authenticated with a device having a respective device ID (Dev i), a registered password (Pass l) and a trusted (authenticated) fob (FOB A) that is also associated with the device (Dev i).
- the associated device allows the user (User l) to access and/or activate functions in a vehicle using the fob and/or device (Dev_l).
- a second user is authenticated with a device having a respective device ID (Dev_2), and a device password (Pass_2), but does not have an associated fob.
- a third user is authenticated with a device having a respective device ID (Dev_3), a registered password (Pass_3) and a trusted (authenticated) fob (FOB B) associated with the device (Device_3).
- the associated device allows the user (User_3) to access and/or activate functions in a vehicle using the fob and/or device (Dev_3).
- the authentication tables may be referenced by the vehicle and/or authentication network to grant/deny permissions for accessing vehicles and/or activating function(s). Also, in some illustrative embodiments, the authentication network may transmit one or more authorization tables to the vehicle to allow for local processing and determination of authorized fobs and/or devices.
- FIG. 12 shows a process for a vehicle to detect authorized fobs and devices and to transmit one or more challenges to authorized devices, and to activate a security function and/or transmit notifications to authorized devices if a proper response is not received under an illustrative embodiment.
- the vehicle detects the presence of a fob, which may be done via proximity sensing and/or via receiving a command from the fob (e.g., user pressing a button on the fob).
- the vehicle determines if the FOB is authorized, for example, using any of the techniques disclosed herein and further disclosed in the example of FIG. 9 and authorization tables of FIGS. 10-1 IB.
- the vehicle denies access in block 1206 and moves to block 1208, where the vehicle detects the presence of a device. If the decision block 1204 determines that the fob is authorized (“YES"), the process moves to block 1208 where the vehicle detects the presence of a device 310. In decision block 1210, the vehicle determines if the device is authorized.
- the authorization may be determined via the registration and/or authentication disclosed herein and further disclosed in the example of FIG. 9 and authorization tables of FIGS. 10-1 IB.
- the vehicle grants access to the device in block 1212 to communicate and/or send commands to the vehicle. If the vehicle does not recognize the device or determines the device is not authorized (“NO"), the vehicle (or authentication network) may look up authorized devices for the vehicle in block 1214 and transmit a challenge to one or more authorized devices in block 1216. In some illustrative embodiments, the challenge may be in the form of a message and/or a request for an entry for authorization. In one example, the vehicle (and/or authentication network) may transmit a message informing the device user that an attempt to access the vehicle is being made, and, if they want to authorize the entry.
- the authorization for entry may be determined by a password from the authorized device, a biometric entry from the device, or by other suitable means.
- the vehicle determines if the proper response is received in response to the message and request for authorization. If an improper response is received, or if the user of the authorized device enters "no" for access, the vehicle may automatically disable device access and certain vehicle functions (e.g., via an immobilizer) until an authorized device and/or fob is present in proximity to the vehicle. If the user responds positively with the proper response (“YES") on the authorized device, the vehicle (and/or the authentication network) may grant access to the vehicle in block 1212.
- the access granted in block 1212 may be limited to one feature (e.g., unlocking a door), selected features, or configured to access the full features of the vehicle.
- the granting of access may occur only between the network and the vehicle.
- the authorized device may dynamically grant access to other devices to have the same or restricted features as the authorized device.
- the process moves to block 1212, where, as part of the access grant, the vehicle and/or the authentication network 314 proceeds to register the requesting (new) device via any of the techniques described herein, and particularly steps 908B-918B of FIG.
- the fob key provided to the new device may be restricted or limited to a predetermined time period that may be set by the authorized device and/or the authentication network.
- the fob key may be set to expire after 8 hours, one day, one week, etc.
- the new user's fob while unauthorized to access the vehicle, may be associated with the user's newly authorized device such that the new user's device will only provide access when the new user's fob is detected together with the device.
- FIGS. 13A-13C show various simplified examples of user devices, with and without an associated fob, approaching a vehicle and requesting access to a vehicle under illustrative embodiments.
- FIG. 13A provides a simplified example of a user (e.g., User l) approaching a vehicle (Vehicle l), where the user is in possession of a device ("1", or Dev i) and fob "A" (FOB A). Assuming in this example that both the device and fob are registered (e.g., see User l of FIGS.
- FIG. 13B provides a simplified example of a user approaching the same vehicle, but possesses a different fob ("B") that is not registered or authenticated directly with the vehicle
- a challenge (e.g., "do you want the vehicle to recognize your fob for future access? (Y/N/)) may be transmitted to the device "1" to allow recognition the fob "B” for future access, since the device "1" is already registered and authenticated with the authentication system.
- the fob will be added to the authentication table as a recognized fob, and vehicle will grant access in the future to the device "1" without a challenge when it is being carried with fob "B".
- a user approaches a vehicle (Vehicle l) carrying a device "1" that is registered and authenticated, but the user does not possess a fob. If the device "1" is authenticated with the vehicle (Vehicle l), the user
- a process flow 1400 is shown for dynamically providing access and authentication as described elsewhere herein from one device to another, where a registered and authenticated device (e.g., via FIG. 9) allows recognition and access of other devices, along with access permissions.
- a vehicle detects a new access, which may be from a device or a device/fob combination that is new to the vehicle (i.e., not recognized or authenticated).
- the new access may be a proximity detection of a device/fob, or a transmitted signal from the device/fob request for accessing the vehicle.
- the vehicle looks up authorized devices (e.g., via authentication table(s)) and transmits a challenge to select devices in block 1404.
- the challenge may include a message informing the authorized device of the new, unauthorized, attempt, a request for permitting access, and a request for entry of access permissions (if any).
- the access permissions may include data such as time limitation parameters and/or vehicle function limitation parameters, which would serve as limitations on the new devices access.
- the vehicle and/or the authentication system receives the response to the challenge granting access that includes access permissions and/or parameters in block 1406. If a fob is detected and access is permitted, the vehicle and/or the authentication system adds the fob to the authentication table as a recognized fob in block 1408. If a device is detected and access is permitted, the vehicle and/or the authentication system adds the devices as a recognized device in block 1410. As discussed above, a device/fob may be recognized as being part of a group, which may assist the vehicle and/or authentication system in associating the recognized device/fob with authorized devices/fobs. While the device/fob in blocks 1408-1410 is not authorized at this point to fully access the vehicle, the adding of the device/fob as a recognized device allows flexibility in associating the recognized device/fob with authorized devices/fobs.
- the authentication system (and/or vehicle, if configured with suitable authentication software) may generate a new fob key in accordance with the access permissions/parameters and transmit the fob key to the device and vehicle, similarly to the embodiment disclosed above in connection with FIG. 9.
- the device authenticates with the vehicle using any of the techniques discussed above, and is added to the authentication table as an authorized device. Without any access permissions/parameters, the device would have a default access to the device which may include the same or fewer vehicle features as the original permitting device.
- FIG. 15 shows a system 1500 that includes a processing device and a server communicating via a network, wherein the system is configured to generate and manage fob keys between a device and a server for vehicle access and functions under an illustrative embodiment.
- the processing device 1502 includes a processor 1504 or processor circuit, one or more peripheral devices 1508, memory/data storage 1506, communication circuity 1512, and a key manager 1514.
- the key manager 1514 may be configured to process and/or manage fob keys.
- the key manager 1514 may be incorporated into memory/data storage 1506 with or without a secure memory area, or may be a dedicated component, or incorporated into the processor 1504.
- processing device 1504 may include other or additional components, such as those commonly found in a digital apparatus and/or computer (e.g., communication circuitry, various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory/data storage 1506, or portions thereof, may be incorporated in the processor 1504 in some embodiments.
- the processor 1504 may be embodied as any type of processor currently known or developed in the future and capable of performing the functions described herein.
- the processor 1504 may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit.
- memory/data storage 1506 may be embodied as any type of volatile or non-volatile memory or data storage currently known or developed in the future and capable of performing the functions described herein.
- memory/data storage 1506 may store various data and software used during operation of the processing device 1504 such as access permissions, access parameter data, operating systems, applications, programs, libraries, and drivers.
- Memory/data storage 1506 may be communicatively coupled to the processor 1504 via an I/O subsystem 1510, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor 1504, memory/data storage 1506, and other components of the processing device 1502.
- the I/O subsystem 1510 may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations.
- the I/O subsystem 1510 may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor 1504, memory/data storage 1506, and other components of the processing device 1502, on a single integrated circuit chip.
- SoC system-on-a-chip
- the processing device 1502 includes communication circuitry 1512 (communication interface) that may include any number of devices and circuitry for enabling communications between processing device 1502 and one or more other external electronic devices and/or systems.
- peripheral devices 1508 may include any number of additional input/output devices, interface devices, and/or other peripheral devices.
- the peripheral devices 1508 may also include a display, along with associated graphics circuitry and, in some embodiments, may further include a keyboard, a mouse, audio processing circuitry (including, e.g., amplification circuitry and one or more speakers), and/or other input/output devices, interface devices, and/or peripheral devices.
- the server 1520 (which may be similar to network server 318) may be embodied as any type of server (e.g., a web server, etc.) or similar computing device capable of performing the functions described herein.
- the server 1520 includes a processor 1524, an I/O subsystem 1530, a memory/data storage 1526, communication circuitry 1532, and one or more peripheral devices 1528.
- Components of the server 1520 may be similar to the corresponding components of the processing device 1502, the description of which is applicable to the corresponding components of server 1520 and is not repeated herein for the purposes of brevity.
- the communication circuitry 1532 of the server 1520 may include any number of devices and circuitry for enabling communications between the server 1520 and the processing device 1502.
- the server 1520 may also include one or more peripheral devices 1528.
- peripheral devices 126 may include any number of additional input/output devices, interface devices, and/or other peripheral devices commonly associated with a server or computing device.
- the server 1520 also includes a fob key generator 1534 that is configured to generate cryptographic secret key for transmission to the device 1502 or a vehicle.
- the fob key and rules manager 1536 stores and manages fob keys that are transmitted, and may further store and process authentication tables and access permission and parameters.
- the network 314 may represent a wired and/or wireless network and may be or include, for example, a local area network (LAN), personal area network (PAN), storage area network (SAN), backbone network, global area network (GAN), wide area network (WAN), or collection of any such computer networks such as an intranet, extranet or the Internet (i.e., a global system of interconnected network upon which various applications or service run including, for example, the World Wide Web).
- LAN local area network
- PAN personal area network
- SAN storage area network
- GAN global area network
- WAN wide area network
- any such computer networks such as an intranet, extranet or the Internet (i.e., a global system of interconnected network upon which various applications or service run including, for example, the World Wide Web).
- the communication circuitry of processing device 1502 and the communication circuitry 1532 of the server 1520 may be configured to use any one or more, or combination, of communication protocols to communicate with each other such as, for example, a wired network communication protocol (e.g., TCP/IP), a wireless network communication protocol (e.g., Wi-Fi, WiMAX), a cellular communication protocol (e.g., Wideband Code Division Multiple Access (W-CDMA)), and/or other communication protocols.
- the network 314 may include any number of additional devices, such as additional computers, routers, and switches, to facilitate communications between the processing device 1502 and the server 1520.
- the techniques for securely accessing vehicle functions may be configured to incorporate a vehicle function control file that includes data for setting or altering vehicle functions.
- the vehicle function control file may be configured as pure data that is processed and/or executed on a vehicle to set and/or alter one or more vehicle functions.
- the vehicle function control file may include executable code that may be configured to execute manually and/or automatically by a processor, such as a vehicle processing system.
- a system 1600 is disclosed that may be used in a system environment such as the one illustrated in the embodiment of FIG. 3, as well as other embodiments disclosed herein.
- a portable device 1604 which may be configured similarly as portable device 310, may be configured to communicate with a local computer 1602, which may be operated by a user or other entity choosing to generate one or more vehicle function control files for a vehicle.
- Local computer 1602 may be configured similarly to computer 316.
- local computer 1602 may be configured with a profile database comprising a plurality of drive or user profiles 1610-1614 that may be generated and associated with fob keys generated in a manner disclosed elsewhere herein.
- Local computer 1602 may be configured to communicate with server 1606, which may be part of an authentication network, and may be configured similarly as server 1520, discussed in greater detail above.
- local computer 1602 may be configured to generate one or more driver (user) profiles 1610-1614 that are associated with a fob key in order to set or control vehicle functions when a user possessing the fob kay in their device 1604, 1606 accesses and/or uses the vehicle.
- Servers 1606 may include wired and/or wireless communication interfaces to receive vehicle data, portable device data, profile data that may include vehicle access and/or function control data and other data from portable devices 1604, 1606 as well as one or more vehicles linked to a key fob. Additional data or instructions from computer 1602 may be received via wired or wireless interface through the network in system 1600.
- the devices 1602, 1606 may be configured to communicate data with each other, including fob keys.
- local computer 1602 may be used to receive device ID and/or device information from any of devices 1604-1606 in order to register those devices as authored users of a key fob for a vehicle.
- one or more driver profiles 1610-1614 may be generated on the local computer 1602 (discussed in greater detail below in connection with FIGS. 17-18), wherein the driver profile and associated data may be transmitted along with device and key fob information to server 1606.
- Server 1606 may be configured to generate a fob key (i.e., a software key) configured to allow the requesting devices 1604-1606 to access one or more vehicle functions, similar to the techniques described herein.
- server 1606 may associate and/or append vehicle access and/or function control data from a respective driver profile 1610, 1612 with a fob key.
- the fob keys may be associated with vehicle access and/or function control data from a respective driver profile to form a vehicle function control file 1608 A, 1608B and may be transmitted from the server 1606 to the local computer 1602.
- the fob key and vehicle access and/or function control data may be configured as separate data files that are associated with the received fob key.
- the system 1600 may be configured to load the vehicle access and/or function control data only after the fob key is authenticated.
- the vehicle access and/or function control data may be encoded into the fob key itself as data packets of the vehicle function control file, where a fob key authentication process unlocks the vehicle access and/or function control data and loads them into the vehicle for execution.
- a fob key authentication process unlocks the vehicle access and/or function control data and loads them into the vehicle for execution.
- FIG. 16 is illustrative only, and that multiple configurations are contemplated in the present disclosure.
- the fob key generation, profile and vehicle access and/or function control data generation, and the fob key / vehicle access and/or function control data association may be performed entirely on local computer 1602.
- server 1606 when server 1606 receives one or more user profiles 1610-1614, the server 1606 detects or extracts the vehicle access and/or function control data and associates and/or appends the vehicle access and/or function control data with each respective fob key 1608 A, 1608B, which together may be configured to represent a vehicle function control file.
- the local computer 1602 may then be configured to transmit each vehicle function control file (i.e., fob key, together with vehicle access and/or function control data) 1608A, 1608B to the respective device 1604, 1606.
- vehicle function control file 1608 A is transmitted to device 1604, while vehicle function control file 1608B is transmitted to device 1606.
- vehicle function control file 1608 A may have different access permissions, perform different vehicle function control (e.g., limit an operational function of the vehicle) and alerts/messaging with vehicle 302 compared to vehicle function control file 1608B.
- FIG. 17 an example of a vehicle function control file 1700 is shown that includes a fob key 1704 and associated vehicle access and/or function control data 1706 under an illustrative embodiment.
- the fob key 1704 and vehicle access and/or function control data 1706 may be combined into a single file, where authentication of the fob key 1704 automatically authenticates or unlocks the vehicle access and/or function control data 1706.
- the fob key 1704 and vehicle access and/or function control data 1706 may be separate files, where vehicle access and/or function control data 1706 is accessed only after fob key 1704 is authenticated.
- vehicle access and/or function control data 1706 may be subjected to separate authentication using any of the techniques disclosed herein or other techniques known in the art.
- Vehicle access control 1708 may include data that sets and/or controls physical access to the vehicle, such as locking/unlocking doors, trunks, hoods, windows, etc.
- Sensor control 1710 may include data that sets and/or controls sensors and/or sensor parameters in the vehicle, such as blind spot sensors, collision sensors, brake sensors, and the like.
- Vehicle function control 1712 may include data that control vehicle functions and/or performance, such as speed and/or acceleration limits, engine RPM limits, braking sensitivity, gear shifting, etc.
- Alerts/messaging 1714 may include data that allows the vehicle to provide messaging externally (e.g., to server 1606, local computer 1602, and/or one or more portable devices registered as primary users) with regard to any vehicle function regardless of whether or not the vehicle function is set and/or modified by vehicle access and/or function control data.
- Illustrative alerts/messages include, but are not limited to, speeding alerts, entertainment system volume alerts, anti-lock brake activation alerts, access attempts to the vehicle, and the like.
- Entertainment system control 1716 may include data that allows the vehicle to limit entertainment system functions, such as volume limits, blocking of specific stations or entertainment apps, etc.
- vehicle and vehicle-related data e.g., geofencing, GPS navigation control, etc.
- any portion 1708-1716 of the vehicle access/function control data 1706 may be combined and/or made dependent on one or more other portions to provide additional restrictions on vehicle use (e.g., limit entertainment system volume when the vehicle exceeds a certain speed).
- FIG. 18 shows an interface 1800 for entering data for vehicle access and function control, wherein the data may be used for a vehicle function control file under an illustrative embodiment.
- the interface 1800 may be implemented e.g. on a local computer 1602 and/or may also be configured as a network interface e.g., via server 1606, for creating, modifying and managing vehicle function control files for a user profile.
- interface 1800 may include a vehicle function control file interface 1802 for a user profile, where a user may enter limitations and/or restrictions for the vehicle function control file.
- limitations and/or restrictions may include a time restriction interface 1804 that allows a user to set times in which e.g.
- the fob key 1704 may access the vehicle e.g., via access control 1708. While the time restrictions 1804 are shown in days in the example (Mon.-Sun.), it should be understood by those skilled in the art that more detailed restrictions (e.g., restrict access between 11 :00PM and 6:00PM) are contemplated in the present disclosure.
- Engine restriction 1806 allows a user to enable/disable limits on the vehicle engine performance e.g., via vehicle function control 1712. While not explicitly shown in the figure, specific restrictions may be entered via the interface 1802, for example, to restrict the vehicle from exceeding a specific speed (e.g., 70MPH), restrict the engine from exceeding a specific RPM, and the like.
- Volume restriction 1808 allows a user to restrict the volume e.g., via entertainment system control 1716 at which an entertainment system may be played in the vehicle.
- Monitoring 1810 may enable or disable alerts and/or messages (e.g., via
- alerts/messaging 1714 that may be associated with any of the vehicle function. While not explicitly shown in the figure, monitoring 1810 may be further configured to enable/disable monitoring for specific vehicle functions, such as speed alert 1812 and may also be configured to all a user to enter specific limitations for alert (e.g., 70MPH). Alert/monitoring 1810 may also be configured to provide customized messaging services, such as text, email, and/or "in-app" messaging.
- a geofence alert 1814 may also be provided to allow a user to set alerts/messages when a vehicle exceeds a geographic perimeter.
- a map interface 1816 may be provided for the interface 1802 that allows a user to set a restriction perimeter 1818 within the map 1816. If the vehicle exceeds the perimeter 181, an alert may be transmitted by the vehicle.
- the geofence alert 1814 may be combined with other vehicle access/function control data to enable other functions (e.g., vehicle access control 1708, vehicle function control 1712) to operate.
- the vehicle may be configured to shut down and/or restrict access to the vehicle (e.g., entering/starting the vehicle) if the vehicle is in a particular geographical area.
- the vehicle may be configured to shut down and/or restrict access to the vehicle (e.g., entering/starting the vehicle) if the vehicle is in a particular geographical area.
- FIG. 19 shows illustrates a vehicle system block diagram 1900 showing multiple components and modules of a vehicle system for processing and executing vehicle function control files under one embodiment of the exemplary system 100 for a vehicle comprising various vehicle electronics modules, subsystems and/or components.
- Engine/transmission module 1902 is configured to process and provide vehicle engine and transmission characteristic or parameter data, and may comprise an engine control unit (ECU), and a transmission control.
- ECU engine control unit
- module 1902 may provide data relating to fuel injection rate, emission control, NOx control, regeneration of oxidation catalytic converter, turbocharger control, cooling system control, and throttle control, among others.
- module 1902 may provide data relating to lambda control, onboard diagnostics, cooling system control, ignition system control, lubrication system control, fuel injection rate control, throttle control, and others.
- Other aspects of module 1902, as they relate to hybrid and/or electrical vehicles, may also be used in some illustrative embodiments.
- Transmission characteristic data may comprise information relating to the transmission system and the shifting of the gears, torque, and use of the clutch.
- an engine control unit and transmission control may exchange messages, sensor signals and control signals and may also use data from the vehicle function control file to control vehicle functions.
- Global positioning system (GPS) module 1903 provides navigation processing and location data for the vehicle 302.
- the sensors 1904 provide sensor data which may comprise data relating to vehicle characteristic and/or parameter data, and may also provide environmental data pertaining to the vehicle, its interior and/or surroundings, such as temperature, humidity and the like.
- Radio/entertainment module 1905 may provide data relating to audio/video media being played in vehicle 302.
- the radio/entertainment module 1905 may be integrated and/or communicatively coupled to an entertainment unit configured to play AM/FM radio, satellite radio, compact disks, DVDs, digital media, streaming media and the like.
- Communications module 1906 allows any of the modules of system 1900 to communicate with each other and/or external devices (e.g., server 1606, local computer 160, devices 1604-1606) via a wired connection or wireless protocol, such as Wi-Fi, Bluetooth, NFC, etc.
- modules 1902-1906 may be communicatively coupled to bus 1912 for certain communication and data exchange purposes.
- Vehicle 302 may further comprise a main processor 1907 that centrally processes and controls data communication throughout the system 1900 and may be configured to execute authentication of fob keys 1704 and vehicle access/function control data 1706 (i.e., vehicle function control files 1700).
- Storage 1908 may be configured to store data, software, media, files and the like.
- Storage 1908 may further be configured to store vehicle function control files 1700.
- Digital signal processor (DSP) 1909 may comprise a processor separate from main processor 1907, or may be integrated within processor 1907. Generally speaking, DSP 1909 may be configured to take signals, such as voice, audio, video, temperature, pressure, position, etc. that have been digitized and then process them as needed.
- Display 1910 may be configured to provide visual (as well as audio) indicial from any module in FIG. 10, and may be a configured as a LCD, LED, OLED, or any other suitable display.
- the messages/alerts from 1714 may further be configured to display alerts/messages on display 1910.
- the display 1910 may also be configured with audio speakers for providing audio output.
- Input/output module 1911 is configured to provide data input and outputs to/from other peripheral devices, such as key fobs, device controllers and the like.
- modules 1907-1911 may be communicatively coupled to data bus 1912 for transmitting/receiving data and information from other modules.
- FIG. 20 shows a process flow 2000 for generating a fob key and associated vehicle function control file from associated control data, and processing the vehicle function control data for application and execution on a vehicle (e.g., via any of the modules of FIG. 19) under an illustrative embodiment.
- vehicle access/function control data is generated or received.
- a fob key is generated using any of the techniques described herein and a vehicle function control file (VFCF) is generated.
- VFCF vehicle function control file
- the vehicle function control file is transmitted and authenticated by the vehicle.
- decision block 2008 the vehicle determines if vehicle access/control data is present in the vehicle function control file. If not (“NO"), the process 2000 proceeds to block 2016, where normal (e.g., factory setting) vehicle access/functions are provided.
- decision block 2008 determines that vehicle access/function control data is present (“YES")
- the process 2000 proceeds to block 2010 and applies the control data (e.g., via any of vehicle access and/or function control data 1708-1716) to the vehicle (e.g., via any of modules 1902-1911) to execute the appropriate limitation/restriction/alert/messaging control function(s) on the vehicle in block 2012.
- decision block 2014 the vehicle determines if the control parameters have ended.
- the control of the vehicle function control file may end when the vehicle ignition is off, indicating that the user is no longer driving and/or has left the vehicle.
- control of the vehicle function control file may end when the vehicle ignition is off and the user's device is no longer detected to be in proximity to the vehicle. If any of these cases do not exist ("NO"), the process 2000 continues to execute the controls on the vehicle in block 2012. If they do exist (“YES”), the process 2000 proceeds to block 2016 where normal vehicle access/functions are provided. Once the user (or another user with a similarly configured device) approaches or returns to the vehicle, the process 2000 may jump to block 2006 to authenticate the user and repeat the process.
- the various technologies and techniques discussed herein provide an efficient platform for allowing a system to effectively authenticate users and implement customized vehicle use restrictions and/or limitation using a portable device.
- These technologies advantageously provide means in which a primary user, such as a parent, may institute controls on a vehicle to enhance the safety of the vehicle for a child.
- an employer may institute controls on a vehicle to enhance safety and limit liability for employees that may be driving company vehicles. Since the vehicle access (e.g., via fob key) and controls (e.g., via the vehicle function control file) are implemented on portable devices, the need for providing physical keys and/or key fobs may be eliminated.
- vehicle controls may be effectively customized and transferred to a vehicle with relative ease.
- first, second, third, etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms may be only used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first element, component, region, layer or section discussed below could be termed a second element, component, region, layer or section without departing from the teachings of the exemplary embodiments.
- the disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any tangibly-embodied combination thereof.
- the disclosed embodiments may also be implemented as instructions carried by or stored on one or more non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors.
- a machine -readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Lock And Its Accessories (AREA)
Abstract
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/173,498 US9865112B2 (en) | 2016-06-03 | 2016-06-03 | Apparatus, system and method for dynamic identification for vehicle access |
US15/261,865 US9870665B2 (en) | 2016-06-03 | 2016-09-09 | Apparatus, system and method for vehicle access and function control utilizing a portable device |
US15/261,857 US9865113B2 (en) | 2016-06-03 | 2016-09-09 | Apparatus, system and method for dynamic identification and key management for vehicle access |
PCT/EP2017/063179 WO2017207644A1 (fr) | 2016-06-03 | 2017-05-31 | Appareil, système et procédé d'accès à un véhicule et de commande de fonction en utilisant un dispositif portable |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3463994A1 true EP3463994A1 (fr) | 2019-04-10 |
Family
ID=59014593
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP17728132.6A Pending EP3463993A1 (fr) | 2016-06-03 | 2017-05-31 | Appareil, système et procédé d'identification et de gestion de clé dynamiques pour l'accès à un véhicule |
EP17728494.0A Pending EP3463994A1 (fr) | 2016-06-03 | 2017-05-31 | Appareil, système et procédé d'accès à un véhicule et de commande de fonction en utilisant un dispositif portable |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP17728132.6A Pending EP3463993A1 (fr) | 2016-06-03 | 2017-05-31 | Appareil, système et procédé d'identification et de gestion de clé dynamiques pour l'accès à un véhicule |
Country Status (3)
Country | Link |
---|---|
EP (2) | EP3463993A1 (fr) |
CN (1) | CN109195840A (fr) |
WO (2) | WO2017207644A1 (fr) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110581876B (zh) * | 2018-06-11 | 2023-05-26 | 阿尔派株式会社 | 车载设备、共享车管理系统及共享车管理方法 |
WO2020012570A1 (fr) | 2018-07-10 | 2020-01-16 | Global Mobility Service株式会社 | Système de commande à distance de véhicule, module de communication, serveur, véhicule, procédé de commande à distance de véhicule, programme de commande à distance de véhicule et support d'informations |
CN109509281A (zh) * | 2018-12-10 | 2019-03-22 | 华南理工大学 | 一种基于STM32和Android的智能开门方法及其系统 |
US11080509B2 (en) | 2018-12-31 | 2021-08-03 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for onboard fraud detection in a transportation service |
US11038877B2 (en) | 2018-12-31 | 2021-06-15 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for device fingerprint determination in a transportation service |
CN112823348B (zh) * | 2018-12-31 | 2022-11-04 | 北京嘀嘀无限科技发展有限公司 | 用于运输服务中的机载欺诈检测的系统和方法 |
US20200410794A1 (en) * | 2019-06-25 | 2020-12-31 | Microchip Technology Incorporated | Configurable access controller, and related systems, methods, and devices |
WO2021082195A1 (fr) * | 2019-10-30 | 2021-05-06 | 上海博泰悦臻电子设备制造有限公司 | Procédé de création et de gestion de clé virtuelle, appareil et support de stockage lisible par ordinateur |
KR20220150346A (ko) * | 2020-03-09 | 2022-11-10 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 차량 내 시스템에 로그인하기 위한 방법 및 관련 장치 |
US11180113B1 (en) * | 2020-05-21 | 2021-11-23 | Micron Technology, Inc. | Security notification based on biometric identifier |
EP4087290A1 (fr) * | 2021-05-04 | 2022-11-09 | Bayerische Motoren Werke Aktiengesellschaft | Unité de commande de véhicule, véhicule comprenant l'unité de commande, procédé et programme informatique |
CN113805563B (zh) * | 2021-08-20 | 2023-07-18 | 东风柳州汽车有限公司 | 整车启动控制方法、系统、设备及存储介质 |
KR102445149B1 (ko) * | 2021-08-30 | 2022-09-20 | 삼보모터스주식회사 | 차량 제어를 위한 사용자 기기의 등록 및 인증 장치, 및 방법 |
CN114379392B (zh) * | 2022-03-24 | 2022-06-07 | 长安新能源南京研究院有限公司 | 一种电动汽车充电枪智能锁控制方法、设备及存储介质 |
CN116142129B (zh) * | 2022-12-19 | 2024-04-26 | 重庆长安汽车股份有限公司 | 车辆无感解锁系统、方法、车辆及存储介质 |
CN116546459B (zh) * | 2023-07-05 | 2023-09-12 | 小米汽车科技有限公司 | 车钥匙的配对方法、装置、存储介质及系统 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102005017451A1 (de) | 2005-04-15 | 2006-10-19 | Hella Kgaa Hueck & Co. | Türgriff für Kraftfahrzeuge mit einem kapazitiven Näherungssensor |
SE534520C2 (sv) * | 2009-11-27 | 2011-09-20 | Phoniro Ab | Åtkomstkontrollmetod och tillhörande låsanordning samt administrationsserver |
US20140002236A1 (en) * | 2010-12-02 | 2014-01-02 | Viscount Security Systems Inc. | Door Lock, System and Method for Remotely Controlled Access |
GB201119792D0 (en) * | 2011-11-16 | 2011-12-28 | Jaguar Cars | Vehicle access system |
WO2014146186A1 (fr) * | 2013-03-22 | 2014-09-25 | Keyfree Technologies Inc. | Gestion d'accès à une zone restreinte |
US9499125B2 (en) * | 2013-10-29 | 2016-11-22 | Volkswagen Aktiengesellschaft | Vehicle system for activating a vehicle component to provide vehicle access |
EP2945129B1 (fr) * | 2014-05-14 | 2019-10-02 | Volvo Car Corporation | Procédés et systèmes permettant à un utilisateur temporaire d'obtenir un accès temporaire à un espace de verrouillage d'un véhicule |
US20150356797A1 (en) * | 2014-06-05 | 2015-12-10 | International Business Machines Corporation | Virtual key fob with transferable user data profile |
US9600949B2 (en) * | 2014-07-30 | 2017-03-21 | Master Lock Company Llc | Wireless key management for authentication |
US9754431B2 (en) * | 2014-08-18 | 2017-09-05 | Livio, Inc. | Method and system for a key fob base station enabling remote car access using a nomadic device |
-
2017
- 2017-05-31 WO PCT/EP2017/063179 patent/WO2017207644A1/fr unknown
- 2017-05-31 EP EP17728132.6A patent/EP3463993A1/fr active Pending
- 2017-05-31 CN CN201780034364.3A patent/CN109195840A/zh active Pending
- 2017-05-31 WO PCT/EP2017/063175 patent/WO2017207641A1/fr unknown
- 2017-05-31 EP EP17728494.0A patent/EP3463994A1/fr active Pending
Also Published As
Publication number | Publication date |
---|---|
CN109195840A (zh) | 2019-01-11 |
WO2017207641A1 (fr) | 2017-12-07 |
EP3463993A1 (fr) | 2019-04-10 |
WO2017207644A1 (fr) | 2017-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9902368B2 (en) | Apparatus, system and method for vehicle access and function control utilizing a portable device | |
US9870665B2 (en) | Apparatus, system and method for vehicle access and function control utilizing a portable device | |
US9865112B2 (en) | Apparatus, system and method for dynamic identification for vehicle access | |
US9865113B2 (en) | Apparatus, system and method for dynamic identification and key management for vehicle access | |
EP3463994A1 (fr) | Appareil, système et procédé d'accès à un véhicule et de commande de fonction en utilisant un dispositif portable | |
US9842443B1 (en) | Computing device as a vehicle key | |
US10235820B2 (en) | Method for safely unlocking and/or locking a vehicle | |
US10369964B2 (en) | Keyless entry system security enhancement | |
US10112581B2 (en) | Remote control system for a vehicle | |
US9381890B2 (en) | Method and apparatus for biometric vehicle activation | |
CN107251105B (zh) | 机动车安防和机动车安全系统 | |
US20150356797A1 (en) | Virtual key fob with transferable user data profile | |
US20170374550A1 (en) | System for Using Mobile Terminals as Keys for Vehicles | |
US8600581B2 (en) | System and method for vehicle control using human body communication | |
US10332328B2 (en) | Device for protecting the access to a vehicle by means of a mobile phone | |
US20170116804A1 (en) | Systems and methods for user based vehicle access control | |
JP6790917B2 (ja) | キーシステムを用いた車載機器の制御方法およびキーシステム | |
CN112188431A (zh) | 车辆智能进入系统及其方法 | |
US10249181B2 (en) | Wireless relay device and wireless relay control system having the same | |
EP3503044A1 (fr) | Procede pour acceder a un vehicule | |
CN113453963B (zh) | 用于提供车辆的钥匙信号或防盗信号的方案 | |
CN106559378A (zh) | 汽车门锁解锁装置、系统及方法和智能终端 | |
US11037388B2 (en) | Systems and methods for creating a password and/or a keypad code for executing keyless operations upon a vehicle | |
KR102255804B1 (ko) | 모바일 단말기의 기능 제한 장치 및 그 방법 | |
CN108367732B (zh) | 用于车辆的认证控制系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20190103 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20200416 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230529 |