(19)
(11)EP 3 591 554 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
09.09.2020 Bulletin 2020/37

(21)Application number: 19181073.8

(22)Date of filing:  10.07.2015
(51)International Patent Classification (IPC): 
G06F 21/34(2013.01)
H04L 29/06(2006.01)
H04W 12/08(2009.01)
G07C 9/00(2020.01)

(54)

NETWORKED ACCESS CONTROL SYSTEM

VERNETZTES ZUGRIFFSKONTROLLSYSTEM

SYSTÈME DE CONTRÔLE D'ACCÈS EN RÉSEAU


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 10.07.2014 US 201462023079 P

(43)Date of publication of application:
08.01.2020 Bulletin 2020/02

(62)Application number of the earlier application in accordance with Art. 76 EPC:
15819302.9 / 3167402

(73)Proprietor: Schlage Lock Company LLC
Indianapolis, IN 46219 (US)

(72)Inventors:
  • NEAFSEY, Jeffrey, Scott
    Arvada, CO Colorado 80007 (US)
  • BAUMGARTE, Joseph, Wayne
    Carmel, IN Indiana 46033 (US)
  • DEXTER, Matthew
    Indianapolis, IN Indiana 46259 (US)
  • HARROLD, Ed
    Brooksville, FL Florida 34605 (US)

(74)Representative: Ganguillet, Cyril et al
ABREMA Agence Brevets & Marques Ganguillet Avenue du Théâtre 16 P.O. Box 5027
1002 Lausanne
1002 Lausanne (CH)


(56)References cited: : 
US-A1- 2010 141 381
US-A1- 2012 213 362
US-A1- 2011 311 052
US-A1- 2012 222 103
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    CROSS-REFERENCE TO RELATED APPLICATIONS



    [0001] The present application claims the benefit of U.S. Provisional Patent Application No. 62/023,079 filed July 10, 2014.

    BACKGROUND



    [0002] Security management systems often utilize hardware such as, for example, electronic lock devices, to control the ingress and/or egress through an entryway. Often the operation of such lock devices requires that a static encryption key or code be transmitted to, and/or detected by, the lock device. If the authenticity of the static encryption key is verified, authorization may be granted for the displacement of a locking mechanism of the lock device from an unlocked and/or locked position so that the associated entryway barrier such as, for example, a door or gate, may be displaced to/from open and/or closed position(s).

    [0003] However, reliance on static encryption keys or codes may compromise the effectiveness of the security system. For example, static keys are susceptible of being obtained through illicit means and/or by unauthorized users via networking hacking techniques including, for example, man-in-the-middle, relay, and replay style active eavesdropping and attacks. Moreover, as the same static encryption key may be repeatedly transmitted and/or continuously used to operate and/or configure the lock device, use of static encryption keys may provide more opportunities for the static encryption key to be hijacked. Further, unauthorized operation of a lock device using a hijacked, but authentic, static encryption key code may be relatively difficult to detect.

    [0004] The documents US 2012/222103, US 2011/311052, US 2010/141381 and US 2012/213362 are also considered relevant prior art.

    BRIEF SUMMARY



    [0005] An aspect of embodiments of the current invention is a method for controlling a network access control system having a server, a mobile device, and a lock device. The method includes encrypting, by the server, a first identifier associated with a registered user of the mobile device and communicating the encrypted first identifier to the mobile device. The lock device receives, from the mobile device, a first data set that includes at least the encrypted first identifier. The method also includes encrypting, by the lock device, at least the received first data set to generate a second data set and communicating the encrypted second data set from the lock device to the mobile device. The server receives, from the mobile device, a third data set that includes at least the encrypted second data set and a second identifier, the second identifier being associated with a registered user of the mobile device. The server extracts from the communicated third data set the first and second identifiers, and the extracted first and second identifiers are compared to verify that the second identifier is related to the first identifier.

    [0006] Another aspect of embodiments of the present invention is a method for controlling a network access control system having a server, a mobile device, and a lock device that includes installing on the lock device an encryption key and communicating to an application on the mobile device an encrypted application token, the encrypted application token including a first identifier. The method also includes the lock device receiving, from the application, the encrypted application token. The lock device further encrypts at least the communicated encrypted application token using the using the assigned encryption key to generate lock encrypted data. The lock encrypted data is communicated from the lock device to the application. The method further includes the server receiving the lock encrypted data and a second identifier from the mobile device and a second identifier, with the first and second identifiers being related to each other. Using the assigned encryption key, the server decrypts the lock encrypted data to extract the encrypted application token and the second identifier. The server also decrypts the extracted encrypted application token to extract the first identifier, and verifies that the extracted first identifier is related to the extracted second identifier. The method further includes encrypting, based verification of the first and second identifiers are similar and using the assigned encryption key, lock capture data that includes a first key for decrypting the encrypted application token. Additionally, the lock device may decrypt the lock capture data using the assigned encryption key.

    [0007] Another aspect of embodiments of the present invention is a method for controlling a network access control system having a server, a mobile device, and a lock device that includes assigning a registered user account a first key, and assigning the lock device an encryption key. The method also includes encrypting at least a first identifier related to the registered user account using the first key to generate an encrypted application token, and communicating the encrypted application key from the server to the mobile device. The lock device receives the encrypted application token and a second identifier from the mobile device, with the second identifier being related to the registered user account. Using the encryption key, the lock device encrypts the encrypted application token and the second identifier to generate lock encrypted data and communicates the lock encrypted data from the lock device to the mobile device. The server receives the lock encrypted data from the mobile device and decrypts the lock encrypted data using the assigned encryption key to extract the second identifier. The encrypted application token from the decrypted lock encrypted data is also decrypted using the first key to extract the first identifier. The method also includes comparing the extracted first and second identifiers to verify that the second identifier is related to the first identifier.

    [0008] Other aspects of the present invention will become apparent by consideration of the detailed description and accompanying drawings.

    BRIEF DESCRIPTION OF THE DRAWINGS



    [0009] 

    FIG. 1 illustrates a schematic diagram of an exemplary access control system that includes a mobile device, a lock device, and a server according to an illustrated embodiment of the present invention.

    FIG. 2 illustrates a schematic flow diagram of an exemplary process for at least initial programming of the lock device according to an illustrated embodiment of the present invention.

    FIG. 3 illustrates a schematic flow diagram of an exemplary process for at least initial set-up of the access control system according to an illustrated embodiment of the present invention.

    FIGS. 4A and 4B illustrate a schematic flow diagram of an exemplary process for capturing a lock device according to an illustrated embodiment of the present invention.



    [0010] The foregoing summary, as well as the following detailed description of certain embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings, certain embodiments. It should be understood, however, that the present invention is not limited to the arrangements and instrumentalities shown in the attached drawings.

    DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS



    [0011] FIG. 1 illustrates a schematic diagram of an exemplary access control system 100 that includes a mobile device 102, a lock device 104, and a server 106 according to an illustrated embodiment of the present invention. A variety of mobile devices 102 may be utilized including, for example, a mobile telephone, smartphone, tablet, personal computing device, and/or a proprietary hand-held device, among other devices. According to the illustrated embodiment, the mobile device 102 may have one or more transceivers 108 for communicating data with other devices, including the lock device 104 and the server 106. Additionally, a variety of different types of transceivers 108 may be used including, for example, active and passive transceivers that may communicate via Bluetooth (including Bluetooth low energy) and/or WIFI. The mobile device 102 may also include an input/output device 110 such as, for example, a keypad, display, and/or touch screen among other input/output devices 110. Additionally, the mobile device may include may include one or more different processing devices 112 such as, for example, programmable, dedicated, and/or hardwired state machine types of processors, as well as any combination thereof. For example, according to certain embodiments, the processing device 112 may include multiple processors and may be of a programmable variety that executes algorithms and processes data in accordance with an operating logic 114 as defined by programming instructions (such as software or firmware) stored in a memory 116.

    [0012] The lock device 104 may be a lock, reader device, a payment terminal, and/or any other type of device that can communicate with the mobile device 102. For example, in the embodiment shown in FIG. 1, the lock device 104 is an electronic lock device having one or more transceivers 118, a processing device 120, a memory 122, and a lock mechanism 123 such as, for, example, bolt and/or latch. The memory 122 may or may not be part of the processor 120. The mobile device 102 and lock device 104 may be adapted to communicate with each other using one or more of a variety of different wireless communication technologies. For example, according to certain embodiments, the lock device 104 may have a transceiver 118 that allows for Bluetooth low energy communication between the mobile device 102 and the lock device 104. Further, according to certain embodiments, the mobile device 102 and the lock device 104 may communication via NFC and/or WIFI (such as WIFI Direct).

    [0013] A variety of different types of processing devices may be employed for the processing device 120 of the lock device 104 such as, for example, a programmable, dedicated, and/or hardwired state machine, or any combination thereof. The processing device 120 may further include multiple processors such as, for example, Arithmetic-Logic Units (ALUs), Central Processing Units (CPUs), Digital Signal Processors (DSPs), or the like. Processing devices 120 with multiple processing units may also utilize distributed, pipelined, and/or parallel processing. The processing device 120 may also be dedicated to performance of just the operations described herein or may be utilized in one or more additional applications. In the depicted form, the processing device 120 is of a programmable variety that executes algorithms and processes data in accordance with operating logic 124 as defined by programming instructions (such as software or firmware) stored in the memory 122 of the lock device 104. Alternatively or additionally, the operating logic 124 is at least partially defined by hardwired logic or other hardware. The processing device 120 may include one or more components of any type suitable to process the signals received from an input/output device 126 of the lock device 107 such as, for example, the keypad, or elsewhere, and to provide desired output signals. Such components may include digital circuitry, analog circuitry, or a combination of both.

    [0014] The memory 122 of the lock device 104 may be included with the processing device 120 and/or coupled to the processing device 120. Further, the memory 122 may be of one or more types, such as a solid-state variety, electromagnetic variety, optical variety, or a combination of these forms. Additionally, the memory 122 can be volatile, nonvolatile, or a combination of these types, and some or all of the memory 122 can be of a portable variety, such as a disk, tape, memory stick, cartridge, or the like. In addition, according to certain embodiments, the memory 122 can store data that is manipulated by the operating logic 124 of processing device 120, such as data representative of signals received from and/or sent to the input/output device 126 in addition to, or in lieu of, storing programming instructions defining the operating logic 124.

    [0015] The server 106 may include one or more servers 106a, 106b that may communicate with the mobile device 102 and/or the lock device 104 in a variety of different manners including, for example, over the Internet, a cellular data network, or any combination thereof. According to certain embodiments, at least one server 106 is a cloud-based server 106a. However, a variety of other different types of servers may also be used for the one or more servers 106 including, for example, a web-based server 106b. Further, according to certain embodiments, different servers 106 may be used for different purposes such as, for example, a cloud-based server 106a for installation, maintenance, and/or management of, or relating to, the access control system 100, lock device 104, and/or the mobile device 102, and another, different server 106 such as, for example, a web-based server 106b for other purposes such as, for example, general, day-to-day usage and/or operation of the lock device 104.

    [0016] The access control system 100 may also include an application 128 that is installed on the mobile device 102, and which processes, receives and/or stores data relating to authenticating the application 128, the mobile device 102, and/or the lock device 104. For example, according to certain embodiments, the application 128 may be used in connection with communicating information such as, for example, encrypted security and/or authentication information or data, via the mobile device 104 to/from the server 106 and the lock device 104. Further, as discussed below, the application 128, and thus the mobile device 102, may not be configured to decrypt at least certain encrypted information that is provided to the mobile device 102 from the server 106 and/or the lock device 104. It is also contemplated that the application 128 may include one or more than applications to carry out the various operations described herein.

    [0017] FIG. 2 illustrates a schematic flow diagram of an exemplary process 200 for at least initial programming of the lock device 104 such as, for example, during the manufacturing, production, and/or assembly of the lock device 104 according to an illustrated embodiment of the present invention. Steps illustrated are understood to be exemplary only, and steps may be combined or divided, and added or removed, as well as re-ordered in whole or in part.

    [0018] At step 202, firmware such as, for example, proprietary firmware used for the operation of the lock device 104 may be installed on the lock device 104, such as, on the memory 122 of the lock device 104. The lock device 104 such as, for example, the installed firmware and/or lock mechanism 123, may then be tested at step 204. At step 206, one or more lock identifiers such as, for example, a serial number for the lock device 104, among other data or information related or assigned to the lock device 104, may be recorded in the lock device 104 such as, for example, in a memory 122 of the lock device 104. Additionally, according to certain embodiments, at step 210, one or more of the lock identifiers may also be recorded in an auxiliary database 130 or other record system for a manufacturer, producer, and/or assembler of the lock device 104, as shown in FIG. 1. Additionally, one or more of the lock identifiers may also be stored, recorded, or otherwise accessible to the server 106. More specifically, according to certain embodiments, a lock identifier(s) may be recorded with, and/or otherwise accessible to, a cloud-based server 106a.

    [0019] FIG. 3 illustrates a schematic flow diagram of an exemplary process 300 for at least initial set-up of the access control system 100 according to an illustrated embodiment of the present invention. At step 302, the application 128 is installed on the mobile device 102 such as, for example, by downloading the application 128 from the server 106 (or another server such as a third party server) and subsequently installing the application 128 on the mobile device 102. At step 304, a registered user account associated with the installed application 128 may be created on the server 106 such as, for example, on the cloud-based server 106a. For example, according to certain embodiments, a registered user account may be established for at least one of the following: the mobile device 102 on which the application 128 is installed, the user(s) and/or entity associated with the mobile device 102 having the application 128, and/or one or more of the lock devices 104 associated with the application 128. Further, the registered user account may be associated with a particular institution and a plurality of lock devices 104 for that institution. Further, according to certain embodiments, access and/or control of the registered user account may be controlled through the use of a user name and password. The server 106 may also generate a first identifier (IDENT1) that is associated with the mobile device 102, lock device 104, application 128, and/or the registered user account. For example, the server 106 may generate for each lock device 104 a serial number (S/N), a production code, and/or a counter, among other identifiers that may be included in the first identifier (IDENT1). The server 106 may also, for example, generate identifiers related to the registered user account. Additionally, permission to access, manage, and/or alter settings of the lock device 104 or system 100 may be controlled through the use of authorization levels, which may be set and/or adjusted through commands sent to the server 106. For example, according to certain embodiments, by default, only users and/or particular mobile devices 102 that have a particular authorization level may be able to set, or otherwise alter, the configuration of the lock device 104 via communications from the application 128 and/or mobile device 102.

    [0020] At step 306, the server 106 may compile the one or more of the various identifiers or data generated at step 306 into one or more strings or functions to provide the first identifier (IDENT1) and encrypt the string(s) or function(s) of the first identifier (IDENTI) with a first encryption key (FK) such as, for example, an encryption key that is associated with, for example, the lock device 104, the server 106, a database 130, and/or the user account to derive an encrypted application token (AppToken). In the illustrated embodiment, the encrypted application token (AppToken) may be expressed as:



    [0021] Further, according to the illustrated embodiment, at step 308, the server 106, such as the cloud-based server 106a, may communicate at least the encrypted application token (AppToken) to the application 128 on the mobile device 102. According to the illustrated embodiment, although encrypted data may pass between the server 106 and the lock device 104 through the application 128 and associated mobile device 102, the application 128 and mobile device 102 may not be provided with encryption keys that would allow the application 128 or mobile device 102 to decrypt such information, including the encrypted application token (AppToken). Thus, according to certain embodiments, decryption of encrypted data relating to operation and/or configuration of the lock device 104 may be performed by the server 106 and/or the lock device 104, but not the application 128 and/or mobile device 102.

    [0022] FIGS. 4A and 4B illustrate a schematic flow diagram of an exemplary process 400 for capturing a lock device 104 according to an illustrated embodiment of the present invention. Although data sets are discussed below in terms being encrypted with a particular key, according to certain embodiments, the encryption key used to encrypted the data in the various data sets may be altered such as, for example, being switched with another existing key and/or be replaced by a new key. For example, according to certain embodiments, a trigger event such as, for example, the expiration of a time period, a number of communications between the application 128 and the server 106, or upon the occurrence of a particular random event, among other trigger events, may result in an alteration or change in the encryption key(s) used to encrypt one or more of the data sets. For example, upon expiration of a predetermined time period, at least an encryption key used for encrypting information or data associated with a first data set may be switched with an encryption key that is used for encryption of information or data in a second data set. Further, rather than switching keys, keys used for encryption of data sets may be subsequently replaced by new encryption keys. Additionally, according to certain embodiments, different trigger events may cause different encryption keys to be switched and/or may change the manner in which at least some of the keys are altered. For example, according to certain embodiments, the occurrence of a first trigger event, such as the expiration of a first time period, may result in the second encryption key that was being used in encrypting information or data of a second data set being switched with a third key that had been used for encrypting a third data set, while a first encryption key that was associated with encrypted information or data in a first data set may be replaced by another key such as, for example, a sixth encryption key. Further, upon the occurrence of a second trigger event such as, for example, expiration of a second time period, a fourth key that had been used for encryption of a fourth data set may be switched with the sixth key that was being used with the first data set, and the second and third keys may be replaced with fifth and seventh encryption keys, respectively.

    [0023] At step 402, the application 128 associated with a registered user account receives the encrypted application token. At step 404, the lock device(s) 104 may be installed at a desired location such as, for example, on a door, wall, and/or door frame, among other locations. At step 406, the lock device 406 may receive power from a power source. Power may be provided to the lock device 104 in a number of manners, including, for example, by an internal power source, such as, for example a battery operably secured to and/or in the lock device 104, and/or from a power source that is external to the lock device 104.

    [0024] At step 408, an attempt may be undertaken to establish communication between the lock device 104 and the mobile device 102, and thus the application 12. Communication between the lock device 104 and the mobile device 102 may be established in a number of different manners. For example, according to the illustrated embodiment, using at least the transceiver 108 of the mobile device 102, the application 128 may request communication with the lock device 104, with the request for communication being transmitted to the lock device 104. In response to the request for communication, at step 410 the lock device 104 may transmit a challenge to the mobile device 102, and more specifically, for the application 128, that seeks to verify that the mobile device 102 and/or associated application 128 is authorized to at least communicate with the lock device 104. For example, according to certain embodiments, the challenge may be a question or request for particular information from the application 128. If the response from the application 128 and/or mobile device 102 that is communicated to the lock device 104 is incorrect, then at step 412 the lock device 104 may determine that the application 128 and/or mobile device 102 is not authorized to communicate with the lock device 104. The lock device 104 may then terminate communications with the application 128 and/or the mobile device 102. However, if the application 128 provides an accurate or correct response, then at step 414 the lock device 104 may determine that the lock device 104 may continue communicating with the application 128 and/or the associated mobile device 102.

    [0025] With communication operably established between the application 128 and the lock device 104, at step 416 a request to capture the lock device 104 from the application 128 may be communicated to the lock device 104. The communicated request to capture may include a first data set that may include a variety of information and data relating to the application 128, the mobile device 102, the lock device 104, and/or other aspects of the access control system 100. Further, according to certain embodiments, the first data set may include information and/or data that at least provide an indication that the application 128 has the authority to request capture of the lock device 104 and/or to capture the lock device 104. In the illustrated embodiment, the first data set may be comprised, either collectively and/or individually, of one or more sets of encrypted data and/or one or more types of non-encrypted data or information. For example, in the illustrated embodiment the first data set may include the encrypted application token (AppToken) as well as a non-encrypted first identifier (IDENT1). Additionally, according to certain embodiments, the encrypted and non-encrypted data or information of the first data set may be compiled together in a manner that forms one or more data strings, algorithms, or functions. For example, in the illustrated embodiment, the first data set may be represented by the following expression:



    [0026] At step 418, the lock device 104 may utilize at least a portion of the information in the first data set to generate a second data set, or lock encryption data. According to the illustrated embodiment, the second set of data may include data that is encrypted, or further encrypted, by the lock device 104, as well as non-encrypted data. For example, according to certain embodiments, the second data set may include, in addition to the first data set, a second lock identifier (IDENT2) that has one or more of the identifiers generated at step 304, or other identifiers. Similar to the first identifier (IDENT1), according to certain embodiments, the second identifier (IDENT2) may be, or related to, one or more identifiers associated with the mobile device 102, lock device 104, application 128, and/or correspond to the registered user account. Further, according to certain embodiments, the second identifier (IDENT2) may, or may not, include at least some of the same identifier(s) used for the first identifier (IDENT1). For example, the second lock identifier (IDENT2) may include one or more of the lock identifiers used in the first identifier (IDENT1) such as, for example, a serial number (S/N), production code, or production date, among other lock identifiers. Additionally, the second identifier (IDENT2) may and/or may not be encrypted with the first data set. For example, the second identifier (IDENT2), may be appended to the first data set prior to the first data set being encrypted by the lock device 104 in connection with the generation of the second data set. Such encryption may use the first key (FK) that was used to generate the application token (AppToken), or another, different second encryption key (SK). Additionally, the second data set may also include a non-encrypted second identifier (IDENT2) that may, or may not, contain the same or similar identifier information that was with the second identifier (IDENT2) that was encrypted by the lock device 104 with the first data set. According to such an embodiment, the second data set may be expressed as:



    [0027] At step 420, the lock device 104 communicates the second data set to the mobile device 102, and more specifically, for the application 128. According to the illustrated embodiment, at step 422, the application 128 may append non-encrypted information to the second data set to generate a third data set. For example, in the illustrated embodiment, the application 128 may append the second data set to include information relating to a third identifier (IDENT3). According to certain embodiments, the third identifier (IDENT3) may contain the same or similar data or information as the first and second identifiers (IDENT1, IDENT2). According to such an embodiment, the third data set from the application 128 may be represented as:



    [0028] At step 424, the third data set is communicated from the application 128 via the mobile device 104, to the server 106. For example, according to certain embodiments, the mobile device 102 may transmit the third data set to the cloud-based server 106a. The server 106 may then extract non-encrypted data or information from the application 128 and information that has been encrypted by the lock device 104, to verify that the application 128 and/or mobile device 104 from which the server 106 received the third data set is the related to, and possibly the same as, the application 128 and/or mobile device that communicated with the lock device 104. Therefore, at step 426, the server 106 extracts the non-encrypted data or information from the third data set such as, for example, in the illustrated embodiment, the non-encrypted second identifier (IDENT2) and the third identifier (IDENT3). At step 428, the server 106 may then utilize the extracted non-encrypted data to identify the corresponding lock device 104 and associated information relating to the lock device 104. For example, in the illustrated embodiment, the server 106 may utilize the extracted non-encrypted identifier(s) from the third data set to identify and retrieve, from the database 129 of the server 106 and/or the auxiliary database 130, information relating to the lock device 104.

    [0029] At step 430, the server 106 may decrypt encrypted information or data from the third data set data and more particularly, encrypted information in the third data set that corresponds to encrypted data from the first and second data sets. For example, according to certain embodiments, the server 106 may utilize extract identifiers from the non-encrypted portion of the second and third identifiers (IDENT2, IDENT3) in the third data set to identify the encryption key(s) that were used to encrypt information in the first and second data sets such as, for example, the first and second keys (FK, SK). For example, according to the illustrated embodiment, the server 106 may utilize the second key (SK) to decrypted the second data set contained in the third data set, and thereby extract the second identifier (IDENT2), the first identifier (IDENT1), and the application token (AppToken). Then, using the associated encryption key such as, for example, the first key (FK), the server 106 may proceed to de-crypt the encrypted application token (AppToken), and thereby extract data or information from the encrypted application token (AppToken) such as, for example, extract the first identifier (IDENT1).

    [0030] As shown above by at least Exs. 1 and 4b, in the illustrated embodiment, both the non-encrypted and encrypted portions of the third data set included a multiple identifiers (IDENT1, IDENT2, IDENT3) having different levels of encryption, if any. For example, in the illustrated embodiment, the encrypted application token (AppToken) from the first data set, which may be encrypted by the first key (FK) and the non-encrypted first identifier (IDENT1), may be subsequently subjected to encryption by the lock device 104 using the second key (SK). Additionally, as shown by Ex. 3, in the illustrated embodiment, the second data set may also include a second identifier (IDENT2) that was also encrypted, with or without data from the encrypted application token (AppToken), using the second key (SK). Thus, the server 106 may utilize a different number of encryption keys to extract various encrypted information from the third data set.

    [0031] At step 432, the server 106 may compare two or more of the identifiers (IDENT1, IDENT2, IDENT3) obtained from the third data set such as, for example, comparing the second identifier (IDENT2) that was added to the encrypted application token (AppToken) in the second data set with the first identifier (IDENT1) that was contained in the encrypted application token. Additionally, according to certain embodiments, the server 106 may also compare the third identifier (IDENT3) from the third data set with the extracted first identifier (IDENT1) and/or the extracted second identifier (IDENT2). If the server 106 determines at step 434 that the compared, extracted identifiers are not related such as, for example, are not the same, similar, and/or associated with the same registered user account, application 128, lock device(s) 104, and/or mobile device 102, among other relations, then at step 436 the server 106 may terminate communication with the application 128. If however, the server 106 confirms that the compared, extracted identifiers (IDENT1, IDENT2, IDENT3) are related to each other, the server 106 may record one or more of the identifiers (IDENT1, IDENT2, IDENT3), or portions of the identifiers (IDENT1, IDENT2, IDENT3) to a record or database associated with the lock device 104 such as, for example, a database 129 of the server 106 and/or the auxiliary database 130.

    [0032] At step 440, the server 106 uses an encryption key such as, for example, a third key (TK) to encrypt a forth data set, or lock data set, that includes encrypt data or information that at least in-part identifies or corresponds to the registered user account, including the application 128 and/or mobile device 102. For example, in the illustrated embodiment, the data or information encrypted by the server 106 at step 440 may include a fourth identifier (IDENT4) and a fourth encryption key (FFK). Further, according to certain embodiments, the third encryption key (TK) may be the same or similar to one of the first or second keys (FK, SK), while the fourth encryption key (FFK) is the same or similar to the other of the first or second keys (FK, SK). Alternatively, according to other embodiments, the third and fourth keys (TK, FFK) may be different than the first and second keys (FK, SK). According to certain embodiments, the information to be encrypted at step 440 may be compiled into one or more strings or functions before encrypting the string(s) or function(s). According to the illustrated embodiment, the fourth data set may be represented as:



    [0033] At step 442, the fourth data set may be operably communicated to the application 128. At step 444, the application 128 may then append information such as, for example, un-encrypted data or information, to the fourth data set to generate a fifth data set that is transmitted to the lock device 104. According to the illustrated embodiment, in generating the fifth data set, the application 128 may append to the fourth data a fifth identifier (IDENT5), such that the fifth data set may be expressed as:

    Again, similar to the first, second, third, and fourth data sets, according to certain embodiment, the non-encrypted and/or encrypted data or information in the fifth data set may be compiled together in a manner that forms one or more data strings, algorithms, or functions.

    [0034] At step 446, the lock device 104 may decrypt the encrypted portion of the fifth data set. Further, the lock device 104 may record or otherwise store at least a portion of the decrypted data from the fifth data set at step 448, as well as the fourth key (FFK), which may already be recorded by the lock device 104. For example, according to certain embodiments, the lock device 104 may record the further identifier (IDENT4) and/or the fifth identifier (IDENT5) and the fourth key (FFK)) obtained by the lock device 104 decrypting the fifth data set in the memory 122 of the lock device 104. Additionally, at step 450, the lock device 104 may cease, at least temporarily, communications with application 128.

    [0035] With communications between the lock device 104 and the application 128 terminated, at step 452 a communication requesting communication with the lock device 104 may be transmitted from the application 128 via the mobile device 102. In response to the request for communication, at step 454 the lock device 104 may transmit a challenge to the mobile device 102, and more specifically, for the application 128, that seeks to verify that the mobile device 102 and/or associated application 128 is authorized to at least communicate with the lock device 104. If the response from the application 128 that is communicated to the lock device 104 via the mobile device 102 is incorrect, then at step 456 the lock device 104 may determine that the application 128 and thus the mobile device 102 is not authorized to communicate with the lock device 104, and the lock device 104 will refuse to communicate with the application 128 and/or mobile device 102. However, if the application 128 provides an accurate or correct response, then at step 458 the lock device 104 may receive a communication that at least provides information identifying the application 128 and/or lock device 104. For example, according to the illustrated embodiment, at step 458, the lock device 104 may receive, from the application 128 via the mobile device 102, a sixth identifier (IDENT6), which may be encrypted using the fourth key (FFK). At step 460, the lock device 104 may retrieve from its memory 122 the stored fourth key (FFK) and decrypt the encrypted data or information in the sixth identifier (IDENT6). The lock device 104 may thereby identify that the application 128 is authorized to communicate with the lock device 104, without requiring a connection between the lock device 104 and the server 106. At step 462, the lock device 104 may save the extracted information from the sixth identifier (IDENT6).

    [0036] With authentication established, at step 464 the lock device 104 and application 128 may proceed with communicating with each other. For example, according to certain embodiments, the lock device 104 and application 128 may communicate with each other using a temporary encrypted key (TempK). Such communications may allow for a variety of different operations of the lock device 104 such as, for example, configuration of the lock device 104 through use of the application 128. Moreover, such configuration of the lock device 104 may then proceed without the lock device 104 having to repeatedly communicate with the server 106.

    [0037] At step 466, the lock device 104 may erase, destroy, ignore, or otherwise discard at least a portion of information associated with communications between the lock device 104 and the application 128 such as, for example, the fourth key (FFK), the temporary encrypted key (TempK), among other information or data. Such discarding of information may occur at predetermined intervals such as, for example, after a predetermined time period, number of communications between the application 128 and the lock device 104, time period between subsequent communications between the application 128 and the lock device 104, number of times the lock device 104, or associated lock mechanism 123, has been operated. For example, in the illustrated embodiment, the information associated with communications between the lock device 104 and the application 128 may be discarded from the lock device 104 every 6 hours, 12 hours, or 24 hours. Thus, after the such information has been discarded, the application 128 may need to contact the server 106 to retrieve at least a new AppToken, thereby imparting the system 100 with at least a degree of dynamic keying. With the generation of a new AppToken, the application 128 may again contact the lock device 104 at step 408 and proceed again with recapturing the lock device 104.

    [0038] Various features and advantages of the present invention are set forth in the following claims. Additionally, changes and modifications to the described embodiments described herein will be apparent to those skilled in the art, and such changes and modifications can be made without departing from the scope of the present invention and without diminishing its intended advantages.

    [0039] While the invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.


    Claims

    1. A method for controlling a network access control system (100) having a server (106), a mobile device (102), and a lock device (104), the method comprising:

    assigning a registered user account a first key;

    assigning the lock device (104) an encryption key;

    encrypting, by the server (106), at least a first identifier related to the registered user account using the first key to generate an encrypted application token;

    communicating, by the server (106), the encrypted application token from the server (106) to the mobile device (102);

    receiving, by the lock device (104), the encrypted application token and a second identifier from the mobile device (102), the second identifier being related to the registered user account;

    encrypting, by the lock device (104) and using the assigned encryption key, the encrypted application token and the second identifier to generate lock encrypted data;

    communicating, by the lock device (104), the lock encrypted data from the lock device (104) to the mobile device (102);

    receiving, by the server (106), the lock encrypted data from the mobile device (102);

    decrypting, by the server (106), the lock encrypted data using the assigned encryption key to extract the second identifier;

    decrypting, by the server (106) and using the first key, the encrypted application token from the decrypted lock encrypted data to extract the first identifier; and

    comparing, by the server (106), the extracted first and second identifiers to verify that the second identifier is related to the first identifier for continued secure communication with the mobile device (102).


     
    2. The method of claim 1, wherein communicating the lock encrypted data from the lock device (104) to the mobile device (102) further includes communicating a lock identifier from the lock device (104) to the mobile device (102); and
    wherein receiving, by the server (106), the lock encrypted data from the mobile device (102) further includes receiving the lock identifier.
     
    3. The method of claim 2, further including:

    locating, by the server (106), the assigned encryption key in a database (129, 130) using the lock identifier; and

    retrieving, by the server (106), the assigned encryption key from the database (129, 130).


     
    4. The method of claim 1, further including:

    encrypting, by the server (106) and in response to a determination that the second identifier is similar to the first identifier, the first key using the assigned encryption key to generate a lock data set;

    communicating, by the server (106), the lock data set from the server (106) to the mobile device (102);

    receiving, by the lock device (104) and from the mobile device (102), the lock data set and an identifier related to the registered user account;

    decrypting, by the lock device (104), the lock data set to extract the first key; and

    storing, by the lock device (104), the extracted first key and the identifier related to the registered user account.


     
    5. The method of claim 4, further including:

    receiving, by the lock device (104) and from the mobile device (102), the encrypted application token;

    decrypting, by the lock device (104), the received encrypted application token using the stored first key to extract a temporary encryption key; and

    receiving, by the lock device (104), communications from the mobile device (102) using at least the extracted temporary encryption key.


     
    6. The method of claim 5, further including:

    monitoring, by the lock device (104), an expiration of a predetermined interval; and

    discarding, by the lock device (104), the stored first key and the extracted temporary encryption key upon expiration of the predetermined interval.


     
    7. The method of claim 6, wherein the predetermined interval is a predetermined period of time.
     
    8. An access control system (100) including a server (106), a mobile device (102), and a lock device (104), the access control system (100) comprising:

    at least one hardware processor; and

    at least one memory comprising a plurality of instructions stored thereon that, in response to execution by the at least one hardware processor, causes the access control system (100) to:

    assign a registered user account a first key;

    assign the lock device (104) an encryption key;

    encrypt, by the server (106), at least a first identifier related to the registered user account using the first key to generate an encrypted application token;

    communicate, by the server (106), the encrypted application token from the server (106) to the mobile device (102);

    receive, by the lock device (104), the encrypted application token and a second identifier from the mobile device (102), the second identifier being related to the registered user account;

    encrypt, by the lock device (104) and using the assigned encryption key, the encrypted application token and the second identifier to generate lock encrypted data;

    communicate, by the lock device (104), the lock encrypted data from the lock device (104) to the mobile device (102);

    receive, by the server (106), the lock encrypted data from the mobile device (102);

    decrypt, by the server (106), the lock encrypted data using the assigned encryption key to extract the second identifier;

    decrypt, by the server (106) and using the first key, the encrypted application token from the decrypted lock encrypted data to extract the first identifier; and

    compare, by the server (106), the extracted first and second identifiers to verify that the second identifier is related to the first identifier for continued secure communication with the mobile device (102).


     
    9. The access control system (100) of claim 8, wherein communication of the lock encrypted data from the lock device (104) to the mobile device (102) further comprises communication of a lock identifier from the lock device (104) to the mobile device (102); and
    wherein reception, by the server (106), of the lock encrypted data from the mobile device (102) further comprises reception of the lock identifier.
     
    10. The access control system (100) of claim 9, wherein the plurality of instructions further causes the access control system (100) to:

    locate, by the server (106), the assigned encryption key in a database (129, 130) using the lock identifier; and

    retrieve, by the server (106), the assigned encryption key from the database (129, 130).


     
    11. The access control system (100) of claim 8, wherein the plurality of instructions further causes the access control system (100) to:

    encrypt, by the server (106) and in response to a determination that the second identifier is similar to the first identifier, the first key using the assigned encryption key to generate a lock data set;

    communicate, by the server (106), the lock data set from the server (106) to the mobile device (102);

    receive, by the lock device (104) and from the mobile device (102), the lock data set and an identifier related to the registered user account;

    decrypt, by the lock device (104), the lock data set to extract the first key; and

    store, by the lock device (104), the extracted first key and the identifier related to the registered user account.


     
    12. The access control system (100) of claim 11, wherein the plurality of instructions further causes the access control system (100) to:

    receive, by the lock device (104) and from the mobile device (102), the encrypted application token;

    decrypt, by the lock device (104), the received encrypted application token using the stored first key to extract a temporary encryption key; and

    receive, by the lock device (104), communications from the mobile device (102) using at least the extracted temporary encryption key.


     
    13. The access control system (100) of claim 12, wherein the plurality of instructions further causes the access control system (100) to:

    monitor, by the lock device (104), an expiration of a predetermined interval; and

    discard, by the lock device (104), the stored first key and the extracted temporary encryption key upon expiration of the predetermined interval.


     
    14. The access control system (100) of claim 13, wherein the predetermined interval is a predetermined period of time.
     
    15. A plurality of non-transitory machine-readable storage media comprising a plurality of instructions stored thereon that, in response to execution by a system (100), causes the system (100) to:

    assign a registered user account a first key;

    assign a lock device (104) of the system (100) an encryption key;

    encrypt, by a server (106) of the system (100), at least a first identifier related to the registered user account using the first key to generate an encrypted application token;

    communicate, by the server (106), the encrypted application token from the server (106) to a mobile device (102) of the system (100);

    receive, by the lock device (104), the encrypted application token and a second identifier from the mobile device (102), the second identifier being related to the registered user account;

    encrypt, by the lock device (104) and using the assigned encryption key, the encrypted application token and the second identifier to generate lock encrypted data;

    communicate, by the lock device (104), the lock encrypted data from the lock device (104) to the mobile device (102);

    receive, by the server (106), the lock encrypted data from the mobile device (102);

    decrypt, by the server (106), the lock encrypted data using the assigned encryption key to extract the second identifier;

    decrypt, by the server (106) and using the first key, the encrypted application token from the decrypted lock encrypted data to extract the first identifier; and

    compare, by the server (106), the extracted first and second identifiers to verify that the second identifier is related to the first identifier for continued secure communication with the mobile device (102).


     


    Ansprüche

    1. Ein Verfahren zur Kontrolle eines Netzwerkzugangskontrollsystems (100) mit einem Server (106), einer mobilen Vorrichtung (102) und einer Sperrvorrichtung (104), wobei das Verfahren umfasst:

    Zuordnen eines ersten Schlüssels zu einem registrieren Benutzerkonto;

    Zuordnen eines Verschlüsselungsschlüssels zur Sperrvorrichtung (104)

    Verschlüsseln mindestens einer ersten Kennung in Bezug auf das registrierte Benutzerkonto durch den Server (106) unter Verwendung des ersten Schlüssels, um einen verschlüsselten Anwendungstoken zu erzeugen;

    Kommunizieren des verschlüsselten Anwendungstokens durch den Server (106) vom Server (106) an die mobile Vorrichtung (102);

    Empfangen des verschlüsselten Anwendungstokens und einer zweiten Kennung von der mobilen Vorrichtung (102) durch die Sperrvorrichtung (104), wobei die zweite Kennung mit dem registrierten Benutzerkontor in Beziehung steht;

    Verschlüsseln des verschlüsselten Anwendungstokens und der zweiten Kennung durch die Sperrvorrichtung (104) und unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um verschlüsselte Sperrdaten zu erzeugen;

    Kommunizieren der verschlüsselten Sperrdaten durch die Sperrvorrichtung (104) von der Sperrvorrichtung (104) an die mobile Vorrichtung (102);

    Empfangen der verschlüsselten Sperrdaten durch den Server (106) von der mobilen Vorrichtung (102);

    Entschlüsseln der verschlüsselten Sperrdaten durch den Server (106) unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um die zweite Kennung zu extrahieren;

    Entschlüsseln des verschlüsselten Anwendungstokens aus den entschlüsselten verschlüsselten Sperrdaten durch den Server (106) und unter Verwendung des ersten Schlüssels, um die erste Kennung zu extrahieren; und

    Vergleichen der ersten und der zweiten extrahierten Kennung durch den Server (106) zum Verifizieren, dass die zweite Kennung mit der ersten Kennung in Beziehung steht, für fortgesetzte sichere Kommunikation mit der mobilen Vorrichtung (102).


     
    2. Das Verfahren nach Anspruch 1, wobei das Kommunizieren der verschlüsselten Sperrdaten von der Sperrvorrichtung (104) an die mobile Vorrichtung (102) ferner ein Kommunizieren einer Sperrkennung von der Sperrvorrichtung (104) an die mobile Vorrichtung (102) umfasst, und
    wobei das Empfangen der verschlüsselten Sperrdaten durch den Server (106) von der mobilen Vorrichtung (102) ferner ein Empfangen der Sperrkennung umfasst.
     
    3. Das Verfahren nach Anspruch 2, ferner umfassend:

    Lokalisieren des zugeordneten Verschlüsselungsschlüssels durch den Server (106) in einer Datenbank (129, 130) unter Verwendung der Sperrkennung; und

    Abrufen des zugeordneten Verschlüsselungsschlüssels durch den Server (106) aus der Datenbank (129, 130).


     
    4. Das Verfahren nach Anspruch 1, ferner umfassend:

    Verschlüsseln des ersten Schlüssels durch den Server (106) und in Reaktion auf eine Bestimmung, dass die zweite Kennung der ersten Kennung ähnelt, unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um einen Sperrdatensatz zu erzeugen;

    Kommunizieren des Sperrdatensatzes durch den Server (106) vom Server (106) an die mobile Vorrichtung (102);

    Empfangen des Sperrdatensatzes und einer Kennung in Bezug auf das registrierte Benutzerkonto durch die Sperrvorrichtung (104) und von der mobilen Vorrichtung (102) ;

    Entschlüsseln des Sperrdatensatzes durch die Sperrvorrichtung (104), um den ersten Schlüssel zu extrahieren; und

    Speichern des extrahieren ersten Schlüssels und der Kennung in Bezug auf das registrierte Benutzerkonto durch die Sperrvorrichtung (104).


     
    5. Das Verfahren nach Anspruch 4, ferner umfassend:

    Empfangen des verschlüsselten Anwendungstokens durch die Sperrvorrichtung (104) und von der mobilen Vorrichtung (102);

    Entschlüsseln des empfangenen verschlüsselten Anwendungstokens durch die Sperrvorrichtung (104) unter Verwendung des gespeicherten ersten Schlüssels, um einen temporären Verschlüsselungsschlüssel zu extrahieren; und

    Empfangen von Kommunikationen von der mobilen Vorrichtung (102) durch die Sperrvorrichtung (104) unter Verwendung wenigstens des extrahierten temporären Verschlüsselungsschlüssels.


     
    6. Das Verfahren nach Anspruch 5, ferner umfassend:

    Überwachen eines Ablaufs eines vorbestimmten Intervalls durch die Sperrvorrichtung (104); und

    Verwerfen des gespeicherten ersten Schlüssels und des extrahierten temporären Verschlüsselungsschlüssels durch die Sperrvorrichtung (104) bei Ablauf des vorbestimmten Intervalls.


     
    7. Das Verfahren nach Anspruch 6, wobei das vorbestimmte Intervall eine vorbestimmte Zeitdauer ist.
     
    8. Ein Zugangskontrollsystem (100), das einen Server (106), eine mobile Vorrichtung (102) und eine Sperrvorrichtung (104) umfasst, wobei das Kontrollsystem (100) umfasst:

    mindestens einen Hardwareprozessor; und

    mindestens einen Speicher, der eine Mehrzahl von Anweisungen darauf gespeichert aufweist, die in Reaktion auf ihre Ausführung durch den mindestens einen Hardwareprozessor das Zugangskontrollsystem (100) veranlasst zum:

    Zuordnen eines ersten Schlüssels zu einem registrieren Benutzerkonto;

    Zuordnen eines Verschlüsselungsschlüssels zur Sperrvorrichtung (104)

    Verschlüsseln mindestens einer ersten Kennung in Bezug auf das registrierte Benutzerkonto durch den Server (106) unter Verwendung des ersten Schlüssels, um einen verschlüsselten Anwendungstoken zu erzeugen;

    Kommunizieren des verschlüsselten Anwendungstokens durch den Server (106) vom Server (106) an die mobile Vorrichtung (102);

    Empfangen des verschlüsselten Anwendungstokens und einer zweiten Kennung von der mobilen Vorrichtung (102) durch die Sperrvorrichtung (104), wobei die zweite Kennung mit dem registrierten Benutzerkontor in Beziehung steht;

    Verschlüsseln des verschlüsselten Anwendungstokens und der zweiten Kennung durch die Sperrvorrichtung (104) und unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um verschlüsselte Sperrdaten zu erzeugen;

    Kommunizieren der verschlüsselten Sperrdaten durch die Sperrvorrichtung (104) von der Sperrvorrichtung (104) an die mobile Vorrichtung (102);

    Empfangen der verschlüsselten Sperrdaten durch den Server (106) von der mobilen Vorrichtung (102);

    Entschlüsseln der verschlüsselten Sperrdaten durch den Server (106) unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um die zweite Kennung zu extrahieren;

    Entschlüsseln des verschlüsselten Anwendungstokens aus den entschlüsselten verschlüsselten Sperrdaten durch den Server (106) und unter Verwendung des ersten Schlüssels, um die erste Kennung zu extrahieren; und

    Vergleichen der ersten und der zweiten extrahierten Kennung durch den Server (106) zum Verifizieren, dass die zweite Kennung mit der ersten Kennung in Beziehung steht, für fortgesetzte sichere Kommunikation mit der mobilen Vorrichtung (102),


     
    9. Das Zugangskontrollsystem (100) nach Anspruch 8, wobei Kommunikation der verschlüsselten Sperrdaten von der Sperrvorrichtung (104) an die mobile Vorrichtung (102) ferner Kommunikation einer Sperrkennung von der Sperrvorrichtung (104) an die mobile Vorrichtung (102) umfasst; und
    wobei Empfang der verschlüsselten Sperrdaten von der mobilen Vorrichtung (102) durch den Server (106) ferner Empfang der Sperrkennung umfasst.
     
    10. Das Zugangskontrollsystem (100) nach Anspruch 9, wobei die Mehrzahl von Anweisungen das Zugangskontrollsystem (100) ferner veranlasst zum:

    Lokalisieren des zugeordneten Verschlüsselungsschlüssels durch den Server (106) in einer Datenbank (129, 130) unter Verwendung der Sperrkennung; und

    Abrufen des zugeordneten Verschlüsselungsschlüssels durch den Server (106) aus der Datenbank (129, 130).


     
    11. Das Zugangskontrollsystem (100) nach Anspruch 8, wobei die Mehrzahl von Anweisungen das Zugangskontrollsystem (100) ferner veranlasst zum:

    Verschlüsseln des ersten Schlüssels durch den Server (106) und in Reaktion auf eine Bestimmung, dass die zweite Kennung der ersten Kennung ähnelt, unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um einen Sperrdatensatz zu erzeugen;

    Kommunizieren des Sperrdatensatzes durch den Server (106) vom Server (106) an die mobile Vorrichtung (102);

    Empfangen des Sperrdatensatzes und einer Kennung in Bezug auf das registrierte Benutzerkonto durch die Sperrvorrichtung (104) und von der mobilen Vorrichtung (102) ;

    Entschlüsseln des Sperrdatensatzes durch die Sperrvorrichtung (104), um den ersten Schlüssel zu extrahieren; und

    Speichern des extrahieren ersten Schlüssels und der Kennung in Bezug auf das registrierte Benutzerkonto durch die Sperrvorrichtung (104).


     
    12. Das Zugangskontrollsystem (100) nach Anspruch 11, wobei die Mehrzahl von Anweisungen das Zugangskontrollsystem (100) ferner veranlasst zum:

    Empfangen des verschlüsselten Anwendungstokens durch die Sperrvorrichtung (104) und von der mobilen Vorrichtung (102);

    Entschlüsseln des empfangenen verschlüsselten Anwendungstokens durch die Sperrvorrichtung (104) unter Verwendung des gespeicherten ersten Schlüssels, um einen temporären Verschlüsselungsschlüssel zu extrahieren; und

    Empfangen von Kommunikationen von der mobilen Vorrichtung (102) durch die Sperrvorrichtung (104) unter Verwendung des extrahierten temporären Verschlüsselungsschlüssels.


     
    13. Das Zugangskontrollsystem (100) nach Anspruch 12, wobei die Mehrzahl von Anweisungen das Zugangskontrollsystem (100) ferner veranlasst zum:

    Überwachen eines Ablaufs eines vorbestimmten Intervalls durch die Sperrvorrichtung (104); und

    Verwerfen des gespeicherten ersten Schlüssels und des extrahierten temporären Verschlüsselungsschlüssels durch die Sperrvorrichtung (104) bei Ablauf des vorbestimmten Intervalls.


     
    14. Das Zugangskontrollsystem (100) nach Anspruch 13, wobei das vorbestimmte Intervall eine vorbestimmte Zeitdauer ist.
     
    15. Mehrere nicht-transitorische maschinenlesbare Speichermedien, die eine Mehrzahl von Anweisungen darauf gespeichert aufweisen, die in Reaktion auf ihre Ausführung durch ein System (100) das System (100) veranlasst zum:

    Zuordnen eines ersten Schlüssels zu einem registrieren Benutzerkonto;

    Zuordnen eines Verschlüsselungsschlüssels zu einer Sperrvorrichtung (104) des Systems (100);

    Verschlüsseln mindestens einer ersten Kennung in Bezug auf das registrierte Benutzerkonto durch einen Server (106) des Systems (100) unter Verwendung des ersten Schlüssels, um einen verschlüsselten Anwendungstoken zu erzeugen;

    Kommunizieren des verschlüsselten Anwendungstokens durch den Server (106) vom Server (106) an eine mobile Vorrichtung (102) des Systems (100);

    Empfangen des verschlüsselten Anwendungstokens und einer zweiten Kennung von der mobilen Vorrichtung (102) durch die Sperrvorrichtung (104), wobei die zweite Kennung mit dem registrierten Benutzerkontor in Beziehung steht;

    Verschlüsseln des verschlüsselten Anwendungstokens und der zweiten Kennung durch die Sperrvorrichtung (104) und unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um verschlüsselte Sperrdaten zu erzeugen;

    Kommunizieren der verschlüsselten Sperrdaten durch die Sperrvorrichtung (104) von der Sperrvorrichtung (104) an die mobile Vorrichtung (102);

    Empfangen der verschlüsselten Sperrdaten durch den Server (106) von der mobilen Vorrichtung (102);

    Entschlüsseln der verschlüsselten Sperrdaten durch den Server (106) unter Verwendung des zugeordneten Verschlüsselungsschlüssels, um die zweite Kennung zu extrahieren;

    Entschlüsseln des verschlüsselten Anwendungstokens aus den entschlüsselten verschlüsselten Sperrdaten durch den Server (106) und unter Verwendung des ersten Schlüssels, um die erste Kennung zu extrahieren; und

    Vergleichen der ersten und der zweiten extrahierten Kennung durch den Server (106) zum Verifizieren, dass die zweite Kennung mit der ersten Kennung in Beziehung steht, für fortgesetzte sichere Kommunikation mit der mobilen Vorrichtung (102).


     


    Revendications

    1. Un procédé de contrôle d'un système de contrôle d'accès réseau (100) comportant un serveur (106), un dispositif mobile (102), et un dispositif de verrouillage (104), le procédé comprenant :

    l'assignation d'une première clé à un compte utilisateur enregistré ;

    l'assignation d'une clé de cryptage au dispositif de verrouillage (104) ;

    le cryptage, par le serveur (106), d'au moins un premier identifiant associé au compte utilisateur enregistré à l'aide de la première clé afin de générer un jeton d'application crypté ;

    la communication, par le serveur (106), du jeton d'application crypté du serveur (106) au dispositif mobile (102) ;

    la réception, par le dispositif de verrouillage (104), du jeton d'application crypté et d'un second identifiant en provenance du dispositif mobile (102), le second identifiant étant associé au compte utilisateur enregistré ;

    le cryptage, par le dispositif de verrouillage (104) et à l'aide de la clé de cryptage assignée, du jeton d'application crypté et du second identifiant afin de générer des données cryptées de verrouillage ;

    la communication, par le dispositif de verrouillage (104), des données cryptées de verrouillage du dispositif de verrouillage (104) au dispositif mobile (102) ;

    la réception, par le serveur (106), des données cryptées de verrouillage en provenance du dispositif mobile (102) ;

    le décryptage, par le serveur (106), des données cryptées de verrouillage à l'aide de la clé de cryptage assignée afin d'extraire le second identifiant ;

    le décryptage, par le serveur (106) et à l'aide de la première clé, du jeton d'application crypté à partir des données cryptées de verrouillage décryptées afin d'extraire le premier identifiant ; et

    la comparaison, par le serveur (106), des premier et second identifiants extraits afin de vérifier que le second identifiant est associé au premier identifiant en vue de la poursuite d'une communication sécurisée avec le dispositif mobile (102).


     
    2. Le procédé selon la revendication l, dans lequel la communication des données cryptées de verrouillage par le dispositif de verrouillage (104) au dispositif mobile (102) comporte en outre la communication d'un identifiant de verrouillage par le dispositif de verrouillage (104) au dispositif mobile (102) ; et
    dans lequel la réception, par le serveur (106), des données cryptées de verrouillage en provenance du dispositif mobile (102) comporte en outre la réception de l'identifiant de verrouillage.
     
    3. Le procédé selon la revendication 2, comportant en outre :

    la localisation, par le serveur (106), de la clé de cryptage assignée dans une base de données (129, 130) à l'aide de l'identifiant de verrouillage ; et

    la récupération, par le serveur (106), de la clé de cryptage assignée à partir de la base de données (129, 130) .


     
    4. Le procédé selon la revendication 1, comportant en outre :

    le cryptage, par le serveur (106) et en réponse à une détermination que le second identifiant est semblable au premier identifiant, de la première clé à l'aide de la clé de cryptage assignée afin de générer un ensemble de données de verrouillage ;

    la communication, par le serveur (106), de l'ensemble de données de verrouillage du serveur (106) au dispositif mobile (102) ;

    la réception, par le dispositif de verrouillage (104) et en provenance du dispositif mobile (102), de l'ensemble de données de verrouillage et d'un identifiant associé au compte utilisateur enregistré ;

    le décryptage, par le dispositif de verrouillage (104), de l'ensemble de données de verrouillage afin d'extraire la première clé ; et

    la mémorisation, par le dispositif de verrouillage (104), de la première clé extraite et de l'identifiant associé au compte utilisateur enregistré.


     
    5. Le procédé selon la revendication 4, comportant en outre :

    la réception, par le dispositif de verrouillage (104) et en provenance du dispositif mobile (102), du jeton d'application crypté ;

    le décryptage, par le dispositif de verrouillage (104), du jeton d'application crypté reçu à l'aide de la première clé mémorisée afin d'extraire une clé de cryptage temporaire ; et

    la réception, par le dispositif de verrouillage (104), de communications en provenance du dispositif mobile (102) à l'aide d'au moins la clé de cryptage temporaire extraite.


     
    6. Le procédé selon la revendication 5, comportant en outre :

    la surveillance, par le dispositif de verrouillage (104), d'une expiration d'un intervalle prédéterminé ; et

    le rejet, par le dispositif de verrouillage (104), de la première clé mémorisée et de la clé de cryptage temporaire extraite à l'expiration de l'intervalle prédéterminé.


     
    7. Le procédé selon la revendication 6, dans lequel l'intervalle prédéterminé est une période de temps prédéterminée.
     
    8. Un système de contrôle d'accès (100) comportant un serveur (106), un dispositif mobile (102), et un dispositif de verrouillage (104), le système de contrôle d'accès (100) comprenant :

    au moins un processeur matériel ; et

    au moins une mémoire dans laquelle est mémorisée une pluralité d'instructions qui, en réponse à son exécution par l'au moins un processeur matériel, amène le système de contrôle d'accès (100) à :

    assigner une première clé à un compte utilisateur enregistré ;

    assigner une clé de cryptage au dispositif de verrouillage (104) ;

    crypter, par le serveur (106), au moins un premier identifiant associé au compte utilisateur enregistré à l'aide de la première clé afin de générer un jeton d'application crypté ;

    communiquer, par le serveur (106), le jeton d'application crypté du serveur (106) au dispositif mobile (102) ;

    recevoir, par le dispositif de verrouillage (104), le jeton d'application crypté et un second identifiant en provenance du dispositif mobile (102), le second identifiant étant associé au compte utilisateur enregistré ;

    crypter, par le dispositif de verrouillage (104) et à l'aide de la clé de cryptage assignée, le jeton d'application crypté et le second identifiant afin de générer des données cryptées de verrouillage ;

    communiquer, par le dispositif de verrouillage (104), les données cryptées de verrouillage du dispositif de verrouillage (104) au dispositif mobile (102) ;

    recevoir, par le serveur (106), les données cryptées de verrouillage en provenance du dispositif mobile (102) ;

    décrypter, par le serveur (106), les données cryptées de verrouillage à l'aide de la clé de cryptage assignée afin d'extraire le second identifiant ;

    décrypter, par le serveur (106) et à l'aide de la première clé, le jeton d'application crypté à partir des données cryptées de verrouillage décryptées afin d'extraire le premier identifiant ; et

    comparer, par le serveur (106), les premier et second identifiants extraits afin de vérifier que le second identifiant est associé au premier identifiant en vue de la poursuite d'une communication sécurisée avec le dispositif mobile (102).


     
    9. Le système de contrôle d'accès (100) selon la revendication 8, dans lequel la communication des données cryptées de verrouillage par le dispositif de verrouillage (104) au dispositif mobile (102) comporte en outre la communication d'un identifiant de verrouillage par le dispositif de verrouillage (104) au dispositif mobile (102) ; et
    dans lequel la réception, par le serveur (106), des données cryptées de verrouillage en provenance du dispositif mobile (102) comporte en outre la réception de l'identifiant de verrouillage.
     
    10. Le système de contrôle d'accès (100) selon la revendication 9, dans lequel la pluralité d'instructions amène en outre le système de contrôle d'accès (100) à :

    localiser, par le serveur (106), la clé de cryptage assignée dans une base de données (129, 130) à l'aide de l'identifiant de verrouillage ; et

    récupérer, par le serveur (106), la clé de cryptage assignée à partir de la base de données (129, 130).


     
    11. Le système de contrôle d'accès (100) selon la revendication 8, dans lequel la pluralité d'instructions amène en outre le système de contrôle d'accès (100) à :

    crypter, par le serveur (106) et en réponse à une détermination que le second identifiant est semblable au premier identifiant, la première clé à l'aide de la clé de cryptage assignée afin de générer un ensemble de données de verrouillage ;

    communiquer, par le serveur (106), l'ensemble de données de verrouillage du serveur (106) au dispositif mobile (102) ;

    recevoir, par le dispositif de verrouillage (104) et en provenance du dispositif mobile (102), l'ensemble de données de verrouillage et un identifiant associé au compte utilisateur enregistré ;

    décrypter, par le dispositif de verrouillage (104), l'ensemble de données de verrouillage afin d'extraire la première clé ; et

    mémoriser, par le dispositif de verrouillage (104), la première clé extraite et l'identifiant associé au compte utilisateur enregistré.


     
    12. Le système de contrôle d'accès (100) selon la revendication 11, dans lequel la pluralité d'instructions amène en outre le système de contrôle d'accès (100) à :

    recevoir, par le dispositif de verrouillage (104) et en provenance du dispositif mobile (102), le jeton d'application crypté ;

    décrypter, par le dispositif de verrouillage (104), le jeton d'application crypté reçu à l'aide de la première clé mémorisée afin d'extraire une clé de cryptage temporaire ; et

    recevoir, par le dispositif de verrouillage (104), des communications en provenance du dispositif mobile (102) à l'aide au moins de la clé de cryptage temporaire extraite.


     
    13. Le système de contrôle d'accès (100) selon la revendication 12, dans lequel la pluralité d'instructions amène en outre le système de contrôle d'accès (100) à :

    surveiller, par le dispositif de verrouillage (104), une expiration d'un intervalle prédéterminé ; et

    rejeter, par le dispositif de verrouillage (104), la première clé mémorisée et la clé de cryptage temporaire extraite à l'expiration de l'intervalle prédéterminé.


     
    14. Le système de contrôle d'accès (100) selon la revendication 13, dans lequel l'intervalle prédéterminé est une période de temps prédéterminée.
     
    15. Une pluralité de supports de mémorisation non transitoires lisibles par machine sur laquelle est mémorisée une pluralité d'instructions qui, en réponse à son exécution par un système (100), amène le système (100) à :

    assigner une première clé à un compte utilisateur enregistré ;

    assigner une clé de cryptage à un dispositif de verrouillage (104) du système (100) ;

    crypter, par le serveur (106) du système (100), au moins un premier identifiant associé au compte utilisateur enregistré à l'aide de la première clé afin de générer un jeton d'application crypté ;

    communiquer, par le serveur (106), le jeton d'application crypté du serveur (106) à un dispositif mobile (102) du système (100) ;

    recevoir, par le dispositif de verrouillage (104), le jeton d'application crypté et un second identifiant en provenance du dispositif mobile (102), le second identifiant étant associé au compte utilisateur enregistré ;

    crypter, par le dispositif de verrouillage (104) et à l'aide de la clé de cryptage assignée, le jeton d'application crypté et le second identifiant afin de générer des données cryptées de verrouillage ;

    communiquer, par le dispositif de verrouillage (104), les données cryptées de verrouillage du dispositif de verrouillage (104) au dispositif mobile (102) ;

    recevoir, par le serveur (106), les données cryptées de verrouillage en provenance du dispositif mobile (102) ;

    décrypter, par le serveur (106), les données cryptées de verrouillage à l'aide de la clé de cryptage assignée afin d'extraire le second identifiant ;

    décrypter, par le serveur (106) et à l'aide de la première clé, le jeton d'application crypté à partir des données cryptées de verrouillage décryptées afin d'extraire le premier identifiant ; et

    comparer, par le serveur (106), les premier et second identifiants extraits afin de vérifier que le second identifiant est associé au premier identifiant en vue de la poursuite d'une communication sécurisée avec le dispositif mobile (102).


     




    Drawing

















    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description