Patent Description:
A keyless entry system is an electronic lock that controls access to a building or vehicle without using a traditional mechanical key. The term 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. The term remote keyless system (RKS), 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.

Keyless remotes contain a short-range radio transmitter, and must be within a certain range, usually <NUM>-<NUM> 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 <NUM> for North America-made cars and at <NUM> 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. On some vehicles, such as minivans, power sliding doors can be opened/closed remotely. Some cars will also close any open windows and roof when remotely locking the car. Some remote keyless fobs also feature a red panic button which activates the car alarm as a standard feature. Further adding to the convenience, some cars' engines with remote keyless ignition systems can be started by the push of a button on the key fob, and convertible tops can be raised and lowered from outside the vehicle while it's parked. On cars where the trunk release is electronically operated, it can be triggered to open by a button on the remote. Conventionally, the trunk springs open with the help of hydraulic struts or torsion springs, and thereafter may be lowered manually. In other configurations, 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. Depending on the system, 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.

Currently, vehicle access systems are relatively inflexible, in that they typically limit access only to users in physical possession of a key fob specific to one vehicle. Most configurations do not have effective means in which grant access to individuals based on dynamic permissions, while retaining the security and convenience of a key fob. Technologies and techniques are needed to provide dynamic user access, and manage that 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.

<CIT> discloses a key fob base station enabling remote car access using a nomadic device. The key fob base station comprises a controller which receives a security code request from the nomadic device and verifies that the nomadic device is approved to communicate with the vehicle key fob based on a pre-registration configuration. If the nomadic device is approved, the controller transmits the request to the key fob and receives the vehicle security code from the key fob. The controller may be further configured to transmit the vehicle security code to the nomadic device.

A virtual key fob with transferable user data profile is disclosed in <CIT>. A first mobile general-purpose processing device, such as a smart phone, is registered with a vehicle. The first mobile general-purpose processing device is authorized to be used as a key fob for controlling the vehicle. A user profile associated with a user of the vehicle is generated. The user profile is stored on the first general-purpose processing device and the vehicle and contains information related to controlling the vehicle. At least part of the user profile is enabled to be downloaded to a second mobile general-purpose processing device to enable the second mobile general-purpose processing device to be used as a key fob for controlling the vehicle.

A method for remotely controlled access is disclosed in <CIT>. A secure door entry without a traditional card reader is made possible by tagging the door with an unpowered, unique token which can be read by a user's personal mobile electronic device. The user's device transmits both door and user identification to a remote server, where the decision is made whether to open the door. If so, the server sends an open door signal using the IP suite of protocols to a processor in a powered door lock, opening the door. Another signal may be used indicate whether access is denied or granted.

<CIT> discloses a method for enabling a temporary user to gain temporary access to a locked space of a vehicle. The vehicle communicates with an intermediate system which receives, from a user device associated with the temporary user, a request message to open a remotely operable lock of the locked space and transmits, based on the request message, an unlock message to the vehicle to open the lock. An owner device associated with an owner of the vehicle transmits a permission message comprising access parameters directly or indirectly to the user device. The access parameters are comprised in the request message to enable the lock to be unlocked based on the access parameters.

Various apparatus, systems and methods are disclosed herein relating to vehicle security and the dynamic granting of access to vehicle functions via a plurality of devices.

According to the invention, a system is disclosed for authorizing access to vehicle functions for a vehicle, according to claim <NUM>.

According to the invention, a method is disclosed for authorizing access to a vehicle, according to claim <NUM>.

According to the invention, a vehicle is disclosed for authorizing access for vehicle functions for a new device, according to claim <NUM>.

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:.

Various embodiments will be described herein below with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail since they may obscure the invention in unnecessary detail.

It will be understood that the structural and algorithmic embodiments as used herein does not limit the functionality to particular structures or algorithms, but may include any number of software and/or hardware components. In general, 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. In this regard, 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.). Furthermore, 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.

Turning to <FIG>, a vehicle <NUM> may comprise a vehicle system <NUM> for activating at least one vehicle component <NUM>. A vehicle component <NUM> can be any component at the vehicle that can be activated by at least another component inside or outside the vehicle <NUM>. Further details of this configuration may be found in <CIT>. The vehicle component <NUM> 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.). As an example, by receiving a specific wireless signal by a vehicle receiver the vehicle fuel filler door may be unlocked or mechanically opened by driving a motorized mechanism to open the fuel filler door. After receiving the signal there might be various electronic circuits, e.g. for decrypting the received signal, verifying the signal, interpreting the signal, transferring and providing a signal for performing a vehicle function including, but not limited to, starting an engine, activating one or more lights, and/or driving an electric motor that is coupled to a door mechanism operable to open a door. This signal processing procedure may apply to any other vehicle component <NUM> as well.

<FIG> provides a systematic overview of a vehicle system <NUM> including a first and second receiver <NUM>, <NUM> to activate a vehicle component <NUM> or function. In one example, a vehicle user is approaching a vehicle <NUM> with at least one electronic device <NUM> and a matching vehicle access key <NUM>. The electronic device <NUM> is able to send out a wireless signal <NUM> to communicate with the first receiver <NUM> if the electronic device <NUM> is in a reception range <NUM> of the first receiver or other suitable signal. In certain illustrative embodiments, 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 <NUM> for a long time without the need to be shut down due to their quiescent current demand when the vehicle <NUM> is parked. In certain illustrative embodiments, when the user approaches the vehicle <NUM>, the first receiver <NUM> obtains a wireless signal <NUM> from the electronic device <NUM>, when the device <NUM> is in the reception range <NUM> of the first receiver <NUM>.

The wireless signal <NUM> of the electronic device <NUM> 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. In one embodiment, the identification data comprises an identification code so that the vehicle system <NUM> can verify that a specific vehicle user carrying the electronic device <NUM> is in the reception range <NUM>. The vehicle system <NUM> comprises a memory <NUM> or memory device in which second identification data is stored. The memory <NUM> 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 <NUM>. By storing multiple sets of identification data the vehicle <NUM> 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 <NUM>. The identification data can also be encrypted by the electronic device <NUM> and decrypted by the vehicle system <NUM>.

If the first identification data match the at least second (reference) identification data stored in the memory <NUM>, the first receiver <NUM> may send a control signal to the second receiver <NUM> to access a matching vehicle access key <NUM> by a wireless signal <NUM>. If the second receiver <NUM> correctly identifies the vehicle key as a matching vehicle access key <NUM>, at least one vehicle component <NUM> is activated or operated. Vehicle components <NUM> 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. In certain illustrative embodiments, a vehicle user can also activate at least one vehicle component <NUM> by directly sending the wireless signal <NUM> from the matching vehicle access key <NUM>. In certain keyless vehicle entry systems, for example, as described in <CIT>, that, upon touching a vehicle door handle, 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 <NUM>.

In the example of <FIG>, the user interaction in vehicle system <NUM> 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 <NUM> or selected vehicle components <NUM> 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> schematically illustrates an approach of a vehicle user to a vehicle <NUM> from a plurality of directions carrying an electronic device <NUM> as well as a vehicle access key <NUM> according to an illustrative embodiment. In a first example, the vehicle user is approaching the vehicle <NUM> from the rear. A dashed circle <NUM> schematically represents the reception range <NUM> of the first receiver <NUM>. At position <NUM> the vehicle user enters the reception range <NUM> of the first receiver <NUM>. The first identification data of the electronic device <NUM> can now be received by the first receiver <NUM>. If positively verified, the first receiver <NUM> wakes up the second receiver <NUM> and checks for a matching vehicle access key <NUM>. If the matching vehicle access key <NUM> is detected, all vehicle doors are unlocked.

In another embodiment, the electronic device <NUM> stores the parking position and heading of the vehicle <NUM>. In this example the electronic device <NUM> is a smartphone with a global positioning system (GPS), along with motion or acceleration sensors. When the user now approaches the vehicle <NUM>, the electronic device <NUM> 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 <NUM> at point <NUM>, the smart phone and the first receiver <NUM> 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 <NUM>. Since the user is approaching the vehicle <NUM> from the rear, a vehicle control command to activate a rear view camera <NUM> is sent to the vehicle <NUM>. The user stops in front of the trunk lid and an image recognition within the vehicle <NUM> is able to identify a person in an image or a video stream taken by the rear view camera <NUM>. The vehicle system <NUM> notices that the user is waiting, for example more than a predefined time, e.g. more than <NUM> seconds, in the rear of the vehicle <NUM> and subsequently opens the trunk lid and activates an automatic trunk lid opener.

In another example, the user enters the reception range <NUM> at a location <NUM> on the driver's side of the vehicle <NUM>. The electronic device <NUM> or a remote server program analyses the GPS or motion data of the electronic device <NUM> and compares that to the direction and position of the vehicle <NUM>. It is determined, that the user is approaching the vehicle <NUM> from the driver's side and subsequently unlocks the door on the driver's side.

<FIG> discloses an exemplary embodiment of a vehicle authentication system <NUM>, in which vehicles <NUM>, <NUM> and their respective key fobs <NUM>, <NUM> are paired or linked with respective portable devices <NUM>, <NUM>, which may be configured to communicate with a local computer <NUM> as well as directly via wireless communication to authentication network <NUM>, which may comprise one or more servers <NUM>. As will be discussed in further detail below, "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. In contrast, 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 <NUM> may comprise wired and/or wireless communication interfaces to receive vehicle data, portable device data and other data from portable devices <NUM>, <NUM> as well as vehicles <NUM>, <NUM>. Additional data or instructions from computer <NUM> may be received via wired or wireless interface through network <NUM>. While not explicitly shown in <FIG>, servers <NUM> further comprise processors, storage and other peripheral devices known in the art to enable data processing and communication. For the purposes of the present disclosure, portable devices <NUM>, <NUM> 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.

In the example of <FIG>, vehicle <NUM> is linked to key fob <NUM>, which may be configured to open or start vehicle <NUM>. Key fob <NUM> may additionally be equipped with buttons (which may be luminous), other lights, and/or a keypad. Vehicle <NUM> may also be configured to be independently linked or paired with portable device <NUM> (i.e., without requiring an initial direct linking with a key fob), belonging to a first user. After being paired with vehicle <NUM> (discussed in greater detail below in <FIG>), portable device <NUM> will be able to receive and transmit data and/or instructions to vehicle <NUM>. The pairing of device <NUM> with vehicle <NUM> may be accomplished using any of a number of wireless communication protocols, including IEEE <NUM>. <NUM>, Bluetooth, Wi-Fi, and NFC. In one exemplary embodiment, portable device <NUM> may also be linked with key fob <NUM> to provide a path for wireless data communication as well.

Vehicle <NUM> is linked to key fob <NUM> and device <NUM> belonging to a second user, similarly as described above. In this example, vehicles <NUM> and <NUM> may each be considered part of authenticated group <NUM>, <NUM> linked to users of portable devices <NUM>, <NUM>, which may be family members, co-workers, drive-share groups and the like. Once registered as such (discussed in greater detail in <FIG> below), devices <NUM>, <NUM> may exchange data and/or instructions with each other (indicated by connecting arrow in <FIG>), as well as vehicles <NUM>, <NUM> of the authenticated group. Thus, in one example, portable device <NUM> would be configured to communicate with vehicles <NUM> and <NUM> as well as portable device <NUM>, while portable device <NUM> would similarly be configured to communicate with vehicle <NUM> and <NUM>, as well as portable device <NUM>. 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 <NUM> independently, in parallel, or in a "daisy-chain" fashion. Furthermore, as will be described in greater detail below, one authenticated device <NUM>, may be used to provide authentication to one or more other devices. In certain illustrative embodiments, computer <NUM> may be used to authenticate and/or manage authentication of registered devices.

Portable devices <NUM>, <NUM> may also be communicatively coupled to local computer <NUM>, which may be located at a user's home, place of work, etc. Local computer <NUM> may be a personal computer, laptop, or any other computing device capable of performing processing operations as well as sending and receiving data communication. In one embodiment, portable devices <NUM>, <NUM> communicates with local computer <NUM> wirelessly. In another embodiment portable devices <NUM>, <NUM> communicate with local computer <NUM> via a wired connection, which may include a dock or docking station (not shown). Local computer <NUM> may be suitably equipped with software allowing computer <NUM> to communicate with authentication network <NUM>, which may include one or more servers <NUM>. In one embodiment, local computer <NUM> communicates to authentication network <NUM> 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 <NUM>, <NUM> may also be configured to directly communicate with authentication network <NUM> via wireless and/or cellular connection as shown in <FIG> utilizing an on-device software application (or "app"), or through a web-based or mobile browser. In another exemplary embodiment, vehicles <NUM>, <NUM> may be equipped with wireless communication to enable vehicles <NUM>, <NUM> to also communicate wirelessly with authentication network <NUM>, similar to portable devices <NUM>, <NUM>.

In certain illustrative embodiments, vehicle authentication system <NUM> is configured to provide two-step or multi-step authentication for allowing entry and/or operation of vehicles <NUM> and/or <NUM>. Two-step authentication (also known as two-step verification) is a process involving two or more stages to verify the identity of an entity trying to access a vehicle. Generally speaking, the process involves 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. When accessing a vehicle, system <NUM> may execute a form of two-step verification. To determine who the individual is when accessing vehicle <NUM>, system may require the detection of a key fob <NUM> to show the individual has possession of a required item. In one embodiment, the system may alternately, or in addition, require the presence ("possession") of portable device <NUM> that is registered in the system. To further verify that the individual is authorized to access vehicle <NUM>, 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. In one embodiment, the individual may be required to enter a PIN on the portable device <NUM>, which is then communicated to vehicle <NUM> and/or authentication network <NUM>. In another embodiment, the individual may be required to physically press a button or series of buttons on key fob <NUM> for entering a PIN or authentication input. In a further embodiment, the vehicle may automatically receive secured device identification data (e.g., IMEI, IMSI) for authentication purposes. In one embodiment, inheritance factors may be utilized via the portable device <NUM> utilizing fingerprint or voice recognition embodied on the device itself.

Turning to <FIG>, an exemplary embodiment is provided illustrating components within a vehicle <NUM>-<NUM> for authentication, which may be incorporated into the embodiment of <FIG>, or may be configured as a stand-alone system. Processor <NUM> is responsible for operating and controlling doors <NUM> and associated locking mechanisms, as well as engine <NUM> operations and control. In one embodiment, processor <NUM> may be a stand-alone processor that communicates and controls a body controller in the vehicle to lock and unlock the doors <NUM>, and further communicates with an immobilizer or engine control unit (ECU) for controlling operation of the vehicle. In another embodiment, processor <NUM> may be two or more processors performing the same functions. In this example, 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. When the ECU determines that the coded key is both current and valid, the ECU activates the fuel-injection sequence.

Processor <NUM> is communicatively coupled to communications <NUM>, 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 <NUM> may include wired interfaces, such as USB or Firewire, as well as wireless interfaces, such as Bluetooth, Wi-Fi or cellular communication. Antennas <NUM> 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 <NUM> may be integrated with communications <NUM>, or may be configured as a stand-alone system. Processor <NUM> is also coupled to storage <NUM> 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 <NUM> may be further provided to display information from processor <NUM> 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.

Turning now to <FIG>, the figure illustrates an exemplary configuration <NUM> for communication among portable device(s) <NUM>, <NUM> and vehicle <NUM>, <NUM> utilizing a Bluetooth protocol. The configuration is particularly useful for pairing and bonding portable devices to vehicles and to each other. Generally speaking, two entities (e.g., device-device; device-vehicle) 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. If the 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 <NUM> coupled one or more applications <NUM>, <NUM> that may communicate via transport protocols RFCOMM <NUM> coupled to L2CAP <NUM>. Each of the user interface <NUM> applications <NUM>, <NUM>, RFCOMM <NUM> and L2CAP <NUM> may communicate with security manager <NUM>.

In <FIG>, an exemplary security management configuration is illustrated, that may be incorporated into a host software package on device(s) <NUM>, <NUM> and vehicle(s) <NUM>, <NUM>. For greater flexibility, 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. In <FIG>, security manager <NUM> resides on the Bluetooth host and communicates with L2CAP <NUM> and with link manager/controller <NUM> through host control interface (HCI) <NUM>. Typically, a connect request from a portable device to a vehicle (and vice-versa) arrives at L2CAP <NUM>, where the L2CAP <NUM> requests evaluation from security manager <NUM>. Security manager <NUM> looks up the requested service in database <NUM> for security information, and looks the requesting device's BD_ADDR or International Mobile Equipment Identity (IMEI) number in database <NUM> for access authorizations. Security manager <NUM> then begins the necessary authentication and (if needed) encryption procedures with the link manager <NUM> through HCI <NUM>. If authentication is determined to be positive, link manager <NUM> provides a response through HCI <NUM>, and L2CAP <NUM> finishes the connection setup process. The security manager architecture in <FIG> could be used to implement link-level (Mode <NUM>) security as well.

The configuration of <FIG> may implement basic security operations primarily at the link manager/controller <NUM> levels. Link controller <NUM> 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 <NUM> provides a set of commands that enable the formation of link management protocol packets containing the security parameters. HCI <NUM> provides a means for the host to communicate security items to the Bluetooth module for use by the link manager controller <NUM>. At the link layer, there may be several different entities used to maintain security. 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. There are several ways that a portable device and a vehicle (and/or another portable device in an authentication group) 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. In another embodiment, 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 <NUM> can enter these via an encrypted Bluetooth link or through an ordinary cable connection. When a device attempts to connect, 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. Under one embodiment, 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 <NUM> 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 <NUM> bits and as long as <NUM> bits.

Once any of the portable devices <NUM>, <NUM> and respective vehicles <NUM>, <NUM> are paired/bonded, the system may be configured to dynamically assign authentication and vehicle access and permissions. In some illustrative embodiments, user devices may be configured to allow them to access and operate vehicle using their device, with or without a key fob. In other illustrative embodiments, vehicle operations and functions (e.g., comfort settings, infotainment preferences, on-demand purchased options, etc.) may also be enabled via a user's device.

<FIG> shows a simplified flow diagram <NUM> for configuring a vehicle system for dynamic vehicle identification and access under an illustrative embodiment. Starting with block <NUM>, one or more fob keys (e.g., from key fob <NUM> and/or <NUM>) are registered with a vehicle. Once registered, the fob keys may provide access to a vehicle and/or activate predetermined functions within the vehicle. In block <NUM>, 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. Accordingly, under various illustrative embodiments provided below, a vehicle may be configured to have a key fob that has two or more devices associated with it. In other illustrative examples, a device associated with a key fob may grant authentication permission to another device.

In block <NUM>, the system may register user and/or device identification (ID) which may include passwords and the like. In certain illustrative embodiments, 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 <NUM>. In one example, 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. Upon completing the registration of the 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. In certain illustrative embodiments, once one or more IDs are registered, 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. As 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.

Once the registration of blocks <NUM>-<NUM> is completed, 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. As explained in further detail below, 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.

Turning to <FIG>, an operating environment <NUM> is shown that may be executed on the server <NUM> 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 <NUM> may be incorporated on other servers or devices, and that the present disclosure is not limited only to the server <NUM> or vehicle <NUM>. As the server loads or generates an access code <NUM>, a hash <NUM> may be created using security parameters <NUM> 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 <NUM> may be created from the hash <NUM> and a private key <NUM>, where the signature is associated <NUM> with the specific access code <NUM>. In an illustrative embodiment, a public key <NUM> may be used to create a root of trust <NUM>.

The operating environment <NUM> may be used to define a security boundary (or "secure environment" or "trusted environment") of the access codes transmitted to the device. The definition of the security boundary may affect the desired protection on interfaces and the way in which sensitive security parameters (SSPs), firmware and software are protected. The root of trust <NUM> 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. In one illustrative embodiment, 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 <NUM> 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. When inside the security boundary of an operating environment, decryption keys may be determined using a chip master key as a key blob decryption key. A chip master key may be configured as a secret key that is not available to any resource except a secure environment. Once a decryption key is recovered, it may be used in a secure process to decipher the access code.

<FIG> shows an operating environment <NUM> for the device <NUM> under an illustrative embodiment, where the device <NUM> may be configured to authenticate an access code received from the server <NUM> or vehicle and generate an access signal <NUM>. In certain illustrative embodiments, before an access signal is allowed on the device, 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 <NUM>, along with security parameters <NUM> and signature <NUM> are received in processing device <NUM>, wherein the hash <NUM> is obtained and used with the root of trust and public key <NUM> and signature <NUM> to perform integrity checking and authentication in <NUM>. If the integrity checking and authentication pass, the processing device <NUM> may generate an access signal <NUM> for accessing or activating one or more functions in the vehicle.

It should be understood by those skilled in the art that the embodiments of <FIG> are merely illustrative, and that other suitable authentication processes may be used. Generally speaking, 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). Using the numbers of the transponder and the vehicle, the algorithm produces a third number. Under an illustrative embodiment, 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.

During authentication, 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. At this point, the transponder sends A to the vehicle, where the vehicle similarly determines if A is correct. In this example, once they are authenticated, both the transponder and the vehicle can confirm or authenticate each other's without actually revealing the secret key or the authenticating algorithm. In one example, an authentication algorithm may be configured as follows. Both a vehicle processor or computer C and a transponder T hold a shared secret key K and a pseudorandom function family (implemented using an authenticating algorithm, such as a Megamos Crypto algorithm or another suitable algorithm) PRF, of which PRFK is a specific instance parametrized by the key K. During operation, the PRF may output a bitstring that is split into two parts, A and B. Thus, in one simplified example, to perform an authentication exchange:.

Now C and T have verified that they can each compute PRFK, and therefore hold the same key K.

Of course, those skilled in the art of cryptography will recognize that other authentication techniques utilizing random or pseudo-random functions and/or permutations may be utilized.

<FIG> is an exemplary flow diagram illustrating a registration process for a fob and a portable device with an authentication network and a vehicle. In this example, registration of portable device <NUM> may further include the incorporation of local computer <NUM>. The configuration of <FIG> may be advantageous in cases where vehicle <NUM> 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 <NUM> to directly communicate with authentication network <NUM>.

The registration process of <FIG> allows users to register and authenticate themselves and their portable devices with authentication network <NUM>, and to provide authentication permissions to other users. In step <NUM>, a key fob <NUM> is registered with the vehicle <NUM>, whereupon data relating to authentication for the fob described above is exchanged. In step <NUM>, the vehicle and fob data, including authentication data, may be transmitted to authentication network <NUM>, where authentication network <NUM> may store and process the received data in a server or similar device(s) associated with the network <NUM>. In step <NUM>, the portable device <NUM> may register with local computer <NUM>, 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 <NUM> (or send directly to the network <NUM>, discussed below) as an authentication profile for the registering user. In this embodiment, users may manually change or augment the authentication profile at computer <NUM> using software specifically configured for interaction with device <NUM> and authentication network <NUM>. For example, users may add or configure devices to be part of an authentication group, or to allow users to manually enter modifications to authentication rules and/or permissions. The device/user identification and authentication profile are then transmitted from computer <NUM> to authentication network <NUM> to initialize system registration.

In certain illustrative embodiments, the registration between device <NUM> and computer <NUM> may be configured via a dedicated wired connection. In other illustrative embodiments, the registration between device <NUM> and computer <NUM> may be done via a wireless (e.g., Wi-Fi, Bluetooth) connection. Once registered, computer <NUM> may transmit the information to authentication network <NUM> in step 908A, where one or more network servers may associate the device information with the registered fob. In certain illustrative embodiments, registration of a device may occur directly with authentication network <NUM> in step 908B, instead of through computer <NUM>, where the device <NUM> transmits device ID and/or any other device and/or user information to authentication network <NUM>, where it is processed and stored in one or more network servers. In this example, device <NUM> may perform the functions of computer <NUM> without requiring a separate device or apparatus.

The authentication network <NUM> may then process the device and fob information in order to associate them together for the vehicle <NUM>. In step <NUM>, the authentication network <NUM> registers the device <NUM> for use with the authentication network <NUM>, and in step 912A the authentication network <NUM> provides a fob key for associating the device <NUM> with fob <NUM>. In some illustrative embodiments, the fob key provided in step 912A is not the same secret key used by the fob <NUM> when authenticating with the vehicle <NUM>, but is a separate and distinct public/private key utilized by the device <NUM> to securely communicate with the authentication network <NUM> and/or the vehicle <NUM>. The network <NUM> also provides the same fob key to the vehicle <NUM> in step 912B, together with the device data/information in order for the vehicle <NUM> to recognize device <NUM> and to allow the device <NUM> to securely communicate with vehicle <NUM>. In certain illustrative embodiments, the network <NUM> may perform step 912A before step 912B. In certain illustrative embodiments, the network may perform step 912B before step 912A.

In step <NUM>, the device <NUM> requests device registration. In some illustrative embodiments, this is performed when the device <NUM> is in proximity to the vehicle <NUM> and communicating via a wireless protocol (e.g., Bluetooth, NFC). In step <NUM>, the vehicle <NUM> performs device/vehicle pairing, which may include a challenge to device <NUM> for authentication. In step 918A, the device <NUM> responds with authentication data that includes device information and the fob key received from the authentication network <NUM>. If the authentication data received from the device <NUM> is valid, the vehicle <NUM> may authenticate the device to communicate with vehicle <NUM> to allow the device <NUM> to send commands for accessing the vehicle <NUM> and/or to activate or control vehicle functions (e.g., start vehicle, control entertainment system, roll down windows, etc.). Device <NUM> may be equipped with special software providing a user interface for communicating commands to the vehicle <NUM> 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 <NUM>. In addition, 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. In one example, after the authentication of step 918A is performed, the vehicle <NUM> may be configured to send a second challenge to the device <NUM> that requires the user to provide a second entry to complete the authentication. In this example, 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. In some illustrative embodiments, multiple challenges may be configured to be transmitted as a multi-layer, single challenge.

In an illustrative embodiment, the vehicle <NUM> may confirm authentication to network <NUM> in step 918B. In some illustrative embodiments, device <NUM> may confirm authentication directly to network <NUM>. One authentication is confirmed, the network <NUM> may associate the device <NUM> with the registered fob from step <NUM> as an authorized fob/device for communicating with vehicle <NUM>. Alternately, the network may preliminarily associate the device <NUM> with fob <NUM> in any of steps 908A-B and confirm the association once authentication is confirmed in steps 918A-B.

Turning now to <FIG>, various illustrative tables <NUM>, <NUM>, <NUM> 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> shows an example of an authorization table that indicates authorized users and fobs for a plurality of vehicles under an illustrative embodiment. In this example, two vehicles (Vehicle_1, Vehicle_2) are associated with authorized users and fobs as shown, and may be associated together as a vehicle group comprising Vehicle_1 and Vehicle_2. In this example, the first vehicle (Vehicle_1) has one authorized user (User_1) and one authorized fob (FOB_A). The second vehicle (Vehicle_2) has three authorized users (User_1, User_2, User_3) and one authorized fob (FOB_B). In some illustrative embodiments, users may be identified and authorized via their device, where one device is associated with one user. In some illustrative embodiments, multiple users may be associated with one device. For example, 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 (e.g., received via step 912A) and a SIM card ID (ICCID). Accordingly, 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>.

<FIG> shows an example of an authorization table <NUM> for a plurality of users (User <NUM>, User_2, User_3) where device identification (ID) data, passwords and/or trusted (authenticated) fobs are registered for vehicle access under an illustrative embodiment. In some illustrative embodiments, a first user (User_1) is authenticated with a device having a respective device ID (Dev_1), a registered password (Pass_1) 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 (FOB_B). As will be explained in further detail below, 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). Thus, under an example, if the first user (User_1) approaches Vechicle_2 of <FIG> attempting to use his fob (FOB_A), access will be denied.

<FIG> shows an example of an authorization table for a plurality of users (User_1, User_2, User_3) 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. In this example, a first user (User_1) is authenticated with a device having a respective device ID (Dev_1), a registered password (Pass_1) and a trusted (authenticated) fob (FOB_A) that is also associated with the device (Dev_1). The associated device allows the user (User_1) to access and/or activate functions in a vehicle using the fob and/or device (Dev_1). 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 (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). As will be explained in further detail below, 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> 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. In block <NUM>, 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). In decision block <NUM>, 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> and authorization tables of <FIG>. If not ("NO"), the vehicle denies access in block <NUM> and moves to block <NUM>, where the vehicle detects the presence of a device. If the decision block1204 determines that the fob is authorized ("YES"), the process moves to block <NUM> where the vehicle detects the presence of a device. In decision block <NUM>, 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> and authorization tables of <FIG>.

If in decision block <NUM> the vehicle determines the device is authorized ("YES"), the vehicle grants access to the device in block <NUM> 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 <NUM> (e.g., via table <NUM>) and transmit a challenge to one or more authorized devices in block <NUM>. 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. In one example, 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. In the decision block <NUM>, 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 <NUM>.

In some illustrative embodiments, the access granted in block <NUM> may be limited to one feature (e.g., unlocking a door), selected features, or configured to access the full features of the vehicle. In some illustrative embodiments, the granting of access may occur only between the network and the vehicle <NUM>. However, in other illustrative embodiments, the authorized device may dynamically grant access to other devices to have the same or restricted features as the authorized device. In this example, when the authorized user provides a proper response in decision block <NUM>, the process moves to block <NUM>, where, as part of the access grant, the vehicle and/or the authentication network <NUM> proceeds to register the requesting (new) device via any of the techniques described herein, and particularly steps 908B-918B of <FIG>, and authenticate the new device as an authorized device. In some illustrative embodiments, 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. For example, the fob key may be set to expire after <NUM> hours, one day, one week, etc. In another example, 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.

<FIG> 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> provides a simplified example of a user (e.g., User_1) approaching a vehicle (Vehicle_1), where the user is in possession of a device ("<NUM>", or Dev_1) and fob "A" (FOB_A). Assuming in this example that both the device and fob are registered (e.g., see User_1 of <FIG>) and authenticated with the vehicle, either of the device or fob may be used to access the vehicle, either by manual entry (e.g., pressing button on device and/or fob) or by proximity detection of the device, the fob, or both. <FIG> 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 (Vehicle _1), but is registered with another vehicle of a registered vehicle group (e.g., see <FIG>). In this example, the device "<NUM>" may be allowed to access the vehicle, even though the associated fob (e.g., fob "A") is not present. In one illustrative embodiment, a challenge (e.g., "do you want the vehicle to recognize your fob for future access? (Y/N/)") may be transmitted to the device "<NUM>" to allow recognition the fob "B" for future access, since the device "<NUM>" is already registered and authenticated with the authentication system. If accepted, the fob will be added to the authentication table as a recognized fob, and vehicle will grant access in the future to the device "<NUM>" without a challenge when it is being carried with fob "B". In <FIG>, a user approaches a vehicle (Vehicle_1) carrying a device "<NUM>" that is registered and authenticated, but the user does not possess a fob. If the device "<NUM>" is authenticated with the vehicle (Vehicle_1), the user.

Turning now to <FIG>, a process flow <NUM> 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>) allows recognition and access of other devices, along with access permissions. In block <NUM>, 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 (and/or authentication system <NUM>) then looks up authorized devices (e.g., via authentication table(s)) and transmits a challenge to select devices in block <NUM>. In some illustrative embodiments, 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 <NUM>. 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 <NUM>. 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 <NUM>. 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 <NUM>-<NUM> 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.

In one example, if permission is given in block <NUM> to authorize (authenticate) a device, 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>. In block <NUM>, 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> shows a system <NUM> 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. In the illustrative embodiment, the processing device <NUM> includes a processor <NUM> or processor circuit, one or more peripheral devices <NUM>, memory/data storage <NUM>, communication circuity <NUM>, and a key manager <NUM>. The key manager <NUM> may be configured to process and/or manage fob keys. The key manager <NUM> may be incorporated into memory/data storage <NUM> with or without a secure memory area, or may be a dedicated component, or incorporated into the processor <NUM>. Of course, processing device <NUM> 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 <NUM>, or portions thereof, may be incorporated in the processor <NUM> in some embodiments.

The processor <NUM> may be embodied as any type of processor currently known or developed in the future and capable of performing the functions described herein. For example, the processor <NUM> may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit. Similarly, memory/data storage <NUM> 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. In operation, memory/data storage <NUM> may store various data and software used during operation of the processing device <NUM> such as access permissions, access parameter data, operating systems, applications, programs, libraries, and drivers.

Memory/data storage <NUM> may be communicatively coupled to the processor <NUM> via an I/O subsystem <NUM>, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor <NUM>, memory/data storage <NUM>, and other components of the processing device <NUM>. For example, the I/O subsystem <NUM> 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. In some embodiments, the I/O subsystem <NUM> may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor <NUM>, memory/data storage <NUM>, and other components of the processing device <NUM>, on a single integrated circuit chip.

The processing device <NUM> includes communication circuitry <NUM> (communication interface) that may include any number of devices and circuitry for enabling communications between processing device <NUM> and one or more other external electronic devices and/or systems. Similarly, peripheral devices <NUM> may include any number of additional input/output devices, interface devices, and/or other peripheral devices. The peripheral devices <NUM> 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 <NUM> (which may be similar to network server <NUM>) 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. In the illustrative embodiment of <FIG> the server <NUM> includes a processor <NUM>, an I/O subsystem <NUM>, a memory/data storage <NUM>, communication circuitry <NUM>, and one or more peripheral devices <NUM>. Components of the server <NUM> may be similar to the corresponding components of the processing device <NUM>, the description of which is applicable to the corresponding components of server <NUM> and is not repeated herein for the purposes of brevity.

The communication circuitry <NUM> of the server <NUM> may include any number of devices and circuitry for enabling communications between the server <NUM> and the processing device <NUM>. In some embodiments, the server <NUM> may also include one or more peripheral devices <NUM>. Such peripheral devices <NUM> 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 <NUM> also includes a fob key generator <NUM> that is configured to generate cryptographic secret key for transmission to the device <NUM> or a vehicle. The fob key and rules manager <NUM> stores and manages fob keys that are transmitted, and may further store and process authentication tables and access permission and parameters.

In the illustrated embodiment, communication between the server <NUM> and the processing device <NUM> takes place via a network <NUM> that may be operatively coupled to one or more network switches (not shown). In one embodiment, the network <NUM> 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). Generally, the communication circuitry of processing device <NUM> and the communication circuitry <NUM> of the server <NUM> 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. As such, the network <NUM> may include any number of additional devices, such as additional computers, routers, and switches, to facilitate communications between the processing device <NUM> and the server <NUM>.

In certain illustrative embodiments, the techniques for securely accessing vehicle functions may be configured for a single user and/or a group of users (e.g., a family). In some illustrative embodiments, key fobs may be scaled to accommodate large groups of users. For example, key fobs may be configured in a system to allow secure large-scale distribution and management of key fobs that may be advantageous in vehicle rental and/or vehicle sharing applications.

Turning to <FIG>, a system <NUM> is disclosed that may be used in a system environment such as the one illustrated in the embodiment of <FIG>, as well as other embodiments disclosed herein. In this example, a portable device <NUM>, which may be configured similarly as portable device <NUM>, may be configured to communicate with a local computer <NUM>, which may be operated and/or controlled by a third party, such as a rental or ride-sharing agency. Local computer <NUM> may be configured similarly to computer <NUM>. In this example, local computer <NUM> may be configured with a fob key database comprising a plurality of registered (or pre-registered) key fobs <NUM>-<NUM> that are registered using any of the techniques disclosed herein. Local computer <NUM> may be configured to communicate with server <NUM>, which may be part of an authentication network, and may be configured similarly as server <NUM>, discussed in greater detail above.

In this example, local computer <NUM> may be configured to register one or more portable devices to a vehicle linked to a respective key fob. Servers <NUM> may include wired and/or wireless communication interfaces to receive vehicle data, portable device data and other data from portable devices <NUM>, <NUM> as well as one or more vehicles linked to a key fob. Additional data or instructions from computer <NUM> may be received via wired or wireless interface through the network in system <NUM>. In some illustrative embodiment, the devices <NUM>, <NUM> may be configured to communicate data with each other, including fob keys.

During operation, local computer <NUM> may be used to receive device ID and/or device information from any of devices <NUM>-<NUM> in order to register those devices as authored users of a key fob for a vehicle. during the registration process, the local computer <NUM> may transmit the device and key fob information to server <NUM>, in order to receive a fob key (i.e., a software key) configured to allow the requesting devices to access one or more vehicle functions, similar to the techniques described elsewhere herein. In an illustrative embodiment, the fob key 1608A may be transmitted from the server <NUM> to the local computer <NUM>, where the local computer may alter the fob key 1608A to include key limitations for setting parameters on vehicle usage (e.g., time limitations, distance limitations, etc.). In some illustrative embodiments, these limitations may be included as separate data files that are associated with the received fob key 1608A. In another illustrative embodiment, these limitations may be encoded into the fob key itself as data packets, where a fob key authentication process unlocks the vehicle use limitation parameters and loads them into the vehicle.

The limitation packet(s) may include time limitation data, which limits the time in which the key fob is valid. After the expiration of the time period, the system <NUM> may be configured to transmit a message to the device and/or the local computer <NUM>, informing that the time period has expired. In another illustrative embodiment, there may be multiple time limitations in which a message is transmitted at the end of a first time period, and wherein access to the vehicle is disabled after the expiration of a second time period. Similarly, a usage limitation may be added, such as a mileage limitation. In this example, the system <NUM> may receive periodic data transmissions from the vehicle indicating one or more vehicle usage parameters. Similar to the time limitations, once a vehicle exceeds a usage limitation (e.g., travels more than <NUM> miles), a message may be transmitted to the device and/or the local computer <NUM>, informing that the usage limitation has been exceeded. Additionally, the vehicle may be disabled from recognizing fob keys. In some illustrative embodiments, time and usage limitations may be combined.

Once the limitations (parameters) are appended and/or associated with the fob key 1608A, the local computer <NUM> transmits the modified fob key 1608B to each registered device. In the example of <FIG>, the local computer may request a fob key for devices <NUM>, <NUM>, where the server returns fob key 1608A. Once the fob key 1608A is modified by local computer <NUM> to incorporate usage limitations, the modified fob key 1608B is transmitted to each device <NUM>, <NUM> to allow the devices to authenticate themselves with the associated vehicle and to allow access to vehicle features, as described in more detail above. Of course, it should be understood by those skilled in the art that the generation and modification of fob key 1608A-B may be performed entirely on server <NUM>, or may alternately be performed entirely on local computer <NUM>, provided the local computer <NUM> has sufficient processing power and storage.

In addition to time and/or usage limitations, the system <NUM> may be configured to refresh fob keys for additional security. In some embodiments, new fob keys may be generated at predetermined times (e.g., <NUM> hours, <NUM> hours, <NUM> hours, etc.) to allow for multiple periodic authentication. As with the original fob key, the authentication keys would be automatically transmitted to the device(s) and the vehicle to ensure that the proper authentication keys are used for vehicle access. In such a configuration, the fob keys may be configured to be disabled after a new (refreshed) fob key is received. Such a feature may be advantageous for security purposes, since even if a key fob was hacked, the maximum time period in which access would be allowed would be the remaining time period before the next secure fob key is authorized between the vehicle and the device(s). In one illustrative embodiment, a fob key may be designated as a "primary" key, subject to the appended limitations, and may further include refresh data, indicating the existence of "secondary" refresh fob keys. Accordingly, the vehicle would grant access only when the primary key and the secondary key are authenticated. In some illustrative embodiments, only a single key may be used and refreshed. Is this configuration, each new key may include updated limits to ensure that the overall limits are maintained throughout vehicle usage.

When using a plurality of keys, and as an example, during initial use, a primary key would be provided and authenticated together with an initial secondary key to establish initial access to vehicle functions. Here, access to vehicle functions would be allowed only after the primary and secondary fob keys are authenticated. In this example, the secondary key may include a time limitation that is shorter than any time limitation for the primary key. Once authenticated, the primary key may include data indicating that one or more additional "refreshed" (new) secondary keys will be received. After the expiration of the time period for the secondary key, they vehicle may limit and/or restrict access to vehicle functions. Preferably before the expiration of this time period, the system may generate and transmit a new secondary key to the device and the vehicle. As the current secondary fob key expires (or at a predetermined time before expiration), the vehicle may determine if a new secondary fob key has been received. If so, the vehicle may authenticate the secondary fob key and replace the current fob key with the new fob key. Alternately, the vehicle may wait until the expiration of the current fob key to replace it with the newly authenticated one. This process may repeat itself according to a refresh cycle until the primary fob key expires.

Turning to <FIG>, an authorization table 1700A is shown that includes fob key limitations, such as the ones discussed above, under an illustrative embodiment. Here, a vehicle (Vehicle _1) includes a plurality of authorized users <NUM> (User_1, User_2) that are linked or associated with a fob key <NUM> (FOB_A). In this example, the fob key generated for the vehicle includes both time <NUM> and use <NUM> limitations, where the (primary) fob key is valid for <NUM> days, <NUM> hours (<NUM>:<NUM>:<NUM>:<NUM>) and the distance limit for the vehicle is <NUM> miles. For the embodiment of <FIG>, key fob refreshing 1710A is disabled ("N"), in which case data related to refreshing such as a refresh cycle 1712A and a refresh time 1714A may be left blank. During use, the key fob would be transmitted to a vehicle and devices to allow a user to access vehicle functions according to prescribed limits, meaning, that the user could access vehicle functions for <NUM> days, <NUM> hours, and be permitted to drive the vehicle for a maximum of <NUM> miles.

<FIG> is similar to the illustrative embodiment of <FIG>, except that key fob refresh is activated 1710B ("Y"). Here, the refresh cycle 1712B is set to <NUM> hours (<NUM>:<NUM>:<NUM>:<NUM>) and the refresh time is set for <NUM>:00AM (<NUM>:<NUM>). In some illustrative embodiments, when the refresh cycle may include a buffer so that new keys may be received at times where there is a low probability that the user is in the process of using the vehicle, which would mitigate the effects of a communication failure that may occur when a new key is being transmitted. In some illustrated embodiments, the system may be configured to automatically re-try transmitting/receiving new keys if they are not properly received and/or authenticated.

<FIG> shows a process flow <NUM> for generating a fob key and appending fob key limits on vehicle usage, where the fob keys may be refreshed and updated until a fob key limitation is reached, under an illustrative embodiment. In block <NUM>, a primary fob key is generated, and fob key limits (e.g., time, vehicle usage) are appended in block <NUM>. As mentioned previously, the limitation data may be configured as one or more separate data files that are associated with the key fob, or may be encoded into the fob key itself. In block <NUM>, the fob key may be transmitted to one or more devices and vehicle and may be authenticated to provide user access to vehicle functions. In decision block <NUM>, it is determined if the key fobs are to be refreshed, and, if so ("YES"), a new (secondary) fob key is generated in block <NUM>, which may be configured to provide updated limits. In block <NUM>, the new fob key is transmitted and authenticated using any of the techniques described herein. In decision block <NUM>, the system determines if the fob key limitation (e.g., time, distance, etc.) has been reached. If not ("NO"), the process moves to decision block <NUM> to determine if a refreshed fob key is to be received. If so, the process proceeds to blocks <NUM>-<NUM> in a similar manner as before. If decision block <NUM> determines that no refreshed fob keys are to be received ("NO"), the process moves to decision block <NUM> until a limit is reached ("YES"), in which case a message is transmitted in block <NUM>. In one example the message may be transmitted to the device linked to the vehicle informing the user of the limit (e.g., "Your time limit for renting this vehicle has expired"). In some illustrative embodiments, a plurality of thresholds may be used, where each limit may be associated with a different message. For example, passing a first threshold may result in a transmitted message communicating an upcoming fob key expiration (e.g., "Your vehicle access expires in <NUM> hours. Please drive vehicle back to rental station. Passing a second threshold may result in a transmitted message communicating a more imminent fob key expiration (e.g., "Vehicle access expires in <NUM> hours. Please return vehicle ASAP. As can be appreciated by those skilled in the art, numerous configurations may be arranged by a system designer to accommodate various kinds of messaging.

In some illustrative embodiments, the transmitted message of block <NUM> may also include executable code that allows a user to respond to the message via a graphical user interface, text box and the like. In these embodiments, the user may be presented with the message, along with a response interface (e.g., "Your vehicle access expires in <NUM> hours. Will you be able to return the vehicle in time (Y/N)?"). Depending on the response (e.g., "N"), the message may include a secondary response interface requiring further input (e.g., "enter how much longer you require the vehicle: 1hr, 2hrs, 3hrs, <NUM> hrs"). Once the secondary response is received, this data may be used to generate another authentication fob key that allows a user to extend vehicle usage beyond the initial limits.

<FIG> shows a process flow <NUM> for a vehicle for receiving and authenticating a fob key, wherein the authenticated fob key limitations are applied, vehicle data is reported and refreshed fob keys may be processed and managed under an illustrative embodiment. In block <NUM>, a vehicle may receive a fob key and authenticate the fob key in block <NUM>. After authentication, the vehicle may apply the limits, including any refresh-related data, to vehicle access and/or vehicle functions in block <NUM>. In block <NUM>, the vehicle may report vehicle usage data (e.g., miles traveled) using any suitable for of communication. In decision block <NUM>, the vehicle determines if a refresh of the fob key is to be performed. If not ("NO"), the process continues to report any vehicle data in block <NUM>, and proceeds to decision block <NUM> to determine if a limit has been reached. If, in decision block <NUM>, the vehicle determines that a refresh of the fob key is to be performed ("YES"), it receives and authenticates (e.g., via process flow <NUM>) a new fob key in block <NUM> and applies any updated limits in block <NUM>. In decision block <NUM>, the vehicle determines if a fob key limit is reached, and, if not ("NO"), the process <NUM> moves to decision block <NUM> to determine if another refreshed fob key is to be received. If so ("YES"), the process <NUM> repeats blocks <NUM>-<NUM> until a limit has been reached ("YES"). Once the limit is reached, the vehicle (and/or a user device) may display a user limitation message, such as the one generated and discussed in block <NUM> of <FIG>, or any other technique disclosed herein. In addition, block <NUM> may restrict fob key access, such as when a fob key has expired.

The various technologies and techniques discussed herein provide an efficient platform for allowing a system to manage a plurality of fob keys for a plurality of users, and particularly for systems, such as vehicle rental or vehicle-sharing systems, in which large scale fob key distribution among hundreds, if not thousands of users may be accomplished. Because, in part, of the fob key security and distribution, millions (and even billions) of different fob keys may be provided to provide vehicle function access in a secure and reliable manner.

It should be appreciated by those skilled in the art that the techniques and configurations disclosed herein provide many flexible features to allowing dynamic access to a vehicle via a device, such as a smart phone, tablet, laptop, wearable device, and the like. Unique and novel technologies may provide secure communication between a vehicle and a device, which in turn may provide secure communication and access to the vehicle via other devices. By monitoring and updating authentication tables, an authentication system may efficiently recognize and associate users and groups of users to provide even further flexibility.

The figures and descriptions provided herein may have been simplified to illustrate aspects that are relevant for a clear understanding of the herein described devices, structures, systems, and methods, while eliminating, for the purpose of clarity, other aspects that may be found in typical similar devices, systems, and methods. Those of ordinary skill may thus recognize that other elements and/or operations may be desirable and/or necessary to implement the devices, systems, and methods described herein. But because such elements and operations are known in the art, and because they do not facilitate a better understanding of the present disclosure, a discussion of such elements and operations may not be provided herein.

Exemplary embodiments are provided throughout so that this disclosure is sufficiently thorough and fully conveys the scope of the disclosed embodiments to those who are skilled in the art. Numerous specific details are set forth, such as examples of specific components, devices, and methods, to provide this thorough understanding of embodiments of the present disclosure. Nevertheless, it will be apparent to those skilled in the art that specific disclosed details need not be employed, and that exemplary embodiments may be embodied in different forms. As such, the exemplary embodiments should not be construed to limit the scope of the disclosure. In some exemplary embodiments, well-known processes, well-known device structures, and well-known technologies may not be described in detail.

The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. The steps, processes, and operations described herein are not to be construed as necessarily requiring their respective performance in the particular order discussed or illustrated, unless specifically identified as a preferred order of performance.

These terms may be only used to distinguish one element, component, region, layer or section from another element, component, region, layer or section. 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).

Claim 1:
A system for authorizing access to vehicle functions, comprising:
a processor (<NUM>);
data storage (<NUM>), operatively coupled to the processor (<NUM>), the data storage configured to store fob data relating to a key fob (<NUM>, <NUM>) linked to the vehicle, and device data comprising data relating to one or more devices that are authorized to access the vehicle; and
communications circuitry (<NUM>), (<NUM>, operatively coupled to the processor (<NUM>), <NUM>), the communications circuitry configured to receive an access request indicating that a new device is requesting access to the vehicle,
wherein the processor (<NUM>) is configured to transmit a challenge via the communications circuitry (<NUM>) to one of the one or more devices that are authorized to access the vehicle and receive a response thereto,
generate a secure fob key based on the response, wherein the secure fob key comprises limitation data (<NUM>, <NUM>) for setting parameters on vehicle access and wherein the limitation data comprises fob key refresh data (1710A, 1710B, 1712A, 1712B, 1714A, 1714B) for refreshing the secure fob key at predetermined times,
transmit the secure fob key to the new device,
authenticate the new device based at least in part on the secure fob key, wherein the new device is authorized to access the vehicle subject to the limitation data upon completion of the authentication,
wherein a new secure fob key is generated based on the refresh data and transmitted to the new device, to refresh the secure fob key.