Patent ID: 12249200

DETAILED DESCRIPTION

One approach to providing advanced functionalities to an electronic lock system is to provide the electronic lock system with means to communicate with a remote computer via a telecommunications network such as the Internet. Such electronic lock systems can be referred to as “connected” lock systems, an example of which is presented inFIG.1.

In one example of a connected lock system10, the control of the electronic lock12can be governed by an application14running on a computer16(which can be referred to as a remote computer or second computer), such as a cloud server or service provided server. The lock's internal computer (which can be referred to as the first computer or lock computer), can communicate with the application via a telecommunications network such as the Internet.

In one potential scheme of operation, an “owner” (e.g. a property owner or system administrator) wishing to provide authorization conditions specific to a first user (who may be a person other than the owner) may interface with the remote computer. This can be performed via a third computer18, such as a smartphone, tablet, laptop, desktop or other electronic device of the owner and via a telecommunications network such as the Internet for instance, and can involve a computerized secure authentication process. Via the application, the owner may determine authorization conditions for the user1, such as a predefined time period of authorized access for instance, or any other suitable authorization conditions (i.e. the authorization condition can be inherent in the fact that the user has access to a given code, can be that a given user will access a specific lock, and not another, and/or that a given user has access only during a defined time period of access, to name some examples). The application can then associate a user code to the user1. The user code can be associated, in a non-transitory memory of the first computer, to the authorization condition(s). The user code can be accessible directly to the user1via the application (e.g. a fourth computer such as a smartphone, tablet, laptop, desktop, or other electronic device of the first user may be used to communicate with the application over the telecommunications network) or accessed by the owner and relayed to the first user by the owner for instance. Then, when user1enters the code into the keypad of the electronic lock12, the electronic lock12communicates a request to the application via a secure connection, to determine whether the request should be granted in association to that user code and electronic lock or not. In this “connected lock system” example, this determination is made by the application itself, e.g. at the remote computer, and the authorization conditions themselves may not be communicated externally of the application (e.g. to user1) for security reasons. If the application14determines that the request satisfies the authorization condition(s), the application responds in a manner to authorize the request, and the electronic lock12grants the access, whereas if the application14determines that the request does not satisfy the authorization conditions, the application14responds in a manner to negate the request, and the electronic lock12denies the access. Similarly, one or more different user code can be associated to one or more additional user (e.g. user n), and tied to the same or different authorization conditions. The application may manage many different lock systems, each of which may be attributed a respective lock identifier (lockID).

Indeed, referring to the timeline presented inFIG.2for instance, a first user code may be attributed to a first user, and associated to authorization conditions specifying a first period of time A of exclusive access to premises to the first user. A second user code may also be attributed to a second user, before or after attributing the first user code to the first user. The second user code may be associated to authorization conditions specifying a second period of time B, distinct from the first period of time, of exclusive access to the premises to the second user. If the first user enters the first user code into the electronic lock12which controls the access to the premises during the first period of time A, the application14accessed by the electronic lock12will grant the access, whereas if the first user code is used during the second period of time B, the application14accessed by the electronic lock12will deny the access, and vice-versa for the second user code.

One advantage of such a connected lock system10is that it can offer a significant amount of versatility in terms of supported modes as the application can be run in a cloud server having quasi-unlimited computing capabilities. Moreover, when the users are persons other than the owner, the request does not require the owner's intervention at the time of access. Indeed, the owner can “program” the authorization conditions beforehand. In some cases, the programming of the authorization conditions can be automated to a certain degree and may even be controlled, via suitable software, without requiring intervention of the owner, but directly by the application14for instance (or another virtual instance which interfaces with the application14). One disadvantage of such a system is that the electronic lock12requires Internet connectivity to determine whether the authorization conditions are met, and access may thus be incorrectly negated in the event of any form of malfunction associated to the connectivity to the application14. Such disadvantages may be deemed unsatisfactory in some embodiments. Another potential disadvantage of such a connected lock system10is the possibility of piracy associated to the Internet connection ability.

It was found that in at least some embodiments, such disadvantages could be addressed or alleviated at least to a certain extent via a different scheme of operation. An example of such a scheme of operation is presented inFIG.3.

A main difference between the scheme of operation illustrated inFIG.1and the scheme of operation illustrated inFIG.3is that in the scheme of operation illustrated inFIG.3, the determination of whether a given code satisfies authorization conditions can be performed at the lock computer forming part of the electronic lock112rather than at a remote computer116running an application114. This can allow more resilience against eventual connectivity issues, such as failures of the telecommunications network, for instance. Such a mode of operation may appear counter-intuitive to persons having ordinary skill in the art, as one may ask, for instance, how to program authorization conditions into a lock computer of the electronic lock112taking into consideration the relatively limited input interface or computing capabilities that such a lock computer may have (e.g. a 12 digit keypad and firmware), and all applicable security and convenience requirements. It was found possible to achieve this in a satisfactory manner in at least some embodiments by using a technique which involves generating user codes which constitute, in fact, plain text programming instructions (plain text code). Each valid user code forms a cipher text of plain text code executable by the lock's computer.

More specifically, with reference toFIG.4for instance, plain text code130incorporating one or more command, such as an access control command including time period of access data132(and/or, as we will see below, one or more behavior-changing command) can be initialized in the form of a plain text code having between 6 and 31, between 6 and 15, between 6 and 12, or 6 or 8 characters (6 in the example presented inFIG.4). The characters can be selected as a function of characters associated to keys of a keypad of the electronic lock, and may be limited to numbers, or may include one or more of symbols and letters depending on the embodiment. Using only numbers is one possible embodiment.

The details of these requests can then be hidden to the users by encrypting them. In some embodiments, the encryption technique may lead to a resulting cipher text which may be longer, and perhaps a significantly longer string of characters than between 6 and 31, or between 6 and 15 characters, leading to a user code which may be deemed inconvenient or unpractical for many applications. In some other embodiments, the length of the user code can be limited. For instance, if format preserving encryption (FPE) is used to convert the plain text code into user codes (cipher text), the resulting user codes will have the same length (number of characters) as the associated plain text rcode, yet will remain undecipherable by the user as long as the user does not have access to the decryption key. A remaining challenge then is to produce plain text programming instructions in a format which accommodates a limited volume of data (number of bytes), and which can be represented by a relatively short string of characters, such as between 6 and 15 numeric characters, preferably 6 or 8. It was found possible to overcome this remaining challenge in a manner which involves selecting a suitable format and providing adapted firmware at the lock's computer. Indeed, in some cases, the firmware can expect the selected format, reducing the amount of information which needs to be shared by the payload, and some default values may be stored at the lock's computer for instance. Moreover, a character of the plain text code can be reserved for a mode number, and used, at the lock computer, to determine in accordance with which mode the command should be interpreted.

One example of an authorization condition is that the decryption succeeds in producing plain text programming instructions (plain text code) which are executable at the lock (i.e. where an attempt to execute the plain text does not lead to errors). Indeed, invalid codes may either not be decipherable or lead to plain text programming instructions which produce errors. However, as it will be understood from the further examples below, it can be preferred to provide additional authorization conditions, and such authorization conditions may depend on the nature of the security-controlled task requested. For instance, one authorization condition would be that the user code be only executable at a specific lock and not others. Another authorization condition could be that the user code be only executable during a given, defined, time period of authorized access. Another authorization can be that the cipher text includes a lock ID which matches the lock ID of the lock where the code is entered. Another additional authorization condition could be a successful validity check such as a checksum check, Luhn check or parity check. Indeed, a checksum, Luhn or parity can be included in the plain text code together with one or more command. More detail will be provided below.

Referring back toFIG.3, one way to avoid sharing the decryption key (associated to the encryption key) with the user is by providing the decryption key directly to the lock computer of the electronic lock112(e.g. at the time of installation or during maintenance). Accordingly, the electronic lock112can be enabled to decrypt the user code (i.e. the cipher text) into the plain text code, and then execute this plain text code, including determining whether any implicit or explicit authorization conditions are fulfilled or not, and performing a security controlled task contingent upon the authorization conditions being determined to be fulfilled. Example types of format preserving encryption (FPE) include FF3-1 and FF1. It was found that in some embodiments, using a format preserving encryption allowed to reach a code length having 6 numerical digits for instance, while allowing relatively complex operation modes. The nature of the security-controlled task to be performed can depend on the embodiment, and can include one or more of controlling an actuator to provide access to a physical space asset, and/or changing the behavior of the of the lock such as preventing a code which would have otherwise been executable from access going forward, and/or toggling the lock to automatic operation in accordance with a schedule. Accordingly, the plain text code can include an access control command (e.g. operate actuator to provide access for a few seconds), a behavior change command (e.g. revoke or override a code and/or toggle into or out from automatic activation in accordance with schedule), or both.

Let us now look more deeply into details of the example embodiment of a lock system110presented inFIG.3. In this example, the owner (e.g. a property owner or system administrator) wishing to grant access to an electronic lock112to a first user (e.g. user1) interfaces with an application114which runs on a computer116which is remote to the electronic lock112. This “remote computer”116can be a server such as a cloud server or a server located at premises owned by an owner of the premises or owned by a service provider. The remote computer116is not the lock computer at the physical locality of the electronic lock112. This can be performed via a third computer118, such as a smartphone, tablet, laptop, desktop or other electronic device of the owner and via a telecommunications network such as the Internet for instance, and can involve a computerized secure authentication process. Alternately, the application114can run on an electronic device of the owner and be accessed directly by the owner. Via the application114, which can provide a user-friendly interface to the owner, the owner may associate different authorization conditions132for different users.

The relatively simple example presented atFIG.4involves setting different access periods (e.g. days, hours, or other time increments) to different users (represented in the computerized environment as userIDs and/or lockIDs136). As presented inFIG.5, the application114running on the remote computer116, having received one or more command, and any specific authorization conditions132in association with a userID or lock ID, can incorporate the command(s) into plain text code130. Validity data such as a Luhn or parity can also be incorporated into the plain text code130. A mode number can also be integrated into the plain text code130. The application114can further encrypt the plain text code130to produce the corresponding user code134. In some embodiments, this user code134may be made available by the application to the owner him/herself, who may be responsible for communicating the different user codes134to the different users by any suitable means (in-person, telephone, email, text message, etc). In some other embodiments, these user codes134may be made available by the application directly to the different users. For instance, the owner may have entered user coordinates, such as email or sms phone numbers, directly into the application114, which may communicate the user codes134directly to the users, automatically. In an alternate embodiment, different users may be provided with a means of establishing a secure authentication process with the application114so as to access the codes directly, which may be more convenient to the owner.

The different users, each provided a user code, with or without knowledge that this code is in fact cipher text of plain text code including one or more command and readable by the lock computer, but without any means to access the decryption key, may then enter the user code into the interface which communicates with the lock computer (e.g. enter it via the keypad) at the premises/electronic lock112. As presented inFIG.6, the lock computer may then proceed to attempt to decrypt the user code, and if the decryption is successful, attempt to execute the plain text code, and if the execution is successful (e.g. does not lead to error) determine whether any explicitly embedded authorization conditions are met or not without requiring any access to a remote server or external application114.

Executing the command may have different results depending on the embodiment and the exact instance of which particular user code is being addressed. If the command is an access control command, it may lead to controlling an actuator to provide access to the physical space asset protected by the electronic lock. If the command is a behavior changing command, it may lead to executing one or more other types security-controlled tasks such as changing the behavior of the electronic lock going forward (e.g. revoking or overriding a user code which would otherwise have provided an acceptable request, or changing the schedule in accordance to which a common access lock is switched between open and closed). Example modes of operation will be presented below.

Referring back toFIG.3, similarly, one or more different user code can be associated to one or more additional user (user ID), and tied to different time period of access data. The application114can manage many different electronic locks112, each of which may be attributed a corresponding lockID. Such a scheme of operation may be applied to an electronic lock112which does not have a telecommunication network connectivity function, or to an electronic lock112which has a telecommunication network connectivity function (e.g. as a fallback in the event of a telecommunication network failure or other failures in the primary mode of operation). Indeed, an advantage of such a scheme of operation is that it may offer a significant amount of versatility, may not require the owner's intervention at the time of access, and may be more resilient to communication failures and/or to piracy.

It will be noted that depending on the embodiment the input interface of the electronic lock may have additional elements than a keypad e.g. (BLE, Wifi, AP, NFC, USB, . . . ), but in many embodiments, a keypad will be provided as part of the electronic lock system (either within a housing of an electronic lock itself or as part of a separate housing communicating wirelessly or in a wired manner with the housing of the electronic lock itself) and can use as a primary or, in some embodiments, only as an auxiliary mode of inputting the user code (e.g. in the event of connectivity issues).

A specific example use case, and several potential modes of operation executable in the context of this specific use case, will now be presented for the purpose of providing a thorough description. It will be noted that his example use case is but one potential example, and that many alternate embodiments are possible as will be understood by persons having ordinary skill in the art at the reading of this specification.

The specific use case can be referred to as “access code on demand” and involve: a) an administrator (such as a property owner, or service provider), b) an application which can be embodied here on a cloud server and responsible for generating the user code associated to authorization conditions, c) users, with each user having his/her own electronic device (e.g. PC, laptop, mobile phone, . . . ) to receive the user code from the application, d) the electronic lock having computer functionalities, an input interface having a pin pad and potentially any other suitable input means, and an actuator controllable by the lock's computer to control access to a physical space asset.

FIG.7Aschematizes one possible embodiment of an electronic lock212which can be seen to have a lock computer240configured to receive an input from an input interface242and to control an actuator244which can selectively block or unblock a handle246which controls a bolt, or pull or push a deadbolt248, or block or unblock a latch bolt, for instance, in this example. The electronic lock212can further have a time awareness module250, such as an internal clock, accessible by the lock computer240to determine whether any time-related authorization conditions (e.g.132,FIG.4) are met or not. It will be understood that this is but one example of an embodiment of an electronic lock, and that many alternate configurations are possible in other embodiments. In particular, it will be understood that the different electronic elements or computerized functionalities of the electronic lock can be incorporated in a same or distributed in different housings, and be configured for communicating with one another in a wired or wireless manner. The embodiment presented inFIG.7Ais an example relatively typical for the North American market where the lock computer, input interface (e.g. a keypad), time awareness module, and actuator are all integrated to a single housing of an electronic lock, an example of which is electronic lock112inFIG.3.

FIG.7Bprovides a different example of an electronic lock which is relatively typical for the European market where the lock computer, time awareness module and actuator are all integrated to a main housing associated to the latch or deadbolt of the electronic lock, but the keypad is manufactured and installed separately and configured to communicate with the lock computer in a wireless manner. The keypad can be adhered or fastened on a wall or on the door, in proximity to the main housing, at the premises of the electronic lock, for example.

A keypad typically has a number of keys associated to corresponding characters. The most typical use case is 10 digits and symbols, but other embodiments are possible. The characters of the user code can be constrained to the characters associated to the keys of the keypad, and to this end, it can be desired to standardize the keypad for the electronic locks associated to all lock IDs in some embodiments, or to limit the characters of the user codes to characters known to be common to keys of all keypads of all lock IDs.

FIGS.8A and8Bschematize an example configuration stage in accordance with this example use case,FIG.8Arepresents an example configuration stage for an online device, in which the access code on demand request scheme may be useful in the event of a telecommunication failure for instance, whereasFIG.8Brepresents a configuration stage for an offline device in which the access code on demand request scheme may be the primary mode of operation. The configuration stage includes providing a plurality of configuration elements to the electronic lock, such as setting the lock ID and providing the decryption key. In this specific example, the configuration stage further sets check-in/check-out hours, offset to cmt timezone, and a list of supported modes. In the online device scheme presented inFIG.8A, the configuration may be performed entirely remotely, i.e. without manual handling at the premises. In the offline device scheme presented inFIG.8B, the configuration may involve accessing the electronic lock through some form of local gateway while the configuration is performed.

FIG.9presents an example code generation stage in accordance with this example use case. The administrator, or perhaps in some embodiments to a certain extent the user him/herself, provides authorization conditions including a lock ID and a time frame for access such as a start day and a duration. The application can then generate the user code and communicate it to the user via text message, email, display it on a web page accessed by the user, etc.

FIG.10presents an example code use stage in accordance with this example use case. A person, typically a user, enters the user code on the lock. This step can be performed via a keypad, but alternately with any other suitable means such as various wireless transmission schemes.

In this example use case, the electronic lock's firmware supports: i) FF3 encryption (for constrained devices AES encryption is mandatory, and FF3-1 can be built on top of it); ii) DKF-SHA256 key derivation function (for constrained devices SHA256 is mandatory, KDF (e.g. HDKF) can be implemented on top of it); iii) a non-transitory memory such as flash storage to store revocation and/or override lists; and enough RAM to support encryption and key derivation. A lock ID check can be done through the decryption key derivation. Moreover, each lock is identified by its lock number which is a unique numeric value; each lock can be configured as a common access or a resident door; each lock of the same residence has a same root key; each lock is date aware (e.g. using RTC), and in some cases, common access locks may have a range of allowed “resident door” IDs set to restrict the access. As will be seen below, an embodiment may use a checksum (sha-256) for the configuration, but it will be understood that it may be preferable to replace this by a signature in some embodiments.

In this embodiment, each electronic lock may support up to 8 concurrent configurations, which may allow to validate codes from 8 different applications/sites.

Locks used at premises with several other electronic locks may be provided with a common root key. Electronic locks associated to resident doors may derive the root key with lock specific data, such as the concatenation of the current year and the lock number. If master codes mode is provided, the encryption key can be derived from dynamic data. If master codes mode is provided, the encryption key can be derived from the concatenation of the year, the day in the year. In this embodiment, due to the way we derive the Lock key, a code is only valid in the January 1st to December 31st range, but other ways to derive the lock key may be used in alternate embodiments. The derivation topic can be utf-8 encoded.

In this example use case the user codes can be 6 to 12 digits (including a checksum or parity), preferably 6 to 9 digits, and FPE encrypted, and can be as per the following generic view:

payloadLuhn or parityOTP Mode0-15 or 0-10-1513 to 23 bits4 bits or 1 bit4 bits

The Luhn or the parity can be computed on the payload, and then the Code is obtained by encrypting using Lock key and the FF3-1 algorithm.

The first mode which will be explored in the context of this example use case is the resident code. This is a code which is valid for an entire year (365 consecutive days) and which, in accordance with this example use case, can be revoked or overridden.

Code starting dayOverride levelLuhnOTP Mode1-3660-30-1509 bits2 bits4 bits4 bits

This gives a total of 19 bits (6 digits). For instance, if this code is generated on 2022 Jul. 18, it will be encrypted with 2022 key and the validy period will be from 2022-07-18 to 2023-07-18 (last day excluded). 4 override levels (0-3) can be supported. Such a resident code can be generated using the following example code in this example use case:

/ *** Resident code generation* the ResidentCode class is not disclosed.*/parameter startDate /**< the date object */parameter overrideLevel /**< the override level (integer) */parameter configuration /**< device configuration object *//** instantiate a ResidentCode object */let ACode = ResidentCode(startDate.dayOfYear( ), overrideLevel)/** compute & append the Luhn value (1 digit) */ACode.computeLuhn( )key = KDF(configuration.buildingKey, startDate.year( ) + configuration.lockNumber( ))outputCode = Acode.encrypt(key, configuration.buildingTweak)secure_wipe(key)del ACode

return outputCodeA second example mode in accordance with this example use case is the visitor code. The visitor code can be a code valid a specific day, starting at a specific time and for a selectable duration (in hours), and which can be revoked or overridden.

Duration (in hours) =OverrideOTPStart time2 * (value + 1)DaylevelLuhnMode0-230-31-3660-30-1515 bits2 bits9 bits2 bits4 bits4 bits

This gives a total of 26 bits (8 digits)

A third example mode in accordance with this example use case is the short term code. The short term code is valid from specific day for a selectable duration (in days). This is a code which can be revoked but not overridden, and which can fit vacation rental usage for instance.

Override levelOverrideParity bit(optional, presentflagStartDuration(set if evenOTPif flag is set)(optional)day(in days)parity)Mode0-30-11-3661-310-122 bits1 bit9 bits5 bits1 bit4 bits

The parity bit is set if the payload parity is odd (payload: concatenation of start day, duration and the override level), which gives a total of 19 bits (6 digits). Optionally: to become active, the code must be entered within a defined time frame (from the stay start), otherwise the code is no longer accepted.

A fourth example mode in accordance with this example use case is the long term code. It is a code which is valid until a defined day. It can be revoked or overridden.

end yearEnd on dayOverride levelLuhnOTP Mode0-11-3660-10-1531 bit9 bits1 bit4 bits4 bits

Here, the end year field value is max(target end year−current year, 1), and the override level had been reduced to 1 bit to fit in 6 digits. This gives a total of 19 bits (6 digits).

A fifth example mode in accordance with this example use case is a delivery code. The code is valid only once in specific week. It can be suitable for a home delivery service. It can be revoked or overridden.

week deliveryValid on weekidentifierOverride levelLuhnOTP Mode1-520-70-30-1546 bits3 bits2 bits4 bits4 bits

This gives a total of 19 bits (6 digits). The code counter allows to generate different codes for different deliveries on the same week.

A sixth example mode in accordance with this example use case is a revocation code. The revocation code can be used to revoke a generated code, independently of whether the code to be revoked has already been used or not.

OTP to revokeLuhnOTP Mode<encrypted OTP value>0-15519 to 26 bits4 bits4 bits

This gives a total from 27 to 34 bits (9 to 11 digits)

A seventh example mode in accordance with this example use case is a passage mode code. Such a code can be configure the device to stay in a state where anyone can access (or be denied the access). It can be revoked or overridden. In the example use case, this mode may be enabled only in electronic locks configured as “common access” locks.

Start timeDurationPassageOTP(half hour steps)(half hour steps)ModeOverrideLuhnMode0-471-480-10-30-1566 bits6 bits1 bit2 bits4 bits4 bits

This gives a total of 23 bits (7 digits).

Passage mode values:

Valuedescription0(Passage mode) The Lock opens at “Start time” for “Duration”1(Lock out mode) The Lock closes at “Start time” for “Duration”

Notes: 1—If the “Start Time” is set to 0 and “duration” is set to 48, the selected mode remains endlessly active; 2—To cancel the current Passage/Lock out state, a code with the same starting hour, duration and mode must be entered; 3—if the Lock is in a Passage or Lock out mode and a new code is entered, the Lock must switch to the new parameters.

An eighth example mode in accordance with this example use case is a time based master code. Such a code can allow access to all devices. The code can be time-based and valid for 10 minutes, and can be revoked or overridden. The Master code use a different key derivation topic in this example use case, the encryption key is HKDF(Root key, year| day of the year).

(optional)codeDay of theCodeTick in theOverrideOTPlifespanyearcountercurrent daylevelLuhnMode0-151-3660-30-1440-30-1574 bits9 bits2 bit8 bits2 bits4 bits4 bits

This gives a total of 29 bits (9 digits), 10 digits if the optional code lifespan is used. The Tick value is computed as: Tick=(start.hour*60+start.minutes)/lifespan. The code counter allows to generate 4 different codes for the current 10 minutes period.

Lifespan valueCode lifespan010min115min230min31h41 h 30 min52h63h74h86h98h1010h1112h1214h1316h1420h1524h

An ninth example mode in accordance with this example use case is a flex code mode. The code is valid from specific day for a selectable duration up to 366 days. It allows flexible check-in/check-out hours. It can be revoked but not overridden.

This code is a variable length code: The start day & duration field are encoded in 6 to 9 bits (each), the field length is declared in the duration size and start day size fields. The check-out and check-in hours are optional. If one of those is used, the Check-in/Check-out flag must be set according to the selected option.

(optional)Override(optional)(optional)Check-in/startlevelParitycheck-outcheck-inCheck-outstaydayduration(if overrideOverride(set if evenOTPoffsetoffsetflagdurationstart daysizesizeflag is set)flagparity)Mode0-150-150-11-3661-3660-30-30-30-10-184 bits4 bits1 bit6 to 9 bits6 to 9 bits2 bits2 bits2 bits1 bit1 bit4 bits

The start day size and duration size fields are computed the same way (respectively to the targeted field). The duration size is computed as the minimum size to encode the stay duration field, with a minimum of 6 bits and a maximum value if 366. It can be computed as duration_size=max(ceil(log 2(stay_duration))−6, 0).

When building the frame, the Stay duration field multiplier can be

duration sizefield multiplier064112822563367

Multiplier can be fetched from a look up table (or dictionary) or a literal such as duration_multiplier=min(1<<(duration_size+6), 367).

If the Check-in or the Check-out options are used, the Check-In/Check-Out flag must be set. This flag is set to ‘1’ if the code contains the Check-in option and is reset to ‘0’ if only the Check-out option is used. Examples:

Check-in optionCheck-out optionI/O flagNot usedNot usedNot presentNot usedused0UsedNot used1UsedUsed1

If used, the Check-in/Check-out fields are encoded on 4 bits (fixed length)

In this example use case, the device key (except for the master key) is derivated from the root key and the concatenation of the year and the Lock-id. This means that every year, the codes must be renewed. The proposal supports to use N−1 year codes for their whole lifespan. Example: if a short term code starts on December 20th for 20 days, the code remains valid in year+1 up to January 10th at midnight. In this example use case, the grace period is supported only for the following modes: Resident code; short term code; long term code; Flex code; revocation code.

The other modes may not require grace period: delivery code is planned on a specific week number (this does not overlap 2 years); maintenance code is scheduled for a specific day; passage mode is an autonomous mode (no code needed once configured), if the user wants to disable it he will have to generate a new code; and Master code is a time based One Time Password (OTP) valid only for a specific day/hour.

The optional overriding function may be useful to generate codes which will automatically revoke a previously generated user code (which may have a lower override level incorporated into the authorization conditions) having an overlapping authorized access period.

In this example use case, the code generation algorithm can run on a cloud server or on a mobile application, and be in accordance with the algorithm presented atFIG.11A. WithFIG.11Bpresenting an example of a potential graphical user interface to facilitate the entering of the parameters associated to the authorization conditions. In this example, tabs can be used to reflect different modes. The selection of each tab can lead to a corresponding window which limits the prompts to values required in association to the corresponding mode. In this example, the generated user code is displayed at the bottom of the screen following entry of the parameters and clicking the “generate code” button.

In this example use case, the code validation algorithm at the electronic lock can be as presented atFIG.12Afor instance, in which case the electronic lock first tries to decrypt master code message (key derivation with year and day in the year), check the Luhn. If the Luhn is correct, process the Master code, otherwise, try to decrypt user codes with key derivation based on year and lock-id. And check the checksum according to the mode. If the entered code is not accepted, the lock computer may activate a throttling mechanism to avoid brute force attack. An example throttling algorithm may be such as

A simple implementation could be:

def on_code_verification_failed(failure_number: int = 0):″″″Implement throtling mecanism on wrong codeThe wait time is defined as 5 * 2{circumflex over ( )}(failure_number − 1) with a maximum of 1 minute.Thus for the 1st failure the penalty is 5 seconds, for the 3rd it will be 40 s,for the 4th or more wrong code the penalty will be 1 min (per code):param: failure_number: number of consecutive wrong codes, must be reset to 0 if a validcode is used:return: None″″″if failure_number <= 0:failure_number = 1wait_time = min(5*2**(failure_number − 1), 60)time.sleep(wait_time)

It will be understood that the code validation algorithm presented atFIG.12Ahas several optional functionalities and is very specific to the use case, it is provided only for the purpose of example.FIG.12Bprovides an example subroutine to address potential one time password mode.

In this example use case, code usage may be as follows: for a “resident door” lock, the user just enters his code and validates with hash sign. Example: Bob has resident code: 604 068. On his door lock, he will use “604068#”. For “common access” locks, the “Resident Door” lock Number can be used to validate a code. In accordance with one example, the “Resident Door” Lock Number is inputted as a prefix to the code. Example: Bob is the Owner of Lock Number 25. His resident code is 604 068. On “Common Access” Locks he will input: “25#604068#”. Such a use case can be introduced into the multihousing vertical and the vacation rental vertical for instance.

Referring toFIG.13, it will be understood that the expression “computer”400as used herein is not to be interpreted in a limiting manner. It is rather used in a broad sense to generally refer to the combination of some form of one or more processing units412and some form of memory system414accessible by the processing unit(s). The memory system can be of the non-transitory type. The use of the expression “computer” in its singular form as used herein includes within its scope the combination of a two or more computers working collaboratively to perform a given function. Moreover, the expression “computer” as used herein includes within its scope the use of partial capabilities of a given processing unit.

A processing unit can be embodied in the form of a general-purpose micro-processor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), application specific integrated circuits (ASIC), a reconfigurable processor, and a programmable read-only memory (PROM, to name a few examples.

The memory system can include one or more memory of one or more types, such as a suitable combination computer-readable memory located either internally, externally, and accessible by the processor in a wired or wireless manner, either directly or over a network such as the Internet. A computer-readable memory can be embodied in the form of random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) to name a few examples. A memory can be non-transitory. A memory can be non-volatile. A memory can be a register of a security processor, for instance. A memory can be secure or general purpose.

A computer can have one or more input/output (I/O) interface to allow communication with a human user and/or with another computer via an associated input, output, or input/output device such as a keyboard, a mouse, a touchscreen, an antenna, a port, etc. Each I/O interface can enable the computer to communicate and/or exchange data with other components, to access and connect to network resources, to serve applications, and/or perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, Bluetooth, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, to name a few examples.

It will be understood that a computer can perform functions or processes via hardware or a combination of both hardware and software. For example, hardware can include logic gates included as part of a silicon chip of a processor. Software (e.g. application, process) can be in the form of data such as computer-readable instructions stored in a non-transitory computer-readable memory accessible by one or more processing units. With respect to a computer or a processing unit, the expression “configured to” relates to the presence of hardware or a combination of hardware and software which is operable to perform the associated functions. Different elements of a computer, such as processor and/or memory, can be local, or in part or in whole remote and/or distributed and/or virtual.

The methods and systems of the present disclosure may be implemented in a high level procedural or object oriented programming or scripting language, or a combination thereof, to communicate with or assist in the operation of a computer system, for example the controller. Alternatively, the methods and systems described herein may be implemented in assembly or machine language. The language may be a compiled or interpreted language. Program code for implementing the methods and systems described herein may be stored on a storage media or a device, for example a ROM, a magnetic disk, an optical disc, a flash drive, or any other suitable storage media or device. The program code may be readable by a general or special-purpose programmable computer for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. Embodiments of the methods and systems described herein may also be considered to be implemented by way of a non-transitory computer-readable storage medium having a computer program stored thereon. The computer program may comprise computer-readable instructions which cause a computer, or more specifically the processing unit of the computing device, to operate in a specific and predefined manner to perform the functions described herein, for example those described in the methods.

Computer-executable instructions may be in many forms, including program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments. The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments.

The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements. The embodiments described herein are directed to electronic machines and methods implemented by electronic machines adapted for processing and transforming electromagnetic signals which represent various types of information. The embodiments described herein pervasively and integrally relate to machines, and their uses; and the embodiments described herein have no meaning or practical applicability outside their use with computer hardware, machines, and various hardware components. Substituting the physical hardware particularly configured to implement various acts for non-physical hardware, using mental steps for example, may substantially affect the way the embodiments work. Such computer hardware limitations are clearly essential elements of the embodiments described herein, and they cannot be omitted or substituted for mental means without having a material effect on the operation and structure of the embodiments described herein. The computer hardware is essential to implement the various embodiments described herein and is not merely used to perform steps expeditiously and in an efficient manner.

As can be understood, the examples described above and illustrated are intended to be exemplary only. The scope is indicated by the appended claims.