Remote programming of access control systems using virtual card data

Abstract

An access control system includes a credential service operable to generate an encrypted programming credential, a mobile library on a mobile device operable to communicate with the credential service, the mobile library operable to receive the encrypted programming credential from the credential service, and a credential module for an access control, the credential module operable to extract programming data from the encrypted programming credential, the programming data being usable to program the access control.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present invention claims the benefit of U.S. Provisional Patent Application No. 62 / 086,271, filed on December 2, 2014, and entitled “Remote Programming For Access Control System With Virtual Card Data,” the disclosure of which is incorporated herein by reference in its entirety as if set forth at length. Background of the Invention

[0003] The present disclosure relates generally to access control systems and, more particularly, to systems and methods for remotely programming access controls.

[0004] Access control systems typically operate by encoding data on a physical key fob that indicates access permissions. Some access control systems are online, where a reader can use some means to communicate with the access control system. In an online system, the access permissions are typically a reference identifier. Other access control systems are offline, and the access permissions are encoded as data that can be decoded and interpreted by an offline lock to retrieve the access permissions. An example is a hotel locking system where the front desk encodes guest cards, and an offline battery-powered lock on a guest room door has a means for decoding the key fob and allowing or denying access based on the encoded access permissions. Some methods of encoding access permissions include sequencing, where subsequent access permissions have a sequence number greater than previous access permissions.

[0005] Some access control systems have utilized means other than physical key fobs to communicate with the lock, such as through audio tones from a mobile device, where there is also a separate method of indicating access privileges that is different from the data on the key fob. Such systems are partially effective because a person can unlock the lock by either method. However, these systems do not allow the use of ubiquitous physical key fobs with mobile devices because of the separate methods used to indicate access privileges (where the lock cannot determine which access privilege is sequenced before another access privilege). The advantage of using virtual card data is that no synchronization is required between different systems used to indicate access privileges, and the lock can have a unified audit trail.

[0006] Conventional hotel lock systems utilize encryption (i.e., AES, RSA, ECC, etc.) to perform cryptographic operations in order to verify digital credentials and encrypt / decrypt / verify data in these credentials. Encryption can be used to authenticate physical or virtual cards that are passed to the lock via near field communication (NFC) or Bluetooth. The lock requires that the encryption key be programmed before entering service, or occasionally changed as part of normal encryption key management. The management of these encryption keys and the configuration of the lock require programming devices and programming operations in order to configure locks and encryption keys dedicated to hotel properties or dedicated to being put into use. Another conventional encryption operation is to preload encryption keys in the factory and preconfigure the lock for the property before being put into use. SUMMARY OF THE INVENTION

[0007] An access control system according to one disclosed non-limiting embodiment of the present disclosure includes: a credential service operable to generate an encrypted programming credential; an installer mobile application on a mobile device operable to communicate with the credential service, the installer mobile application operable to receive the encrypted programming credential from the credential service; and a credential module for the access control, the credential module operable to extract programming data from the encrypted programming credential, the programming data being usable to program the access control.

[0008] Another embodiment of the present disclosure includes wherein the credential module is operable to decrypt and verify the encrypted programming credentials.

[0009] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein the programming data is operable to set a lock encryption key.

[0010] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein the programming data is operable to roll the lock encryption key.

[0011] Another embodiment of any of the foregoing embodiments of the present disclosure includes: it further includes decrypting and extracting the programming data.

[0012] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein the programming data is identical to the card metadata physically encoded on the physical key card.

[0013] Another embodiment of any of the foregoing embodiments of the present disclosure includes: wherein the mobile device includes a smart phone.

[0014] A further embodiment of any of the foregoing embodiments of the present disclosure includes wherein the access control is a lock.

[0015] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein the mobile device includes a mobile application used by hotel maintenance.

[0016] A further embodiment of any of the foregoing embodiments of the present disclosure includes wherein the access control is a lock.

[0017] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein the mobile device comprises a key fob.

[0018] A further embodiment of any of the foregoing embodiments of the present disclosure includes wherein the access control is a lock.

[0019] A method for managing encryption of a mobile device, the method according to another disclosed non-limiting embodiment of the present disclosure includes: downloading an encrypted mobile credential to the mobile device; transmitting the encrypted programming credential to a credential module in an access control; decrypting and verifying the encrypted programming credential; extracting programming data from the encrypted programming credential; and transmitting the programming data from the credential module to program the access control.

[0020] A further embodiment of any of the foregoing embodiments of the present disclosure includes setting a lock encryption key in response to the programming data.

[0021] Another embodiment of any of the foregoing embodiments of the present disclosure includes rolling the lock encryption key in response to the programming data.

[0022]

[0013] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein downloading the encrypted programming credentials to the mobile device includes downloading the encrypted programming credentials to a smartphone.

[0023]

[0013] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein downloading the encrypted programming credentials to the mobile device includes downloading the encrypted programming credentials to a key fob.

[0024] A method for managing credentials of a mobile device, according to another disclosed non-limiting embodiment of the present disclosure, includes: downloading encrypted programming credentials and encrypted mobile credentials to the mobile device; transmitting the encrypted programming credentials to a credential module in an access control; decrypting and verifying the encrypted programming credentials; extracting programming data from the encrypted programming credentials; transmitting the programming data from the credential module to program the access control; after transmitting the programming data from the credential module to program the access control, transmitting the encrypted mobile credentials to the credential module in the access control; decrypting and verifying the encrypted mobile credentials; extracting virtual card data from the encrypted mobile credentials; and transmitting the virtual card data from the credential module to operate the access control as a "virtual card read".

[0025] A further embodiment of any of the foregoing embodiments of the present disclosure includes setting a lock encryption key in response to the programming data.

[0026] Another embodiment of any of the foregoing embodiments of the present disclosure includes rolling the lock encryption key in response to the programming data.

[0027] Another embodiment of any of the foregoing embodiments of the present disclosure includes wherein the encrypted mobile credential includes an access category in addition to the mobile credential having the virtual card data for a specific access control.

[0028] The foregoing features and elements may be combined into various combinations without exclusivity, unless otherwise expressly indicated. These features and elements and their operation will become more apparent from the following description and accompanying drawings. However, it should be understood that the following description and accompanying drawings are intended to be exemplary in nature and are non-restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Various features will become apparent to those skilled in the art from the detailed description of the following disclosed non-limiting embodiments. The drawings accompanying the detailed description can be briefly described as follows:

[0030] Figure 1 It is a general schematic system diagram of the user authentication system;

[0031] Figure 2 is a block diagram of a user authentication system;

[0032] Figure 3 is a flow chart of a credential management method performed by a user authentication system;

[0033] Figure 4 is a flow chart of a credential management method performed by a user authentication system according to one disclosed non-limiting embodiment;

[0034] Figure 5 is a schematic diagram of a voucher according to another disclosed non-limiting embodiment;

[0035] Figure 6 is a schematic diagram of a lock initialization method according to another disclosed non-limiting embodiment; and

[0036] Figure 7 is a schematic diagram of a lock initialization method according to another disclosed non-limiting embodiment. DETAILED DESCRIPTION

[0037] Figure 1 An access control system 10 is schematically shown. The system 10 generally includes: a mobile device 12, a server 14, and a plurality of access controls 16 (which are schematically shown as 16a, 16b, ..., 16n). It should be understood that although specific systems are defined separately in the schematic block diagram, each or any of the systems may be further combined or separated by hardware and / or software.

[0038] The mobile device 12 is a handheld device (such as a smart phone) with wireless communication capabilities that is operable to communicate with the server 14 and the access control 16. The server 14 may provide the mobile device 12 with credentials and other data, such as firmware or software updates to be transmitted to one or more access controls 16. Although the server 14 is described herein as a single device, it should be understood that the server 14 may alternatively be embodied as a plurality of systems from which the mobile device 12 receives credentials and other data.

[0039] Each access control 16 is a device with wireless communication capability, limited access, or limited use, such as a wireless lock, an access control reader for a building entrance, an electronic banking control, a data transfer device, a key distributor device, a tool distribution device, and other limited use machines. The mobile device 12 submits the credentials to the access control 16, thereby selectively allowing the user to enter or activate the function of the access control 16. For example, a user can submit the credentials to an electromechanical lock to unlock it and thereby gain access to a restricted area. In another example, a user can submit the credentials to an electronic banking control in order to withdraw funds. In another example, a user can submit the credentials to a unit that assigns data associated with the credentials to a key card or data retrieved from the credentials. The mobile device 12 can store credentials for one or all or other instances of the above, and can also store multiple credentials for each type of application at the same time. Some credentials can be used for multiple access controls 16. For example, multiple electronic locks in a facility can respond to the same credentials. Other credentials can be dedicated to a single access control 16.

[0040] refer to Figure 2 , a block diagram of an exemplary electronic lock system 20 includes an access control 16a, a mobile device 12, and a server 14. The access control 16a generally includes: a lock actuator 22, a lock controller 24, a lock antenna 26, a lock transceiver 28, a lock processor 30, a lock memory 32, a lock power supply 34, a lock card reader 90, and a credential module 36. The access control 16a is responsive to credentials from the mobile device 12, and may be, for example, a lock of a lock box, a door lock, or a lock cylinder. Although the present disclosure is primarily concerned with credentials for access control, it should be understood that other systems will benefit from it, in which credentials are transmitted from a mobile device to the access control in order to identify a user of an online system, or to verify a user's access rights or permissions in an offline system. Such systems include virtual or electronic banking systems, machine operating systems, distribution systems, and data access systems.

[0041] The lock controller 24 commands the lock actuator 22 to lock or unlock the mechanical or electronic lock upon receiving and verifying the appropriate credentials from the mobile device 12 using the credential module 36, or after receiving card data from the lock card reader 90. The lock controller 24 and the lock actuator 22 may be parts of a single electronic or electromechanical locking unit, or may be components that are sold or installed separately.

[0042] The lock transceiver 28 is capable of transmitting data to and receiving data from at least the mobile device 12. For example, the lock transceiver 28 may be a near field communication (NFC), Bluetooth, or Wi-Fi transceiver, or another suitable wireless transceiver. The lock antenna 26 is any antenna suitable for the lock transceiver 28. The lock processor 30 and the lock memory 32 are a data processing device and a storage device, respectively. For example, the lock processor 30 may be a microprocessor that may process instructions to verify card data and determine access rights contained in the card data, or pass a message from the transceiver to the credential module 36, and receive a response indication with card data returned from the card credential module 36. The lock memory 32 may be a RAM, EEPROM, or other storage medium, wherein the lock processor 30 may read and write data including, but not limited to, lock configuration options and a lock check trace. The lock check trace may be a unified check trace that includes events initiated by accessing the lock via the lock reader 90 or the mobile device 12. The lock power supply 34 is a power source, such as a line power connection, a power scavenging system, or a battery that powers the lock controller 24. In other embodiments, the lock power supply 34 may only power the lock controller 24 , with the lock actuator 22 being powered primarily or entirely by another source, such as user action (eg, turning a bolt).

[0043] The credential module 36 is in communication with the lock processor 30 and is operable to decrypt and verify the credential to extract the virtual card data to be transmitted to the lock controller 24 as a "virtual card read." That is, the access control 16a basically has two readers, one reader 90 for reading the physical key card 92; and the credential module 36 for communicating with the mobile device 12 through the lock processor 30 and the transceiver 28 and antenna 26.

[0044] Although the figure shows the lock antenna 26 and transceiver 28 connected to the processor 30, this is not limiting that other embodiments may have additional antennas 26 and transceivers 28 directly connected to the credential module 36. The credential module 36 may include the transceiver 28 and antenna 26 as part of the credential module. Or the credential module 36 may have a transceiver 28 and antenna 26 separate from the processor 30, which also has a separate transceiver 28 and antenna 26 of the same type or a different type. In some embodiments, the processor 30 may route communications received through the transceiver 28 to the credential module 36. In other embodiments, the credential module may communicate directly with the mobile device 12 through the transceiver 28.

[0045] The mobile device 12 generally includes: a key antenna 40, a key transceiver 42, a key processor 44, a key memory 46, a GPS receiver 48, an input device 50, an output device 52, and a key power supply 54. The key transceiver 42 is a transceiver of a type corresponding to the lock transceiver 28, and the key antenna 40 is a corresponding antenna. In some embodiments, the key transceiver 42 and the key antenna 40 can also be used to communicate with the server 14. In other embodiments, one or more separate transceivers and antennas can be included to communicate with the server 14. The key memory 46 is a type used to store multiple credentials locally on the mobile device 12. In other embodiments, the mobile device 12 communicates with the server 14 at the same time as it communicates with the access control 16a. This is an online configuration, and in this embodiment, the mobile credentials are retrieved in real time and passed to the credential module 36 without first being stored in the key memory 46 on the mobile device 12.

[0046] refer to Figure 3, a method 100 for facilitating the transmission of a credential representing data that would normally be physically encoded on a key fob 92 is to retrieve (step 110) the data in digital form, encapsulate the data in an encrypted credential (step 112), download the encrypted credential to the mobile device 12 (step 114), securely pass the encrypted credential to the credential module 36 (step 116), the credential module 36 decrypts and verifies the credential (step 118), extracts the virtual card data (step 120), and then passes the virtual card data to the lock controller 24 as a "virtual card read" (step 122). For example, as will be further described, this would allow a user to bypass the front desk of a hotel and directly enter their room. The server 14 may generate the encrypted credential using well-known techniques for digital credential creation and encryption, using cryptographic algorithms such as AES, ECC, RSA, etc. For example, the credential may include, but is not limited to, including a credential identifier, parameters indicating the type or format of the credential, it may include encrypted data such as virtual card data, and it may include a digital signature. The encrypted data may be encrypted by an AES-128 encryption key that may be known to the credential module 36. Alternatively, it may be encrypted by a derived encryption key that may be determined from information contained in the credential. Additionally, the digital signature may be a CBC-MAC type signature based on an AES-128 encryption key that may be known to the credential module 36, for example. Alternatively, it may be a digital signature based on a private key known to the server 14 and verifiable by a public key known to the credential module 36.

[0047] refer to Figure 4 , an example of bypassing the front desk method 200 is initiated by a user who first reserves a hotel room through any process supported by the hotel (such as mobile reservation, website, travel agency, etc.) (step 210). Afterwards, the check-in process confirms their check-in (step 212). Again, this can be performed through any process supported by the hotel.

[0048] Next, based on the guest preferences (or room selections) and room availability at the time of check-in, a room is assigned in the hotel property management system 60 (step 214). The hotel property management system 60 may use a software-to-software application programming interface (API) provided by the front desk application 62 to request the card data in digital form (step 216). The front desk application 62 may range from a stand-alone encoder 64 to a complete software package running in the cloud that is operable to encode a virtual card for the selected room and return the virtual card data to the hotel system (step 218).

[0049] Next, after the hotel system has authenticated the user and has assigned a room check-in reservation, the hotel property management system 60 will make another software-to-software API call (step 220) to the credential service 70. Relevant information is transmitted to the credential service 70, where the indication includes, for example, what hotel property, what room, what guest (e.g., user ID), what date, and also the virtual card data for the check-in.

[0050] Simultaneously or sequentially sending the virtual card data to the credential service 70, the hotel property management service 60 transmits instructions to the user (again by any conventional method) confirming the check-in and assigning a room (step 222).

[0051] Next, the hotel loyalty mobile application 80 based on the mobile device 12 will utilize the software-to-software API in the mobile library 82 (step 224) to download the credentials from the credential service 70 (step 226). The mobile library 82 will securely authenticate the credential service 70 through a previously established shared secret that can be changed on each successful connection.

[0052] Once authenticated, the credential service 70 generates a credential for the user when communicating from the mobile library 82, and encrypts the virtual card data received in step 220 into the credential for the guest associated with this mobile library instance. A credential is generated for each door or access point, and the virtual card data will be the same in each of these individual credentials, but can be encrypted for a specific door or access point by a unique key. The encryption method can be AES, 3DES, or other such encryption methods. The method and type of credential used can be a compressed digital credential or a standard-based credential (such as X.509) or other credential formats known in the art. That is, for example, the virtual card data is encrypted into the credential by a unique key known to the credential module 36 and the credential service 70.

[0053] The mobile library 82 will download the credential list and store it on the mobile device 12 using native OS protection and additional encryption of data with device specific information (e.g., UDID, IMEI, IMSI, MAC address, etc.). Now that the sign-in is complete and the encrypted mobile credentials (with virtual card data) reside on the mobile device 12 ( Figure 2 ), the user can operate the access control 16 in an offline mode at any time later without connecting the mobile device 12 to the credential service 70. For example, additional embodiments can cause the mobile device 12 to download credentials at the same time as the user wishes to enter their room while the mobile device is communicating with the access control 16.

[0054] When the user wishes to enter their room (step 228), the user indicates this intent through a gesture, a click of a button, a tap on a screen, a fingerprint read, a password, a proximity lock, a touch lock, etc. In response to this intent, the hotel loyalty mobile application 80 again calls the software-to-software API in the mobile library 82 to initiate a secure transfer of the encrypted mobile credentials to the entry controller 16 (step 230). When the loyalty application 80 initiates the transfer, the mobile library implements the secure transfer in the next step respectively.

[0055] The secure transfer of credentials (step 232) can begin with the mobile library 82 listening for signal announcements (such as Bluetooth Low Energy (BTLE) announcements) from access controls 16 within range. That is, the access control 16 announces its presence at a periodic rate through announcement data indicating an identifier of the access control 16, and the mobile device 12 can automatically listen and connect without the person having to press a button to wake up a sleeping battery-powered lock 16, or leave the vehicle to interact with a card reader access point on a garage door or other device. A card reader access point is another type of lock 16. Another embodiment is to use near field communication (NFC), and the person 'taps' their mobile device to the lock 16, and the secure credential exchange transfers the mobile credentials to the access control 16 (step 232). The secure credential exchange can be accomplished using standard techniques, such as establishing session keys, encrypting communication messages, and verifying the authenticity of the message transmitter and receiver.

[0056] In a preferred embodiment where the access control uses Bluetooth Low Energy (BTLE) for notifications, the mobile library 82 filters the received notifications based on the received identifier of the access control 16 and by comparing with the identifier contained in or associated with each credential in the mobile credential list, and based on the user's intent to enter a particular room. Once the notification for the target access control 16 is received, the mobile library 82 initiates a wireless connection and performs a secure transfer of the encrypted mobile credentials (step 232). The secure transfer can utilize a unique session encryption key and standard encryption algorithms and techniques. It should be understood that data can be securely transmitted over any wireless link (including but not limited to BTLE, zigbee, near field communication, etc.).

[0057] The credential module 36 will receive the encrypted mobile credential and then verify and decrypt the encrypted mobile credential to retrieve the virtual card data. The decryption and verification may include, but is not limited to, verifying the digital signature, verifying the credential type, verifying that the credential identifier matches the identifier in the lock memory 32, verifying the start date and expiration date of the credential, verifying the source of the credential, etc. (step 118; Figure 3 ). Once verified and decrypted, the virtual card data is extracted (step 120; Figure 3 ).

[0058] According to an embodiment, the virtual card data is then transmitted to the lock controller 24 through a hardware and software interface, which can further decrypt the virtual card data, process the data based on the lock vendor rules, and then unlock the lock if access is allowed (step 234). Notably, the virtual card data is transmitted to the lock controller 24 as a "virtual card read" in a data format equivalent to the physical key card data format. Therefore, this allows the continued use of a traditional guest key card 92 (such as a traditional guest key card 92 of a family member, or a guest who only wants a copy of the physical key card 92), as well as the use of the mobile device 12 at the same time.

[0059] The audit trail uploaded by the mobile device 12 may be just the audit generated by the mobile device 12 itself, or may be a unified audit that includes the openings made by the guest using the physical key card. In addition, when the lock 16 is opened, the battery status or other maintenance information thereof may be uploaded to the audit trail from the mobile device 12 to the credential service 70 so that the hotel may be notified of low battery conditions and proactively replace the battery, or perform other maintenance. Other information associated with the audit trail may include, for example, failed openings or failed attempts or failed credentials for verification.

[0060] The use of "virtual card reading" maintains a continuous audit trail and also maintains all known use cases for access control that have been encoded into traditional card data. In addition, the credential module 36 is agnostic to the lock vendor so that the data of any lock vendor can be passed through to allow each lock vendor to independently innovate the card data. In addition, the credential module 36 can be supplied by a different company from the lock 16. And in addition, in addition to the card data as a data object to be encoded, encrypted, transferred, retrieved and delivered, the server 14, the mobile device 12 and the credential module 36 may not have a method for further decrypting or verifying the card data. In addition, the "virtual card reading" can be used offline without the need for the mobile device 12 to connect to the credential service online through a Wi-Fi connection or a real-time connection. That is, the data of the "virtual card reading" is stored on the mobile device 12 and securely passed to the credential module 36 in an offline mode. This is not to limit the ability to send the "virtual card reading" in addition in the online mode. An additional benefit is that in addition to using the credential module 36, any access control 16 can use any card type, where the card type includes but is not limited to magnetic stripe, RFID, Proximity, etc.

[0061] In another disclosed non-limiting embodiment, the credential module 36 can be used for many purposes, including but not limited to passing data to a self-service hard key dispenser unit 98 that generates a physical key fob 92. The hard key dispenser unit 98 has a credential module 36 that receives virtual card data, decrypts, extracts, and sends the virtual card data to a lock controller 24 that is configured to encode the data onto a physical key fob 92. That is, the virtual card data on the mobile device 12 is written to the physical key fob 92 by the unit 98, and the key fob 92 is dispensed in an automatic manner. The unit 98 does not require any user interface other than the dispensing elements for the key fob 92 and the unit power source (including but not limited to batteries, mains power, energy harvesting, etc.). The user interface of the unit 98 is actually the interface of the mobile device 12. When the unit 98 begins to run low on a blank key fob 92, the mobile device 12 can upload a status indication to the credential server 70, which can become a report to the hotel notifying the hotel that the unit 98 needs to be refilled.

[0062] In other disclosed non-limiting embodiments, the virtual card data can be standard access control card data (i.e., identification data) used to mark entry into a system or be integrated into a vending machine, where the virtual card data serves as credit card information, a token, a purchase reference identifier, etc.

[0063] refer to Figure 5 In addition to mobile credentials with virtual card data (explicit permissions) 302 generated by the credential service 70 for a specific access control 16a, the mobile library 82 may include a collection of mobile credentials generated by the credential service 70 based on access categories 300 (implicit permissions). Access categories 300 operate to grant users access to specific groups of access controls 16b that have collective significance. For example, one access category may be access to a swimming pool, business center, elevator, and 'public rooms' for wall readers. In the context of a hotel reservation, when the mobile device 12 communicates with the credential service 70 to download an encrypted mobile credential, the credential service 70 generates a credential for each lock in one or more access categories to which the guest has been granted access. Thus, the encrypted mobile credential will have the same virtual card data specifically encoded for each designated access point (e.g., swimming pool, business center, etc.), and may optionally be downloaded in the credential or by the credential to access the category. However, each mobile credential will be individually encrypted by a unique key for each access control 16b.

[0064] The provision and use of the access categories 300 by the credential service 70 facilitates efficient management of multiple access controls 16b in a system where a mobile device 12 can open multiple locks with specific credentials for each lock. This is simpler than what is conventionally required, such as two access control systems - one for the hotel system to generate virtual card data through all current techniques for the hotel system access business rules; and another access control system for granting access to each access point through mobile credentials, such as guest rooms, wall readers, swimming pools, business lounges, etc. In other words, the business rules for the hotel system need to be repeated in the credential service.

[0065] The entry categories 300 allow for multi-vendor integration and can work independently of the hotel system entry business rules encoded into the virtual card data. Thus, the mobile credential is an additional security 'layer' on top of the virtual card data. The entry categories 300 also allow for relatively simpler maintenance procedures, for example, when a lock in a 'public' entry category is replaced, the replacement lock only needs to be assigned the same entry category. However, in order to download a new set of mobile credentials, the mobile device 12 still needs to communicate with the credential service 70 again. Other than including the replacement lock in the correct entry category, no further management is required on the part of the guest or system, and all guest permissions will continue to work seamlessly without modification even if the new lock has a unique encryption key from the previous lock.

[0066] refer to Figure 6 In another disclosed non-limiting embodiment, the lock initialization method 400 is initiated by an administrator who inputs a lock initialization request (e.g., setting a lock encryption key) into the hotel property management system 60, or a lock update request (e.g., rolling a lock encryption key) into the hotel property management system 60. It should be understood that the method 300 is not limited to hotels and can be easily extended to various access control systems.

[0067] Initially, the administrator creates a new property or imports the new property into the hotel property management system 60 (step 410). A part of this property creation process includes that the hotel system 60 calls software to the software application programming interface (API) to distribute or retrieve the associated hotel ID in the voucher service 70, which can be used to link the hotel ID of the voucher service 70 to the property ID of the hotel property management system 60 (step 420). The voucher service 70 distributes or creates a link between the property ID and the hotel ID (step 430). Therefore, in this specification, the hotel ID and the property ID can be used interchangeably, because the voucher service 70 or the hotel property management system 60 can retrieve the association and determine another according to one. In one embodiment, the administrator can transmit this hotel ID to the installer, and the installer can import the hotel ID into the application on the mobile device 12 (step 440). An alternative embodiment is to download the hotel ID associated with the installer's account after the application on the mobile device 12 is authenticated for the voucher service 70.

[0068] Next, the installer associates the credential module 36, and by association, the lock 16, and by association, the serial number of the credential module 36 is associated with the associated hotel ID in the credential service 70 (step 450). In addition, the serial number can be specifically assigned to the room or entry category as described above. This assignment can be performed by scanning a QR code to detect the serial number (based on active detection of BTLE signals) when the lock 16 is in a specific mode and the BTLE advertising characteristics reflect the mode to distinguish one lock 16 from another lock 16; and / or by reading or scanning a label on the lock 16 or credential module 36 (step 460). Alternatively, the serial number is generated in the credential module 36 or lock 16 at the time of installation. In all cases, the application on the mobile device 12 obtains the serial number of the lock 16 and the credential module 36, and assigns it to the hotel ID and uploads it to the credential service 70 (step 470).

[0069] Now, the credential service 70 has the relevant information (e.g., the serial number and hotel property ID in this example) to create an encrypted programming credential in real time and download it in the same session when uploading the assignment (step 470). The encrypted programming credential contains programming data for programming the encryption key of a specific lock, such as a specific AES-128 key of a property, a MiFare Plus encryption key dedicated to the property, and / or an RSA / ECC encryption key for trusted authorization verification. The specific encryption key in the programming credential may be associated with a specific hotel ID. Alternatively, it can be randomly assigned. Alternatively, the encryption key can be preconfigured to be loaded into this device serial number. The above example assigns lock 16 to the hotel ID uploaded to the credential service 70 by the mobile device 12. An alternative embodiment is to preconfigure the association of lock 16 with the hotel ID through a separate interface in the hotel property management system 60, which can use a software API to transmit the association to the credential service 70.

[0070] The programming credentials are now encrypted and contain the new encryption key for the credential module 36, as well as the mobile application downloaded to the mobile device 12. In one embodiment, the mobile application is the same installer application used to detect the lock serial number when in the vicinity of the lock. Alternatively, the application can be a separate mobile application used by hotel maintenance personnel, or a hotel guest mobile phone application such as the application described above.

[0071] As described above, upon receiving the appropriate BTLE advertisement (step 460), the installer mobile application initiates a wireless connection with the lock and performs a secure transfer of the encrypted programming credentials (step 480). Additionally, as part of this step, the credential module 36 will receive the encrypted programming credentials and then decrypt and verify the encrypted programming credentials in order to retrieve the programming data. Once verified and decrypted, the programming data is extracted and the credential module 36 and lock 16 are initialized thereby (step 480).

[0072] While the above description describes a BTLE exchange, the presentation of the encrypted programming credentials to the lock may be performed via a secure peer-to-peer wireless communication session between the mobile device and the lock, or using Host Emulation (HCE) via an NFC-enabled smartphone to present the programming credentials as a virtual MiFare card, through various communication protocols (i.e., Bluetooth, BTLE, IrDA, Wi-Fi, Wi-Fi Direct, NFC peer, NFC reader / writer, etc.). Additionally, while the preferred embodiment presents the programming credentials to the lock 16 via an authenticated and encrypted communication means, the programming credentials are constructed in encrypted form and may be presented to the lock without an encrypted or authenticated link without compromising the security of the programming credentials. The credential module 36 is capable of determining the validity of the programming credentials independently of the device that communicates the credentials to the lock.

[0073] Once the lock is programmed, maintenance personnel can use the mobile application to further authenticate the lock and configure lock parameters such as real-time clock time, BTLE transmit power, BTLE advertising rate, etc. In addition, the encryption key in the lock 16 can be rolled periodically, where additional encrypted programming credentials are created and delivered to the mobile application on the mobile device 12 in order to update the lock. For example, such rolling can be accomplished by using a technician to communicate with each lock in the hotel, or the programming credentials can be downloaded to the guest phone 12 without the guest's awareness, and the normal guest activity of opening the lock 16 will present the programming credentials and thus roll the key.

[0074] refer to Figure 7 In another disclosed non-limiting embodiment, the key fob 92 can be used to transfer encrypted programming credentials to configure the lock. That is, the hotel guest transmits the encrypted programming credentials via the key fob 92. In this embodiment, the first guest attempting to access the lock 16 transmits the encrypted programming credentials to configure the lock, and then transmits the conventional card data ( Figure 4 ) to operate the access control 16. The lock reads the key fob, first processes the encrypted programming credentials, and then reads the rest of the key fob data for subsequent processing. It should be understood that there are various ways to accomplish this on the key fob, such as through separate sectors, separate data elements, and / or a multi-application smart card. A standard hotel card encoder can create this physical implementation, which is updated to encode the remote programming data on the key fob.

[0075] Alternatively, the key card 92 can be a 'master card' used by maintenance or cleaning staff (rather than guests), or it can be a regular guest card. In either case, the encrypted programming credentials are stored on the key card alone, or in addition to the mobile credentials, together with the virtual card data stored on the key card. Thus, the method 400 allows the lock to be configured without the need for maintenance personnel to physically access each specific lock, and the lock does not need to be pre-programmed for use in the hotel. In addition, since guests, hotel cleaning staff, etc. can transparently configure the lock by interacting with other 'normal' with the lock, there is no need for hotel or lock-specific encryption keys, so there is no need to establish a specific programming program for each lock in the hotel.

[0076] The elements described and depicted herein, including the flowcharts and block diagrams throughout the drawings, imply logical boundaries between the elements. However, according to software or hardware engineering practices, the depicted elements and their functions may be implemented on a machine as an integral software structure, as an independent software module, or as a module using external routines, codes, services, etc., or any combination of these, through a computer-executable medium having a processor capable of executing program instructions stored thereon, and all such implementations may be within the scope of the present disclosure.

[0077] The use of the terms "a," "an," "the," and similar references in the context of the description (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or specifically negated by context. The modifier "about" used in conjunction with a quantity is inclusive of the stated value and has the meaning dictated by the context (e.g., the modifier includes the degree of error associated with measurement of the particular quantity). All ranges disclosed herein are inclusive of the endpoints, and the endpoints are independently combinable with each other.

[0078] Although different non-limiting embodiments have specifically shown components, embodiments of the invention are not limited to those specific combinations. It is possible to use some of the components or features from any non-limiting embodiment in combination with features or components from any other non-limiting embodiment.

[0079] It should be understood that throughout the several drawings, like reference numerals identify corresponding or similar elements. It should also be understood that although a particular component arrangement is disclosed in the illustrated embodiments, other arrangements will benefit therefrom.

[0080] Although a particular order of steps is shown, described, and claimed, it should be understood that the steps may be performed in any order, separate or combined unless otherwise indicated, and will still benefit from the present disclosure.

[0081] The foregoing description is exemplary and not limited by the limitations therein. Various non-limiting embodiments are disclosed herein, however, one of ordinary skill in the art will appreciate that various modifications and variations in accordance with the above teachings will fall within the scope of the appended claims. Therefore, it should be understood that within the scope of the appended claims, the present disclosure may be practiced in a manner other than as specifically described. Therefore, the appended claims should be studied to determine the true scope and content.

Claims

1. A method for configuring an access control device, comprising: receiving a configuration request for an access control device; creating, by a credential service, an encrypted programming credential in response to the configuration request, the encrypted programming credential including programming data for programming an encryption key of the access control device and including a new encryption key for a credential module associated with the access control device; downloading the encrypted programming credentials to a mobile device; initiating, by the mobile device, a wireless connection with the access control device to perform a secure transfer of the encrypted programming credentials; The encrypted programming credentials are received by the credential module to extract the programming data and configure the credential module accordingly.

2. The method of claim 1, further comprising: The encrypted programming credentials are decrypted and verified by the credential module prior to extracting the programming data.

3. The method of claim 1, wherein: The programming data is identical to the card metadata physically encoded on the physical key card.

4. The method of claim 1, wherein: The mobile device comprises a smart phone.

5. The method of claim 1, wherein: The mobile device includes a mobile application used by hotel maintenance.

6. The method of claim 1, wherein: The mobile device includes a key fob.

7. The method according to any one of claims 1 to 6, wherein: The access control device is a lock.

8. The method of claim 7, wherein: The programming data is operable to set a lock encryption key.

9. The method of claim 7, wherein: The programming data is operable to roll a lock encryption key.

10. The method of claim 7, wherein: The configuration request includes one of a lock initialization request and a lock update request.

11. The method of claim 1, wherein: The mobile device has a memory storing a mobile library, wherein the step of downloading the encrypted programming credentials onto the mobile device further comprises: the mobile library securely authenticating the credential service, and the mobile library downloading and storing the encrypted programming credentials.

12. An access control system comprising: an access control device having an associated credential module; a credential service operable to create an encrypted programming credential in response to receiving a configuration request for the access control device, the encrypted programming credential comprising programming data for programming an encryption key for the access control device and including a new encryption key for the credential module; as well as a mobile device operable to download the encrypted programming credentials from the credential service; wherein the mobile device is further operable to initiate a wireless connection with the access control device to perform a secure transfer of the encrypted programming credentials, and Therein, the credential module is operable to receive the encrypted programming credentials to extract the programming data and thereby configure the credential module.

13. The system of claim 12, wherein: The credential module is further operable to decrypt and verify the encrypted programming credentials prior to extracting the programming data.

14. The system of claim 12, wherein: The programming data is identical to the card metadata physically encoded on the physical key card.

15. The system of claim 12, wherein: The mobile device comprises a smart phone.

16. The system of claim 12, wherein: The mobile device includes a mobile application used by hotel maintenance.

17. The system of claim 12, wherein: The mobile device includes a key fob.

18. The system of any one of claims 12 to 17, wherein: The access control device is a lock.

19. The system of claim 18, wherein: The programming data is operable to set a lock encryption key.

20. The system of claim 18, wherein: The programming data is operable to roll a lock encryption key.

21. The system of claim 18, wherein: The configuration request includes one of a lock initialization request and a lock update request.

Images