Methodology for the emergency transfer of keys for a vehicle equipped with biometric access and start

Abstract

System, comprehensive: a control panel communicating with a function controller, the control panel being configured as follows: Receiving an authentication request that includes user input; authenticating the user input by comparing the user input with at least one stored input; Determining a vehicle mode; Update, via function control, a status associated with a key fob, in response to the vehicle mode being an authenticated mode.

Description

[0001] Motor vehicles can have multiple vehicle-associated keys that grant access to the vehicle, as is known, for example, from publication CA 2 778 543 A1. Furthermore, biometrics can be used to authenticate a driver. A combination of at least two valid keys is required to program another key. Alternatively, two valid biometric inputs or one valid key and one valid biometric input can be used to program an additional key. Therefore, at any given time, the driver of a vehicle can possess only physical keys, only learned biometric inputs, or combinations thereof.In cases where only learned biometric data is available, it may be impossible to transfer driving privileges to the vehicle if the user with the sole biometric access moves away from the vehicle or is unable to approach it. For this reason, conventional systems prevent the simple transfer of an active key or the programming of an additional key, especially if only one other valid key exists. Therefore, an improved system for programming additional keys and transferring existing keys while maintaining vehicle security is needed.

[0002] In one embodiment, a system can have a control unit that communicates with a function controller and is configured to receive an authentication request. The authentication request can include user input, and the user input can be authenticated by comparing it with at least one stored input. The control unit can determine a vehicle mode and, via the function controller, update a status associated with a key fob in response to the vehicle mode being an authenticated mode.

[0003] A procedure can involve receiving an access request with user input. The user input can be compared to at least one stored input, and authenticated in response to the user input matching the at least one stored input. A vehicle mode can be determined, and a status associated with a key fob can be updated in response to the vehicle mode being an authenticated mode.

[0004] A procedure can also involve detecting a key fob within a container. An initial and a second input can be authenticated. A state associated with the key fob can be updated to include a backup state in response to the authentication of the initial and second inputs.

[0005] They show: Fig. 1. An exemplary system diagram of an emergency transfer system; Fig. 2 an exemplary container and key ring; Fig. 3A to C an exemplary flowchart of the emergency transfer system; and Fig. 4A to B shows another example flowchart of the system.

[0006] With reference to the processes, systems, procedures, heuristics, etc., described herein, it will be understood that, although the steps of such processes, etc., are described as occurring in a specific, ordered sequence, such processes with the described steps may be carried out in a different order than that described herein. It will further be understood that certain steps may be carried out simultaneously, that other steps may be added, and that some of the steps described herein may be omitted. In other words, the descriptions of processes herein serve solely to illustrate specific embodiments and are in no way to be construed as limiting the patent claims.

[0007] In certain situations, a vehicle driver may wish to transfer a key fob to another driver to grant them access and driving privileges (e.g., service drivers, car dealership staff, friends and family, etc.). Some of these situations may include emergencies, such as allowing the police to move the vehicle after an accident, transferring the key fob due to a medical emergency, or transferring the key fob in cases of coercion, such as car theft or robbery. Therefore, programming a backup or emergency transfer key fob to be kept in the vehicle can allow a driver, under certain circumstances, to activate the emergency transfer key and then easily transfer the key fob to grant access and driving privileges to the vehicle. Under the right conditions, such as...With proper authentication and vehicle status, the emergency transfer key can be handed to the other driver within seconds. A vehicle's emergency transfer system can include a container and a biometric device configured to grant access to the container. The container can be configured to hold an emergency transfer key fob. After user authentication, the fob can be removed from the container and transferred to a second user. Therefore, even if the second user is not a registered user, they can use the vehicle normally. Before removing the fob from the container, the system can determine whether the fob was removed during an authenticated or unauthenticated operating mode.Based on this determination, the status of the key fob can be updated, thus influencing the functionality of the key.

[0008] Fig. Figure 1 shows an exemplary system for the emergency transfer system. The system 100 can include a controller 102 that communicates with a biometric device 104 and a container 106. The biometric device 104 can be configured to collect biometric input from a user. In one example, the device 104 can be a fingerprint scanner configured to read at least one of the user's fingerprints or thumbprints (hereinafter referred to as fingerprints). In another example, the device 104 can be a voice recorder or a retinal scanner. For the sake of completeness, the biometric device 104 described herein is a fingerprint scanner. The biometric device 104 can be contained within the vehicle. In one example, the biometric device 104 can be integrated into a push-button starter.In another example, the biometric device 104 can be integrated into the top of a gearshift lever of the vehicle, or into a dashboard. In yet another configuration, the biometric device 104 can be located near or inside the container 106.

[0009] The biometric device 104 can communicate with the controller 102 via a first interface 108. The interfaces described herein, including the first interface 108, the second interface 110, the third interface 112, the fourth interface 114, and the fifth interface 115, can have an input / output system configured to send and receive data from the respective components. For example, the first interface 108 can provide the transfer of biometric data from the biometric device 104 to the controller 102. Furthermore, the interfaces 108, 110, 112, 114, and 115 can be unidirectional, meaning that data can only be transmitted in one direction. For example, the first interface 108 can be configured only to transmit biometric data to the controller 102, but not vice versa.Furthermore, interfaces 108, 110, 112, 114, and 115 can be bidirectional, both receiving and sending data between the components. For example, the first interface, 108, can be unidirectional, while the remaining interfaces, 110, 112, 114, and 115, can be bidirectional.

[0010] Interfaces 108, 110, 112, 114, and 115 can incorporate security features and therefore be considered trusted. For example, in one approach, these interfaces can implement Trusted Execution Technology (TXT), enabling secure key generation, storage, and authentication. By securing the signal paths, interfaces 108, 110, 112, 114, and 115 provide an enhanced system to protect against data transmission (e.g., copied biometric data) that could lead to false identifications. Other security mechanisms can also be implemented. For instance, timestamps can be generated with the biometric data. Therefore, when controller 102 receives the data, the timestamp can be verified to ensure that the input is genuine biometric evidence and not copied.

[0011] The controller 102 may include a processor 116 configured to facilitate the authentication processes described herein. The controller 102 may also include a device driver 118 for controlling communication between the biometric device 104 and the controller 102. The device driver 118 can facilitate the reception of biometric data at the controller 102. It can convert or translate the biometric data into a usable biometric template. These templates can be used to authenticate a user based on the received biometric data. In the example where the biometric data is a fingerprint, the data may need to be converted into a readable format, such as a template, before the authentication process can be performed. For example, each fingerprint contains unique data points, such as an arc in the middle, a double loop, etc.These details can be translated into a numerical pattern, such as a vector, that forms the biometric template. Because the biometric template is a numerical representation of the fingerprint data, an image of the fingerprint itself is never stored in Control 102. This template can be represented and transmitted in a standard format, such as a Biometric Interworking Protocol (BIP). A Biometric Identification Record (BIR) can include a header, biometric data, and a signature that is recognized by Control 102.

[0012] Biometric data can be received by the Control Unit 102 in various situations. First, the data can be received for login purposes. A user can register their biometric data (e.g., fingerprint) during login mode. In this situation, two or more key fobs previously programmed for the vehicle (typically at the factory) or two or more previously stored prints (i.e., key fobs and / or the person to whom the prints belong) may be required to ensure that the user attempting to register their biometric data is authorized to do so. Additionally or alternatively, a personal identification number (PIN) can be entered via a separate interface and analyzed by the Control Unit 102 for further user authentication prior to biometric login.After user authentication, the received biometric data can be converted into a biometric template, as described previously. The login biometric template is then stored in template database 120. This template can be stored in database 120 and used to authenticate the user at a later time. Although a number of biometric templates can be stored in database 120, a typical system may allow for the storage of up to twelve templates.

[0013] As mentioned, biometric data can also be received in an authentication mode to authenticate the user. The biometric data can be received in an attempt to grant access to the vehicle. When biometric data is received for authentication purposes, it can be converted into a received biometric template in the controller 102. A comparator 124 of the controller 102 can then compare the received template with the registered templates in the template database 120. After finding a match between the received template and at least one of the registered templates, the comparator 124 can output a pass notification to the controller 102. If no match is returned, an error notification can be sent.

[0014] After receiving a positive match indication from the comparator 124, access and driving authorizations for the vehicle can be granted. Such access can include unlocking the vehicle's door(s) to allow the user to enter the vehicle. Access can also include other functions, such as normal vehicle operation (e.g., starting the vehicle, driving, radio operation, lights, etc.). As described in more detail below, an emergency transfer key fob 126 can also be activated during biometric authentication. In a normal state within container 106, the emergency transfer key fob 126 may be marked INACTIVE. Therefore, for theft prevention reasons, if the key fob is removed while the vehicle is switched off or parked, the key fob cannot be used to access or drive the vehicle. This process is described below with reference to Fig. 3 described in more detail.

[0015] The key fobs 126 and 128 described herein have PEPS (Passive Entry Passive Start) capabilities. The key fobs 126 and 128 can also be part of systems referred to as keyless entry systems, Advance Key, Comfort Access Systems, Enter-NG™, Intelligent Access, Smart Entry, SmartKeys, Intelligent Key®, SmartPass, and Kessy systems, to name just a few. The key fobs 126 and 128 can communicate with the vehicle via LF and / or UHF frequency communication protocols, including requests and responses between the key fob 126 and 128 and a function controller 132. The function controller 132 can be a PEPS controller and can communicate with the controller 102. The function controller 132 can also be integrated into the system controller 102. The function controller 132 can have or communicate with a PEPS database 138.The PEPS database 138 can contain a list of registered key fobs 126 and 128 and their associated statuses. For example, key fob 128-1 can be a primary key fob, while key fob 128-2 can be a secondary key fob. These associated status indicators can relate to specific vehicle settings associated with the normal user of that key fob 128, such as seat position, temperature control, etc.

[0016] The PEPS functions can provide a user with various keyless functions, such as passive access, passive engine start, engine shutdown, passive locking, etc. For example, a key fob 128 can be associated with a user (e.g., in the user's pocket or wallet). The function controller 132 and the key fob 128 can communicate with each other. After authenticating the key fob 128, the function controller 132 can unlock a vehicle door. The key fob 128 can have a transponder configured to operate as an RFID tag and paired with the function controller 132. To gain access to the vehicle by unlocking the doors, the controller 102 can wake up to establish communication between the key fob 128 and the function controller 132.For example, the user can touch or operate a vehicle door handle, or press the start button, which is detected by the control unit 102. Once the control unit 102 has woken up, and in turn has woken up the function control unit 132, the control unit 132 can transmit a low-frequency signal to the key fob 128. The key fob 128 can respond with a high-frequency signal containing a key fob ID. After receiving a valid key fob ID from the key fob, the function control unit 132 can send a signal to the control unit 102 via the fifth interface 115, indicating that the key fob is authorized. The control unit 102 can then send the appropriate signals to unlock the door. Therefore, the key fob 128, the function control unit 132, and the control unit 102 initially work together before the function request is executed.

[0017] As in Fig. As shown in Figure 1, multiple key fobs 128 can be recognized by the function controller 132. Each key fob 128 can have a specific key fob ID as well as a vehicle identification number (VIN) associated with the vehicle. These IDs are generated by the manufacturer during vehicle production. Therefore, an unrecognized key fob cannot be used to access the vehicle. Furthermore, if the key fob is lost or stolen, it cannot be reprogrammed for use with another vehicle except by an authorized dealer of the original equipment manufacturer (OEM). Additionally, if the key fob is tampered with, for example, by removing one or more IDs, reprogramming the key fob would require a dealer verification tool. This additional security measure renders a stolen key virtually useless.

[0018] In certain situations, an unrecognized key fob can be programmed with the function control 132. For example, if one or more original key fobs 128 are located within the predetermined area of ​​the control 132 or placed in the container 106, the vehicle 100 can verify that this key fob is authorized. Each of these key fobs can be associated with a specific status, such as primary or secondary driver, which is stored in the database 138 of the function control 132. Additionally, a key fob can be defined as an emergency transfer key fob 126. As described herein, this key fob 126 can be kept in the vehicle's container 106. After user authentication during a valid vehicle mode, the emergency transfer key fob 126 can be defined as ACTIVE in the function control 132.A vehicle can operate in different modes. For example, it can operate in authenticated and unauthenticated modes. An authenticated mode can include vehicle operation where user authentication is required to access the vehicle. For example, driving the car might require authentication by a user via a key, biometric input, a signal from a recognized key fob, etc. These operating modes include auxiliary and motion modes, and can include delayed auxiliary modes. When the vehicle is in an auxiliary mode, some functions that require relatively little power or have a limited operating time are functional. In motion mode, the car's engine can run, so all functions are operational.In delayed accessory mode, the car may have just exited motion mode. In this mode, some functions, such as the car radio, may remain available even after the engine has been switched off. In motion-off mode, the car is switched off, except in the special case of a remote start event (which is equivalent to a non-motion mode with very limited functionality).

[0019] An unauthenticated mode can include events and occurrences where a vehicle is entered without authentication. For example, a car may be parked and thus in a non-motion mode. In another example, the vehicle may be started via a passive-start remote start function. Therefore, the user may not be in or around the car, but the car may be idling in a non-motion mode. These operating modes can be considered non-motion off and non-motion on operating modes, respectively. In one embodiment, if the emergency transfer key fob 126 is removed from the container 106 while the vehicle is in a non-motion or unauthenticated state, the key fob 126 may be INACTIVE. However, if the key is removed from the container 106 during the auxiliary, motion, and delayed auxiliary modes, the key fob may be updated to ACTIVE.

[0020] In another example, the emergency transfer key fob 126 can be removed from its container while the engine is running (e.g., in RUN mode). Because the device has been authenticated, key fob 126 can be redefined and become an active key fob (e.g., the key fob's status in database 120 can be updated to ACTIVE), granting it all access and other functions just like other active keys. By activating the emergency transfer key fob 126 as an active key, key fob 126 can be transferred to another user, who can then obtain full access and driving privileges for the vehicle. Conversely, if the key fob is removed from its container 106 during a non-RUN mode (when the vehicle is off), key fob 126 can still be defined as INACTIVE.Some functions, such as panic and locking functions, can also be performed by an inactive key. This allows a user to know that the key fob is functional but not in an active mode.

[0021] Therefore, in certain emergency situations, the emergency transfer key fob 126 can be transferred to another user. For example, if the driver of the vehicle suffers a medical emergency while driving, such as a heart attack, stroke, etc., and emergency personnel have removed the person from the vicinity of the vehicle, the key fob 126 can be removed from container 106 and used by a second user, such as the passenger or another driver. The second user can then operate the vehicle and take the first driver to the hospital, follow the ambulance, move the vehicle to a safer location, etc. In another example, a driver might wish to have their vehicle parked without handing over their key fob to the parking attendant.Upon reaching the parking attendant, the driver can park the vehicle and remove the emergency transfer key fob 126 from the container 106. Since the vehicle was running when the key fob was removed, the emergency transfer key fob 126 can be defined as ACTIVE by the function control 132. Therefore, the driver can hand the emergency transfer key fob 126 to the parking attendant, thus granting them full access to the vehicle.

[0022] After an emergency transfer key fob 126 is returned to container 106 following its use, the key fob 126 can be marked as INACTIVE again. Additionally or alternatively, the function control 132 can be configured to reset the key fob 126 to INACTIVE after a predetermined time period or a predetermined action within the vehicle. For example, the emergency transfer key fob 126 can be INACTIVE if it is not returned to container 106 within four hours of being set to ACTIVE. Therefore, if a parking attendant does not return the key fob, it does not pose a security risk because it cannot be used to access the vehicle. Details of this procedure are described below.

[0023] It can be beneficial for the key fob to remain in an inactive state during a non-movement mode. This can protect the key fob from being used if it is removed by an unauthorized user (e.g., a thief).

[0024] The status associated with a specific key (e.g., ACTIVE, INACTIVE, primary, secondary, emergency transfer / backup) can be stored in or communicated with a database 138 of the function controller 132. This database 138 can contain a list of key fobs and their respective statuses. For example, key fob 128-1 can be a primary key fob, while key fob 128-2 can be a secondary key fob. Additionally, a key fob 126 located in container 106 can be used as an emergency transfer key fob 126 or a backup key fob. The database 138 can store these statuses. When the status of a key fob changes (e.g., from INACTIVE to ACTIVE), the database 138 can display this change and update a status indicator associated with the key fob ID in the database.Function control 132 can communicate with system control 102 to grant access to the active keys. Furthermore, multiple statuses can be associated with a single key fob. For example, a key fob can be an ACTIVE backup key fob.

[0025] The system may also include a telematics function 134, which can communicate with the control unit 102 via the third interface 112. The telematics function 134 can enable the integration of certain telecommunications functions within the system. For example, an in-vehicle navigation system may be included in the telematics function 134. Furthermore, the telematics function 134 can enable communication between the control unit 102 and a mobile device associated with the vehicle. Other functions included in the telematics function 134 may be global positioning systems (GPS), hands-free calling via a mobile device, safety alerts and instructions, driver assistance systems, vehicle tracking, etc.

[0026] A vehicle display 136 can communicate with the control unit 102 via a fourth interface 114. The vehicle display 136 can be a display device configured to provide information and options to the user in the vehicle. An example configuration may also include input mechanisms such as a touchscreen, keypad, dials, buttons, etc. The display 136 can provide the user with warnings, information, control options, and the like. For example, the vehicle display 136 can be used to enable fingerprinting of additional authorized users and / or the programming of key fobs, including everyday use key fobs and emergency transfer key fobs 126. Example displays 136 may include the MyFord Touch and MyLincoln Touch.

[0027] Fig. Figure 2 shows an exemplary container mounting system 105 with a container lid 140 in a vehicle. The container mounting system 105 can have a key fob holder wall 142 configured to receive and hold an emergency transfer key fob 126 in the backup container 106. The lid 140 can have a lock 144. The lock 144 can be configured to hold the lid 140 in a closed position. Furthermore, the lock 144 can communicate with the biometric device 104 or with another biometric device 104 configured to read biometric inputs and can remain locked until it receives an authenticated biometric input.

[0028] Container 106 can facilitate communication between the function controller 132 and a key fob with a low battery. As described above, the key fob and the function controller 132 can communicate with each other via radio frequencies. When the battery of a key fob 126, 128 is low, its ability to transmit signals may be impaired. Therefore, by placing the key fob 126, 128 in the container, the key fob can be positioned in close proximity to the low-frequency transmitter coils of the controller 132. Since the key fob 126, 128 is now closer to the low-frequency transmitter coils of the controller 128, a low-frequency signal from the key fob 126, 128 can be used to communicate with the controller. When such low frequencies are used, the controller 132 can determine that a key fob is located in the container.

[0029] Although not shown, a key detector, such as a switch, may be present in the holder wall 142. This detector can indicate to the function control 132 or the system control 102 that a key is present in the container. Additionally, an indicator LED may be present in the container. The indicator can show the user the status of the key fob 126. For example, the indicator may be green when the key fob 126 is ACTIVE and red when it is INACTIVE.

[0030] Fig. 3 and Fig. Figure 4 shows exemplary procedures for implementing the key transfer system. Specifically, they show Fig. 3A to C a registration procedure, while Fig. 4A to B demonstrate authentication methods. Although Fig. 3 and Fig. Since the four procedures are presented as separate processes, overlaps between the procedures can occur. Specific examples of this overlap are described below.

[0031] Starting at Fig. 3A allows the system 100 at block 312 to determine whether a key fob is located in container 106. As described above, a key fob located in container 106 can be a backup key fob or an emergency transfer key fob 126. The system 100 can determine whether a key fob is located inside container 106 by sending a low-frequency signal from the function controller 132. If a key fob is located in container 106, the key fob can respond to the low-frequency signal by sending a reply signal at a similarly low frequency. Due to the location of the container relative to the controller 132, the key fob 126 can only transmit signals at low frequencies, as opposed to the higher frequencies required when attempting to access the vehicle or start the engine.Additional information can be transmitted to Function Control 132 and / or System Control 102 during this response. For example, the key fob's ID can be transmitted. Other relevant information, such as a vehicle identification number associated with the key fob, timestamps, etc., can also be transmitted. If Function Control 132 and / or System Control 102 receive a response from a key fob indicating that the key fob is located in container 106 (e.g., a low-frequency response), the process proceeds to Block 316. Otherwise, the process proceeds to Block 314.

[0032] Block 314 can be configured so that if no low-frequency response is received from a key fob in response to the low-frequency, low-energy request, no key fob is located in container 106. Furthermore, the vehicle function controller 132 can issue a high-frequency, high-energy request in search of a previously programmed emergency key fob. If no high-frequency response is received from the key, the vehicle can warn the user that the emergency transfer key is not located in or near container 106. The function controller 132 can then instruct the vehicle display 136 to show that no emergency transfer key fob 126 is located in container 106. For example, the display 136 can show a message with the following text: "No emergency transfer key fob detected".This message can be displayed for a predetermined number of cycles. For example, the message can be displayed five consecutive times. The process can return to START after the message has been displayed.

[0033] At block 316, system 100 determines whether the key fob ID of key fob 126, located in backup container 106, matches the emergency transfer key fob ID assigned in the database. The controller would address key fob 126 using a low-frequency, low-power request, and the key fob could respond with a low-frequency, low-power message or transmit its response as a high-frequency reply to communicate its key fob ID. The key fob ID can be compared to a list of valid IDs in the database. If there is no match between the received key fob ID and an ID in the database, or if the matching ID is not associated with an assigned emergency transfer key fob, the procedure proceeds to block 320.

[0034] If the key fob ID matches the ID of the assigned emergency transfer key fob 126 in the database, key fob 126 may already be programmed in container 106 or assigned in the database as emergency transfer key fob 126. Therefore, reprogramming key fob 126 is not necessary at this time. In this example, the procedure for block 412 from Fig. 4A, where, after appropriate authentication, the emergency transfer key fob 126 can be marked as ACTIVE. In other words, after determining that the key fob 126 in the container 106 was previously assigned as an emergency transfer key fob 126, the system can proceed with the normal authentication procedures within procedure 400. Furthermore, because the key fob 126 is located in the container 106, there is no need to continue the registration procedure, as the key fob 126 is ready for use after appropriate authentication.

[0035] At block 320, after determining that key fob 126 in container 106 is not assigned as an emergency transfer key fob for vehicle system 100, the system can determine whether key fob 126 in container 106 contains a VIN associated with vehicle system 100. In other words, no key fob 126 has yet been assigned as an emergency transfer key fob 126, and it must now be determined whether the key contains a VIN in the fob's memory and whether the VIN specified in the response signal matches that of the vehicle. If the VINs match, the procedure proceeds to block 324; if not, the procedure proceeds to block 322. If the fob does not contain a VIN, it can be assigned either as a normal key or as an emergency transfer key fob.

[0036] At block 322, the vehicle display 136 may show that key fob 126 cannot be programmed as an emergency transfer key fob. For example, the following message may be displayed: “Key in container cannot be assigned to this vehicle. Please contact your car dealer.” The procedure can then proceed to START. After proceeding to START, the user can place a different key fob in the container, and procedure 300 can be restarted with this key fob.

[0037] Block 324 allows the user to access programming options via the vehicle display 136. These options can include any of the following combinations: 1. Programming a new key as permanently active, 2. Adding a new biometric template, 3. Starting the vehicle in backup mode due to a low key fob battery level; and 4. Assigning an emergency transfer key.

[0038] With reference to Option 1, as described above, a new key fob 128-n can be assigned as continuously ACTIVE after proper authentication by at least one or more authorized key fobs or fingerprints, provided the person with the fingerprints is presented for validation. For example, a third key fob can be programmed and given to a third user, such as a teenager from a parent. To activate this third key fob, the third key fob, as well as two additional previously programmed / paired keys, must be recognized by the function controller 132, or the biometric inputs (e.g., fingerprints) of two different people previously paired with the vehicle, or a previously paired key and a person with previously paired fingerprints must be present.The ID of the third key fob can be stored in the database and associated with an active display. Therefore, access and driving authorizations for the vehicle can be transferred after the function control unit 132 has recognized the third key fob. Regarding the second option, a new biometric template can be added to the database 120 containing the stored templates to authenticate a user. This procedure is similar to the one described above in that two previously paired keys or biometric inputs, or one of each, must be stored in the vehicle system 100. Regarding the third option, after detecting the key fob's low battery level and thus its inability to transmit sufficient information about the desired distance to start the vehicle, the key fob can be placed in the backup container 106.As described, low-frequency signals with low energy consumption can be transmitted to control unit 132 to start the vehicle. If the fourth option is selected, the procedure proceeds to block 326. Fig. 3B.

[0039] At block 326, the system determines that the fourth option has been selected. If the fourth option has been selected, the procedure proceeds to block 330. If not, the procedure proceeds to block 328.

[0040] At block 328, the procedure executes the selected option (option 1, 2, or 3) from block 324. The procedure then returns to START.

[0041] Block 330 handles the procedure for programming the emergency transfer key fob 126 (option 4 of block 324). As previously described, a user can select this option via the vehicle display 136. Alternatively, or in addition, this procedure can be initiated when a key fob is placed in the container 106 while the vehicle is in motion, auxiliary, or delayed auxiliary mode. In this case, the user can be instructed via the vehicle display 136 to program the available key fob 126. Regardless, after initiating key fob programming, the controller 102 can first determine whether an authenticated key fob 128 is present (e.g., a key fob 128-1 belonging to a regular user). As with the previous authentication, a function module can be woken up by receiving a signal from a key fob 128.Function controller 132 can send a low-frequency signal to key fob 128, and key fob 128 can respond with a high-frequency reply. After recognizing that key fob 128 is an active and authorized key fob, for example, when function controller 132 recognizes the key fob ID, key fob 128 can be considered authenticated. If the key fob has been authenticated, the procedure proceeds to block 340. If not, the procedure proceeds to block 334.

[0042] In block 340, the function control 132 can determine whether an additional key (e.g., key fob 128-2 for everyday use) is present in the vehicle. If so, the procedure continues to block 344. Fig. 3C. If not, the procedure proceeds to block 342. Fig. 3C.

[0043] Block 342 issues a warning that multiple keys have been detected. When multiple keys are detected, it may be important for a function controller 132 to distinguish between a key to be programmed as an emergency transfer key fob 126 and a key fob used to authenticate the user (e.g., grant access to the vehicle). Therefore, a warning may be issued to the user. An example warning message could be: “A second valid key has been detected in the passenger compartment. Please ensure that the key is in your possession and not in the possession of a person who can exit the vehicle. Once a key has been assigned as an emergency transfer key in container 106, access to the vehicle may no longer be available until 1) another paired key is present; or 2) biometric identification is authenticated.”“The procedure then proceeds to block 352.”

[0044] At block 344, the user can be instructed to enter user information. Examples of user information include password, PIN, biometric input, RFID, etc. In one example, the biometric device 104 can scan the user's fingerprint. The procedure then proceeds to block 346.

[0045] Block 346 displays a warning on the vehicle display 136 that a single key fob must be programmed as an emergency transfer key fob 126. As with the warning for multiple key fob detection, a sample message might read: “Once the key in the container has been assigned as the emergency transfer key, access to the vehicle is not possible except 1) if another paired key is present, or 2) until biometric identification is authenticated. Since no other keys were detected in the passenger compartment, it is recommended that you use the biometric device to ensure you have authentication before assigning the key fob in the container as the emergency transfer key.”

[0046] At block 348, function control 132 and / or system control 102 determine whether the received user input matches a stored input in database 120. In this example, control 102 can determine whether the received biometric template matches a stored template in database 120. Since only one authorized key fob is available, a second authentication (e.g., biometric authentication) may be required to program an emergency transfer key fob 126. Therefore, the control can compare the received biometric input / template with the one in template database 120. If a match is found, the procedure proceeds to block 352; if not, the procedure proceeds to block 356.

[0047] Block 352 may display a message on vehicle display 136 indicating that the key is being programmed. For example, display 136 may show: "Emergency transfer key programming in progress..." The process then proceeds to block 354.

[0048] At block 354, key fob 126 can be assigned to container 106 as an emergency transfer key fob 126. The default status of the emergency transfer key fob 126 is INACTIVE. Therefore, the key fob cannot be used to gain access to or driving authorization for the vehicle until it is reassigned as ACTIVE. By assigning key fob 126 as INACTIVE, the key fob cannot be used to operate the vehicle. Therefore, when key fob 126 is removed from the container, it will be inoperable, thus maintaining vehicle security.

[0049] Block 356 may display an error message via vehicle display 136. This error message could read: “Emergency transfer programming aborted. Please present a valid, paired key or another biometrically authenticated user.” The process can then return to START.

[0050] With regard to the Fig. 4A and Fig. Section 4B describes an exemplary authentication procedure for programming an emergency transfer key fob 126 and updating its status in the database 138. The procedure begins at block 412. The system can receive an access request. The access request can include an authentication request for access to the vehicle. The access request can also include a request to start the vehicle. The request can be transmitted in several ways, as described herein. For example, a key fob 128 can send a request to the function controller 132. In another example, a user can submit biometric input via the biometric device 104, such as a fingerprint.

[0051] At block 414, system 100 can determine whether the user is authenticated based on the user input accompanying the request. This can be done by comparing an entered biometric template with the stored templates in database 120. It can also be done by transmitting signals between a function controller 132 and the key fob 128, as described above. If the request is authenticated, the process proceeds to block 418. If not, the process proceeds to block 416.

[0052] At block 416, the request can be rejected, and a message will appear on the vehicle display 136 indicating that an error has occurred. For example, the message might read: "Invalid biometric input," "No key found," "Key inactive," or "Invalid." Additional messages may also be displayed to the user. For example, display 136 might show: "Please revalidate your biometric input" or "Please press Start again." This message can be repeated after a failed authentication request until the request is authenticated or a predetermined number of cycles are repeated. For example, the error message might repeat for up to three requests.After a third failed access attempt, display 136 may show a final error message such as "Invalid biometric input" or "No key found after several attempts." The message may also include: "Please locate the authenticated key or the person with authenticated biometrics. If the problem persists, contact your dealer." The process may then return to START.

[0053] At Block 418, access to the vehicle can be granted based on an authenticated request.

[0054] At block 420, the controller can determine the vehicle's mode at the time of the access request. For example, as described above, a vehicle can be in authenticated mode or unauthenticated mode. If the vehicle is in authenticated mode, the procedure proceeds to block 422. If not, the procedure can return to START.

[0055] At block 424, the controller 132 can determine whether an emergency transfer key fob 126 is located in container 106. If so, the procedure continues to block 430. Fig. 4B. If not, the procedure ends.

[0056] At block 430, function control 132 updates the status of the emergency transfer key fob 126 in the PEPS database to ACTIVE. Therefore, when the key fob is removed from container 106, it can be a fully functional key fob for granting access and driving authorizations for the vehicle.

[0057] Block 432 can display a message on the vehicle display 136 indicating that the emergency transfer key fob 126 is now active. For example, the message might read: "Emergency transfer key is active."

[0058] In block 440, the control system determines whether a key is present in container 106. If the key is located in container 106, the process proceeds to block 450. If not, the process proceeds to block 442.

[0059] At block 442, the PEPS database is updated to indicate that the key has been removed. For example, the key's status in the database might change to REMOVED.

[0060] At block 444, the vehicle display 136 can indicate that the key fob has been removed. A message might read, for example: "Active emergency transfer key has been removed from the container and is now fully activated." The process can then proceed to block 424. In this example, the vehicle can detect when the key is returned to container 106.

[0061] At block 450, the system control 102 and / or the function control 132 can determine whether the vehicle is in an authenticated mode. If so, the process proceeds to block 440. If not, the process proceeds to block 354, where the key fob 126 is set to INACTIVE. Therefore, if a vehicle is not in the appropriate mode, the emergency transfer key fob 126 will not switch to ACTIVE. It should be noted that once a key fob 126 is ACTIVE, it remains in this state as long as it is not removed from the backup container 106 in a non-RUN mode. Furthermore, once an emergency transfer key fob 126 has been removed, it can revert to an INACTIVE state as soon as it is placed back in the holder wall 142.

[0062] It should be noted that an emergency transfer key fob 126 cannot be used or set as a primary everyday key. To use a spare key fob as a primary key, the VIN must match the VIN associated with the key fob. This is to protect against theft and prevent unauthorized users from reprogramming key fobs. Furthermore, if the emergency transfer key fob 126 is removed from container 106 while marked INACTIVE, the vehicle may be configured to send a warning or message to an assigned communication address (e.g., telephone number, email address, etc.). In one embodiment, telematics or another form of sync technology may be used to communicate with an external device (e.g., mobile phone, computer, tablet, etc.).

[0063] Accordingly, the system described herein provides a simplified solution for programming backup keys and an authentication system configured to ensure the maintenance of vehicle security. It should be understood that the above description is purely illustrative and not intended to be limiting. Many other embodiments and applications besides the examples provided would become apparent upon reading the above description. The scope of protection of the invention should therefore be determined not by reference to the above description, but by reference to the accompanying claims together with all equivalents to which such claims entitle. It is anticipated and intended that future developments of the technologies described herein will take place and that the disclosed systems and methods will be incorporated into such future embodiments.In summary, it should be understood that the application can be modified and varied.

[0064] All terms used in the claims are to be understood in their broadest reasonable scope and conventional meanings, as understood by those familiar with the technologies described herein, unless expressly stated otherwise. In particular, the use of singular articles such as "a", "an", "a", etc., is to be read as designating one or more of the elements indicated, unless the claim expressly limits this to the contrary.

[0065] In general, computer systems and / or devices such as controllers, biometric devices, telematics display functions, etc., may use any of a number of computer operating systems, including versions and / or variants of the Microsoft Windows® operating system, Unix operating systems (e.g., Solaris® from Oracle Corporation, Redwood Shores, California), AIX UNIX from International Business Machines, Armonk, New York, Linux, Mac OS X and iOS from Apple Inc., Cupertino, California, BlackBerry OS from Research In Motion, Waterloo, Canada, and Android from the Open Handset Alliance, but are not limited to these.

[0066] Computer devices such as controllers, biometric devices, telematics display functions, etc., can generally contain computer-executable instructions that can be executed by one or more processors. Computer-executable instructions can be compiled or designed by computer programs created using several programming languages ​​and / or technologies, such as, alone or in combination, Java™, C, C++, Visual Basic, JavaScript, Perl, and others. Generally, a processor or microprocessor receives instructions, for example, from memory or a computer-readable medium, etc., and executes these instructions, thereby carrying out one or more processes, which include one or more of the processes described herein. Such instructions and other data can be stored and transmitted using several computer-readable media.

[0067] A computer-readable medium (also referred to herein as a processor-readable medium) comprises any non-transient (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor of a computer device). Such a medium can take many forms, such as non-volatile or volatile media, but is not limited to these. Non-volatile media can be, for example, optical or magnetic drives or other persistent storage. Volatile media can be, for example, dynamic random access memory (DRAM), which typically forms main memory. Such instructions can be transmitted by one or more transmission media, including coaxial cables, copper wire, and fiber optics, including cables comprising a system bus coupled to a computer's processor.Common forms of computer-readable media include, for example, floppy drives, flexible drives, magnetic tape and other magnetic media, CD-ROMs, DVDs and other optical media, punched cards, paper strips and other physical media with hole patterns, RAM, PROM, EPROM, FLASH EEPROM and other memory chips or cartridges, or other media that a computer can read.

[0068] Databases, data repositories, or other data stores described herein may include various mechanisms for storing, accessing, and retrieving different types of data, such as a hierarchical database, a record in a file system, an application database in a proprietary format, a relationship database management system (RDBMS), and so on. Each of these data stores is generally contained within a computer device running a computer operating system such as those mentioned above and is accessed over a network in one or more different ways. A file system may be accessible from a computer operating system and contain files stored in various formats. An RDBMS generally uses Structured Query Language (SQL) in addition to a language for creating, storing, manipulating, and executing stored operations, such as the PL / SQL languages ​​mentioned above.

[0069] In some examples, the system elements can be implemented as computer-readable instructions on one or more computer devices, stored on associated computer-readable media. A computer program product can comprise such instructions stored on computer-readable media for performing the functions described herein. In some examples, the application software products can be provided as software which, when executed by processors of the devices and servers, performs the operations described herein. Alternatively, the application software product can be provided as hardware or firmware, or as a combination of software, hardware, and / or firmware.

Claims

[1] System, encompassing: a control panel communicating with a function controller, the control panel being configured as follows: Receiving an authentication request that includes user input; authenticating the user input by comparing the user input with at least one stored input; Determining a vehicle mode; Update, via function control, a status associated with a key fob, in response to the vehicle mode being an authenticated mode. [2] System according to claim 1, wherein the updated status associated with the key fob indicates that the key fob is functional. [3] System according to claim 1, wherein the key fob is arranged in a container inside a vehicle. [4] System according to claim 1, wherein the function control is configured to determine that the key fob is not placed in the container. [5] System according to claim 1, wherein the function control is configured to: associate a remote status with the key fob after removing the key fob from the container. [6] Procedure, comprehensive: Detecting a key fob inside a container; Authenticating an initial entry; Authenticating a second input; on a computer device, updating the status associated with the key fob to include a backup status in response to the authentication of the first and second inputs. [7] Method according to claim 6, wherein the first input is a frequency signal that includes a first input identification, and wherein the second input is a frequency signal that includes a second input identification. [8] Method according to claim 6, wherein the first input is a frequency signal that includes a first input identification, and wherein the second input is a biometric input. [9] Method according to claim 6, further comprising updating the status associated with the key fob to include an inactive status. [10] Method according to claim 6, wherein the recognition of the key fob includes receiving a signal from the key fob at a function controller.

Images