Patent Application
20170001598
Embodiments disclosed herein generally relate to accessing an interior cabin of a vehicle.
Vehicles often authenticate users and unlock in response to recognizing the presence of a trusted key, such as a key fob. However, due to the increasing use of keyless entry systems, users often misplace or forget their keys. Replacement keys may be expensive, and gaining access to a locked vehicle without a key may require a user to contact an authorized service center.
A vehicle authentication system may include a controller configured to detect a trigger event, activate at least one camera, transmit a unique identifier to a mobile device, receive an image from the at least one camera, and grant access to the vehicle in response to the image including the unique identifier.
A vehicle authentication system may include a camera and a controller configured to determine a trigger event, activate the camera, receive a unique image from the camera, compare the received image with at least one stored image, and unlock at least one vehicle door in response to the received image and stored image matching.
A non-transitory computer-readable medium tangibly embodying computer-executable instructions of a software program, the software program being executable by a processor of a computing device to provide operations, may include to activate at least one vehicle camera in response to a trigger event, transmit a unique identifier to a mobile device, receive an image from the at least one vehicle camera, and grant access to the vehicle in response to the image including the unique identifier.
The embodiments of the present disclosure are pointed out with particularity 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:
As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
Often times drivers misplace their keys or key fobs and thus cannot unlock, drive or otherwise access their vehicle. In response to this, drivers may often call an administrator or authorized service center who may remotely unlock the vehicle. The driver may also call a friend or family member to locate a spare set of keys. However, these methods are often burdensome and time consuming. Moreover, replacement keys are often expensive. Providing temporary access and operation of a vehicle may allow the user enough time to find or retrieve his or her key, without contacting a third party for help.
Disclosed herein is a vehicle authentication system that may authenticate a user based on an image or unique identifier made available via a user's mobile device. A vehicle camera may capture the image, and a controller may authenticate the user based on the image. In one example, the image may be a Quick Response (QR) Code unique to the driver and capable of authenticating the driver when compared to a stored code associated with the driver in a database.
The vehicle camera may be any camera on or within the vehicle. For example, the vehicle camera may be a back-up camera arranged on the rear of the vehicle (i.e., rear-mounted camera). The camera may be activated when the vehicle is running, but otherwise may not be continually turned on. The camera may be turned on in response to a trigger event. The trigger event may be initiated by the user and may include a unique sequence of events such as pulling a vehicle door handle three times, or folding in a vehicle minor twice. Upon recognizing the trigger event, the controller may activate the camera. Also, upon recognizing the trigger event, the controller may instruct the unique image to be transmitted to the mobile device via a wireless connection between the vehicle and the mobile device. The user may then place the mobile device showing the received image in front of the activated camera. The camera may capture the image and the controller may compare the image to at least one authorized image, and proceed to unlock the vehicle in response to a match between the images.
Accordingly, the vehicle authentication system provides for a secure, user-friendly system for gaining access to a vehicle in the case of a missing or lost key. The system uses many existing vehicle features and prevents unnecessary power consumption.
Referring to the Figures,
The vehicle 105 may include a wireless transceiver 125 configured to create a wireless connection 145 between the vehicle 105 and the mobile device 110. The wireless connection 145 may be a BLUETOOTH connection, or other wireless connection such as Wi-Fi, ZIGBEE, or other wireless protocol. By facilitating communication between the mobile device 110 and the vehicle 105, the user's mobile device 110 may receive and transmit information and data with the vehicle 105.
The vehicle 105 may include a plurality of motion sensors 150-A-150-D (collectively referred to as motion sensors 150). These motion sensors 150 may be used to gather information about the vehicle environment such as surrounding objects, and the distance thereto in relation to the vehicle 105. The motion sensors 150 may provide certain distance data indicative of the surrounding objects, which may in turn be used by a parking aid system, or accident warning system. The motion sensors 150 may be ultrasonic or infrared sensors, for example.
The controller 130 may have one or more processors and a memory. The controller 130 may be configured to receive wireless transmitted information via the wireless transceiver 125 and to perform certain instructions, commands, and other routines in support of the processes described herein. The controller 130 may be a body control module (BCM) and/or electrical control unit (ECU) which may interface with various vehicle modules, systems and components, including but not limited to the cameras 120, door handles 135, wireless transceiver 125, mirrors 140, motion sensors 150, as well as navigation systems, accident warning systems, heads-up displays, radio, unlocking, security modules, etc.
The controller 130 may also be a camera control unit and/or an audio head unit. The controller 130 may also be other electrical module configured to control locking or unlocking of the vehicle 105.
The memory of the controller 130 may be a computer-readable storage medium (also referred to as storage and/or database herein). The medium may be non-transitory (e.g., a tangible medium) that provides instructions or other data that may be read by the processor of the controller 130. Instructions may be compiled or interpreted from computer programs created using a variety of languages and/or technologies, including, but not limited to, Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL/SQL.
The controller 130 may be programmed to authenticate a user based on the unique visual identifier captured at the camera 120 and unlock the doors in response to the authentication. The controller 130 may also enable other vehicle modules and systems in response to the authentication. In one example, the controller 130 may permit all vehicle features to function as if the user's key was present. This may include updating certain status' and other conditions so that the vehicle may be freely used by the user. In one situation, this may include updating an ignition status to ON to enable engine start. The controller 130 may also disable certain rules and constraints placed on the vehicle 105 such as disabling key logic that would prevent unlocking the doors unless the key is present. In other examples, some, but not all features may be enabled.
The controller 130 may be programmed to recognize and pair with the mobile device 110 via the wireless connection 145. This pairing may be automatically achieved as the user approaches the vehicle via BLUETOOTH, or another wireless communication between the vehicle 105 and the mobile device 110. Upon recognizing the mobile device 110, the controller 130 and the mobile device 110 may communicate with each other via the wireless connection 145. This may include sending and receiving authentication data.
In the event that a user has lost or misplaced his or her vehicle key or key fob, it may be difficult, if not impossible to gain access to the vehicle 105, let alone operate the vehicle 105. Using the unique identifier, the controller 130 may facilitate a secondary authentication using the mobile device 110 and one of the vehicle cameras 120. When a user realizes he or she has lost the vehicle key, he or she may initiate a trigger event. The trigger event may be an action, or series of actions, taken at the vehicle 105 that may be recognized by the vehicle 105 such as actuating the vehicle handles 135 or mirrors 140, or a combination of both.
The trigger event may be any event at the vehicle 105. It may be a unique sequence of actions that are not typically used in the normal course of use of the vehicle 105. For example, pulling a door handle once may be a typical action used to open a vehicle door. However, pulling a door handle three consecutive times may not be. In another example, folding and unfolding a rear view mirror 140 two consecutive times may not be a typical action and may also be used as a trigger event.
Other trigger events are possible. In another example, moving the windshield wipers, front or rear, may act as a trigger event. The trigger event may also be recognized by the motion sensors 150. The user may move his or her hand in front of one of the motion sensors 150 multiple times. The motion sensors 150 may recognize the close range motion. Any combination of activities may also be used as a trigger. For example, a sequence including a door handle pull followed by a mirror fold may serve as a trigger event.
The controller 130 may recognize the actions making up the trigger event by receiving data indicative of the actions from the various vehicle modules associated with the vehicle components. For example, the controller 130 may receive data indicative of a door handle pull and may determine whether two consecutive, or near consecutive door handle pulls are recognized (e.g., determine whether three door handle pulls recognized within five seconds of each other.)
Once the controller 130 recognizes a trigger event, the controller 130 may determine that authentication is being requested from the user. The controller 130 may generate a visual identifier and transmit the visual identifier to the mobile device 110 via the wireless connection 145. Once the visual identifier is transmitted, the controller 130 may activate the camera 120. Each of the cameras 120 may be activated, or only a subset may be activated. By waiting to activate the exterior cameras 120 until after a trigger event has been recognized, power consumption, as well as wear and tear on the cameras, is conserved. That is, the cameras 120 are not ‘awoken’ until needed.
Once the camera 120 is activated, the user may place the mobile device 110 in front of the camera. The interface 115 of the mobile device 110 may show the visual identifier, which may be captured by the camera 120. The visual identifier, which was issued by the controller 130, may be any number of unique identifiers. In the example shown in
Because the code, or unique visual identifier, is transmitted to the mobile device 110 after recognition of the trigger event, the code is not continually stored on the mobile device 110. Instead, each time access is requested to the vehicle 105, a new unique identifier may be transmitted to the mobile device 110, creating a more secure and reliable system. In another example, the code may ‘expire’, after a certain amount of time (e.g., 24 hours) or uses (e.g., 5 uses). For example, after a predefined amount of time has lapsed, the code may not be used to gain access to the vehicle 105. In another example, after the code has been used a predefined number of times, the code may also expire.
The controller 130 may generate the visual identifier using any number of techniques. It may randomly and dynamically generate the identifier and store the identifier in memory, or a separate database. Additionally or alternatively, visual identifiers may be generated by the vehicle OEM and a plurality of reusable codes may be stored or maintained either remotely by the OEM, or within the processor memory.
Once the camera 120 captures an image including the visual identifier from the mobile device 110, the controller 130 may compare the captured identifier to the stored identifier. If the identifiers match, or nearly match, the controller 130 may proceed to permit access to the vehicle 105 and the vehicle features.
The trigger event may be unique to a specific driver or vehicle. For example, each vehicle 105 may have a unique, predetermined trigger sequence used solely for the purpose of gaining access to that specific vehicle 105, in the event of key loss. Additionally, the controller 130 may be configured to transmit the visual identifier to a recognized mobile device 110 that has previously been paired with the vehicle 105. Thus, a non-authorized person, even if he or she knew the trigger sequence, would not receive the visual identifier. Additional verification may be included via a mobile device application in which a password and username may be required prior to transmitting the visual identifier. Thus, a secure, yet easy to use process may be implemented for authorizing a user.
At block 305, the controller 130 may detect the mobile device 110 via the wireless connection 145. The controller 130 may recognize, via transmission of data between the mobile device 110 and the vehicle 105, the mobile device 110 and authenticate the mobile device 110.
At block 310, the controller 130 may recognize a trigger event. As explained above, the trigger event may include a trigger sequence of actionable activities at the exterior of the vehicle such as, for example, pulling door handles 135 and folding mirrors 140. The controller 130 may recognize the trigger event by receiving data indicative of the actions from one or more vehicle modules (e.g., module associated with door handles 135 and mirrors 140).
At block 315, the controller 130, in response to recognizing the trigger event and detecting the mobile device 110, may activate at least one of the vehicle cameras 120. That is, at least one camera 120 on the exterior of the vehicle may be enabled, or turned on. In an effort to preserve vehicle power, the camera 120 may not be continually activated or enabled. Typically, the camera 120 may be enabled while the vehicle engine is running, but not otherwise. In a situation of a lost key, it may not be possible to start the vehicle 105, and thus, the camera 120 may be activated in response to the trigger event. By using a unique trigger event or sequence, vehicle power may be preserved, while permitting the possibility of identification of the user via the camera 120.
At block 320, the controller 130 may transmit a unique identifier to the mobile device 110. As explained, the unique identifier may be a QR code capable of being displayed on the mobile device interface 115. The identifier may be transmitted in response to the pairing between the mobile device 110 and the vehicle 105, and in response to the trigger event. A new code may be generated each time a trigger event is recognized and the code may be maintained at the database. Thus, the identifier is not necessarily maintained on the user's mobile device 110 until the vehicle 105 realizes that access to the vehicle 105 is being requested. In another example, the identifier may expire after a certain period of time, such as after 24 hours. The period of time may vary, but may be one that allows the user enough time to locate his or her key, or procure a replacement key. This is described in more detail below with respect to block 345. The identifier may be generated at the vehicle 105, or via a third party remote from the vehicle 105.
At block 325, the controller 130 may determine whether the camera 120 has captured an image and whether that image includes the visual identifier. That is, the user may place the mobile device 110 showing the unique identifier in front of the camera 120. The camera 120 may capture an image in response to recognizing an object, such as the mobile device 110, in front of the camera. The camera 120 may then transmit the captured image to the controller 130. If an image has been captured by the camera 120, the process 300 proceeds to block 330. If not, the process 300 proceeds to block 335.
At block 335, the controller 130 determines whether a predefined amount of time has lapsed since the transmission of the unique identifier. The predefined amount of time may be approximately 30 seconds, but may be anywhere from approximately 15 seconds to 180 seconds, or more. If the predefined amount of time has not lapsed, the process 300 returns to block 325 where the controller 130 waits to receive an image. If the predefined amount of time has lapsed, the process 300 proceeds to block 340.
At block 340, the controller 130 instructs the camera 120 to deactivate, or turn off. The process 300 then ends.
At block 330, the controller 130 may determine whether the captured identifier matches the stored identifier. The controller 130 may compare the generated identifier stored in the database with the identifier within the image captured by the camera 120. If the two images are the same, or substantially similar within a certain degree, the process 300 may proceed to block 345. If not, the process 300 may proceed to block 340.
At block 345, the controller 130 may determine whether the identifier has expired. The identifier may expire after a certain amount of time (e.g., 24 hours) or uses (e.g., 5 uses). That is, the identifier may be used to permit access for a reasonable amount of time so that the user may procure a replacement key. The identifier may not be intended to be used a key substitute. If the identifier has expired, the process 300 proceeds to block 340. If not, the process 300 proceeds to block 350.
At block 350, the controller 130 may permit vehicle access in response to a valid, unexpired unique identifier being captured at the vehicle camera 120. Vehicle access may include unlocking the vehicle doors and allowing for operation of the vehicle 105 (e.g., driving of the vehicle 105). As mentioned above, the controller 130 may permit all vehicle features to function as if the user's key was present. The process 300 may then end.
At block 405, the controller 130 may detect three consecutive door handle pulls. The door handle pulls may trigger the controller 130 to activate the camera 120 at block 410. At block 415, the controller 130 may instruct the camera 120 to activate for a predefined amount of time, such as 30 seconds, after receiving instructions from the controller 130.
At block 425, the controller 130 may wait for the camera 120 to capture the visual code (e.g., unique visual identifier). If a code is captured, the process 400 proceeds to block 430, if not, the process ends. At block 430. The controller 130 determines whether the received visual code matches the code stored in the database. If so, the process 400 proceeds to block 435. If not, access to the vehicle 105 is denied at block 440.
At block 435, the controller 130 determines whether a predefined amount of access attempts (via the image) have been exceeded. If so, the process 400 proceeds to block 440 where access to the vehicle 105 is denied. If not, the process 400 proceeds to block 445. At block 445, the controller 130 may disable any key logic preventing access to the vehicle 105 and may permit access and update an ignition status to ON at block 450. The process 400 may then end.
Computing devices described herein generally include computer-executable instructions, where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic, Java Script, Perl, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media.
With regard to the processes, systems, methods, heuristics, etc., described herein, it should be understood that, although the steps of such processes, etc., have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.
While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.
