Networked access control system

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent application Ser. No. 14/796,501 filed Jul. 10, 2015, which claims the benefit of U.S. Provisional Patent Application No. 62/023,079 filed Jul. 10, 2014, the contents of each application hereby incorporated by reference in their entirety.

BACKGROUND

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).

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.

BRIEF SUMMARY

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.

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.

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.

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

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> 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.

<figref idref="DRAWINGS">FIG. 2</figref> 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.

<figref idref="DRAWINGS">FIG. 3</figref> 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.

<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate a schematic flow diagram of an exemplary process for capturing a lock device according to an illustrated embodiment of the present invention.

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

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a schematic diagram of an exemplary access control system <b>100</b> that includes a mobile device <b>102</b>, a lock device <b>104</b>, and a server <b>106</b> according to an illustrated embodiment of the present invention. A variety of mobile devices <b>102</b> 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 <b>102</b> may have one or more transceivers <b>108</b> for communicating data with other devices, including the lock device <b>104</b> and the server <b>106</b>. Additionally, a variety of different types of transceivers <b>108</b> 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 <b>102</b> may also include an input/output device <b>110</b> such as, for example, a keypad, display, and/or touch screen among other input/output devices <b>110</b>. Additionally, the mobile device may include may include one or more different processing devices <b>112</b> 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 <b>112</b> may include multiple processors and may be of a programmable variety that executes algorithms and processes data in accordance with an operating logic <b>114</b> as defined by programming instructions (such as software or firmware) stored in a memory <b>116</b>.

The lock device <b>104</b> may be a lock, reader device, a payment terminal, and/or any other type of device that can communicate with the mobile device <b>102</b>. For example, in the embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, the lock device <b>104</b> is an electronic lock device having one or more transceivers <b>118</b>, a processing device <b>120</b>, a memory <b>122</b>, and a lock mechanism <b>123</b> such as, for, example, bolt and/or latch. The memory <b>122</b> may or may not be part of the processor <b>120</b>. The mobile device <b>102</b> and lock device <b>104</b> 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 <b>104</b> may have a transceiver <b>118</b> that allows for Bluetooth low energy communication between the mobile device <b>102</b> and the lock device <b>104</b>. Further, according to certain embodiments, the mobile device <b>102</b> and the lock device <b>104</b> may communication via NFC and/or WIFI (such as WIFI Direct).

A variety of different types of processing devices may be employed for the processing device <b>120</b> of the lock device <b>104</b> such as, for example, a programmable, dedicated, and/or hardwired state machine, or any combination thereof. The processing device <b>120</b> 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 <b>120</b> with multiple processing units may also utilize distributed, pipelined, and/or parallel processing. The processing device <b>120</b> 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 <b>120</b> is of a programmable variety that executes algorithms and processes data in accordance with operating logic <b>124</b> as defined by programming instructions (such as software or firmware) stored in the memory <b>122</b> of the lock device <b>104</b>. Alternatively or additionally, the operating logic <b>124</b> is at least partially defined by hardwired logic or other hardware. The processing device <b>120</b> may include one or more components of any type suitable to process the signals received from an input/output device <b>126</b> of the lock device <b>107</b> 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.

The memory <b>122</b> of the lock device <b>104</b> may be included with the processing device <b>120</b> and/or coupled to the processing device <b>120</b>. Further, the memory <b>122</b> 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 <b>122</b> can be volatile, nonvolatile, or a combination of these types, and some or all of the memory <b>122</b> 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 <b>122</b> can store data that is manipulated by the operating logic <b>124</b> of processing device <b>120</b>, such as data representative of signals received from and/or sent to the input/output device <b>126</b> in addition to, or in lieu of, storing programming instructions defining the operating logic <b>124</b>.

The server <b>106</b> may include one or more servers <b>106</b><i>a</i>, <b>106</b><i>b </i>that may communicate with the mobile device <b>102</b> and/or the lock device <b>104</b> 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 <b>106</b> is a cloud-based server <b>106</b><i>a</i>. However, a variety of other different types of servers may also be used for the one or more servers <b>106</b> including, for example, a web-based server <b>106</b><i>b</i>. Further, according to certain embodiments, different servers <b>106</b> may be used for different purposes such as, for example, a cloud-based server <b>106</b><i>a </i>for installation, maintenance, and/or management of, or relating to, the access control system <b>100</b>, lock device <b>104</b>, and/or the mobile device <b>102</b>, and another, different server <b>106</b> such as, for example, a web-based server <b>106</b><i>b </i>for other purposes such as, for example, general, day-to-day usage and/or operation of the lock device <b>104</b>.

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

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a schematic flow diagram of an exemplary process <b>200</b> for at least initial programming of the lock device <b>104</b> such as, for example, during the manufacturing, production, and/or assembly of the lock device <b>104</b> 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.

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

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

At step <b>306</b>, the server <b>106</b> may compile the one or more of the various identifiers or data generated at step <b>306</b> into one or more strings or functions to provide the first identifier (IDENT₁) and encrypt the string(s) or function(s) of the first identifier (IDENT1) with a first encryption key (FK) such as, for example, an encryption key that is associated with, for example, the lock device <b>104</b>, the server <b>106</b>, a database <b>130</b>, 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: <br />AppToken=<i>FK</i>(IDENT₁)  (Ex. 1)

Further, according to the illustrated embodiment, at step <b>308</b>, the server <b>106</b>, such as the cloud-based server <b>106</b><i>a</i>, may communicate at least the encrypted application token (AppToken) to the application <b>128</b> on the mobile device <b>102</b>. According to the illustrated embodiment, although encrypted data may pass between the server <b>106</b> and the lock device <b>104</b> through the application <b>128</b> and associated mobile device <b>102</b>, the application <b>128</b> and mobile device <b>102</b> may not be provided with encryption keys that would allow the application <b>128</b> or mobile device <b>102</b> 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 <b>104</b> may be performed by the server <b>106</b> and/or the lock device <b>104</b>, but not the application <b>128</b> and/or mobile device <b>102</b>.

<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate a schematic flow diagram of an exemplary process <b>400</b> for capturing a lock device <b>104</b> 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 <b>128</b> and the server <b>106</b>, 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.

At step <b>402</b>, the application <b>128</b> associated with a registered user account receives the encrypted application token. At step <b>404</b>, the lock device(s) <b>104</b> may be installed at a desired location such as, for example, on a door, wall, and/or door frame, among other locations. At step <b>406</b>, the lock device <b>406</b> may receive power from a power source. Power may be provided to the lock device <b>104</b> 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 <b>104</b>, and/or from a power source that is external to the lock device <b>104</b>.

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

With communication operably established between the application <b>128</b> and the lock device <b>104</b>, at step <b>416</b> a request to capture the lock device <b>104</b> from the application <b>128</b> may be communicated to the lock device <b>104</b>. The communicated request to capture may include a first data set that may include a variety of information and data relating to the application <b>128</b>, the mobile device <b>102</b>, the lock device <b>104</b>, and/or other aspects of the access control system <b>100</b>. Further, according to certain embodiments, the first data set may include information and/or data that at least provide an indication that the application <b>128</b> has the authority to request capture of the lock device <b>104</b> and/or to capture the lock device <b>104</b>. 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 (IDENT₁). 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: <br />IDENT₁,AppToken  (Ex. 2)

At step <b>418</b>, the lock device <b>104</b> 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 <b>104</b>, 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 (IDENT₂) that has one or more of the identifiers generated at step <b>304</b>, or other identifiers. Similar to the first identifier (IDENT₁), according to certain embodiments, the second identifier (IDENT₂) may be, or related to, one or more identifiers associated with the mobile device <b>102</b>, lock device <b>104</b>, application <b>128</b>, and/or correspond to the registered user account. Further, according to certain embodiments, the second identifier (IDENT₂) may, or may not, include at least some of the same identifier(s) used for the first identifier (IDENT₁). For example, the second lock identifier (IDENT₂) may include one or more of the lock identifiers used in the first identifier (IDENT₁) such as, for example, a serial number (S/N), production code, or production date, among other lock identifiers. Additionally, the second identifier (IDENT₂) may and/or may not be encrypted with the first data set. For example, the second identifier (IDENT₂), may be appended to the first data set prior to the first data set being encrypted by the lock device <b>104</b> 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 (IDENT₂) that may, or may not, contain the same or similar identifier information that was with the second identifier (IDENT₂) that was encrypted by the lock device <b>104</b> with the first data set. According to such an embodiment, the second data set may be expressed as: <br />IDENT₂<i>,SK</i>(IDENT₂,IDENT₁,AppToken)  (Ex. 3)

At step <b>420</b>, the lock device <b>104</b> communicates the second data set to the mobile device <b>102</b>, and more specifically, for the application <b>128</b>. According to the illustrated embodiment, at step <b>422</b>, the application <b>128</b> may append non-encrypted information to the second data set to generate a third data set. For example, in the illustrated embodiment, the application <b>128</b> may append the second data set to include information relating to a third identifier (IDENT₃). According to certain embodiments, the third identifier (IDENT₃) may contain the same or similar data or information as the first and second identifiers (IDENT₁, IDENT₂). According to such an embodiment, the third data set from the application <b>128</b> may be represented as: <br />IDENT₃,IDENT₂<i>,SK</i>(IDENT₂,IDENT₁,AppToken)  (Ex. 4)

At step <b>424</b>, the third data set is communicated from the application <b>128</b> via the mobile device <b>104</b>, to the server <b>106</b>. For example, according to certain embodiments, the mobile device <b>102</b> may transmit the third data set to the cloud-based server <b>106</b><i>a</i>. The server <b>106</b> may then extract non-encrypted data or information from the application <b>128</b> and information that has been encrypted by the lock device <b>104</b>, to verify that the application <b>128</b> and/or mobile device <b>104</b> from which the server <b>106</b> received the third data set is the related to, and possibly the same as, the application <b>128</b> and/or mobile device that communicated with the lock device <b>104</b>. Therefore, at step <b>426</b>, the server <b>106</b> 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 (IDENT₂) and the third identifier (IDENT₃). At step <b>428</b>, the server <b>106</b> may then utilize the extracted non-encrypted data to identify the corresponding lock device <b>104</b> and associated information relating to the lock device <b>104</b>. For example, in the illustrated embodiment, the server <b>106</b> may utilize the extracted non-encrypted identifier(s) from the third data set to identify and retrieve, from the database <b>129</b> of the server <b>106</b> and/or the auxiliary database <b>130</b>, information relating to the lock device <b>104</b>.

At step <b>430</b>, the server <b>106</b> 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 <b>106</b> may utilize extract identifiers from the non-encrypted portion of the second and third identifiers (IDENT₂, IDENT₃) 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 <b>106</b> may utilize the second key (SK) to decrypted the second data set contained in the third data set, and thereby extract the second identifier (IDENT₂), the first identifier (IDENT₁), and the application token (AppToken). Then, using the associated encryption key such as, for example, the first key (FK), the server <b>106</b> 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 (IDENT₁).

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 (IDENT₁, IDENT₂, IDENT₃) 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 (IDENT₁), may be subsequently subjected to encryption by the lock device <b>104</b> 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 (IDENT₂) that was also encrypted, with or without data from the encrypted application token (AppToken), using the second key (SK). Thus, the server <b>106</b> may utilize a different number of encryption keys to extract various encrypted information from the third data set.

At step <b>432</b>, the server <b>106</b> may compare two or more of the identifiers (IDENT₁, IDENT₂, IDENT₃) obtained from the third data set such as, for example, comparing the second identifier (IDENT₂) that was added to the encrypted application token (AppToken) in the second data set with the first identifier (IDENT₁) that was contained in the encrypted application token. Additionally, according to certain embodiments, the server <b>106</b> may also compare the third identifier (IDENT₃) from the third data set with the extracted first identifier (IDENT₁) and/or the extracted second identifier (IDENT₂). If the server <b>106</b> determines at step <b>434</b> 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 <b>128</b>, lock device(s) <b>104</b>, and/or mobile device <b>102</b>, among other relations, then at step <b>436</b> the server <b>106</b> may terminate communication with the application <b>128</b>. If however, the server <b>106</b> confirms that the compared, extracted identifiers (IDENT₁, IDENT₂, IDENT₃) are related to each other, the server <b>106</b> may record one or more of the identifiers (IDENT₁, IDENT₂, IDENT₃), or portions of the identifiers (IDENT₁, IDENT₂, IDENT₃) to a record or database associated with the lock device <b>104</b> such as, for example, a database <b>129</b> of the server <b>106</b> and/or the auxiliary database <b>130</b>.

At step <b>440</b>, the server <b>106</b> 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 <b>128</b> and/or mobile device <b>102</b>. For example, in the illustrated embodiment, the data or information encrypted by the server <b>106</b> at step <b>440</b> may include a fourth identifier (IDENT₄) 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 <b>440</b> 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: <br /><i>TK</i>(IDENT₄<i>,FFK</i>)  (Ex. 5)

At step <b>442</b>, the fourth data set may be operably communicated to the application <b>128</b>. At step <b>444</b>, the application <b>128</b> 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 <b>104</b>. According to the illustrated embodiment, in generating the fifth data set, the application <b>128</b> may append to the fourth data a fifth identifier (IDENT₅), such that the fifth data set may be expressed as: <br />IDENT₅<i>,TK</i>(IDENT₄<i>FFK</i>)  (Ex. 6)<br /> 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.

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

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

With authentication established, at step <b>464</b> the lock device <b>104</b> and application <b>128</b> may proceed with communicating with each other. For example, according to certain embodiments, the lock device <b>104</b> and application <b>128</b> 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 <b>104</b> such as, for example, configuration of the lock device <b>104</b> through use of the application <b>128</b>. Moreover, such configuration of the lock device <b>104</b> may then proceed without the lock device <b>104</b> having to repeatedly communicate with the server <b>106</b>.

At step <b>466</b>, the lock device <b>104</b> may erase, destroy, ignore, or otherwise discard at least a portion of information associated with communications between the lock device <b>104</b> and the application <b>128</b> 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 <b>128</b> and the lock device <b>104</b>, time period between subsequent communications between the application <b>128</b> and the lock device <b>104</b>, number of times the lock device <b>104</b>, or associated lock mechanism <b>123</b>, has been operated. For example, in the illustrated embodiment, the information associated with communications between the lock device <b>104</b> and the application <b>128</b> may be discarded from the lock device <b>104</b> every 6 hours, 12 hours, or 24 hours. Thus, after the such information has been discarded, the application <b>128</b> may need to contact the server <b>106</b> to retrieve at least a new AppToken, thereby imparting the system <b>100</b> with at least a degree of dynamic keying. With the generation of a new AppToken, the application <b>128</b> may again contact the lock device <b>104</b> at step <b>408</b> and proceed again with recapturing the lock device <b>104</b>.

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 spirit and scope of the present invention and without diminishing its intended advantages.

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.