Vehicle transfer key management system

Abstract

The present disclosure provides a "vehicle transfer key management system". A transfer key system for a vehicle can include a key container configured to detect a presence of a transfer key, and a controller configured to receive a key status signal from the key container and activate the transfer key as an active transfer key in response to the status signal indicating that the transfer key is removed from the key container and an authentication signal is received from a user.

Description

Technical Field

[0001] This disclosure generally relates to a transfer key management system. Background Technology

[0002] Automobiles can have various authentication systems to enable drivers to access and start their vehicles. These authentication systems include device-free solutions (i.e., codes or biometrics). Other device-driven solutions can use keys, key fobs, or mobile phones as authentication devices. However, existing systems may require the driver to physically hand over his or her device or credentials to another person for that person to operate the vehicle. This is especially true in situations such as chauffeur services, maintenance, etc. Summary of the Invention

[0003] A transfer key system for a vehicle may include: a key container configured to detect the presence of a transfer key; and a controller configured to receive a key status signal from the key container and activate the transfer key as an active transfer key in response to the status signal indicating that the transfer key has been removed from the key container and to receiving an authentication signal from a user.

[0004] A vehicle transfer key system for presenting an alert to a vehicle user may include: a temperature sensor configured to detect the temperature inside the vehicle compartment; and a controller configured to detect the presence of a transfer key inside the vehicle compartment, determine whether the transfer key has been activated, receive the vehicle compartment temperature from the temperature sensor, and transmit a temperature notification in response to the temperature falling outside a predefined threshold.

[0005] A method for a vehicle transfer key system may include: receiving a key status signal from a key container in the vehicle; activating the transfer key as an active transfer key in response to the status signal indicating that the transfer key has been removed from the key container; and transmitting a notification of the activation of the transfer key to a mobile device associated with the vehicle owner. Attached Figure Description

[0006] Embodiments of this disclosure are particularly pointed out in the appended claims. However, other features of the various embodiments will become more apparent and will be best understood by referring to the following detailed description in conjunction with the accompanying drawings, in which:

[0007] Figure 1 An exemplary vehicle system with a key transfer system is shown.

[0008] Figure 2 An exemplary container and transfer key are shown;

[0009] Figure 3An exemplary process for a key transfer system is shown;

[0010] Figure 4 An exemplary human-machine interface for a key transfer system is shown; and

[0011] Figure 5 Another exemplary human-machine interface for a key transfer system is shown; and

[0012] Figure 6 An exemplary warranty process for a key transfer system is shown. Detailed Implementation

[0013] Detailed embodiments of the invention are disclosed herein as needed; however, it should be understood that the disclosed embodiments are merely examples of the invention that may be embodied in various forms and alternative forms. The drawings are not necessarily to scale; some features may be enlarged or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but only as representative bases for teaching those skilled in the art to utilize the invention in various forms.

[0014] In certain situations, a vehicle driver may wish to transfer the keys to another driver (e.g., a chauffeur, dealership service personnel, friend, or family member) to gain access to and driving privileges of the vehicle. Some of these situations may include emergencies, such as allowing police access to move a vehicle after an accident, transferring keys in a medical emergency, or transferring keys under threats such as carjacking or robbery. Therefore, programming a spare key or transfer key allows a driver to easily transfer the keys under specified conditions to allow another person access to and driving privileges of the vehicle. Under appropriate circumstances, such as with proper authentication, the transfer key can be handed over to another driver within seconds. A vehicle key transfer system may include a key container and an authentication method. The authentication method may include a device configured to authenticate a user, such as a key fob or mobile phone configured to grant access to the container. The key may be activated after being removed from the container.

[0015] The container can be configured to hold a key, which can take the form of a smart key fob, an NFC / RFID key card, or an introduced consumer device (such as a smartphone) or any portable device capable of running an application and communicating with the vehicle via a vehicle-supported RF protocol. The key can be removed from the container and transferred to a second user. Therefore, although the second user may not be the registered user, the second user can use the vehicle normally.

[0016] This document describes a solution for enabling and managing transfer keys. Transfer keys and non-transfer keys are distinguished by one or both of their physical appearance and a unique key index associated with the Body Control Module (BCM). Keys can be registered to the BCM in an inactive state during production. Keys can remain inactive until user-authorized activation. Various processes for activation and deactivation can be implemented.

[0017] Figure 1 An exemplary system 100 is illustrated, comprising a vehicle 102 configured to access a telematics server and a mobile device 152 having a manufacturer application 170. Vehicle 102 may include various types of passenger vehicles, such as crossover SUVs, sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), boats, aircraft, or other mobile machines used for transporting people or goods. As some non-limiting possibilities, telematics services may include navigation, route guidance, vehicle health reports, local business search, accident reporting, and hands-free calling. In the example, vehicle 102 may include a SYNC system manufactured by Ford Motor Company of Dearborn, Michigan, USA. It should be noted that the illustrated system 100 is merely an example and more, fewer, and / or differently positioned components may be used.

[0018] Computing platform 104 (also referred to herein as controller 104) may include one or more processors 107 configured to execute instructions, commands, and other routines that support the processes described herein. For example, computing platform 104 may be configured to execute instructions for vehicle application 111 to provide features such as navigation, accident reporting, satellite radio decoding, and hands-free calling. Such instructions and other data may be retained in a non-volatile manner using various types of computer-readable storage media 112. Computer-readable media 112 (also referred to as processor-readable media or storage devices) includes any non-transitory medium (e.g., tangible medium) involved in providing instructions or other data that can be read by processor 107 of computing platform 104. Computer-executable instructions may be compiled or interpreted from computer programs created using various programming languages ​​and / or technologies, including but not limited to, individual or combined forms of the following: Java, C, C++, C#, Objective C, Fortran, Pascal, JavaScript, Python, Perl, and PL / SQL.

[0019] The computing platform 104 may be provided with various features that allow vehicle occupants to interact with the computing platform 104. For example, the computing platform 104 may include: an audio input 114 configured to receive verbal commands from vehicle occupants via a connected microphone 116; and an auxiliary audio input 118 configured to receive audio signals from a connected device. The auxiliary audio input 118 may be a physical connection, such as a wire or fiber optic cable; or a wireless input, such as a Bluetooth audio connection. In some examples, the audio input 114 may be configured to provide audio processing capabilities, such as pre-amplifying low-level signals and converting analog inputs into digital data for processing by the processor 107.

[0020] The computing platform 104 may also provide one or more audio outputs 120 to the input of an audio module 122 with audio playback functionality. In other examples, the computing platform 104 may provide audio output to occupants using one or more dedicated speakers (not shown). The audio module 122 may include an input selector 124 configured to provide audio content from a selected audio source 127 to an audio amplifier 129 for playback via vehicle speakers 130 or headphones (not shown). As some examples, the audio source 127 may include decoded amplitude modulation (AM), frequency modulation (FM), or satellite digital audio radio service (SDARS) signals, as well as audio signals from optical disc (CD) or digital universal disc (DVD) audio playback. The audio source 127 may also include audio received from the computing platform 104, such as audio content generated by the computing platform 104; audio content decoded from a flash memory drive connected to a Universal Serial Bus (USB) subsystem 132 of the computing platform 104; and audio content passed through the computing platform 104 from an auxiliary audio input 118. The computing platform 104 can utilize the voice interface 134 to provide a hands-free interface to the computing platform 104.

[0021] The computing platform 104 can also receive input from a human-machine interface (HMI) control 136 (also referred to herein as vehicle display 136), which is configured to provide occupant interaction with the vehicle 102. For example, the computing platform 104 may interface with one or more buttons or other HMI controls (e.g., steering wheel audio buttons, push-button talk buttons, dashboard controls, etc.) configured to invoke functions on the computing platform 104. In some cases, the display 136 may be a touchscreen, which is also configured to receive user touch input via a video controller; in other cases, the display 136 may simply be a display without touch input capability. The display 136 may present warnings, information, control options, etc., to the user. In one example, the vehicle display 136 may be used to facilitate the addition of an authorized user's fingerprint and / or the programming of key fobs, including everyday keys and transfer keys 128.

[0022] Vehicle 102 may include various temperature sensors 139 configured to detect the temperature inside and outside the passenger compartment. Temperature sensor 139 may be part of a climate control system configured to control the passenger compartment temperature, or it may be a separate sensor specifically configured to transmit the passenger compartment temperature to the transfer key system 100. Temperature sensor 139 may transmit the sensed temperature to computing platform 104 so that the computing platform can detect situations where the transfer key 128 may be inoperable due to high temperatures. The following is about... Figure 6 Describe this situation in more detail.

[0023] The computing platform 104 can also be configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 142. As some examples, the in-vehicle network 142 may include one or more of a vehicle controller local area network (CAN), an Ethernet network, and a media-oriented system transport (MOST). The in-vehicle network 142 may allow the computing platform 104 to communicate with other vehicle 102 systems, such as a vehicle modem 145 (which may not be present in some configurations), a Global Positioning System (GPS) module 146 configured to provide current vehicle position and heading information, and various vehicle ECUs 148 configured to be integrated with the computing platform 104. As some non-limiting possibilities, the vehicle ECU 148 may include: a powertrain control module configured to provide control of engine operating components (e.g., idle speed control components, fuel delivery components, emission control components, etc.) and monitoring of engine operating components (e.g., the status of engine diagnostic codes); a body control module configured to manage various power control functions, such as exterior lighting, interior lighting, passive entry, passive start, remote start, and entry point status verification (e.g., the closing status of the hood, doors, and / or trunk of vehicle 102); a radio transceiver module configured to communicate with a key fob or other local vehicle 102 device; and a climate control management module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).

[0024] As shown in the figure, the audio module 122, HMI control 136, and temperature sensor 139 can communicate with the computing platform 104 via a first in-vehicle network 142-A, and the vehicle modem 145, GPS module 146, and vehicle ECU 148 can communicate with the computing platform 104 via a second in-vehicle network 142-B. In other examples, the computing platform 104 may be connected to more or fewer in-vehicle networks 142. Alternatively, one or more HMI controls 136 or other components may be connected to the computing platform 104 via a different in-vehicle network 142 than shown, or directly connected to the in-vehicle network 142 without a connection.

[0025] The computing platform 104 can also be configured to communicate with a mobile device 152 belonging to a vehicle occupant. The mobile device 152 can be any of a variety of portable computing devices, such as a cellular phone, tablet, smartwatch, laptop, portable music player, wearable device, electronic fabric, or other device capable of communicating with the computing platform 104. In many examples, the computing platform 104 may include a wireless transceiver 150 (e.g., a Bluetooth module, ZigBee transceiver, Wi-Fi transceiver, IrDA transceiver, RFID transceiver, etc.) configured to communicate with a compatible wireless transceiver 154 of the mobile device 152. Alternatively, the computing platform 104 may communicate with the mobile device 152 via a wired connection (such as a USB connection between the mobile device 152 and the USB subsystem 132). In some examples, the mobile device 152 may be battery-powered, while in others, the mobile device 152 may receive at least a portion of its power from the vehicle 102 via a wired connection.

[0026] Communication network 156 can provide communication services, such as packet-switched network services (e.g., Internet access, VoIP communication services), to devices connected to communication network 156. Examples of communication network 156 may include cellular mobile phone networks. Mobile device 152 can provide network connectivity to communication network 156 via device modem 158 of mobile device 152. To facilitate communication through communication network 156, mobile device 152 can be associated with a unique device identifier (e.g., Mobile Device Number (MDN), Internet Protocol (IP) address, etc.) to identify communication conducted by mobile device 152 through communication network 156. In some cases, occupants of vehicle 102 or devices authorized to connect to computing platform 104 can be identified by computing platform 104 based on pairing device data 160 maintained in storage medium 112. Pairing device data 160 may indicate, for example, a unique device identifier of a mobile device 152 previously paired with computing platform 104 of vehicle 102, so that computing platform 104 can automatically reconnect to the mobile device 152 referenced in pairing device data 160 without user intervention. In some vehicles 102, computing platform 104 wireless transceiver 154 may be configured to provide hotspot functionality to a user's mobile device 152.

[0027] When a network-connected mobile device 152 is paired with a computing platform 104, the mobile device 152 can allow the computing platform 104 to use the network connectivity of the device modem 158 to communicate with a remote telematics server 162 or other remote computing devices via the communication network 156. In one example, the computing platform 104 can utilize the onboard data plan or data plan of the mobile device 152 to transmit information between the computing platform 104 and the communication network 156. Alternatively, the computing platform 104 can utilize a vehicle modem 145 to transmit information between the computing platform 104 and the communication network 156 without using the communication facilities of the mobile device 152.

[0028] Similar to computing platform 104, mobile device 152 may include one or more processors 164 configured to execute instructions of a mobile application loaded from storage medium 168 of mobile device 152 into memory 166 of mobile device 152. In some examples, the mobile application may be configured to communicate with computing platform 104 via wireless transceiver 154 and with a telematics server or shuttle server 162 or other network services via device modem 158. Computing platform 104 may also include device link interface 172 to facilitate the integration of mobile application functionality into the syntax of commands available via voice interface 134. Device link interface 172 may also provide the mobile application with access to vehicle information, which may be used by computing platform 104 via in-vehicle network 142. An example of device link interface 172 may be the SYNCAPPLINK component of the SYNC system provided by Ford Motor Company of Dearborn, Michigan.

[0029] Manufacturer application 170 may be an example of an application installed on mobile device 152 and configured to interact with computing platform 104 via device link interface 172. Manufacturer application 170 may also be configured to operate when disconnected from vehicle 102, such as when the user is away from the vehicle. Manufacturer application 170 may also be configured to communicate with a server (e.g., server 162) via communication network 156, as discussed in detail below. Users can interact with manufacturer application 170 via a web interface or via the HMI of vehicle 102 through the HMI of mobile device 152 to avoid distraction while driving. Typically, mobile device 152 may belong to the owner or operator of the vehicle. Manufacturer application 170 may allow users to perform or modify certain vehicle functions from mobile device 152. Manufacturer application may allow users to grant access to auxiliary keys or devices, enabling those devices to gain access to and operate the vehicle. In some examples, manufacturer application 170 may be a key transfer-specific application, but it may also be integrated into another application (such as FORDPASS).

[0030] Biometric sensor 110 can be configured to collect biometric input from a user. In one example, sensor 110 can be a fingerprint scanner configured to read at least one fingerprint or thumbprint of a user (hereinafter referred to as fingerprint). In another example, sensor 110 can be a voice recorder (e.g., microphone 116), a retinal scanner, or a vehicle camera. In the vehicle camera example, biometric sensor 110 can be configured to identify a user's face, gait, etc., from outside the vehicle. Biometric sensor 110 can also be included within a vehicle. In one example, biometric sensor 110 can be integrated with a push-button starter. In another example, biometric sensor 110 can be integrated within the top of the vehicle's gearshift lever or within the dashboard. In yet another configuration, biometric sensor 110 can be positioned adjacent to or within container 106. Biometric sensor 110 can communicate with controller 104. Biometric sensor 110 can be inside or outside the vehicle.

[0031] Controller 104 may include processor 107 configured to facilitate the processes described herein. Processor 107 may facilitate the receipt of biometric data at controller 104. It may convert or translate the biometric data into usable biometric templates. These templates may be used to authenticate a user based on the received biometric data. In the example where the biometric data is a fingerprint, it may be necessary to convert the data into a readable format, such as a template, before the authentication process can be performed. For example, each fingerprint includes unique data points, such as a central arch, double rings, etc. These details may be converted into digital patterns, such as vectors, that constitute the biometric template. Because the biometric template is a digital representation of the fingerprint data, an image of the fingerprint itself is never stored within controller 104. The template may be represented and transmitted in a standard format, such as the Biometric Interaction Protocol (BIP). A Biometric Identification Record (BIR) may include a header, biometric data, and a signature that can be identified by controller 104.

[0032] In several cases, biometric data may be received at controller 104. Initially, data may be received for registration purposes. A user may register his or her biometric data (e.g., fingerprint / facial recognition) during registration. Alternatively, a personal identification number (PIN) may be entered via a separate interface and analyzed by controller 104 to further authenticate the user prior to biometric registration. Upon user authentication, the received biometric data may be converted into a biometric template, as described above. The registered biometric template is then stored in a template database. The registered template may be stored in the database and used later for user authentication.

[0033] As mentioned, biometric data can also be received to authenticate users. Biometric data can be received to attempt to gain access to the vehicle. When biometric data is received for authentication purposes, it can be converted into a received biometric template at controller 104. A comparator within controller 104 can then compare the received template with registered templates in a template database. Upon finding a match between the received template and at least one of the registered templates, the comparator can send a "pass" indicator to the controller. If no match is returned, a "fail" indicator can be returned. Upon receiving a positive match indication from the comparator, access to and driving privileges for the vehicle can be granted. This access may include unlocking one or more doors of the vehicle to allow the user to enter the vehicle. Access may also include other functionalities such as routine vehicle operations (e.g., starting the vehicle, driving, operating the radio, lights, etc.). As described in more detail below, the transfer key fob 128 can also be activated after certain authentications.

[0034] The key fobs 126, 128 (also referred to as keys 126, 128 and key devices 126, 128) described herein may have passive entry / passive start (PEPS) capability. The master key 126 is typically held and maintained by the vehicle owner or administrator. Transfer keys 128-1, 128-2, 128-n may be auxiliary keys typically used to grant temporary or limited access to the vehicle and its features.

[0035] Keychains and other devices mentioned in this article can also be referred to as passive / keyless access systems, advanced keys, comfort access, or Enter-N-Go. TM Smart access, smart entry, smart key, smart key Examples include SmartPass and Kessy. The key fob can communicate with the vehicle via LF and / or UHF frequency communication protocols, including interrogation and response between the key fob and the vehicle. Keys 126 and 128 can be NFC devices registered in the BCM. The PEPS database can include a list of registered key fobs and their associated statuses. For example, the database could maintain that key 126 can be the master key, while 128-1 can be a secondary key. These associated status indicators can relate to certain vehicle settings associated with the normal user of the transfer key 128, such as seat position, temperature control, etc.

[0036] PEPS capability can provide users with several keyless functions, including passive entry, passive engine start, engine shutdown, and passive locking. In one example, key 126 can be associated with the user (e.g., in the user's pocket or wallet). The user can touch or flick the vehicle door handle or press the start button recognized by controller 104.

[0037] It's important to note that PEPS features are not limited to use cases involving keychains. These features can be used with other devices and authentication mechanisms. In one example, the device could be a mobile phone or other user mobile device. Biometric input can also enable PEPS features such as facial recognition (when a user approaches a vehicle). Therefore, PEPS authentication can be performed using physical devices as well as by using the user's biometric attributes. Physical devices such as keychains, mobile phones, and cards can be stored inside a container.

[0038] Besides manufacturer-specific keys, other devices (such as NFC cards and devices) and mobile devices (including mobile phones, key fobs, etc.) can also be used as vehicle "keys." That is, instead of having a dedicated key fob for vehicle access, a user's mobile device can be used to authorize access to the vehicle. Alternatively, the reference to "key" may also include authentication via biometric attributes (such as facial recognition). Although "key" is used herein, the term generally includes all devices capable of granting access to vehicle 102. Figure 1 In the example, transfer key 128 may include transfer device 128-2. This transfer key 128-2 may be an auxiliary mobility device for the owner of vehicle 102. The owner may wish to transfer the key to a chauffeur, auto mechanic, or other person who may require temporary access to the vehicle. Although not shown, this transfer key 128-2 may also include manufacturer application 170, but is not required.

[0039] In some examples, the "emergency" transfer key 128 can be stored inside the vehicle container 106. Regarding... Figure 2 Let's discuss this situation in more detail.

[0040] By activating the transfer key 128 stored in container 106 as an active key, the key 128 can be transferred to any other user, who can then have full access to and driving rights over the vehicle.

[0041] Therefore, in certain emergency situations, the transfer key 128 can be transferred to another user. For example, if the driver of a vehicle suffers a health crisis (such as a heart attack, stroke, etc.) while driving and emergency responders have removed the person from the vicinity of the vehicle, the transfer key 128 in container 106 can be removed and used by a second user (such as a passenger or another driver). The second user can then operate the vehicle and drive the original driver to the hospital, follow an ambulance, move the vehicle to a safer location, etc. In another example, a driver may wish to have their vehicle driven by a designated driver without providing them with their key fob. Upon arriving at the designated location, the driver can park their car in a parking lot and remove the transfer key fob 128 from container 106. After use, the transfer key 128 can be returned to container 106, and then the key 128 can be disabled.

[0042] Figure 2 An exemplary container 106 with a lid 140 and located within a vehicle is shown. Container 106 can be configured to receive and hold a transfer key 128. The lid 140 may include a latch 144. The latch 144 can be configured to hold the lid 140 in a closed position. Additionally, the latch 144 can communicate with a biometric sensor 110 or another biometric sensor 110 configured to read biometric input and can be locked until an authenticated biometric input is received. The latch can also be unlocked, thereby making the key accessible but inactive (e.g., unauthenticated).

[0043] A key detector 202 may be disposed within container 106 to detect the removal or replacement of key 128. This detector 202 may be a spring-loaded actuator having a wire for transmitting a key status signal indicating an actuation threat. In another example, detector 202 may be a contactless reader that communicates with the transferred key via, for example, LF or NFC / RFID communication.

[0044] Detector 202 can indicate to controller 104 that the key is present in the container. Additionally, an indicator LED can be present within the container. The indicator can indicate the status of the transfer key 128 to the user. For example, the indicator can be green when the transfer key 128 is active, and red when inactive. The HMI can also indicate various key statuses to the user, including providing an alarm when the status changes (such as when the key is removed). For example, the HMI can notify the user that the key has been removed but is inactive. The HMI can provide a predetermined time from removal onwards that the key must be activated. This time window can also be presented to the user. As explained above, the key can be activated via authentication, which is performed by sensing biometric attributes via key fob or mobile phone, coded ignition, or other key activation technologies (such as passive keys).

[0045] The transfer key 128 can be automatically deactivated upon returning to container 106. If the transfer key 128 is in valet mode, the user can be prompted to choose whether the vehicle wants to exit valet mode. This article is about Figure 3 and Figure 5 This situation is described. In addition, to prevent a second user from accidentally staying behind, the second user can be prompted that if key 128 is not removed from the container, the transfer key 128 will be deactivated within a given time window (i.e., 10 seconds).

[0046] In cases where the mobile phone can be used as a transfer key 128, this option is only available when other devices such as PEPS key fobs, NFC cards, etc., are unavailable. Furthermore, even if the user is not biometrically programmed into the vehicle, the user can still utilize the system by making the transfer key available, thus eliminating the need for them to hand over their mobile phone to a second user.

[0047] In some cases, the capabilities of the transfer key 128 may be limited. Certain autonomous features and other vehicle systems (such as data usage, connection to the vehicle via SYNC, etc.) may be restricted. Remote Parking Assist (RePA) and other remote control features may also be disabled. While the transfer key 128 can respond to commands from these systems, these systems may ignore commands from the transfer key 128. That is, the controller 104 may ignore certain forms of communication and commands from devices (key fobs, NFC devices, mobile phones) that have been identified and tagged as the transfer key 128. Other restrictions imposed on vehicle features may include speed limiters, audio limiters, restrictions on hands-free calling, restrictions on remote control features (e.g., parking, towing), functional geofencing, activation of timers, etc.

[0048] Figure 3An exemplary process 300 for a key transfer system 100 is illustrated. As explained above, the transfer key 128 may include a physical PEPS type key and a device or mobile phone serving as the key. Alternatively, the device may be a card, such as an NFC / RFID card. At block 305, the controller 104 may determine whether the transfer key 128 is located within the container 106. As explained above, the key detector 202 may detect the removal or replacement of the transfer key 128. The detector 202 may indicate to the controller 104 that the key is present within the container 106, wherein the detector 202 is in a pressed state when the transfer key 128 is within the container. The controller 104 may also determine whether the physical key is located within the container 106 by sending a low-frequency signal or an NFC / RFID signal from the controller 104. If the physical key is located within the container 106, the key may respond to the low-frequency or NFC / RFID signal by transmitting a response signal at a similar low frequency.

[0049] Due to the container's position relative to controller 104, when attempting to access the vehicle or start the engine, the transfer key 128 may only need to transmit signals at a low frequency, rather than a higher frequency. During this response, additional information may be transmitted to controller 104. For example, the key fob's ID may be transmitted. Other relevant information may also be transmitted, such as the vehicle identification number associated with the key fob, timestamp, etc. If controller 104 receives a response from the key fob or key fob detector 202 indicating that the key fob is located within container 106 (e.g., a low-frequency response), the process proceeds to block 310. Otherwise, the process proceeds to block 375.

[0050] In block 310, controller 104 can determine whether transfer key 128 has been removed from container 106. This can be determined by the absence of a press at detector 202. Controller 104 can also determine that transfer key 128 has been removed from container 106 by the absence of a low-frequency or NFC / RFID response from the key fob in response to a low-frequency or NFC / RFID challenge. Additionally, controller 104 can issue a high-power low-frequency challenge to search for the previously programmed transfer key 128. If no high-frequency response is heard from transfer key 128, the vehicle can warn the user that transfer key 128 is not in container 106 or not near the vehicle. Controller 104 can then instruct vehicle display 136 to indicate that no transfer key 128 is present in container 106. For example, display 136 can show a message indicating "Transfer key not detected." The message can be displayed in a predefined number of cycles before pausing. For example, the message can be displayed five times consecutively. If controller 104 determines that key 128 has been removed, process 300 can proceed to block 315.

[0051] It is worth noting that the controller 104 can issue a message indicating that the transfer key has not been found, regardless of whether the system is active or inactive. This can warn the user that the transfer key has been removed and not replaced, or that the device has not been activated / located.

[0052] Reference frame 360: A physical key may not be necessary, and a mobile phone serving as the key can be used as a transfer key. As explained above, this could be a response to the primary user losing key 128, or simply a response to the general preference of either the first or second user to use transfer device 128-2 as a transfer key.

[0053] A second user can request the first user to remotely activate the transfer key via the manufacturer's application 170 (i.e., FORDPASS). This can be particularly useful in situations where the second user might inadvertently leave themselves stranded. For example, the second user might have lost or deactivated the transfer key and have no backup way to access and operate vehicle 102. For added security, this process may be limited to a specific time window after deactivation, and may be subject to geofencing, etc. The vehicle administrator can remotely activate or deactivate the key at any time.

[0054] In box 315, controller 104 can determine whether the user is authenticated. User authentication can take many forms and can be similar to authorization for vehicle power-on. In one example, the user can be authenticated via the presence of a known key device (such as a smart key fob or a mobile phone as a key). The mobile phone can communicate via wireless RF (e.g., BLE, Wi-Fi, UWB) or via NFC. In another example, the user can be authenticated via biometric identification of the driver at the driver's seat. These examples are described in detail herein. In another example, the user can be authenticated by entering a password into the vehicle's HMI. In yet another example, the vehicle is in an active operating mode (e.g., power, attachment, or delayed attachment mode) and not in a safe idling mode. It is noteworthy that if a clear intent to access the vehicle is identified and the user is authenticated, the user can be authenticated before being inside the vehicle and before the vehicle is started. The user can also be authenticated via a mobile device 152 using an application and mobile phone as a key features.

[0055] If the user is authenticated, process 300 can proceed to box 325. Otherwise, process 300 proceeds to box 320.

[0056] At box 325, controller 104 can display the valet mode option. This option can be displayed via vehicle display 136. Display 136 can display a screen requesting feedback from the user. Figure 4An exemplary screen is shown. User interface 400 can indicate to the user that the transfer key has been activated. That is, the transfer key can now be handed over to someone and used to gain access to vehicle 102. Screen 500 can also ask the user whether they should activate transfer key 128 in chauffeur mode. That is, "Do you want to enter chauffeur mode?" The user can indicate his or her answer by touching one of the buttons presented via user interface 400. As explained, chauffeur mode allows the person with the transfer key to operate the vehicle. However, certain features may be disabled, and certain data may not be accessible to the person with the transfer key, such as the vehicle's previous route, saved home address, etc.

[0057] While the HMI screen is displayed and requests some form of touch feedback from the user at user interface 400, other forms of requests and feedback can be presented. For example, an audible message such as "Would you like to activate this key in valet mode?" can be played via the vehicle speakers. The user can respond with an audible response picked up by the vehicle speakers. Gestures can also be used to provide a response. As explained above, the HMI screen can also indicate the location and status of the key (e.g., active or inactive), as well as other information related to the key's status and activation.

[0058] At frame 330, controller 104 can receive the user's selection to enter the designated driver mode.

[0059] At box 335, controller 104 can present additional access restriction options to the user. These access restriction options can be restrictions on vehicle options and features not otherwise restricted by the chauffeur mode settings. For example, mileage, duration, or time length can be restricted. The user can choose to have the transfer key expire after a predefined metric, such as maximum miles, driving time, or a set time window. If a relative requests to borrow the vehicle, the duration may be limited to the number of days the relative wishes to borrow the car. In another example, mileage for a teenage driver might be restricted. Furthermore, to account for situations where the user might want the key to remain active until they have explicitly left the vicinity of the vehicle, the user can choose to use a simple pause metric after the door is locked, or to perform walk-out detection. That is, the key can be moved to an inactive state once the user leaves the vehicle. Walk-out detection can be detected by the removal of an external camera or a mobile device or key fob associated with the user. These options and metrics can be presented to the user on the vehicle via display 136 or via mobile device 152 via an HMI.

[0060] At box 340, controller 104 can receive access restrictions selected by the user.

[0061] At box 345, controller 104 can activate transfer key 128. This can be a response to user authentication. Various modes and options selected at boxes 330 and 335 can be applied to transfer key 128. Upon activation, notification can be provided to one or both of the first and second users. If a status alarm is configured in the application, notification can be sent via manufacturer application 170. Other forms of alarms can be implemented via prompts on vehicle display 136 and text messages to the mobile device. Notifications may include location and timestamp information.

[0062] At box 350, controller 104 can determine whether a deactivation signal has been received. The deactivation signal can be received in various forms, depending on whether the transfer key 128 is a physical device held within container 106 or whether the transfer key is another user's mobile device. If the physical transfer key 128 is held within the container, the deactivation signal can be a signal received from key detector 202 that the key has been returned to the container. In the mobile phone-as-key example, transfer key 128-2 can send a deactivation signal. This deactivation signal can be automatic due to expiration or initiated by a second user via manufacturer application 170. Furthermore, the deactivation signal can only be sent after the user intentionally selects to deactivate the device and authenticates the user via the same method described above for activating the transfer key.

[0063] Regardless of whether the transfer key is a physical key or a mobile phone key, the controller 104 can automatically receive a deactivation signal if the predefined metrics described in box 335 are met. For example, if the time period set for the transfer key 128 has elapsed, the access granted to the transfer key (whether it is a physical key or a mobile device) can indicate a deactivation signal. In another example, a deactivation signal can be transmitted from the user's mobile device 152 via an application to stop authorized access to the transfer key. That is, the user can deactivate the transfer key from a remote location. This can be beneficial if the user detects that the transfer key permissions have been abused or if the transfer key 128 cannot be found inside the vehicle.

[0064] If controller 104 receives a deactivation signal, process 300 proceeds to block 370. If no deactivation signal is received, process 300 returns to block 345.

[0065] At box 370, controller 104 can instruct transfer key 128 to be deactivated. That is, transfer key 128 may no longer have access to the vehicle or no longer operate the vehicle. In some cases, particularly when the key fob 128 is deactivated upon returning to container 106, controller 104 can prompt the user to choose to remove the vehicle from valet mode. Figure 5 An exemplary HMI is shown and described. Then, process 300 can end.

[0066] At box 375, controller 104 may instruct vehicle display 136 to display a key loss error to indicate to the user that the key has been lost from container 106. Alternatively, controller 104 may present error messages, audibly indicate errors, etc., via a display on mobile device 152.

[0067] At box 320, controller 104 may similarly instruct vehicle display 136 to display an authentication error to indicate that the user has not been authenticated. Alternatively, controller 104 may present error messages, audibly indicate errors, etc., via a display on mobile device 152.

[0068] Figure 4 An exemplary user interface 400 is shown for presenting a user with options to program the key 128 for chauffeur mode. The user interface 400 may be presented via a vehicle display 136 or a mobile device 152. The controller 104 may receive user input indicating whether chauffeur mode should be entered via user input.

[0069] Figure 5 An exemplary user interface 500 is shown for presenting the user with the option to exit chauffeur mode. As explained above, this prompt may be presented in response to returning the transfer key 128 to the container 106.

[0070] Figure 6 An exemplary process 600 for a warranty system using a transfer key system 100 is illustrated. In some examples, if the driver or other passengers do not recognize the device designated as the transfer key (i.e., an NFC card, PEP key fob, or other smart device), the user may assume that the transfer key or the vehicle has malfunctioned. To dispel this and reassure the user, certain messages and information may be presented to the user.

[0071] At box 605, controller 104 can determine whether a transfer key has been detected. This can be similar to... Figure 3 This is achieved through box 305. If a transfer key is detected, process 600 proceeds to box 610. If no transfer key is detected, process 600 terminates.

[0072] At box 610, controller 104 can determine whether to activate the transfer key. This can be done... Figure 3 The process is implemented at box 345. If transfer key 128 is not activated, the process proceeds to box 625. If transfer key 128 is activated, the process proceeds to box 615.

[0073] At box 615, controller 104 can determine whether the cabin temperature is within a predefined threshold. The threshold can be set at a point where the transfer key 128 might stop functioning properly due to temperature. That is, if the battery temperature exceeds a certain threshold, the battery may stop providing necessary power to the key 128. The temperature can be obtained from temperature sensor 139. The threshold can depend on the type of transfer key 128. In an example where the transfer key 128 is a mobile device or a smart device, the threshold could be approximately 35 degrees Celsius. In an example where the transfer key 128 is a PEPS key fob, the temperature threshold could be approximately 60 degrees Celsius. Minimum temperature thresholds, such as below the freezing point of a smart device, can also be considered.

[0074] If the temperature inside the carriage falls outside a predefined threshold, process 600 proceeds to box 620. Otherwise, process 600 proceeds to box 630.

[0075] At box 620, controller 104 may issue a warning that key 128 may malfunction due to high temperature. At box 625, controller 104 may issue a warning that key 128 is not functioning properly because the transfer key is not activated. In some cases, key 128 may be a physical key fob or an NFC card. These physical keys may have a similar appearance to other devices held by the driver, the driver's partner, etc. In this case, whenever someone attempts to use the key, such as a stored key that looks like a fully functional key, the user may not know whether the stored key is a backup or an emergency transfer key. This may happen when the driver leaves with an authorized key (physical, biometric, mobile phone, etc.) and the person left in the vehicle does not have a valid key. The person may try to move the vehicle with the stored key while the driver is away. However, if the stored key is not activated, the vehicle will not respond. In the case of an NFC card, the NFC reader will not recognize the NFC card. Therefore, whenever someone in the vehicle attempts to passively use the stored key without a valid key, controller 104 may issue a warning that the feature is unavailable. For example, an alert could be "Vehicle start unavailable, key fob designed for ETK, ETK inactive." The alert can be pushed to vehicle displays, mobile devices, etc. The alert may include other features the user has tried with the inactive key, such as unlocking, locking, emergency, trunk, power sliding doors, etc. The alert uses the term ETK or spells it as Emergency Transfer Key.

[0076] In the example of the NFC card as a key 128, when tapped on the NFC reader inside the vehicle, the controller 04 can display a prompt such as "This NFC card is designated as an ETK, and the ETK is inactive." Therefore, a better user experience can be achieved through prompts and communication between the vehicle and the user.

[0077] At frame 630, controller 104 can issue a warranty warning that key 128 is not functioning properly and needs to be replaced. Similar to other messages discussed herein, these warnings can be presented via vehicle display 136, mobile device 152, 128-2. Warnings can also be transmitted via vehicle speakers, etc.

[0078] Therefore, the system described in this paper provides a simplified solution for programming backup keys and an authentication system configured to ensure the security of maintenance vehicles.

[0079] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the entire scope of the appended claims and their equivalents. It is anticipated and intended that the techniques discussed herein will evolve in the future, and that the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and variations are possible with this application.

[0080] All terms used in the claims are intended to give their broadest reasonable structure and their general meaning, as would be understood by one of skill in the art described herein, unless explicitly indicated otherwise herein. In particular, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” “the,” etc., should be interpreted as referring to one or more of the elements indicated by the recitation.

[0081] Typically, computing systems and / or devices such as controllers, biometric sensors, and display telematics functions can employ any of a variety of computer operating systems, including but not limited to Microsoft. Operating systems, Unix operating systems (e.g., those distributed by Oracle Corporation of Redwood Coast, California). Operating systems: AIX UNIX, Linux, Mac OS X and iOS, distributed by International Business Machines Corporation of Armonk, New York; BlackBerry OS, distributed by Apple Inc. of Cupertino, California; and versions and / or variants of Android, developed by the Open Handset Alliance.

[0082] Computing devices (controllers, biometric sensors, display telematics functions, etc.) typically include computer-executable instructions that can be executed by one or more processors. These computer-executable instructions can be compiled or interpreted by computer programs created using various programming languages ​​and / or techniques, which, individually or in combination, include, but are not limited to, Java. TM Languages ​​include C, C++, Visual Basic, JavaScript, Perl, etc. Generally, a processor or microprocessor receives instructions from, for example, memory or a computer-readable medium, and executes these instructions to perform one or more processes, including one or more of the processes described herein. Such instructions and other data can be stored and transmitted using a variety of computer-readable media.

[0083] Computer-readable media (also known as processor-readable media) include any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor of a computing device). Such media can take many forms, including but not limited to non-volatile and volatile media. Non-volatile media can include, for example, optical discs or magnetic disks, and other persistent storage. Volatile media can include, for example, dynamic random access memory (DRAM), which typically constitutes main memory. Such instructions can be transmitted via one or more transmission media, including coaxial cables, copper wires, and optical fibers, including wires that constitute a system bus coupled to the processor of a computer. Common forms of computer-readable media include, for example, floppy disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs, any other optical media, punched cards, paper tape, any other physical media with a punched pattern, RAM, PROM, EPROM, FLASH-EEPROM, any other memory chip or memory cartridge, or any other medium from which a computer can read.

[0084] Databases, data repositories, or other data storage devices described herein can include various mechanisms for storing, accessing, and retrieving a wide variety of data, including hierarchical databases, file sets in file systems, application databases in proprietary formats, relational database management systems (RDBMS), etc. Each such data storage device is typically contained within a computing device employing a computer operating system (such as one of the operating systems mentioned above) and is accessed via a network in one or more of a variety of ways. File systems can be accessed from the computer operating system and can include files stored in various formats. In addition to languages ​​used for creating, storing, editing, and executing stored programs (such as the PL / SQL language mentioned above), RDBMS typically employs Structured Query Language (SQL).

[0085] In some examples, system elements may be implemented as computer-readable instructions stored on one or more computing devices and on an associated computer-readable medium. A computer program product may include such instructions stored on a computer-readable medium for performing the functions described herein. In some examples, an application software product may be provided as software that, when executed by a processor of a device or server, provides the operations described herein. Alternatively, the application software product may be provided as hardware or firmware, or a combination of software, hardware, and / or firmware.

[0086] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the invention. Rather, the terminology used herein is descriptive rather than restrictive, and it should be understood that various changes can be made without departing from the spirit and scope of the invention. Furthermore, features of various embodiments can be combined to form other embodiments of the invention.

[0087] According to the present invention, a transfer key system for a vehicle is provided, the transfer key system comprising: a key container configured to detect the presence of a transfer key; and a controller configured to receive a key status signal from the key container, and to activate the transfer key as an active transfer key in response to the status signal indicating that the transfer key has been removed from the key container and to receiving an authentication signal from a user.

[0088] According to an embodiment, the controller is also configured to transmit a notification of transfer key activation to a mobile device associated with the vehicle owner.

[0089] According to an embodiment, the controller is also configured to activate the transfer key in response to receiving an authentication signal from a mobile device associated with the vehicle owner, the mobile device being separate and distinct from the transfer key.

[0090] According to an embodiment, the controller is also configured to apply a chauffeur mode to the activated transfer key-restricted vehicle feature when the vehicle is accessed using a transfer key.

[0091] According to an embodiment, the controller is also configured to apply user-defined access restrictions to the activated transfer key-restricted vehicle feature when the vehicle is accessed using a transfer key.

[0092] According to an embodiment, the controller is also configured to deactivate the transfer key in response to receiving a subsequent key status signal instructing the transfer key to be replaced in the key container and a user authentication signal.

[0093] According to an embodiment, the controller is also configured to deactivate the transfer key in response to receiving a deactivation signal from the mobile device, wherein the mobile device is away from the vehicle.

[0094] According to the present invention, a vehicle transfer key system for presenting an alarm to a vehicle user is provided, the vehicle transfer key system comprising: a temperature sensor configured to detect the temperature inside the vehicle compartment; and a controller configured to detect the presence of a transfer key inside the vehicle compartment, determine whether the transfer key has been activated, receive the vehicle compartment temperature from the temperature sensor, and transmit a temperature notification in response to the temperature falling outside a predefined threshold.

[0095] According to an embodiment, the controller is also configured to transmit an activation notification in response to the transfer key not being activated.

[0096] According to an embodiment, a temperature notification is transmitted in response to the activation of the transfer key.

[0097] According to an embodiment, the controller is also configured to transmit a warranty warning indicating a possible transfer key malfunction in response to the transfer key being activated and the temperature being within a predefined threshold.

[0098] According to the present invention, a method for a vehicle transfer key system includes: receiving a key status signal from a key container in a vehicle; activating the transfer key as an active transfer key in response to the status signal indicating that the transfer key has been removed from the key container; and transmitting a notification of the activation of the transfer key to a mobile device associated with the vehicle owner.

[0099] According to an embodiment, the invention is further characterized in that the transfer key is activated in response to receiving an authentication signal from a mobile device associated with the vehicle owner, and the mobile device and the transfer key are separate and distinct.

[0100] According to an embodiment, the invention is further characterized in that when accessing the vehicle using a transfer key, a valet mode is applied to the activated transfer key-restricted vehicle feature.

[0101] According to an embodiment, the present invention is further characterized in that, when accessing a vehicle using a transfer key, user-defined access restrictions are applied to the activated transfer key-restricted vehicle feature.

[0102] According to an embodiment, the invention is further characterized in that the transfer key is deactivated in response to receiving a subsequent key status signal indicating that the transfer key should be replaced in the key container.

[0103] According to an embodiment, the invention is further characterized in that the transfer key is deactivated in response to the elapsed duration of a predefined time.

[0104] According to an embodiment, the invention is further characterized in that the transfer key is deactivated in response to receiving a deactivation signal from the mobile device, wherein the mobile device is away from the vehicle.

[0105] According to an embodiment, the invention is further characterized in that the temperature of the passenger compartment is received from a temperature sensor, and a notification is sent in response to the temperature falling outside a predefined threshold.

[0106] According to an embodiment, the notification is in response to the activation of the transfer key.

Claims

1. A transfer key system for a vehicle, comprising: A key container configured to detect the presence of a transfer key; A temperature sensor, configured to detect the temperature inside the carriage; as well as The controller is configured as follows: Receive key status signal from the key container; In response to the status signal indicating that the transfer key has been removed from the key container and an authentication signal received from the user, the transfer key is activated as an active transfer key, and The controller is also configured to receive the temperature inside the vehicle compartment from the temperature sensor and, in response to the activation of the transfer key and the temperature being within a predefined threshold, transmit a warranty warning indicating a possible transfer key malfunction.

2. The system of claim 1, wherein the controller is further configured to transmit the activation notification of the transfer key to a mobile device associated with the vehicle owner.

3. The system of claim 2, wherein the controller is further configured to activate the transfer key in response to receiving an authentication signal from the mobile device associated with the vehicle owner, the mobile device being separate and distinct from the transfer key.

4. The system of claim 1, wherein the controller is further configured to apply a chauffeur mode to the activated transfer key-restricted vehicle features when the vehicle is accessed using the transfer key.

5. The system of claim 1, wherein the controller is further configured to apply user-defined access restrictions to the activated transfer key-restricted vehicle features when the vehicle is accessed using the transfer key.

6. The system of claim 1, wherein the controller is further configured to deactivate the transfer key in response to receiving a subsequent key status signal and a user authentication signal instructing the transfer key to be replaced in the key container.

7. The system of claim 3, wherein the controller is further configured to deactivate the transfer key in response to receiving a deactivation signal from the mobile device, wherein the mobile device is remote from the vehicle.

8. A vehicle transfer key system for presenting an alarm to a vehicle user, the vehicle transfer key system comprising: A temperature sensor, configured to detect the temperature inside the carriage; as well as The controller is configured as follows: Detect the presence of the transfer key inside the carriage; Determine whether the transfer key has been activated; The temperature inside the carriage is received from the temperature sensor; and A temperature notification is transmitted in response to the temperature falling outside a predefined threshold. The controller is also configured to transmit a warranty warning indicating a possible transfer key malfunction in response to the transfer key being activated and the temperature being within a predefined threshold.

9. The system of claim 8, wherein the controller is further configured to transmit an activation notification in response to the transfer key not being activated.

10. The system of claim 8, wherein the temperature notification is transmitted in response to the activation of the transfer key.

11. A method for a vehicle transfer key system, the method comprising: Receive key status signals from the key container inside the vehicle; The transfer key is activated as an active transfer key in response to the status signal indicating that the transfer key has been removed from the key container; Transmit the activation notification of the transfer key to the mobile device associated with the vehicle owner; The temperature inside the carriage is received from a temperature sensor; as well as In response to the transfer key being activated and the temperature being within a predefined threshold, a warranty warning indicating a possible transfer key malfunction is transmitted.

12. The method of claim 11, further comprising activating the transfer key in response to receiving an authentication signal from the mobile device associated with the vehicle owner, wherein the mobile device is separate and distinct from the transfer key.

13. The method of claim 11, further comprising applying a chauffeur mode to the activated transfer key-restricted vehicle features when the vehicle is accessed using the transfer key.

14. The method of claim 11, further comprising applying user-defined access restrictions to the activated transfer key-restricted vehicle features when accessing the vehicle using the transfer key.

Images