阅读说明：本技术 用于为锁定系统动态递送访问凭证的系统和方法 (System and method for dynamic delivery of access credentials for a locking system ) 是由 J·巴尔图奇 K·安德森 B·巴纳赫 G·米勒 于 2020-03-06 设计创作，主要内容包括：一种锁定系统包括多个电子锁定设备和服务器。服务器被配置为接收关于多个电子锁定设备中的每一个的位置的锁定位置数据,接收关于多个用户设备中每一个的当前位置的用户设备位置数据,根据基于锁定位置数据和用户设备位置数据的地理围栏递送协议向多个用户设备中的每一个递送访问凭证,响应于使用地理围栏递送协议而监控当前聚合负载,以及响应于当前聚合负载超过负载阈值,根据非地理围栏递送协议向多个用户设备中的一个或更多个递送访问凭证,以减少当前聚合负载。(A locking system includes a plurality of electronic locking devices and a server. The server is configured to receive lock position data regarding a location of each of the plurality of electronic locking devices, receive user device location data regarding a current location of each of the plurality of user devices, deliver access credentials to each of the plurality of user devices according to a geo-fence delivery protocol based on the lock position data and the user device location data, monitor a current aggregate load in response to using the geo-fence delivery protocol, and deliver the access credentials to one or more of the plurality of user devices according to a non-geo-fence delivery protocol to reduce the current aggregate load in response to the current aggregate load exceeding a load threshold.)

1. A method of dynamically delivering access credentials, the method comprising:

storing, by a server, a plurality of access credentials;

receiving, by the server, a plurality of geofence settings for geofences of a plurality of user devices used during a geofence delivery protocol;

receiving, by the server, locking location data regarding a location of each of a plurality of locking devices;

receiving, by the server, first user device location data from respective user devices of the plurality of user devices regarding first locations of the respective user devices;

determining, by the server, a first locked subset of the plurality of locking devices within a geofence based on the locking location data and the first user device location data;

delivering, by the server, a first subset of credentials of the plurality of access credentials to the respective user device, wherein the first subset of credentials is (i) associated with the respective user device and (ii) corresponds to the first locked subset;

receiving, by the server, second user device location data from the respective user device regarding a second location of the respective user device;

determining, by the server, a second locked subset of the plurality of locked devices within the geofence based on the locked location data and the second user device location data; and

delivering, by the server, a second subset of credentials of the plurality of access credentials to the respective user device, wherein the second subset of credentials is (i) associated with the respective user device and (ii) corresponds to the second locked subset within the geofence.

2. The method of claim 1, wherein the second subset of credentials replaces the first subset of credentials.

3. The method of claim 1, wherein the first subset of credentials remains on the respective user device until a specified condition is satisfied regardless of the respective user device receiving the second subset of credentials.

4. The method of claim 1, wherein a frequency with which the server provides the respective user device with the credential subset of the plurality of access credentials varies based on a current aggregate load on the server.

5. The method of claim 1, wherein the geofence is based on a plurality of predefined coverage zones of a building or building floor, wherein the first subset of locks is located within a first predefined coverage zone of the plurality of predefined coverage zones, and wherein the second subset of locks is located within a second predefined coverage zone of the plurality of predefined coverage zones.

6. The method of claim 5, further comprising:

receiving, by the server, a first indication that a user of the respective user device is marked as a first building or a first floor associated with the first predefined coverage zone;

delivering, by the server, the first subset of credentials in response to the first indication;

receiving, by the server, a second indication that a user of the respective user device is marked as a second building or a second floor associated with the second predefined coverage zone; and

delivering, by the server, the second subset of credentials in response to the second indication.

7. The method of claim 1, wherein the geofence is defined based on a predefined area subdivided into a plurality of sectors, wherein the first subset of locks is located within a first sector of the plurality of sectors, and wherein the second subset of locks is located within a second sector of the plurality of sectors.

8. The method of claim 1, wherein the geofence is defined based on a preset radius extending from a current location of the respective locking device.

9. The method of claim 8, further comprising decreasing, by the server, the preset radius of the geofence in response to a current aggregate load on the server exceeding a load threshold.

10. The method of claim 1, wherein the locking location data indicates at least one of (i) a real-time location, (ii) a last known location, or (iii) a fixed location of each of the plurality of locking devices.

11. The method of claim 10, wherein the server receives the lockdown location data from (i) one or more of the plurality of lockdown devices directly, (ii) one or more of the plurality of lockdown devices indirectly via one or more of the plurality of user devices, or (iii) one or more of the plurality of user devices without receiving the lockdown location data from the plurality of lockdown devices.

12. The method of claim 1, further comprising transitioning, by the server, from using the geo-fence delivery protocol to using a non-geo-fence delivery protocol to deliver, to one or more of the plurality of user devices, an access credential of the plurality of access credentials associated with one or more of the plurality of user devices in response to a current aggregate load on the server exceeding a load threshold.

13. The method of claim 12, wherein transitioning from using the geo-fence delivery protocol to using the non-geo-fence delivery protocol to deliver access credentials of the plurality of access credentials associated with one or more of the plurality of user devices to one or more of the plurality of user devices based on at least one of a permission level or a subscription level of the respective user causes a first user device of the plurality of user devices associated with a first user having a first permission level or a first subscription level to receive the respective access credentials associated with the first user according to the non-geo-fence delivery protocol prior to a second user device of the plurality of user devices associated with a second user having a second permission level or a second subscription level.

14. The method of claim 13, further comprising:

monitoring, by the server, the current aggregate load on the server as a result of monitoring by the server as a result of delivering the access credential to one or more of the plurality of user devices using the non-geo-fencing transport protocol delivery protocol; and

in response to the current aggregate load exceeding the load threshold, performing at least one of:

(i) increasing, by the server, a number of the plurality of user devices receiving the access credential via the non-geo-fence delivery protocol; or

(ii) Delivering, by the server, the access credential associated with one or more of the plurality of user devices to one or more of the plurality of user devices using a different non-geo-fence delivery protocol.

15. The method of claim 1, wherein at least one of the plurality of locking devices is a portable locking device, and wherein at least one of the plurality of locking devices is a fixed locking device.

16. A method of dynamic access credential delivery, the method comprising:

storing, by the server, the access credential;

receiving, by the server, a plurality of geofence settings for a plurality of geofences for a plurality of user devices;

receiving, by the server, locking location data regarding a location of each of a plurality of locking devices;

receiving, by the server, user device location data regarding a current location of each of the plurality of user devices;

executing, by the server, a geo-fence delivery protocol for delivering the access credential to the plurality of user devices, wherein the geo-fence delivery protocol comprises, for each of the plurality of user devices:

determining, based on the (i) a locked subset of a plurality of locking devices within geofences of a plurality of geofences of a user device of the plurality of user devices based on the locked location data and the user device location data and (ii) the plurality of locking devices accessible by a user of the user device;

determining a credential subset of the access credential associated with the lock subset; and

delivering the subset of credentials to the user equipment;

monitoring, by the server, a current aggregate load on the server using a geofence transport protocol; and

transitioning, by the server, from the geo-fence delivery protocol to a non-geo-fence delivery protocol to deliver the access credential to at least one of the plurality of user devices to reduce the current aggregate load on the server in response to the current aggregate load exceeding a load threshold.

17. The method of claim 16, wherein the non-geofence delivery protocol is a first non-geofence delivery protocol, further comprising:

monitoring, by the server, the current aggregated load on the server as a result of delivering the access credential to at least one of the plurality of user devices using the non-geo-fence delivery protocol; and

in response to the current aggregated load again exceeding the load threshold, delivering, by the server, the access credential to at least one of the plurality of user devices receiving the access credential via the first non-geo-fence delivery protocol using a second non-geo-fence delivery protocol different from the first non-geo-fence delivery protocol.

18. The method of claim 16, further comprising:

monitoring, by the server, the current aggregated load on the server as a result of delivering the access credential to at least one of the plurality of user devices using the non-geo-fence delivery protocol; and

increasing, by the server, a number of the plurality of user devices receiving the access credential via the non-geo-fence delivery protocol in response to the current aggregated load again exceeding the load threshold.

19. A locking system, comprising:

a plurality of electronic locking devices; and

a server configured to:

receiving lock position data regarding a position of each of the plurality of electronic lock devices;

receiving user equipment location data regarding a current location of each of a plurality of user equipment;

delivering access credentials to each of the plurality of user devices in accordance with a geo-fence delivery protocol based on the locking location data and the user device location data;

monitoring a current aggregate load in response to using the geofence delivery protocol; and

delivering access credentials to one or more of the plurality of user devices according to a non-geo-fence delivery protocol to reduce the current aggregate load in response to the current aggregate load exceeding a load threshold;

wherein at least one of the plurality of electronic locking devices is disconnected from the server and unable to communicate directly with the server; and

wherein at least one of the plurality of electronic locking devices is configured to:

receiving respective access credentials from respective user devices; and

deciding to initiate an access control session with the respective user device independent of the server based on the respective access credentials received from the respective user device.

20. The locking system of claim 19, wherein the plurality of user devices includes (i) a first user device associated with a first user having at least one of a first permission level or a first subscription level and (ii) a second user device associated with a second user having at least one of a second permission level or a second subscription level, and wherein the server is configured to begin delivering access credentials to the first user device in accordance with the non-geo-fence delivery protocol before beginning delivering access credentials to the second user device in accordance with the non-geo-fence delivery protocol.

Background

The electronic lock may be accessed (e.g., unlocked, settings changed, etc.) using a user's personal device (e.g., a smartphone). Typically, the user's personal device and the corresponding electronic lock will interact with each other so that access decisions can be made by the phone and/or the electronic lock (e.g., based on access rights). As electronic locks become mainstream, the number of electronic locks owned by businesses or individuals has increased dramatically. Managing access rights to such a large number of electronic locks on each user's personal device may become unwieldy and consume a large amount of storage space on each user's personal device, and increase the vulnerability of the security system in the event that one of the user's personal devices is compromised (e.g., stolen, hacked, etc.) by the access rights of the hundreds of electronic locks stored thereon.

Disclosure of Invention

One embodiment relates to a method for dynamic delivery of access credentials. The method includes storing, by a server, a plurality of access credentials; receiving, by a server, a plurality of geofence settings for a geofence of a plurality of user devices used during a geofence delivery protocol; receiving, by a server, locking location data regarding a location of each of a plurality of locking devices; receiving, by a server, first user device location data from respective ones of a plurality of user devices regarding a first location of the respective user devices; determining, by the server, a first locked subset of the plurality of locking devices within the geofence based on the locking location data and the first user device location data; delivering, by the server, a first subset of credentials of the plurality of access credentials to the respective user device, wherein the first subset of credentials is (i) associated with the respective user device and (ii) corresponds to a first locked subset; receiving, by the server, second user device location data regarding a second location of the respective user device from the respective user device; determining, by the server, a second locked subset of the plurality of locked devices within the geofence based on the locked location data and the second user device location data; and delivering, by the server, a second subset of credentials of the plurality of access credentials to the respective user device, wherein the second subset of credentials is (i) associated with the respective user device and (ii) corresponds to a second locked subset within the geofence.

Another embodiment relates to a method for dynamic access credential delivery. The method includes storing, by a server, a plurality of access credentials; receiving, by a server, a plurality of geofence settings for a plurality of geofences for a plurality of user devices; receiving, by a server, locking location data regarding a location of each of a plurality of locking devices; receiving, by a server, user device location data regarding a current location of each of a plurality of user devices; executing, by a server, a geo-fence delivery protocol for delivering access credentials to a plurality of user devices; monitoring, by a server, a current aggregated load on the server using a geofence delivery protocol; and transitioning, by the server, from the geo-fence delivery protocol to a non-geo-fence delivery protocol to deliver the access credential to at least one of the plurality of user devices to reduce a current aggregate load on the server in response to the current aggregate load exceeding a load threshold. For each of the plurality of user devices, the geo-fence delivery protocol includes: (i) determine, based on the locking location data and the user device location data, a locked subset of a plurality of locking devices within geofences of a plurality of geofences of a user device of the plurality of user devices and (ii) the plurality of locking devices accessible by a user of the user device; determining a subset of credentials for access credentials associated with the subset of locks; and delivering the subset of credentials to the user device.

Yet another embodiment relates to a locking system. The locking system includes: a plurality of electronic locking devices and a server. The server is configured to receive lock location data regarding a location of each of the plurality of electronic lock devices, receive user device location data regarding a current location of each of the plurality of user devices, deliver access credentials to each of the plurality of user devices according to a geo-fence delivery protocol based on the lock location data and the user device location data, monitor a current aggregate load in response to using the geo-fence delivery protocol, and deliver the access credentials to one or more of the plurality of user devices according to a non-geo-fence delivery protocol to reduce the current aggregate load in response to the current aggregate load exceeding a load threshold. At least one of the plurality of electronic locking devices is disconnected from the server and unable to communicate directly with the server. At least one of the plurality of electronic locking devices is configured to receive a respective access credential from a respective user device; and deciding to initiate an access control session with the respective user device independent of the server based on the respective access credentials received from the respective user device.

Yet another embodiment relates to a method for dynamically receiving access credentials. The method includes sending, by a mobile user device, first user device location data regarding a first location of the mobile user device to a server, wherein the server stores a geofence associated with the mobile user device, a plurality of access credentials associated with the mobile user device, and a last known or current location of each of a plurality of locking devices; receiving, by the mobile user device, a first subset of credentials of the plurality of access credentials from the server based on the geofence, the first user device location data, and a last known location or a current location of each of the plurality of locking devices; sending, by the mobile user device, second user device location data regarding a second location of the mobile user device to the server; and receiving, by the mobile user device, a second subset of the plurality of access credentials from the server based on the geofence, the second user device location data, and a last known location or a current location of each of the plurality of locking devices. In some embodiments, the method includes receiving, by the mobile user device, one or more of the plurality of access credentials from the server in accordance with a non-geo-fence delivery protocol to reduce a current aggregate load on the server in response to the current aggregate load on the server exceeding a load threshold.

This summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the described apparatus or process will become apparent in the detailed description set forth in conjunction with the drawings, in which like reference numerals refer to like elements.

Drawings

FIG. 1 is a block diagram of a system for wireless user profile management among one or more servers, one or more user devices, and/or one or more locking systems, according to an example embodiment.

Fig. 2A and 2B are block diagrams of one or more servers of fig. 1, according to an example embodiment.

Fig. 3A depicts a first technique for implementing geofencing using the system for wireless user profile management of fig. 1, according to an exemplary embodiment.

Fig. 3B depicts a second technique for implementing geofencing using the system for wireless user profile management of fig. 1, in accordance with an exemplary embodiment.

Fig. 3C depicts a third technique for implementing geofencing using the system for wireless user profile management of fig. 1, according to an exemplary embodiment.

Fig. 4 is a block diagram of one or more user devices of fig. 1, according to an example embodiment.

Fig. 5 is a first graphical user interface provided by one or more user devices of fig. 4, according to an example embodiment.

Fig. 6 is a second graphical user interface provided by one or more user devices of fig. 4, according to an example embodiment.

Fig. 7 is a third graphical user interface provided by one or more user devices of fig. 4, according to an example embodiment.

FIG. 8 is a block diagram of one or more locking systems of FIG. 1, according to an example embodiment.

Fig. 9 is a perspective view of a first locking system of the one or more locking systems of fig. 8, according to an exemplary embodiment.

Fig. 10 is a perspective view of a second locking system of the one or more locking systems of fig. 8, according to an exemplary embodiment.

Fig. 11 is a perspective view of a third locking system of the one or more locking systems of fig. 8, according to an exemplary embodiment.

Fig. 12 is a schematic illustration of a fourth locking system of the one or more locking systems of fig. 8, according to an exemplary embodiment.

Fig. 13 is a flowchart of a method for delivering one or more user profiles to a user device based on a proximity/geofence delivery protocol, in accordance with an exemplary embodiment.

FIG. 14 is a flowchart of a method for interacting with a locking system using a user device, according to an example embodiment.

FIG. 15 is a flowchart of a method for dynamically delivering a user profile to a user device, according to an example embodiment.

Detailed Description

Before turning to a detailed description of certain exemplary drawings, it is to be understood that the disclosure is not limited to the detailed methods set forth in the specification or illustrated in the drawings. It is also to be understood that the terminology, which has been used, is for the purpose of description only and should not be regarded as limiting.

As used herein, the term "disconnected device" refers to a device that cannot communicate directly with a server, but rather requires an intermediate device (e.g., a smartphone, etc.) that communicates short-range with the disconnected device to facilitate data transfer between the disconnected device and the server. As used herein, the term "connected device" refers to a device that can communicate directly with a server (e.g., using a telecommunication protocol, cellular, radio, Wi-Fi, etc.) without such intermediate devices (excluding routers/modems of the Wi-Fi architecture). As used herein, the term "key" (e.g., lock key, user key, cryptographic key, etc.) denotes a numeric or alphanumeric code, which may be, for example, a parameter in a block cipher algorithm used to determine a forward cipher function. As used herein, the term "random number" (e.g., a handshaking random number, a reply random number, a modified reply random number, etc.) refers to a value that is used only once in a given context.

Overview of the system

According to the exemplary embodiments shown in fig. 1-12, an access credential management system, shown as a user profile management system 10, includes a remote server (e.g., a credential management server, a profile management server, etc.), shown as a server 100, a portable device (e.g., a smartphone, a mobile phone, a cellular phone, a tablet, a laptop, a smartwatch, a smartcard, a card, etc.), shown as a user device 200, and a product (e.g., an electronic locking device, an electronic padlock, an electronic disk lock, an electronic safe, an electronic and portable lockbox, an electronic locker, an electronic door lock, a door access system, etc.), shown as a locking system 300. As shown in fig. 1, the server 100 is configured to communicate with the user device 200 (e.g., using a first communication protocol, using a long range communication protocol, cellular, Wi-Fi, radio, etc.), and the user device 200 is configured to communicate with the locking system 300 (e.g., using a second communication protocol, using a short range communication protocol, bluetooth low energy ("BLE"), near field communication ("NFC"), radio frequency identification ("RFID"), etc.). User device 200 may thus act as an intermediary device facilitating data transfer between server 100 and locking system 300 (e.g., if locking system 300 is a disconnected device, etc.). In some embodiments, the locking system 300 is configured to facilitate direct communication with the server 100 (e.g., using a remote communication protocol, cellular, Wi-Fi, radio, etc.). In some embodiments, the server 100 is or includes a plurality of servers. In some embodiments, the server 100 communicates with a plurality of user devices 200. In some embodiments, user device 200 communicates with multiple locking systems 300. In some embodiments, the server 100 is in communication with a plurality of locking systems 300.

According to an exemplary embodiment, server 100 is configured to manage a plurality of access credentials or user profiles for a plurality of users having access to at least one of locking systems 300 associated with user profile management system 10. The server 100 is further configured to selectively deliver one or more user profiles of respective users to respective user devices 200 (e.g., owned, operated, etc. by respective users) according to a profile delivery protocol (e.g., based on location, server load, etc.). According to an exemplary embodiment, server 100 implements a profile delivery protocol that delivers one or more user profiles associated with respective users to their user devices 200 based on the current location and geofence of user devices 200. In some embodiments, the server 100 implements a dynamic profile delivery protocol that delivers one or more user profiles of respective users to respective user devices 200 according to various different profile delivery protocols based on current demand or load on the server 100 (e.g., throttling techniques to reduce server load, etc.).

In general, a user profile may include one or more files that include data related to the operation of the corresponding locking system 300. For example, a user profile may contain when the associated locking system 300 may be accessed (unlocked, locked, etc.). The calendar may specify lock access rights, e.g., by day of the week, including a start time (hours, minutes, etc.) and an end time (hours, minutes, etc.) for each respective right. For example, a calendar may specify a time span over which an associated locking system 300 may be unlocked via a user device 200 of a particular user associated with a user profile. As another example, a calendar may specify time periods in which typical interactions are expected to occur, and the trust level may be determined based on these time periods. Thus, an unlock request sent during an expected time period may be more trusted by the associated locking system 300 than a request sent at an unexpected/atypical time. In one embodiment, a default user schedule is set (e.g., by the manufacturer, etc.). In addition, a list of typical user calendars may be provided to allow the user to select from one of a number of configuration options. In this way, the manufacturer may provide various recommended operational settings to the user. The user may also customize the calendar to suit his or her needs (e.g., administrator, etc.).

The user profile may also specify the model/serial number of the associated locking system 300 and the types of access available to the user. For example, such access may include: reading software/hardware version information of the associated locking system 300, updating software of the associated locking system 300, reading shackle/latch status, lock, unlock, read/set time/clock values of the associated locking system 300, reading battery power, reading/clearing event related data (e.g., flags, counters, etc.), reading a log of locks, reading/setting/resetting keypad codes of the associated locking system 300, reading communication data (e.g., transmission status, transmission power level, channel information, addressing information, etc.) of the associated locking system 300, reading/setting default values (e.g., default number of releases, default unlock time, etc.) stored by the associated locking system 300, etc. The user profile may also specify a start time and a revocation date/time for the user profile (i.e., when the user profile starts to be valid and when the user profile expires and is no longer valid). The user profile may provide a maximum release/unlock time for the associated locking system 300. The user profile may also provide an indication of the trust level of the corresponding user device 200 (e.g., whether the time value/timestamp provided by the user device 200 is trusted). The locking system 300 may be configured to enable or disable certain functions based on the trust level of the respective user device 200 requesting access. The trust level may be stored as a separate license that may or may not be accessible to the user (e.g., the trust level may be managed/adjusted by software of locking system 300, user device 200, server 100, etc.). For example, only highly trusted user devices 200 may be able to upgrade the firmware of the respective locking system 300 or change certain settings.

Further, locking system 300 may have a security algorithm that takes into account trust level and time values. For example, as the respective user device 200 successfully interacts with the respective locking system 300 more frequently, the respective locking system 300 may increase (or adjust) the trust level of the respective user device 200. However, if the time value is not synchronized with the maintenance time of the corresponding locking system 300 or the authentication fails, the corresponding locking system 300 may decrease (or adjust) the trust level of the corresponding user equipment 200. The time value provided by the respective user device 200 may be compared to the time value maintained by the respective locking system 300, and the proximity between the two times may be used to indicate the trust level of the respective user device 200 (e.g., the closer the two times are to synchronization, the higher the trust level, etc.). If the trust level falls below a certain threshold, the respective locking system 300 may interrupt or restrict interaction with the respective user device 200. The trust level may also be based on the calendar discussed above. For example, a respective user device 200 may be considered more or less trusted based on the time at which the respective user device 200 accessed a respective locking system 300 and whether the time falls within a particular time period defined by a calendar. The time value provided by the respective user device 200 may also be used to synchronize the clock of the respective lock system 300 with the clock of the respective user device 200, or may be otherwise used during authentication communication. Any of the user profile items discussed may have default values (e.g., manufacturer default values) or user-provided values (e.g., from a user with administrator privileges, etc.). The user profile is not limited to the above data and may include or exclude additional data.

According to an exemplary embodiment, user profile management system 10 implements a method of providing secure communication between user device 200 and locking system 300 (and/or server 100 in direct communication with server 100 and locking system 300 for locking system 300) by utilizing a dual-key authentication mechanism, without the need to store both keys on locking system 300 (e.g., during the manufacturing phase). In such embodiments, (i) the first key or locking key is known/stored on each locking system 300 and server 100, unique to each locking system 300, and (ii) the second key or user key is known/stored on each user device 200, unique to each user device 200 or user profile and not pre-stored on any locking system 300. Each locking key, each user key, and each user profile may be specific to a respective locking system 300. In this manner, the locking key, user key, and user profile may be uniquely associated with a single locking system 300. According to an exemplary embodiment, server 100 is configured to encrypt each user profile using the locking key of locking system 300 associated with the user profile. When attempting to access locking system 300, user device 200 may receive a lock identifier from locking system 300 and compare the lock identifier to a list of lock identifiers associated with one or more encrypted user profiles currently loaded on user device 200 (e.g., delivered according to a profile delivery protocol). If a match is found, user device 200 may transmit the associated encrypted user profile to locking system 300. The encrypted user profile includes a user key. The locking system 300 may decrypt the encrypted user profile using a locking key previously stored thereon to obtain the user key. User device 200 may then generate and send the encrypted command to locking system 300. The encryption command is encrypted using the user key. Locking system 300 may then decrypt the encrypted command using the user key obtained from the decrypted user profile and initiate the action specified by the decrypted command (e.g., unlock the physical locked component, implement a firmware update, etc.). In some cases, the dual-key authentication process including the locking key and the user key further includes a handshake random number, a reply random number, and/or a modified reply random number, as described in more detail.

It should be understood that the dual-key authentication mechanism described above is not meant to be limiting, but is provided as an example of one possible way of providing secure communication between the server 100, the user device 200 and the locking system 300 of the user profile management system 10. In still other embodiments, the secure communication is established using different authentication mechanisms, such as using a digital signature, a challenge-response procedure, multi-factor authentication (e.g., two-factor authentication, user profile plus biometric, user profile plus PIN, etc.), and/or other suitable authentication mechanisms.

Server

As shown in fig. 2A, server 100 includes a processing circuit 102 and a network interface 148. The processing circuit 102 has a processor 104 and a memory 106. The processing circuitry 102 may include a general purpose processor, an application specific integrated circuit ("ASIC"), one or more field programmable gate arrays ("FPGAs"), a digital signal processor ("DSP"), circuitry including one or more processing components, circuitry to support a microprocessor, a set of processing components, or other suitable electronic processing components. In some cases, processor 104 is configured to execute computer code stored in memory 106 to facilitate the activities described herein. Memory 106 may be any volatile or non-volatile computer-readable storage medium capable of storing data or computer code related to the activities described above. According to an exemplary embodiment, the memory 106 includes computer code modules (e.g., executable code, object code, source code, script code, machine code, etc.) configured to be executed by the processor 104.

According to an exemplary embodiment, network interface 148 is configured to facilitate wireless communication to and from server 100 (i) directly to and from user device 200, (ii) indirectly to and from at least one of locking systems 300 via user device 200 (e.g., for locking system 300 as a disconnected device), and/or (iii) directly to and from at least one of locking systems 300 (e.g., for locking system 300 as a connected device). The server 100 may communicate with the user device 200 and/or the locking system 300 directly or via an intermediate network (e.g., an internet network, a cellular network, etc.). For example, network interface 148 may include physical network components (e.g., network cards, etc.) configured to allow server 100 to establish a connection to user device 200 and/or locking system 300. In one embodiment, communications from network interface 148 are routed through a cellular interface, allowing server 100 to communicate with user device 200 and/or locking system 300 via a cellular network. In one embodiment, network interface 148 allows server 100 to establish an internet-based connection with user device 200 and/or locking system 300. The server 100 may be one server (physical or virtual) or may include a plurality of servers.

According to an exemplary embodiment, memory 106 of server 100 includes various modules configured to (i) generate and securely store a locking key, a user key, and a user profile, and (ii) selectively and/or dynamically deliver an encrypted user profile (e.g., each user profile including an associated user key) to user device 200 based on one or more factors, including a location of user device 200, permissions (e.g., permission/authorization levels, calendar, etc.) of a user of user device 200, a current cumulative load on server 100, and/or other possible factors.

As shown in FIG. 2A, memory 106 of server 100 includes a locking key module 108, a user key module 110, a random number module 112, a user profile module 114, a location module 116, a permissions module 118, a geofencing module 120, and a throttling module 122. In some embodiments, memory 106 does not include random number module 112. In some embodiments, memory 106 does not include throttle module 122. For example, the memory 106 may not include the throttling module 122 in the user profile management system 10, the system 10 having less than a threshold number of locking systems 300 associated therewith and/or managed thereby (e.g., less than 100, 200, 500, 1000, etc. locking systems 300).

Locking key module 108 is configured to generate and securely store a locking key (e.g., which may be provided to locking system 300 at the time of manufacture, etc.). As an example, locking key module 108 may correspond to a first database of keys and may include software configured to store and retrieve such keys from the first database. Locking key module 108 may be further configured to facilitate updating, replacing, and/or deleting a locking key (e.g., if the corresponding locking key on the corresponding locking system 300 is compromised, etc.), which may be propagated to the associated locking system 300 using the described methods (e.g., directly for connected devices, indirectly for disconnected devices through user device 200, etc.).

User key module 110 is configured to generate and securely store a user key (e.g., when a user is registered with a corresponding locking system 300, etc.). As an example, the user key module 110 may correspond to a second key database and may include software configured to store and retrieve such keys from the second database. User key module 110 may also be configured to facilitate updating, replacing, and/or deleting user keys (e.g., if a user's access is revoked, if a user key expires, etc.), which may be updated as needed in an associated user profile.

Random number module 112 is configured to generate a handshaking random number for each user profile each time the user profile is transmitted to user device 200. In some modules, no handshaking random number is used.

The user profile module 114 is configured to generate and securely store a user profile. As an example, the user profile module 114 may correspond to a third database of user profiles and may include software configured to store and retrieve such user profiles from the third database. The user profile module 114 may also be configured to facilitate updating, replacing, and/or deleting a user profile. For example, user profile module 114 may be configured to generate a user profile for a particular user and/or lock system 300 when a new user is added to a corresponding lock system 300 in response to expiration of the corresponding user profile. The user profile module 114 is also configured to encrypt the user profile before or while it is being transmitted to the user device 200. For example, when a user profile is transmitted to a respective user device 200, the user profile module 114 may be configured to (i) insert or append an associated user key into the user profile, (ii) encrypt the user profile and the user key using (a) a locking key associated with a particular locking system 300 and/or (b) a handshaking random number (in embodiments using a handshaking random number) to generate an encrypted user profile, and/or (iii) append the user key (a) and/or (b) a handshaking random number (in embodiments using a handshaking random number) into the encrypted user profile. The user profile module 114 may also be configured to facilitate updating, replacing, and/or deleting a user profile (e.g., if a user's access is revoked, if a user key is updated, etc.).

The location module 116 is configured to receive first location data (e.g., in real-time, periodically, etc.) from the user device 200 regarding a current location of the user device 200. In some embodiments, the location module 116 is configured to receive the second location data 300 from the user device 200 and/or the locking system 300, the second location data 300 being related to a current location (e.g., real-time) and/or a last known location of the locking system 300. In some embodiments, the location module 116 is configured to store predetermined locations of one or more locking systems 300 (e.g., a fixed locking system). The first location data and the second location data may be generated by user device 200 and/or locking system 300, as described in more detail herein.

The permissions module 118 is configured to receive and store access permissions of users associated with one or more locking systems 300. The access permissions may include an authorization or permission level of the user (e.g., administrator permissions, limited permissions, etc.) that defines which locking system 300 the respective user can access and/or restrict their access to (e.g., a first user may unlock or lock only the respective locking system 300 without changing its settings, while a second user may unlock or lock the respective locking system 300 and change its settings, etc.). Access permissions may also include an access calendar, as described in more detail herein, that limits the number of times a user may access a respective locking system 300 and/or affects the level of trust of a user attempting to access a respective locking system 300 outside of the access calendar.

Geofence module 120 is configured to selectively deliver a subset of the encrypted user profiles associated with the respective users (e.g., stored in user profile module 114) to user devices 200 of the respective users based on (i) a current location of user devices 200 (e.g., received by location module 116), (ii) a current location or last known location of locking system 300 to which the respective users have access (e.g., received by location module 116), and (iii) the geofences assigned to the respective users and stored in geofence module 120. The size (e.g., radius) of the geofence may be static or may be dynamic (e.g., based on day of the week, time of day, current load on the server 100, etc.). The geofences may be predefined and fixed according to user adjustments (e.g., set by an administrator, according to a subscription level of the user or company, based on current demand for the server 100, etc.), or selectively adjusted based on user preferences. For example, geo-fence module 120 may dynamically decrease the size of the geo-fence when the load on server 100 exceeds various thresholds.

As shown in fig. 3A, geofence module 120 is configured to implement a first geofence, displayed as geofence 160, defined based on a radius extending from a location of user device 200 of the respective user, displayed as current location 150. The geofence 160 thus forms a circle extending around the current location 150 of the user device 200. The radius of the geofence 160 may be fixed according to user adjustments (e.g., based on a subscription level of the user or company with which the user is associated, based on load on the server 100, etc.) or selectively adjusted based on user preferences (e.g., from 100 feet to 5 miles, etc.). Geofence module 120 is configured to deliver only encrypted user profiles for locking systems 300 located within geofence 160 and/or to which the respective users have access (e.g., based on access permissions defined in permissions module 118) to respective user devices 200, while encrypted user profiles associated with locking systems 300 outside geofence 160 are not delivered to respective user devices 200.

In some embodiments, encrypted user profiles on respective user devices 200 are added and removed as the current location 150 of the respective user devices 200 changes. For example, when locking systems 300 "enter" and "exit" geofence 160 (i.e., as the user moves around, changing current location 150), the encrypted user profiles associated with those locking systems 300 will be added to or discarded (e.g., removed, erased, etc.) from respective user devices 200, respectively. Such monitoring of the current location 150 of the respective user device 200 may be continuous, periodic (e.g., every thirty seconds, every minute, every five minutes, every fifteen minutes, etc.), and/or passive (e.g., in response to a user opening an application on the respective user device 200 associated with the user profile management system 10). Geofence module 120 can switch between continuous, periodic, and/or passive profile delivery based on current demand on server 100.

As shown in fig. 3B, geo-fence module 120 is configured to implement a second geo-fence, shown as geo-fence 170, defined based on a predefined area (e.g., city, large or factory, campus, etc.), subdivided into areas (e.g., city blocks, etc.), shown as geo-fence sector 172. According to an exemplary embodiment, geofence module 120 is configured to selectively activate geofences 170 around a respective geofence sector 172 in response to the current location 150 of the respective user device 200 being within one of the predefined geofence sectors 172. Geofence module 120 is configured to deliver only encrypted user profiles for locking system 300, with locking system 300 located within geofence 170 of currently active geofence sector 172 and/or with the respective user having access to (e.g., based on access permissions defined in permissions module 118) the respective user device 200, while encrypted user profiles associated with locking system 300 outside of geofence 170 and located within inactive geofence sector 172 are not delivered to the respective user device 200.

In some embodiments, encrypted user profiles on respective user devices 200 are added and removed as the current location 150 of the respective user devices 200 changes. For example, when a respective user device 200 leaves the first geo-fence sector 172 and enters the second geo-fence sector 172 (i.e., as the user moves around, changing the current location 150), the encrypted user profile associated with the locking system 300 within the first geo-fence sector 172 can be discarded from the respective user device 200 and the encrypted user profile associated with the locking system 300 within the second geo-fence sector 172 can be added to the respective user device 200. Such transitions between the various geo-fence sectors 172 may be continuously monitored, periodically monitored (e.g., every thirty seconds, every minute, every five minutes, every fifteen minutes, etc.), and/or passively monitored (e.g., in response to a user opening an application on a respective user device 200 associated with the user profile management system 10). Geofence module 120 can switch between continuous, periodic, and/or passive profile delivery based on current demand on server 100.

As shown in fig. 3C, geofence module 120 is configured to implement a third geofence, shown as geofence 180, which is shown as building coverage area 182 based on a predefined coverage area of a building or floor definition of a building to which the user has access. According to an exemplary embodiment, geo-fence module 120 is configured to selectively activate geo-fences 180 around a respective building coverage area 182 in response to a current location 150 of a respective user device 200 being positioned within one of the building coverage areas 182. Geofence module 120 is configured to deliver only the encrypted user profiles of locking systems 300 that are located within geofence 180 of currently active building coverage area 182 and/or that the respective users have access to (e.g., based on access rights defined in permissions module 118) the respective user devices 200, while user profiles associated with locking systems 300 outside geofence 180 and located within inactive building coverage area 182 are not delivered to the respective user devices 200.

In some embodiments, the encrypted user profiles on the respective user devices 200 are added and removed as the current locations 150 of the respective user devices 200 change. For example, when a respective user device 200 leaves a first building coverage area 182 and enters a second building coverage area 182 (i.e., as the user moves about, thereby changing the current location 150), the encrypted user profile associated with the locking system 300 within the first building coverage area 182 may be discarded from the respective user device 200 and the encrypted user profile associated with the locking system 300 within the second building coverage area 182 may be added to the respective user device 200. The monitoring may be continuous, periodic (e.g., every thirty seconds, every minute, every five minutes, every fifteen minutes, etc.), passive (e.g., in response to a user opening an application on a respective user device 200 associated with the user profile management system 10), and/or based on timing, inspection, entry, marking, etc. of entry into and exit from a building associated with the building floor coverage zone 182. Geofence module 120 can switch between continuous, periodic, and/or passive profile delivery based on current demand on server 100.

In some embodiments, when the current location 150 of the respective user device 200 changes in response to user movement, the encrypted user profile on the respective user device 200 is not immediately removed in response to the associated locking system 300 no longer falling within geofence 160, geofence 170, and/or geofence 180. For example, some users may have access to "roaming" functionality. When the roaming feature is activated, the encrypted user profile of the user is loaded onto the corresponding user device 200 and retained for a specified period of time (e.g., for the user's entire work shift, etc.) before being removed from the corresponding user device 200. For example, a user may be in a first location with a first subset of locking systems 300 and then move to a second location with a second subset of locking systems 300. Geofence module 120 may thereby deliver the encrypted user profiles associated with the first subset of locking systems 300 to the respective user devices 200 while located at the first location. While in the second location, geo-fence module 120 may then deliver the encrypted user profiles associated with the second subset of locking systems 300 to the respective user devices 200 while maintaining the encrypted user profiles associated with the first subset of locking systems 300 on user devices 200. The geo-fence module 120 can then remove all encrypted user profiles on the respective user devices 200 upon expiration of a specified period of time (e.g., end of user shift, etc.). Such a roaming mode may prevent loading and removing the same user profile multiple times during a day if the user jumps back and forth between different locations (e.g., reducing the load on the server 100, etc.).

In some embodiments, when demand on the server 100 is above one or more thresholds or in response to one or more throttling triggers, the throttling module 122 is configured to employ throttling techniques to reduce the load on the server 100. Throttling may affect one user differently than another. For example, the server 100 may limit profile delivery for the first user before the second user (e.g., based on a subscription level, an authorization level, a permission level, etc.). The throttling technique can include transitioning from a proximity/geofence delivery protocol (as described with respect to geofence module 120) to a non-geofence delivery protocol. Various non-geo-fence delivery protocols may be employed to reduce server load, including techniques such as wake delivery protocol, favorite keychain delivery protocol, known offline delivery protocol, overlay request delivery protocol, key cache delivery protocol, dynamic lifecycle delivery protocol, and secure slider delivery protocol.

As shown in FIG. 2B, throttle module 122 includes a plurality of sub-modules, shown as proximity module 124, key cache module 126, favorites module 128, known offline module 130, dynamic lifecycle module 132, favorites keychain module 134, override request module 136, wake module 138, security slider module 140, and prioritization module 142. As a brief overview, (i) proximity module 124 is configured to facilitate implementation of a geo-fence delivery protocol (as described herein with respect to geo-fence module 120), (ii) key cache module 126, favorites module 128, known offline module 130, dynamic lifecycle module 132, favorites keychain module 134, override request module 136, and wake module 138 are configured to implement various non-geo-fence delivery protocols, and (iii) prioritization module 142 is configured to dynamically translate user profiles based on current demand or load on server 100 (a) between geo-fence delivery protocols and various non-geo-fence delivery protocols and (b) between various non-geo-fence delivery protocols.

The key cache module 126 is configured to facilitate implementing a key cache delivery protocol for the user profile. According to an exemplary embodiment, key cache module 126 is configured to asynchronously refresh each user's user profile pool when system demand is low (e.g., below a threshold demand level, etc.), and store such user profile pool in a cache, which each user can easily access when access to locked system 300 accessible to the user is required. This pre-buffering reduces system load during higher peak access periods. The key cache module 126 may select a user profile for the user profile pool based on various factors including past access/download history, current time and date, current location of the user device 200, and the like. Thus, the key cache module 126 is configured to intelligently preload or pre-buffer the user profile when the server 100 has free or unused capacity so that the user profile can be delivered to the user device 200 at a reduced load on the server 100 when needed.

The favorites module 128 is configured to facilitate implementing a favorites delivery protocol to deliver the user profile. According to an exemplary embodiment, the favorites module 128 is configured to monitor the access history of each user device 200 (e.g., through an audit trail or the like that the user device 200 provides after accessing the locked system 300) to determine the frequency with which the respective user accesses each locked system 300 that the respective user is allowed to access. Based on the access history, the favorites module 128 may be configured to categorize the locking systems 300 that the respective user has access to based on the frequency of access over a particular period of time (e.g., the number of times the user accessed each locking system 300 during the previous day, week, month, etc.). The favorites module 128 may then automatically generate a favorites list for each user that includes the user profile of the locking system 300 that each user most frequently accesses as determined based on the access history. According to an exemplary embodiment, the favorites module 128 is configured to dynamically update the favorites list based on the user's updated access history. The number of user profiles included in the favorites list may vary from user to user. For example, a first user may have a first subscription that provides a list of favorites with a first number of user profiles (e.g., five, ten, fifteen, etc. user profiles), while a second user may have a second subscription that provides a list of favorites with a second, greater number of user profiles (e.g., twenty-five, etc. user profiles). When the favorites delivery protocol is implemented by the favorites module 128 to deliver user profiles to one or more user devices 200, one or more of the user devices 200 may automatically send only the user profiles of the locking systems 300 on their user's favorites list. The user device 200 may manually access the locking system 300 not included in the favorites list using another delivery protocol (e.g., wake delivery protocol, override request delivery protocol, favorites keychain delivery protocol, etc.).

Known offline module 130 is configured to facilitate implementing known offline delivery protocols for delivering user profiles. According to an exemplary embodiment, the known offline module 130 is configured to identify locking systems 300 that are located in areas of known user equipment 200 that have poor wireless connectivity. In some embodiments, the known offline module 130 is configured to manually receive an indication of the locking system 300 located in a poorly connected area (e.g., by a user via their respective user device 200, etc.). In some embodiments, the known offline module 130 is additionally or alternatively configured to automatically determine which of the locking systems 300 are located in areas of known user equipment 200 with poor wireless connectivity. For example, when user device 200 accesses locking system 300, user device 200 and/or locking system 300 is configured to generate an audit trail detailing the interactions (e.g., which locking system was accessed, when the access occurred, which functions were performed, etc.). User device 200 and/or locking system 300 may also insert details about the connection (e.g., cellular connection, network connection, etc.) into the audit trail when accessing locking system 300. The known offline module 130 may be configured to (i) interpret such connection information within the audit trail received from the user device 200 and (ii) identify which of the locking systems 300 should be classified as being located in a poorly connected region (e.g., via machine learning, etc.). For example, if it is determined that when user device 200 accesses a particular locking system 300, the connection is poor or there is no more than a threshold percentage of time (e.g., 50%, 75%, etc.), then the particular locking system 300 may be marked as "offline known". Thus, when a known offline delivery protocol is implemented by the known offline module 130 to deliver the user profiles to one or more of the user devices 200, one or more of the user devices 200 may automatically send only user profiles for the locking system 300 that are classified as "offline known". The user device 200 may then manually access the other locking system 300 (i.e., the unknown offline locking system) using another locking system (e.g., wake delivery protocol, override request delivery protocol, favorite keychain delivery protocol, etc.).

Dynamic lifecycle module 132 is configured to facilitate implementing a dynamic lifecycle delivery protocol for delivering a user profile. According to an exemplary embodiment, dynamic lifecycle module 132 is configured to dynamically adjust the lifecycle (i.e., the amount of time the respective user profile is valid) of the user profiles associated with each user profile based on the frequency with which the user accesses locking system 300 associated with the respective user profile. For example, the dynamic lifecycle module 132 may be configured to (i) identify and extend the lifecycle of user profiles associated with locking systems 300 that are more frequently accessed by the respective users, and (ii) identify and reduce the lifetime of user profiles associated with locking systems 300 that are less frequently accessed by the respective users. Thus, more frequently used user profiles will remain active for a longer duration and stored offline on the user device 200 of the respective user, thus preventing the need to continually re-deliver user profiles associated with locking systems 300 that are more frequently accessed by the respective user. On the other hand, dynamic lifecycle module 132 is configured to (i) identify and avoid transmission of user profiles associated with infrequently accessed locking systems 300, and (ii) shorten the lifetime of such user profiles, such that when these user profiles are requested by a user (e.g., on demand, via an override request delivery protocol, via a wake delivery protocol, etc.), the effective duration of the user profiles is shorter than usual (e.g., single use, thirty minutes, etc.).

Favorites keychain module 134 is configured to facilitate implementing a favorites keychain delivery protocol for delivering user profiles. According to an exemplary embodiment, favorites keychain module 134 is configured to receive an indication of which locking system 300 the respective user wishes to favorite (e.g., via manual selection on their user device 200, etc.). The favorites keychain module 134 is configured to generate a favorites keychain for a respective user based on an indication that includes a user profile associated with the locking system 300 that the respective user manually favorites. The number of user profiles contained in the favorites keychain may vary from user to user. For example, a first user may have a first subscription that provides a favourites keychain with a first number of user profiles (e.g., five, ten, fifteen, etc. user profiles), while a second user may have a second subscription that provides a favourites keychain with a second, larger number of user profiles (e.g., twenty-five, etc. user profiles). When the favorite keychain module 134 is implementing a favorite keychain delivery protocol to deliver the user profile to one or more of the user devices 200, one or more of the user devices 200 may automatically send only the user profile of the locking system 300 on the favorite keychain associated with their user. User device 200 may manually access locking system 300 not included in the favorites keychain using another delivery protocol (e.g., wake delivery protocol, override request delivery protocol, etc.).

The overlay request module 136 is configured to facilitate implementing an overlay request delivery protocol for delivering the user profile. According to an exemplary embodiment, the override request module 136 is configured to selectively deliver a user profile that the user manually requests on the user device 200. For example, during an overlay request delivery protocol, user device 200 may display a list of locking systems 300 that the user has access to. The list of locking systems 300 may include (i) all locking systems 300 that the user has access to or (ii) only locking systems 300 that the user has access to within the current geofence of the user device 200 and/or locking systems 300 that the user device 200 does not currently have a locally stored user profile. The user may then select which of the locking systems 300 to use from a list of locking systems 300 he or she wishes to have the user profile. The override request module 136 may then deliver the user profile of the selected locking system 300 to the user device 200. Thus, when an overlay request delivery protocol is being implemented by the overlay request module 136 to deliver a user profile into one or more user devices 200, only the user profile of the locking system 300 that is manually requested via the user device 200 may be sent to the one or more user devices 200.

The wake module 138 is configured to facilitate a wake delivery protocol for delivering a user profile. According to an exemplary embodiment, the wake-up module 138 is configured to selectively deliver the user profile in real-time to the user device 200 that is attempting to access the locking system 300. For example, if the corresponding user device 200 does not currently have a user profile associated with the lock system 300, the user may wake up the lock system 300 (e.g., by pressing a button thereon, etc.). The locking system 300 may broadcast an identifier associated therewith in response to being awakened, which may be received by the respective user device 200 and transmitted to the server 100. The wake-up module 138 may be configured to verify that the respective user device 200 is allowed to access the locking system 300 and, in response to verifying the respective user device 200, transmit a user profile associated with the respective user device 200 for accessing the locking system 300 to the respective user device 200.

The secure slider module 140 is configured to facilitate implementation of a secure slider delivery protocol for delivering user profiles. According to an exemplary embodiment, the security slider module 140 is configured (e.g., by an administrator, etc.) to (i) facilitate a user (e.g., administrator, etc.) to selectively increase security (and thus increase demand and subscription costs for the server 100) by selecting to expire more frequently with a user profile and (ii) selectively decrease security (and thus decrease demand and subscription costs for the server 100) by selecting to expire less frequently with a user profile. For example, the user may choose to expire the user profile associated with locking system 300 located outside the building more frequently and expire the user profile associated with locking system 300 located inside the building less frequently. Thus, the secure slider module 140 may be configured to first deliver the user profile associated with the more secure locking system 300 when implementing the secure slider delivery protocol.

When the demand on the server 100 is above one or more thresholds or in response to one or more throttling triggers, the prioritization module 142 is configured to employ throttling techniques to reduce the load on the server 100. For example, prioritization module 142 may be configured to dynamically transition delivery of a user profile to one or more user devices 200 based on (a) current demand or load on server 100 from user device 200 and/or (b) a permission or subscription level of each user associated with one or more user devices 200 (i) between geo-fence delivery protocols and various non-geo-fence delivery protocols and (ii) between various non-geo-fence delivery protocols.

According to an exemplary embodiment, prioritization module 142 is configured to determine and monitor a current aggregate load on server 100 as a result of delivering a user profile to user device 200 using a geofence delivery protocol. The prioritization module 142 is then configured to determine whether the current aggregate load on the server 100 (e.g., due to the number of user profile requests, longer than normal searches to provide a user profile, new profile generation and/or locks added to the system by administrators, etc.) is greater than a load threshold. The prioritization module 142 may be configured to initiate delivery of user profiles associated with one or more user devices 200 to the one or more user devices 200 using a corresponding non-geofencing delivery protocol (e.g., wake delivery protocol, favorite keychain delivery protocol, known offline delivery protocol, override request delivery protocol, key cache delivery protocol, dynamic lifecycle delivery protocol, secure slider delivery protocol, etc.) in response to the current aggregate load being greater than the load threshold. For example, prioritization module 142 can be configured to convert delivery of user profiles for users of lower permission levels and/or users of lower subscription levels from a geo-fence delivery protocol to one or more non-geo-fence delivery protocols to reduce server load as needed prior to converting users of higher permission levels and/or users of lower subscription levels.

The prioritization module 142 can also be configured to (i) convert profile delivery from the geo-fence delivery protocol to the non-geo-fence delivery protocol for more user devices 200 that have not received a user profile via the non-geo-fence delivery protocol and/or (ii) begin delivering user profiles of user devices 200 that have received a user profile via the non-geo-fence delivery protocol to the less load-intensive non-geo-fence delivery protocol to reduce server load. The prioritization module 142 may continue to do so until the current load on the server 100 decreases to an acceptable level (e.g., below a load threshold, etc.). For example, prioritization module 142 may be configured to convert between non-geofence delivery protocols in the following order: (i) a key cache delivery protocol, (ii) a favorite delivery protocol, (iii) a known offline delivery protocol, (iv) a dynamic lifecycle delivery protocol, (v) a favorite keychain delivery protocol, (vi) a secure slider delivery protocol, (vi) an override request delivery protocol, and (vii) a wake delivery protocol. It should be understood that the above sequence is for illustrative purposes only, and that different sequences may be implemented in different embodiments or for different users. In some embodiments, the permission level or subscription level of a user may limit the non-geo-fence delivery protocols that may be implemented with that user (i.e., at least one of the non-geo-fence delivery protocols is not used with the respective user).

User equipment

In general, user device 200 is configured to selectively receive and store various encrypted user profiles in accordance with a profile delivery protocol (e.g., a proximity/geo-fencing delivery protocol, a non-geo-fencing protocol, etc.) employed by server 100 to facilitate accessing and/or at least partially managing operation of locking system 300 to which user device 200 has access. For example, user device 200 may be used to unlock, lock, and/or otherwise manage the functionality of locking system 300 (e.g., change settings, update firmware, etc.). User device 200 may access and/or manage locking system 300 through the use of an application ("app") configured to run on user device 200. For example, the application may be installed on a mobile phone or other portable device, and the application may be used to configure and/or control locking system 300 via a wireless connection. In some embodiments, user device 200 is a portable device, such as a smartphone, cell phone, mobile phone, tablet, smart watch, laptop computer, and/or other type of suitable portable device. In another embodiment, user device 200 is a desktop computer.

As shown in fig. 4, the user device 200 includes processing circuitry 202, a first transceiver 222, a second transceiver 224, a user interface 226, and location determination circuitry 228. The processing circuit 202 has a processor 204, a memory 206, and a timer 220. The processing circuitry 202 may include a general purpose processor, an ASIC, one or more FPGAs, a DSP, circuitry including one or more processing components, circuitry to support a microprocessor, a set of processing components, or other suitable electronic processing components. In some embodiments, the processor 204 is configured to execute computer code stored in the memory 206 to facilitate the activities described herein. Memory 206 may be any volatile or non-volatile computer-readable storage medium capable of storing data or computer code related to the activities described herein. According to an exemplary embodiment, the memory 206 includes computer code modules (e.g., executable code, object code, source code, script code, machine code, etc.) configured to be executed by the processor 204. Timer 220 is configured to maintain a time value for user equipment 200. For example, timer 220 may be a clock of processor 204 or may be any other timing circuitry of user device 200. The time value maintained by the timer 220 may be used for secure communications (e.g., synchronizing time with the locking system 300, providing a timestamp associated with the event for logging purposes, etc.).

According to an exemplary embodiment, (i) first transceiver 222 is configured to facilitate communication between user device 200 and server 100 using a first communication protocol, and (ii) second transceiver 224 is configured to facilitate communication between user device 200 and locking system 300 using a second communication protocol. In some embodiments, the first communication protocol and the second communication protocol are different. By way of example, the first communication protocol may be a long-range communication protocol, and the second communication protocol may be a short-range communication protocol. In an alternative embodiment, user device 200 communicates with server 100 and locking system 300 using the same transceiver (e.g., only first transceiver 222). In one embodiment, the first transceiver 222 comprises a cellular component for communicating with the server 100 via a cellular network. In another embodiment, the first transceiver 222 includes a wired or wireless (e.g., Wi-Fi) component for communicating with the server 100 over the Internet or other network. In one embodiment, the second transceiver 224 includes a bluetooth component for establishing a bluetooth connection with the locking system 300. In another embodiment, the second transceiver 224 includes different types of components that facilitate different types of short-range and/or wireless communication protocols (e.g., radio frequency, RFID, WiFi, bluetooth, ZigBee, NFC, etc.).

User interface 226 may include a display screen and/or one or more user input devices (e.g., touch screen, buttons, microphone, speaker, display, keyboard, stylus input, mouse, touch pad, etc.) to allow a user to interact with user device 200, server 100, locking system 300, and/or any application running on user device 200. The location determination circuit 228 (e.g., a global positioning system ("GPS") receiver) can be configured to generate and facilitate providing a location of the user device 200 (e.g., the current location 150) and/or a current location of the respective locking system 300 (e.g., the first location data, the second location data, etc.) for transmission to the server 100 to perform the geofencing operations disclosed herein.

According to an exemplary embodiment, memory 206 of user device 200 includes various modules configured to receive, manage, and transmit encrypted user profiles. As shown in FIG. 4, memory 206 of user device 200 includes an application module 208 having a location module 210, a profile management module 212, a user input module 214, a locking system module 216, and a command module 218. According to an exemplary embodiment, the location module 210 is configured to (i) receive first location data regarding the current location 150 of the user device 200 from the location determination circuit 228 and (ii) provide the first location data to the first transceiver 222 for transmission to the server 100. In some embodiments, the location module 210 is configured to (i) receive second location data from the location determination circuitry 228 regarding a current location of the respective locking system 300 that the user device 200 is accessing or attempting to access, and (ii) provide the second location data for transmission to the server 100. In other embodiments, the location module 210 is configured to (i) receive, via the second transceiver 224, second location data from the locking systems 300 (e.g., in an audit trail) regarding the current location of the respective locking system 300 accessed by the locking system 300 and (ii) provide the second location data to the first transceiver 222 for transmission to the server 100.

The profile management module 212 is configured to receive and store encrypted user profiles and user keys that the server 100 transmits to the first transceiver 222 of the user device 200 according to one or more profile delivery protocols disclosed herein. The profile management module 212 is also configured to discard (e.g., erase, delete, remove, etc.) the encrypted user profile and user key according to one or more profile delivery protocols disclosed herein. The user input module 214 is configured to (i) provide various graphical user interfaces on a display of the user interface 226 and (ii) receive inputs provided by a user to the user interface 226 and perform functions associated therewith. The locking system module 216 is configured to identify the respective locking system 300 that the user device 200 is attempting to access (e.g., based on an identifier broadcast by the respective locking system 300) and provide the respective encrypted user profile stored in the profile management module 212 (e.g., without an appended user key, appended with a handshaking nonce, etc.) to the second transceiver 224 to deliver the encrypted user profile to the respective locking system 300 in order to control various functions of the respective locking system 300 (e.g., unlock, lock, change settings, update firmware, etc.).

The command module 218 is configured to generate and transmit encrypted commands to the respective locking system 300. The encrypted commands may include commands for the respective locking system 300 to perform actions such as unlock, lock, change settings, update firmware, and so forth. According to an exemplary embodiment, the commands are encrypted using a user key associated with the user profile transmitted to the respective locking system 300 at the beginning of the communication session. In some embodiments, the command module 218 is configured to generate a modified reply nonce based on the reply nonce received from the respective locking system 300, as described in more detail herein (e.g., in response to the respective locking system 300 successfully decrypting the encrypted user profile, etc.). In such embodiments, the command module 218 is configured to encrypt the command using the user key and the modified reply random number.

As shown in FIG. 5, a first graphical user interface provided by user interface 226 of user device 200, shown as profile list interface 230, includes a list, shown as profile list 232, having one or more encrypted user profiles, shown as profile 234. The profile list 232 includes profiles 234 currently stored in the profile management module 212 (e.g., profiles 234 delivered to the user device 200 according to one or more profile delivery protocols).

As shown in fig. 6 and 7, the second graphical user interface provided by user interface 226 of user device 200, shown as locking system interface 240, displays various information about the corresponding locking system 300 (i) user device 200 currently has an encrypted user profile stored thereon (e.g., in profile management module 212, by selecting one of profiles 234 via profile list interface 230 or the like) and/or (ii) user device 200 is currently accessing the locking system 300. Locking system interface 240 includes a first tab displayed as a settings tab 250, a second tab displayed as a location tab 260, and a third tab displayed as a history tab 270.

As shown in FIG. 6, settings tab 250 provides information regarding various settings of a respective locking system 300, such as an automatic relock delay (e.g., the time elapsed after unlocking a respective locking system 300 before the respective locking system 300 relocks if it is not physically opened/unlocked), code for manual entry into an interface of a respective locking system 300 to perform an unlocking and/or locking function, an identification of a user or group of users of the respective locking system 300, and a current firmware version of the respective locking system. The settings tab 250 may also facilitate changing settings of the respective locking system 300 (e.g., if the respective user has permission to change the settings). As shown in FIG. 7, position tab 260 provides information about the last known position of the corresponding locking system 300 and a mapping interface 262. According to an exemplary embodiment, the history tab 270 provides information about the history of the respective locking system 300 (e.g., audit history; time the locking system 300 was locked, unlocked, updated, etc.; who accessed the locking system 300, etc.).

Locking system

In general, locking system 300 is configured to receive encrypted user profiles from respective user devices 200 and make access and/or administrative control decisions (e.g., whether to allow respective user devices 200 to be unlocked, updated, etc.) based on the encrypted user profiles. In one embodiment, locking system 300 is an electronic padlock, such as an electronic combination or keyboard padlock. In other embodiments, locking system 300 may be or include, but is not limited to, a locking system such as an electronic door lock or keyboard device (e.g., a keyboard latch), an electronic safe (e.g., a small file safe, an electronic key safe, etc.), an electronic rim or mortise lock or other type of cabinet lock, an electronic vehicle accessory lock (e.g., a coupler lock, a hitch lock, a trailer lock, etc.) and/or a steering wheel or door lock of an automobile, a vehicle lock (e.g., a wheel lock, an ignition lock, etc.) for other motorized or non-motorized vehicles (e.g., a bicycle, a motorcycle, a scooter, an ATV, and/or a snowmobile), a storage box, a box with an electronic lock (e.g., a file box, a box to store small valuables, etc.), an electronic cable lock (e.g., a cable lock with an alarm function, e.g., to protect a computing device, etc.), a locking tagger device to ensure access (e.g., for protecting electrical control boxes, etc. while performing electrical work), lockers with electronic locks, and/or electronic luggage locks.

As shown in fig. 8, locking system 300 includes a processing circuit 302, a first transceiver 322, a second transceiver 324, a user interface 326, a position determination circuit 328, a locking mechanism 330, and a battery 332. In some embodiments, locking system 300 does not include second transceiver 324, position determination circuit 328, and/or battery 332. The processing circuit 302 has a processor 304, a memory 306, and a timer 320. The processing circuitry 302 may include a general purpose processor, an ASIC, one or more FPGAs, a DSP, circuitry including one or more processing components, circuitry to support a microprocessor, a set of processing components, or other suitable electronic processing components. In some embodiments, processor 304 is configured to execute computer code stored in memory 306 to facilitate the activities described herein. Memory 306 may be any volatile or non-volatile computer-readable storage medium capable of storing data or computer code related to the activities described herein. According to an exemplary embodiment, the memory 306 includes computer code modules (e.g., executable code, object code, source code, script code, machine code, etc.) configured to be executed by the processor 304. Timer 320 is configured to maintain a time value for lock system 300. For example, timer 320 may be a clock of processor 304 or may be any other timing circuit of lock system 300. The time value maintained by timer 320 may be used for secure communications (e.g., synchronizing time with user device 200, providing a timestamp associated with an event for logging purposes, etc.).

According to an exemplary embodiment, first transceiver 322 is configured to facilitate communication between locking system 300 and user device 200 using a first communication protocol. For example, the first communication protocol may be a short-range communication protocol. In one embodiment, the first transceiver 322 includes a bluetooth component for establishing a bluetooth connection with the second transceiver 224 of the user device 200. In another embodiment, the first transceiver 322 includes different types of components and/or wireless communication protocols (e.g., radio frequency, RFID, Wi-Fi, bluetooth, ZigBee, NFC, etc.) that facilitate different types of short distances. In embodiments where the locking system 300 includes the second transceiver 324, the second transceiver 224 is configured to facilitate direct communication between the locking system 300 and the server 100 using a second communication protocol. For example, the second communication protocol may be a telecommunications protocol. In an alternative embodiment, the locking system 300 uses the same transceiver (e.g., only the first transceiver 322, via Wi-Fi, etc.) to communicate with the server 100 and the user device 200. In one embodiment, the second transceiver 324 comprises a cellular component for communicating with the server 100 via a cellular network. In another embodiment, the second transceiver 324 includes a wired or wireless (e.g., Wi-Fi) component for communicating with the server 100 over the Internet or other network. In other embodiments, locking system 300 is hardwired to a network (e.g., in an access control system implementation, etc.).

User interface 326 may include a display screen and/or one or more user input devices (e.g., a touch screen, buttons, microphone, speaker, display, keypad, directional keys, etc.) to allow a user to interact with locking system 300. For example, the user interface 326 may facilitate waking the locking system 300 from a sleep mode. As another example, the user interface 326 may facilitate manual entry of an unlock combination. In embodiments that include location determination circuitry 328, location determination circuitry 328 (e.g., a global positioning system ("GPS") receiver) may be configured to generate and facilitate providing the current location (e.g., second location data) of locking system 300 to user device 200 (e.g., via first transceiver 322) and/or directly to server 100 (e.g., via second transceiver 324) to perform the geofencing operations disclosed herein.

The one or more locking mechanisms 330 may include one or more physical and/or electronic locking mechanisms (e.g., pins, shackles, dials, buttons, shafts, keyed keyways, motors, latches, deadbolts, etc.). In embodiments that include a battery 332, the battery 332 is configured to provide power to the locking system 300 to facilitate its operation (e.g., locking, unlocking, etc.). The battery 332 may be rechargeable and/or replaceable. Accordingly, such a battery-powered locking system 300 may be portable. In embodiments that do not include a battery 332, the locking system 300 may be coupled to another power source to facilitate its operation (e.g., hardwired to a mains power source, coupled to an external power source, etc.). Such a locking system 300 may be fixedly mounted. In some embodiments, locking system 300 includes an input/output port (e.g., a USB port, a COM port, a network port, etc.) that may be used to establish a physical connection to another device. For example, a manufacturer may use such a physical connection to program or otherwise communicate with locking system 300.

According to an exemplary embodiment, memory 306 of locking system 300 includes various modules configured to make access control decisions. As shown in FIG. 8, memory 306 of locking system 300 includes a user input module 308, an access control module 310, and a location module 312. In some embodiments, memory 306 does not include location module 312 (e.g., in embodiments where locking system 300 does not include location determination circuitry 328, etc.).

The user input module 308 is configured to receive input through the user interface 326. For example, the user input module 308 may receive an input to wake the locking system from a sleep mode. As another example, user input module 308 may receive a manual access code to unlock or otherwise access locking system 300. As another example, user input module 308 may receive an encrypted user profile from a respective user device 200.

Access control module 310 is configured to store a lock identifier, a lock key, and/or a manual access code for locking system 300. The access control module 310 may be configured to broadcast the lock identifier via the first transceiver 322 (e.g., in response to being awakened from a sleep mode, etc.). In response to the broadcast, the locking system 300 may receive an associated encrypted user profile from the respective user device 200. The access control module 310 is configured to retrieve the user key from the decrypted user profile using (i) a lock key pre-stored thereon and/or (ii) a handshake random number appended to the encrypted user profile (in embodiments using the handshake random number) to decrypt the encrypted user profile. In some embodiments, the access control module 310 is configured to generate and transmit a reply random number to the respective user device 200 via the first transceiver 322 in response to successfully decrypting the encrypted user profile.

The access control module 310 may receive an encryption command from the respective user device 200 via the first transceiver 322 (e.g., after successfully decrypting the encrypted user profile, etc.). The access control module 310 is configured to use the user key obtained from the decrypted user profile. In some embodiments, the access control module 310 is configured to generate a modified reply random number based on the reply random number to decrypt the encrypted command along with the user key (in embodiments where the access control module 310 generates and sends a reply random number to the user device 200 and the user device 200 generates and encrypts the command using the user key and the modified reply random number). The access control module 310 is configured to initiate an action specified by the decrypt command (e.g., unlock the physical lock component, implement a firmware update, update its settings, etc.) in response to successfully decrypting the encrypted command.

According to an exemplary embodiment, the access control module 310 is configured to decrypt the encrypted user profile and the encrypted command using a single decryption algorithm. For example, the decryption algorithm may be or include a counter with a cipher block chaining message verification code ("CCM") algorithm, as described in further detail in the suggestion of a block cipher mode of operation: CCM schema for identity verification and confidentiality, published by the national institute of standards and technology in 2004 and written by Morris desvorkin (Morris Dworkin), is incorporated herein by reference in its entirety.

In some embodiments, the dual-key authentication scheme using the locking key and the user key eliminates any need to pair the locking system 300 with the user device 200 (e.g., using a bluetooth pairing) to create a secure communication session between the locking system 300 and the user device 200. In such embodiments, after the communication session between locking system 300 and user device 200 ends, locking system 300 therefore does not store the user key received from user device 200 (e.g., after executing the command, in response to not receiving the encrypted command within a predefined period of time, due to being unable to decrypt the encrypted command, etc.).

It should be appreciated that the dual-key authentication scheme implemented by the access control module 310 described herein is not meant to be limiting, but is provided as an example of one possible way of providing secure communications between the user device 200 and the locking system 300. In other embodiments, the secure communication is established by access control module 310 using a different authentication scheme, such as an authentication scheme using a digital signature, a challenge-response process, multi-factor authentication (e.g., two-factor authentication, user profile plus biometric, user profile plus PIN, etc.), and/or other suitable authentication schemes.

In embodiments where the lock system 300 includes the position determination circuit 328 and does not include the second transceiver 324, the position module 312 is configured to (i) receive second position data from the position determination circuit 328 regarding the current position of the lock system 300 and (ii) provide the second position data to the first transceiver 322 for transmission to the respective user device 200 (which is in turn provided to the server 100 by the respective user device 200). In embodiments where the lock-in system 300 includes the position determination circuit 328 and the second transceiver 324, the position module 312 is configured to (i) receive second position data regarding the current position of the lock-in system 300 from the position determination circuit 328, and (ii) provide the second position data to the second transceiver 324 for direct transmission to the server 100. In embodiments where the locking system 300 does not include the position determination circuit 328 or the second transceiver 324, the position module 312 may be configured to store a predetermined position of the locking system 300 (e.g., in a fixed-mount implementation, such as in an access control system, etc.) and/or the user device 200 of the access locking system 300 is configured to generate second position data as described in further detail herein.

As shown in fig. 9, the locking system 300 is configured as a first locking system, shown as an electronic padlock 400. The electronic padlock 400 includes a housing, shown as housing 402, a locking mechanism (e.g., locking mechanism 330, etc.), shown as shackle 404, and an interface (e.g., user interface 326, etc.), shown as user interface 406. According to the exemplary embodiment shown in fig. 9, the user interface 406 includes a sensor, shown as a touch sensor 408, configured to wake the electronic padlock 400 and a directional pad, shown as a D-pad 410, in response to a user's touch, configured to facilitate entry of a manual code (e.g., an unlock code, etc.). In some embodiments, the sensor of the user interface 406 additionally or alternatively includes a proximity sensor and/or microphone configured to wake the electronic padlock 400 in response to detecting a nearby user. In another embodiment, the user interface 406 includes a mechanical dial or keypad configured to allow a user to enter a manual code and/or a keyway configured to receive a key (e.g., unlock the shackle 404, etc.).

As shown in fig. 10, the locking system 300 is configured as a second locking system, shown as an electronic key safe 500. Electronic key safe 500 includes a housing, shown as housing 502, a locking mechanism (e.g., locking mechanism 330, etc.), shown as shackle 504, an interface (e.g., user interface 326, etc.), shown as user interface 506, and a pivoting door, shown as door 512. According to the exemplary embodiment shown in FIG. 10, user interface 506 includes a sensor, shown as touch sensor 508, configured to wake up electronic key safe 500 in response to a user's touch, and a keyboard, shown as numeric keypad 510, configured to facilitate entry of a manual code (e.g., an unlock code, etc.). In some embodiments, the sensors of the user interface 506 additionally or alternatively include proximity sensors and/or microphones configured to wake up the electronic key safe 500 in response to detecting a nearby user. In another embodiment, the user interface 506 includes a mechanical dial or D-key configured to allow a user to enter a manual code and/or a key slot configured to receive a key (e.g., to unlock the shackle 504, door 512, etc.). According to an exemplary embodiment, the door 512 is pivotally coupled to the housing 502 to facilitate selectively exposing an interior cavity of the housing 502 (e.g., configured to store a set of keys, etc.).

As shown in FIG. 11, the locking system 300 is configured as a third locking system (e.g., lockbox, locker, etc.), shown as an electronic lockbox 600. The electronic lock box 600 includes a housing, shown as housing 602, a door, shown as cover 604, an interface (e.g., user interface 326, etc.), shown as user interface 606, and a sensor, shown as sensor 608. According to an exemplary embodiment, the cover 604 is pivotally coupled to and selectively secured (e.g., by a locking mechanism, etc.) to the housing 602 to facilitate selectively exposing the interior cavity of the housing 602. In one embodiment, the user interface 606 includes a keyboard or other component configured to facilitate entry of a manual code (e.g., an unlock code, etc.), a microphone, a display screen, and the like. In another embodiment, the user interface 606 includes a mechanical dial or d-pad configured to allow a user to enter a manual code and/or a key slot configured to receive a key (e.g., to unlock the cover 604, etc.). In one embodiment, the sensor 608 is or includes a proximity sensor and/or camera device configured to wake the electronic lockbox 600 in response to detecting a nearby user. More details regarding the electronic lockbox 600 can be found in U.S. patent No.10,205,913 filed on 9/14/2015, which is incorporated herein by reference in its entirety.

As shown in fig. 12, locking system 300 is configured as a fourth locking system, shown as electronic door locking system 700. The electronic door locking system 700 includes a door lock, shown as an electronic door lock 702, and a receiver, shown as a doorframe receiver 704, configured to interact with the electronic door lock 702 (e.g., its latch, its keeper, etc.). In one embodiment, the doorframe receiver 704 is a door latch receiver. In another embodiment, the doorframe receiver is an electric strike. In some embodiments, the electronic door lock 702 is a door lock having a communication component (e.g., a bluetooth component, etc.) configured to facilitate communication with the user device 200. In some embodiments, the electronic door lock 702 is part of a building access control system. In such embodiments, the electronic door lock system 700 may also include a stand-alone reader (e.g., a card reader, a keychain reader, a credential reader, etc.), shown as a reader 706, that is hardwired to the electronic door lock 702 and configured to make access control decisions. Reader 706 may include various components of processing circuitry 302 of lock system 300. In some embodiments, the electronic door lock 702 does not have a communication component configured to facilitate communication with the user device 200. In such embodiments, the electronic door locking system 700 may also include an external wireless transceiver (e.g., BLE relay, etc.), shown as a wireless relay 708, configured to interact with the electronic door lock 702 to facilitate wireless communication with the user device 200. The wireless relay 708 may thus provide a "retrofit" solution for existing door locks that do not have the necessary wireless communication capabilities. The wireless relay 708 may include various components of the processing circuit 302 of the locking system 300.

Method

Referring now to fig. 13, a method 1300 for delivering one or more user profiles to a user device (e.g., user device 200, etc.) based on a proximity/geofence delivery protocol is shown, in accordance with an exemplary embodiment. In alternative embodiments, fewer, additional, and/or different steps may be performed. Furthermore, the use of flow charts is not meant to limit the order of steps performed.

At step 1302, a server (e.g., profile management server, server 100, etc.) is configured to store a plurality of user profiles. At step 1304, the server is configured to receive geofence settings for the geofence of the user device (e.g., based on the user's subscription, user-selected settings, etc.). At step 1306, the server is configured to receive locking position data (e.g., second position data, etc.) regarding the position of the one or more locks. The server may receive the lock location data directly from the lock and/or indirectly via one or more user devices. The lock location data may indicate a real-time current location, a last known location, and/or a fixed location of one or more locks.

At step 1308, the server is configured to receive first user device location data (e.g., first location data, etc.) from the user device regarding a first location (e.g., current location 150, etc.) of the user device. At step 1310, the server is configured to determine which of the one or more locks are within the geofence based on the lock location data and the first user device location data (see, e.g., fig. 3A-3C). At step 1312, the server is configured to provide a first subset of the plurality of user profiles corresponding to the one or more locks within the geofence to the user device. Prior to providing the first subset of user profiles, the server may be configured to (i) insert or append the associated user key to each user profile of the first subset of the plurality of user profiles, (ii) generate a handshake random number (in embodiments using handshake random numbers) for each user profile of the first subset of the plurality of user profiles, (iii) encrypt each user profile and user key combination of the first subset of the plurality of user profiles, use (a) a lock key locking key for a particular lock associated with each user profile and/or (b) the handshake random number (in embodiments using handshake random numbers) to generate an encrypted user profile, and/or (iv) appending (a) a user key and/or (b) a handshake random number (in embodiments using a handshake random number) associated with each encrypted user profile to the encrypted user profile.

At step 1314, the server is configured to receive second user device location data from the user device regarding a second location of the user device. At step 1316, the server is configured to determine which of the one or more locks are within the geofence based on the locking position data and the second user device location data. At step 1318, the server is configured to provide a second subset of the plurality of user profiles corresponding to the one or more locks within the geofence to the user device. Prior to providing the second subset of user profiles, the server may be configured to encrypt the second subset of user profiles similar to the first subset of user profiles. At step 1320, the server and/or the user device is configured to delete the first subset and/or the second subset of the plurality of user profiles from the user device. For example, when the user device receives the second subset of the plurality of user profiles, the first subset of the plurality of user profiles may be deleted from the user device. As another example, the first subset of the plurality of user profiles and the second subset of the plurality of user profiles may remain on the user device until the predefined time period ends (e.g., a transition of the user, during a roaming mode, etc.).

Referring now to FIG. 14, a method 1400 for interacting with a lock (e.g., locking system 300, etc.) using a user device (e.g., user device 200, etc.) is shown, according to an exemplary embodiment. In alternative embodiments, fewer, additional, and/or different steps may be performed. Furthermore, the use of flow charts is not meant to limit the order of steps performed.

In some embodiments, at step 1402, the lock may be awakened from a low power standby or sleep state. For example, the locking system may be touched by a user (e.g., a button on a lock may be pressed, etc.) or may automatically detect the proximity of a user (e.g., using a proximity sensor, NFC sensor, etc.). The standby/sleep state may use less power (e.g., battery power, etc.) than if the lock was in a fully operational awake state. In some embodiments, the lock may always be in a fully functional state and may not be able to wake up from a standby/sleep state (e.g., if hardwired to an external power source, etc.). In some embodiments, upon waking from the low power sleep state, the lock may broadcast or otherwise advertise a unique lock identifier (e.g., an identifier formed by its model number, serial number, etc.) associated with the lock.

At step 1404, the user equipment receives a lock identifier from the lock. In one embodiment, the lock identifier is compared to a set of lock identifiers stored on the user device to determine whether the user device is associated with the lock device (e.g., whether there is an encrypted user profile corresponding to the lock identifier, etc.). For example, each encrypted user profile may have a list of lock identifiers that identify locks to which the user associated with the user profile has access. If an encrypted user profile is found for the lock, then in step 1406, the user device transmits the encrypted user profile to the lock (e.g., including the user key encrypted therein, encrypted with the locking key and/or the handshake random number, including the handshake random number appended thereto, etc.). In embodiments using a handshake random number, the encrypted user profile may be encrypted by the server (e.g., server 100, etc.) with a locking key (i.e., a key unknown to the user device) and a handshake random number that is also sent with (e.g., appended to, see step 1312, etc.) the encrypted user profile.

At step 1408, the lock receives the encrypted user profile and decrypts the encrypted user profile using the locking key previously stored thereon to obtain the user key from the decrypted user profile. In the case of transmitting after attaching a handshake random number to the encrypted user profile, the lock acquires the user key from the decrypted user profile using a locking key previously stored thereon and a handshake random number received together with the encrypted user profile during decryption. In some cases, the lock generates and sends back a complex random number to the user device in response to successfully decrypting the encrypted user profile.

At step 1410, the user device generates and sends an encryption command to the lock. According to an exemplary embodiment, the command is encrypted using a user key. In some embodiments, the user device generates a modified reply random number based on the reply random number received from the lock, and encrypts the command using the user key and the modified reply random number.

At step 1412, the lock decrypts the encrypted command using the user key obtained from the decrypted user profile. In an embodiment where the encrypted command is encrypted by a user key used by the user device and a modified reply random number, the lock generates its own modified reply random number based on the reply random number, and then attempts to decrypt the encrypted command using the user key obtained from the decrypted user profile and the modified reply random number independently generated by the lock. In step 1414, in response to successfully decrypting the encrypted command using the user key and/or the modified reply nonce, the lock initiates an action specified by the decrypted command (e.g., the lock may activate a physical locking component, perform a firmware update, change a lock setting, etc.).

In some embodiments, the user device and/or the lock may also ensure that the user profile of the lock provides user access at the verification time (e.g., by reference to scheduling information included in the user profile, etc.). In embodiments where the user device transmits the timestamp, the lock may verify the timestamp by comparing the timestamp to the current time of the lock. In embodiments utilizing the timestamps discussed above, the received timestamp may also be required to be within a threshold amount of time of the time held by the lock. In one embodiment (e.g., if permitted by the user profile permissions), the timestamp from the user device may be used to synchronize or update the lock time. Thus, if both the user profile and the command are verified (e.g., by successful decryption, time compliance, etc.), the lock may comply with the user device's command and initiate a corresponding action.

Referring now to fig. 15, a method 1500 for dynamically delivering a user profile to a user device (e.g., user device 200, etc.) is shown, according to an exemplary embodiment. In alternative embodiments, fewer, additional, and/or different steps may be performed. Furthermore, the use of flow charts is not meant to limit the order of steps performed.

At step 1502, a server (e.g., profile management server, server 100, etc.) is configured to deliver a user profile associated with each of a plurality of user devices (e.g., user device 200, etc.) to the plurality of user devices using a geo-fence delivery protocol (see, e.g., method 1300). At step 1504, the server is configured to determine and monitor a current aggregate load on the server as a result of delivering the user profile to the plurality of user devices using the geo-fencing transport protocol delivery protocol. At step 1506, the server is configured to determine whether the current aggregate load on the server is greater than a load threshold. The server is configured to repeat step 1502 and 1506 and continue delivering the user profile using the geo-fence delivery protocol in response to the current aggregate load being less than the load threshold (i.e., the server is able to adequately manage the current demand). Instead, the server is configured to proceed to step 1508 in response to the current aggregate load exceeding a load threshold (e.g., high demand on the server, peak demand, etc.).

At step 1508, the server is configured to begin using a corresponding non-geo-fence delivery protocol (e.g., wake delivery protocol, favorite keychain delivery protocol, known offline delivery protocol, overlay request delivery protocol, key cache delivery protocol, dynamic lifecycle delivery protocol, secure slider delivery protocol, etc.) in an attempt to reduce the load on the server. The server may begin delivering the user profile to (i) all user devices associated therewith or (ii) a subset of the plurality of user devices using a respective non-geofencing transport protocol delivery protocol (e.g., based on a subscription level of each respective user, etc., a first subset of the plurality of user devices may continue to receive the user profile via the geofencing delivery protocol, and a second subset of the plurality of user devices may begin receiving the user profile via the non-geofencing delivery protocol).

At step 1510, the server is configured to determine and monitor a current aggregate load on the server as a result of delivering the user profile to one or more of the plurality of user devices using a non-geo-fencing transport protocol delivery protocol. At step 1512, the server is configured to determine whether the current aggregate load on the server is greater than a load threshold. The server is configured to repeat step 1508 plus 1512 and continue to deliver the user profile using the non-geofencing delivery protocol and/or the geofencing delivery protocol (e.g., if all of the user devices do not receive the user profile using the non-geofencing transport protocol delivery protocol, etc.) in response to the current aggregate load being less than the load threshold (i.e., the server is able to adequately manage the current demand). Instead, the server is configured to proceed to step 1514 in response to the current aggregate load exceeding the load threshold.

At step 1514, the server is configured to (i) increase a number of the plurality of user devices that receive the user profile via the respective non-geo-fence delivery protocol (e.g., if only a subset of the plurality of user devices are currently receiving their associated user profiles using the respective non-geo-fence delivery protocol, if a subset of the plurality of user devices are currently receiving their associated user profiles using the geo-fence delivery protocol, etc.) and/or (ii) deliver the user profile associated with one or more of the plurality of user devices to one or more of the plurality of user devices using a different non-geo-fence delivery protocol (e.g., a second non-geo-fence delivery protocol, etc.). One or more of the plurality of user devices that may receive the user profile using the different non-geofencing delivery protocols may be (i) the same user device that previously received the user profile via the first non-geofencing delivery protocol, (ii) a different user device than the user device that continued to receive the user profile via the first non-geofencing delivery protocol, and/or (iii) a subset of the user devices that previously received the user profile via the first non-geofencing delivery protocol (e.g., may be based on a subscription level, etc.). The server may then return to step 1510.

If the steps taken at step 1514 successfully reduced the current aggregate load on the server, the server may continue to deliver the user profile as previously implemented at step 1514. However, if the current aggregate load again exceeds the load threshold, the server is configured to: (i) increasing a number of the plurality of user devices receiving the user profile via the respective non-geo-fence delivery protocol (e.g., further decreasing the number of user devices receiving the user profile via the geo-fence delivery protocol, increasing the number of user devices receiving the user profile via the first non-geo-fence delivery protocol, increasing the number of user devices receiving the user profile via the second non-geo-fence delivery protocol, etc.) and/or (ii) delivering the user profile associated with one or more of the plurality of user devices to one or more of the plurality of user devices using another different non-geo-fence delivery protocol (e.g., a third non-geo-fence delivery protocol, etc.). When the load on the server exceeds the load threshold, the process in step 1508-1514 may be repeated. When the load decreases, the server may return to step 1502 or gradually increase the number of user devices receiving the user profile according to the geofence delivery protocol (e.g., as allowed by the current demand on the server, etc.).

As used herein, the terms "approximately," "about," "substantially," and similar terms are intended to have a broad meaning consistent with the common and accepted usage by those of ordinary skill in the art to which the subject matter of this disclosure pertains. Those skilled in the art who review this disclosure will appreciate that these terms are intended to allow description of certain features described and claimed without limiting the scope of these features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or inconsequential modifications or alterations to the described and claimed subject matter are considered within the scope of the disclosure as recited in the appended claims.

It should be noted that the term "exemplary" and variations thereof used to describe various elements are intended to indicate that these are possible examples, representations or illustrations (and these terms are not intended to imply that these must be extraordinary or highest-level examples).

The term "couple" and variations thereof, as used herein, means the joining of two members directly or indirectly to one another. Such engagement may be fixed (e.g., permanent or fixed) or movable (e.g., removable or releasable). Such joining may be achieved by directly coupling the two members to each other, using a separate intermediate member to couple the two members to each other and using any additional intermediate members to couple each other, or using an intermediate member integrally formed as a single unitary body with one of the two members to couple each other. If "coupled" or variations thereof are modified by additional terms (e.g., directly coupled), the general definition of "coupled" provided above is modified by the plain meaning of the additional terms (e.g., "directly coupled" means joining two members without any separate intervening members), resulting in a narrower definition than the general definition of "coupled" provided above. This coupling may be mechanical, electrical or fluid.

The term "or" is used in its inclusive sense (and not in its exclusive sense), so that when used in connection with a list of elements, the term "or" indicates that one, part or all of the elements are in the list. Unless specifically stated otherwise, conjunctions such as the phrase "X, Y and at least one of Z" are understood to express that the element may be X, Y, Z; x and Y; x and Z; y and Z; or X, Y and Z (i.e., any combination of X, Y and Z). Thus, unless otherwise specified, such conjunctions are generally not intended to imply that certain needs exist for at least one of X, at least one of Y, and each of Z to be present.

References to the positions of elements (e.g., "top," "bottom," "above," "below") are used merely to describe the orientation of various elements in the figures. It should be noted that the orientation of the various elements may differ according to other examples, and such variations are intended to be covered by the present disclosure.

The hardware and data processing components used to implement the processes, operations, illustrative logic, logic blocks, modules, and circuits described in connection with the various disclosures may be implemented or performed with a general purpose single-or multi-chip processor, digital processor, signal processor (DSP), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described above. A general purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some embodiments, certain processes and methods may be performed by circuitry that is specific to a given function. The memory (e.g., memory unit, storage device) may include one or more devices (e.g., RAM, ROM, flash memory, hard disk storage) for storing data and/or computer code to complete or facilitate the various processes, layers, and modules described in this disclosure. The memory may be or include volatile memory or non-volatile memory, and may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in this disclosure. According to an exemplary embodiment, the memory is communicatively connected to the processor via the processing circuitry and includes computer code for performing (e.g., by the processing circuitry or the processor) one or more processes described in.

The present disclosure contemplates methods, systems, and program products on any machine-readable media for performing various operations. The present disclosure may be implemented using an existing computer processor, or by a special purpose computer processor for an appropriate system, incorporated for this or other purposes, or by a hardwired system. Embodiments within the scope of the present disclosure include machine, program products-readable media for carrying or storing machine-executable instructions or data structures. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

Although the drawings and description may illustrate a particular order of method steps, the order of the steps may differ from that depicted and described, unless specified otherwise above. Further, two or more steps may be performed concurrently or with partial concurrence, unless stated otherwise above. Such variations may depend, for example, on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the present disclosure. Likewise, a software implementation of the described methods can be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.

It is important to note that the construction and arrangement of the user profile management system 10 and its components as shown in the various examples is illustrative only. In addition, any element disclosed in one embodiment may be combined with or used in any other embodiment disclosed. Although only one example of an element from one embodiment that may be incorporated or used in another embodiment is described above, it should be understood that various other elements may be combined or used with any other elements.