AUTHENTICATION DEVICE AND METHOD

Abstract

An authentication device includes at least one processor, at least one computer-readable medium, and program instructions stored on the at least one computer-readable medium for execution by the at least one processor. The program instructions include first program instructions to wirelessly pair the authentication device with a controlled access device. The program instructions further include second program instructions to broadcast data indicative of an authorization to grant access to the controlled access device, while the controlled access device is within a predefined range of the authentication device, upon successfully pairing with the controlled access device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. Patent Application No. 61/929,845 filed on Jan. 21, 2014, which is incorporated by reference herein in its entirety.

FIELD OF INVENTION

The present disclosure relates to the field of access control. More particularly, the present disclosure relates to an authentication device and method for controlling access.

BACKGROUND

Access to computer software, hardware, and other devices, both electrical and mechanical, is commonly controlled using passwords or other types of digital or mechanical keys. A smartphone, for example, may require a passcode or password to be input before it can be unlocked and used to make a call. Similarly, a computer may require a password to be input before it can be used for various computing functions. Software, such as a banking application, may require a password to be input before the application may be used to perform banking tasks. And a door may require a physical key to be inserted before the door can be unlocked and opened.

Remembering passwords and passcodes, however, may be cumbersome and impractical, particularly when a user may be required to keep track of multiple passwords that correspond to gaining access to a variety of software applications, devices, doors, and so on. In addition, storing physical keys for gaining access to a variety of doors, devices, and so on, may be cumbersome and impractical as well.

SUMMARY

An authentication device includes at least one processor, at least one computer-readable medium, and program instructions stored on the at least one computer-readable medium for execution by the at least one processor. The program instructions include first program instructions to wirelessly pair the authentication device with a controlled access device. The program instructions further include second program instructions to broadcast data indicative of an authorization to grant access to the controlled access device, while the controlled access device is within a predefined range of the authentication device, upon successfully pairing with the controlled access device.

In an authentication method, a computing device receives a request to pair with a controlled access device. The computing device wirelessly pairs with a controlled access device. The computing device broadcasts data indicative of an authorization to grant access to the controlled access device, while the controlled access device is within a predefined range of the computing device, upon successfully pairing with the controlled access device.

In a method for granting access to a controlled access device using a key device, a controlled access device communicates a request to pair with a key device. The controlled access device confirms successful pairing with the key device. The controlled access device receives a communication from the key device indicative of an authorization to grant access to the controlled access device. The controlled access device grants access by disabling a lock while the controlled access device continues to receive communications from the key device, at predefined intervals, indicative of an authorization to grant access to the controlled access device.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various example systems, methods, and so on, that illustrate various example embodiments of aspects of the invention. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that one element may be designed as multiple elements or that multiple elements may be designed as one element. An element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.

FIG. 1 illustrates a key device and a controlled access device.

FIG. 2 is a block diagram illustrating exemplary components of an embodiment of a key device of FIG. 1.

FIG. 3 is a flow diagram illustrating exemplary interactions between a key device and a controlled access device.

FIG. 4 is a flow diagram illustrating exemplary interactions between a key device and a controlled access device.

FIG. 5 is a flow diagram illustrating exemplary interactions between a key device and a controlled access device.

DETAILED DESCRIPTION

A user authentication device and method is disclosed. In one embodiment, a universal access device (henceforth referred to as “key device”) is configured to provide access to computer hardware, computer software, and other electrical and mechanical devices that requires a virtual or physical key or password. The key device may include a wireless communications enabled device that the user wears, possesses, or otherwise maintains in physical proximity to allow for access to a suitably configured smartphone, tablet, computer, and devices not normally thought of as having logic such as a door, car door, bike lock, and other controlled access devices. It should be appreciate that controlled access devices such as doors that are not normally thought of as having logic may need to be outfitted with a device including logic in order to communicate with the key device. When the key device is within range of one of the user's controlled access devices, the key device will allow the user to bypass that controlled access device's password or physically unlock it, eliminating the need for complicated passwords and cumbersome keys. When the key device is moved out of range, the controlled access device may re-enable its security mechanisms, so it is safe and secure when out of the user's hands.

In another embodiment, the key device may communicate with controllers in a user environment such as a room in a house, an office, or a vehicle to establish user environmental preferences such as temperature, lighting, music, video and the like. When a user departs the area or after a delay, the controllers may revert to default preferences such as turning off lights and otherwise adjusting environmental controls for energy efficiency.

In operation, the key device and the controlled access device do not require two-way communication and authentication protocols provided that the devices have been initialized and maintain relatively close clock synchronization.

The following description includes definitions of selected terms used throughout the disclosure. Both singular and plural forms of all terms fall within each meaning.

“Address”, as used herein, includes but is not limited to one or more network accessible addresses, device identifiers, telephone numbers, IP addresses, URL and ftp locations, e-mail addresses, names, a distribution list including one or more addresses, network drive locations, postal addresses, account numbers or other types of addresses that can identify a desired destination or device.

“Computer-readable medium”, as used herein, refers to any medium that participates directly or indirectly in providing instructions and/or data to one or more processors for execution. Such a medium may take many forms, including but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical or magnetic disks. Volatile media may include, for example, dynamic memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other medium which can be read by a computer, a processor or other electronic device.

“Logic”, as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another component. For example, based on a desired application or needs, logic may include a software controlled microprocessor, discrete logic such as an application specific integrated circuit (ASIC), a programmed logic device, memory device containing instructions, or the like.

“Signal”, as used herein, includes but is not limited to one or more electrical or optical signals, analog or digital signals, one or more computer or processor instructions, messages, a bit or bit stream, or other means that can be received, transmitted, and/or detected.

“Software”, as used herein, includes but is not limited to one or more computer readable and/or executable instructions that cause a computer or other electronic device to perform functions, actions, and/or behave in a desired manner. The instructions may be embodied in various forms such as routines, algorithms, modules or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in various forms such as a stand-alone program, a function call, a servlet, an applet, instructions stored in a memory, part of an operating system or other type of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like.

“User”, as used herein, includes but is not limited to one or more persons, software components, computers, or other devices capable of using or accessing a component, or combinations of these.

Generally speaking, one embodiment of a system and method as used herein, includes but is not limited to a user associated key device that communicates with and provides access to a controlled access device having some form of access control such as password, key and the like. When in wireless communication and the key device and controlled access device successfully communicate, the controlled access device is at least temporarily accessible without the user having to manually engage with the access control apparatus.

With reference to FIG. 1, an exemplary key device 100 is formed from any suitable material and is shaped to be worn on the wrist of a user (not shown). In other embodiments, the key device 100 may take the form of a wristband, finger ring/toe ring, ear ring/ear stud, necklace, credit card sized wallet insert/purse insert, eyeglasses, epidermal implant, tattoo, other accessory, smartphone, key fob, key chain, sticker, pen, or pencil. The key device 100 communicates 120, preferably via wireless communication such as radio-frequency, infra-red, WiFi, Bluetooth, RFID or Near Field Communication, with a controlled access device 130 such as the smartphone illustrated, and grants access to controlled access device 130. In other embodiments, controlled access devices may alternatively or additionally include, but are not limited to, a tablet device, a laptop computer/desktop computer, house door/apartment door/office door/hotel room door, car door, bike lock, payment terminal, padlock, safe, locking drawer/locking cabinet, firearm, light, television, heating/air conditioning unit, garage door, sink, shower, ATM, music player, printer, public storage rental unit, personal identification system, or controllers for other devices.

With reference now to FIG. 2, a block diagram illustrates exemplary components of an embodiment of a key device 100 of FIG. 1. Key device 100 includes processing logic 140 and a processor 110 to execute the processing logic 140 stored on a computer-readable medium. The processing logic 140 is configured to control clocking, authentication, and communication activities. Of course, these activities may be divided or allocated among other application specific logics. As further discussed below, processing logic 140 obtains data from a data store 150. From the stored data, processing logic 140 forms a message, preferably in the form of “unlock advertising” for transceiver logic 160, stored on a computer-readable medium, to broadcast via antenna 170. Processing logic 140 may optionally provide an indication to a user through a user interface 180 of communications generally, or success or failure to access a controlled access device. The user interface 180 may be configured as a visual indicator such as an LED, an audible indication, a graphical indication or the like. The processor 110 may be powered from an internal power supply 190 such as a battery. The power supply 190 may be replaceable, rechargeable, or both.

In one embodiment, to preserve power supply 190, the processing logic 140 may be configured to place components of key device 100 in a stand-by or low power state and periodically “wake” needed components to perform needed activities such as authentication or communication.

In one embodiment, the key device 100 would be able to manage access for third-party controlled access devices 130 through software and hardware plug-ins. For example, software plug-ins may include a software development kit (“SDK”) and/or an application programming interface (“API”) that could be used on a third-party controlled access device to communicate with the key device 100. Exemplary hardware plug-ins, which include a piece of hardware developed to communicate with the key device 100, could be connected to a third-party controlled access device 130 as a way to grant access to features of their device. The hardware plug-in would send a current to the third-party controlled access device 130 when communicating with key device 100 and would send no current when communication breaks. For example, the hardware plug-in can authenticate with key device 100 and send an electrical signal to a wire or a pin when key device 100 is determined to be within a defined range. If the key device 100 is not within range, the plug-in would not send any signals to the pin. A third party controlled access device 130 interfaces with the hardware plug-in by connecting to the pin or wire. The third party controlled access device 130 is configured to unlock when an electrical signal is detected on the wire or pin and to lock when no electrical signal is detected. The reverse of this behavior could also occur if specified by the third-party. The communication would follow the schema of the algorithm described below.

With reference now to FIG. 3, an example flow diagram of the interactions between a key device 100 and a controlled access device 130 is described. Initially, a key device 100 and a controlled access device 130 will pair 310 upon an initial encounter or after pairing data is lost between the two. The initial pairing 310 may include a user entering a code into an application or data entry field on the controlled access device 130. The controlled access device 130 may store the code in a computer-readable medium and calculate a key from the code using a formula. The controlled access device 130 may also store the calculated key. An initial pairing may additionally include a clock synchronization as described more fully below. Initial pairing is complete upon successful synchronization (if needed) and a matching code exchanged from the key device 100 to the controlled access device 130. Alternately, the initial pairing may include a code match from the controlled access device 130 to the key device 100 as well as a code match from the key device 100 to the controlled access device 130.

Upon successfully validating a request and pairing 320 with the controlled access device 130, the key device 100 will then periodically “advertise” its presence by broadcasting or advertising the code 330. When the controlled access device 130 receives the broadcast code, it may compare the received code to a stored code 340. The stored code may actually include several codes, for example, codes for a current time as well as codes for neighboring times, where neighboring times include those a few seconds to a few minutes on either side of current device time. If the received code matches the stored code, the controlled access device 130 disables its password or other access control and grants access 350. If the received code does not match the stored code, one problem may be that the respective clocks have drifted or been set too far apart. To check, the controlled access device 130 may synchronize 360 its clock with the clock of the key device 100. The clock synchronization may be accomplished by the controlled access device 130 generating a random number, encrypting the random number and sending it to the key device 100. The key device 100 may decrypt the random number and return it encrypted with clock data. The controlled access device 130 decrypts the number and clock data and checks the random number for continuity. If the random number correctly decrypts and matches the generated number, the device may update its offset based on the received clock data 370. Thereafter, the codes should match enabling access to the controlled access device 130. If the random number is not correctly decrypted, authentication fails and the controlled access device 130 ensures its password or other access controls are maintained or restored 380, and therefore the controlled access device 130 remains locked.

In operation and under normal conditions, the key device 100 and the controlled access device 130 operate without two-way communication. For example, once initial pairing is complete, whenever the key device 100 and controlled access device 130 are within signal proximity, the controlled access device 130 receives periodic unlock advertising from the key device 100, authenticates the code, and overrides or bypasses its password or access controls. The controlled access device 130 may permit continued use while continuing to receive the periodic advertising and may restore its access controls when the advertising is not received for a time.

With reference now to FIGS. 4-5, variables “wCode”, “wKey”, “rKey”, “storedTime”, “Local Time”, “Remote Time”, “AdvMsg”, “cOffset”, “actOffset”, and “wFormula” are introduced and are used as follows. “wCode” is deemed to include a code, for example, a code printed on the wristband or key device. “wKey” is defined as a symmetric encryption key generated by “wFormula.” “rKey” is defined as a symmetric encryption key stored in memory of key device. “storedTime” is defined as the Local Time stored in memory of the key device. “Local Time” is defined as the actual date and time on the local device, either at the key device or the controlled access device. “Remote Time” is defined as the actual date and time on a device remote to the local device, which can be either the key device or the controlled access device. “AdvMsg”, or Advertising Message is defined as “wCode” and key device “Local Time” encrypted with “rKey”. “cOffset”, or Expected Clock Offset, is defined as the expected offset between the key device clock and controlled access device clock. “actOffset”, or Actual Clock Offset, is defined as the actual offset between the key device clock and controlled access device clock. “wFormula” is a formula that generates “wKey” from “wCode”.

With reference now to FIG. 4, an example flow diagram of the steps of the initial pairing 310 between key device 100 and a controlled access device 130 is described. A user first obtains a wCode printed on, or otherwise obtained from or provided with, the key device 100 and provides the wCode to the controlled access device 130, 402. This can include entering the wCode into a software application being executed by the controlled access device 130, for example. The controlled access device 130 stores the wCode in memory. The controlled access device 130 then uses the stored wCode to generate or calculate a wKey using wFormula and stores the wKey in memory 404.

The controlled access device 130 then generates a random number and encrypts the random number, along with actual Local Time at the controlled access device 103, using the stored wKey and communicates the encrypted data to the key device 100, 406. The key device 100 decrypts the random number and the Remote Time, or the time at the controlled access device 103, 408. The key device 100 then encrypts the random number along with the Local time at the key device 100 and with a device version number, using the wKey, and responds by communicating the encrypted data back to controlled access device 130, 408.

The controlled access device 130 then decrypts and checks the response, 410. In particular, controlled access device 130 checks the random number and compares it to the initially sent random number. If it doesn't match, the controlled access device 130 notifies the user that the pairing has failed. Otherwise, the controlled access device 130 updates cOffset by determining the difference between the Remote Time, or the Local Time at the key device 100, and the Local Time at the controlled access device 130. The controlled access device 130 also checks device version to confirm that key device 100 is supported. Checking the version may include comparing the version number to a list of supported version numbers, for example. If the controlled access device 130 determines that the version number is not supported, the user is notified that the pairing failed. Otherwise, controlled access device 130 stores the version number.

If the controlled access device 130 determines that the key device 100 successfully responded, 412, meaning that the key device 100 returned a correct random number and that the version number of the key device 100 is supported, then the controlled access device 130 proceeds to request an rKey from key device 100, 414. The key device 130 encrypts the rKey using wKey and responds to the request, after which the controlled access device 130 decrypts and stores the rKey in memory, 414.

The controlled access device 130 then sends a message to key device 100 confirming successful pairing. In one example, a clock synchronization, as described above, is performed after an initial pairing if needed. Once pairing is complete, key device 100 may begin to advertise or broadcast a code to controlled access device 130.

With reference now to FIG. 5, an example flow diagram of the steps of the unlock advertising 330 between key device 100 and a controlled access device 130 is described. In one example, unlock advertising 330 occurs once every second but it should be appreciated that any suitable time interval may be used. The key device 100 first generates AdvMsg by encrypting wCode and Local Time at the key device 100 using the rKey and sends the AdvMsg to the controlled access device 130, 502. The controlled access device 130 receives and decrypts the AdvMsg, 504. The secured access device 130 then compares the wCode received in the AdvMsg with a stored wCode, 506. Based on the comparison, the controlled access device 130 then determines whether to grant access, 508. In particular, if the wCode in the received AdvMsg does not match the stored wCode, the controlled access device 130 is locked and access is not granted. If the codes do match, an actOffset is calculated using Local Time at the controlled access device 130 and the Remote Time, or the received Local Time at the key device 100. If the difference between actOffset and the stored cOffset is less than a predetermined value such as 3 seconds, for example, the controlled access device 130 is unlocked and access is granted. But if the difference between the actOffset and the stored cOffset is greater than or equal to the predetermined value, a clock synchronization is performed, as already described.

It should be appreciated that example system and method described can be applied for granting access to multiple devices simultaneously. In particular, upon receiving a valid AdvMsg, the controlled access device 130 grants access and does not respond to the key device 100. This method allows an unlimited number of controlled access devices 130 to receive the same AdvMsg and grant access simultaneously.

While the systems, methods, and so on have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and so on provided herein. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention, in its broader aspects, is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the applicants' general inventive concept. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims. Furthermore, the preceding description is not meant to limit the scope of the invention. Rather, the scope of the invention is to be determined by the appended claims and their equivalents.

As used herein, “connection,” “connected,” or “connectable” means both directly, that is, without other intervening elements or components, and indirectly, that is, with another component or components arranged between the items identified or described as being connected. To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim. Furthermore, to the extent that the term “or” is employed (e.g., A or B) it is intended to mean “A or B or both.” When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Similarly, when the applicants intend to indicate “one and only one” of A, B, or C, the applicants will employ the phrase “one and only one.” Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).

Claims

1-22. (canceled)

23. An authentication system, comprising:

an authentication device comprising at least one processor, at least one computer-readable medium, and program instructions stored on the at least one computer-readable medium for execution by the at least one processor, the program instructions comprising: first program instructions to send data indicative of an authorization to grant access to any of a plurality of controlled access devices; and

each of the controlled access devices comprising at least one processor, at least one computer-readable medium, and program instructions stored on the at least one computer-readable medium for execution by the at least one processor, the program instructions comprising: second program instructions to receive the data from the authentication device; third program instructions to determine if the data received from the authentication device is valid to grant access to the respective controlled access device based on an evaluation of the data; fourth program instructions to grant access to the respective controlled access device based on the evaluation of the data indicating valid authorization and to continue to allow access to the respective controlled access device while continuing to receive valid data from the authentication device; and fifth program instructions to enable access controls of the respective controlled access device to deny access to the respective controlled access device based on the respective controlled access device not receiving valid data from the authentication device.

24. The authentication system of claim 23, wherein the authentication device is configured to pair with each of the plurality of controlled access devices in response to an initial encounter with each respective controlled access device, and, after pairing with each respective control access device the authentication device is programmed to send the data to each respective controlled access device, and

wherein each of the controlled access devices is configured to pair with the authentication device in response to the initial encounter with the authentication device, and, after pairing with the authentication device is configured to receive the data from the authentication device.

25. The authentication system of claim 23, wherein the data comprises variable data.

26. The authentication system of claim 25, wherein the variable data comprises time.

27. The authentication system of claim 25, wherein the first program instructions are further programmed to encrypt the variable data and send the encrypted variable data to the respective controlled access device.

28. The authentication system of claim 23, wherein the data comprises advertisement data, wherein the authentication device wirelessly communicates the advertisement data to each of the plurality of controlled access devices that is within range of the authentication device.

29. The authentication system of claim 28, wherein prior to sending the data to the any of the plurality of controlled access devices, the first program instructions are further programmed to establish a wireless connection from the authentication device and each of the plurality of controlled access devices within range thereof, and

wherein the second program instructions of each of the plurality of controlled access devices are further programmed to establish the wireless connection and pair with the authentication device, prior to receiving the data from the authentication device, such that a bond forms between the authentication device and each respective controlled access device to which it pairs to enable automatically establishing a subsequent wireless connection between the authentication device and each respective controlled access device when within range of each other.

30. The authentication system of claim 23, wherein the fifth program instructions are further programmed to wait for at least a predetermined period of time while not receiving valid data from the authentication device to deny access to the respective controlled access device.

31. The authentication system of claim 23, wherein the access controls are further programmed to lock the respective controlled access device automatically based on the respective controlled access device not receiving valid data from the authentication device in response to the authentication device going out of range with respect to the respective controlled access device.

32. The authentication system of claim 23, wherein the access controls are further programmed to unlock and grant access to the respective controlled access device automatically based on the respective controlled access device receiving valid data from the authentication device in response to the authentication device coming within range of the respective controlled access device.

33. A method comprising:

receiving, at a respective controlled access device, data from an authentication device, the received data being data indicative of an authorization to grant access to any of a plurality of controlled access devices including the respective controlled access device;

determining, by a processor, if the data received from the authentication device is valid to grant access to the respective controlled access device based on an evaluation of the data;

granting access to the respective controlled access device based on the evaluation of the data indicating valid authorization and continuing to allow access to the respective controlled access device while the respective controlled access device continues to receive valid data from the authentication device; and

enabling access controls of the respective controlled access device to deny access to the respective controlled access device based on the respective controlled access device not receiving valid data from the authentication device.

34. The method of claim 33, further comprising:

pairing the authentication device with at least some of the plurality of controlled access devices, including the respective controlled access device, in response to an initial encounter by the authentication device with each respective controlled access device; and

in response to the pairing, each of the controlled access devices is configured to receive the data from the authentication device.

35. The method of claim 33, wherein the received data comprises variable data.

36. The method of claim 35, wherein the variable data comprises time.

37. The method of claim 35, wherein the variable data is encrypted such that the respective controlled access device receives the encrypted variable data from the authentication device.

38. The method of claim 33, wherein the received data comprises advertisement data, wherein the respective controlled access device and any of the other of the plurality of controlled access devices within range of the authentication device receives the advertisement data in a wireless communication from the authentication device.

39. The method of claim 38, wherein prior to the respective controlled access device receiving the advertisement data, the method further comprises

establishing a wireless connection and pairing the respective controlled access device with the authentication device, such that a bond forms between the authentication device and the respective controlled access device to which it pairs to enable automatically establishing a subsequent wireless connection between the authentication device and the respective controlled access device when within range of each other.

40. The method of claim 33, further comprising waiting, by the respective controlled access device, for at least a predetermined period of time while not receiving valid data from the authentication device prior to enabling the access controls of the respective controlled access device.

41. The method of claim 33, further comprising automatically locking the respective controlled access device, by the access controls thereof, based on the respective controlled access device not receiving valid data from the authentication device in response to the authentication device going out of range with respect to the respective controlled access device.

42. The method of claim 41, further comprising automatically unlocking and granting access to the to the respective controlled access device based on the respective controlled access device receiving valid data from the authentication device in response to the authentication device coming within range of the respective controlled access device.