Patent Description:
Locks and keys are evolving from the traditional pure mechanical locks. These days, electronic locks are becoming increasingly common. For electronic locks, no mechanical key profile is needed for authentication of a user. The electronic locks can e.g. be opened using an electronic key stored on a special carrier (fob, card, etc.) or in a smartphone. The electronic key and electronic lock can e.g. communicate over a wireless interface. Such electronic locks provide a number of benefits, including improved flexibility in management of access rights, audit trails, key management, etc..

However, management of access rights for electronic keys can be complex and time consuming, especially for large organisations where access rights are managed for many people and many locks. This complexity is also a security risk, since large complexity can lead to mistakes, which can lead to security risks.

<CIT> discloses a method of controlling access to a location, the location being secured by a lock mechanism, the system comprising an access control management system adapted to administrate electronic keys for a plurality of locations and a plurality of users.

<CIT> discloses secure door entry without a traditional card reader made possible by tagging the door with an unpowered, unique token which can be read by a user's personal mobile electronic device.

<CIT> discloses systems and methods for electronic access control for secured assets including locked facilities, lockers, shared vehicles and vending machines, which do not have internet connectivity.

<CIT> discloses an apparatus comprising a memory configured to store a user key specific to a particular user or token; software code; a token relating to a second apparatus, the token comprising the user key and the software code, and at least one processing core configured to: participate in an interaction with the second apparatus, the interaction being based at least partly on the token and the user key and the interaction comprising transmitting the token to the second apparatus.

One objective is to improve convenience and security for managing access rights for electronic keys in mobile devices.

According to a first aspect, it is provided a method of claim <NUM>.

The one or more access groups may also be used for access to computer-based assets.

The method may further comprise the step of renewing validity of the token prior to it expiring.

The step of authenticating may comprise receiving user input for authentication data and providing the authentication data to the authentication server.

The step of authenticating may comprise collecting biometric data of the user.

In the step of authenticating, the authentication server may be a single sign-on server.

The token may be in a format according to JavaScript Object Notation Web Token, JWT.

The step of obtaining a lock identifier may be based on short-range wireless communication.

According to a second aspect, it is provided a system of claim <NUM>.

Additional examples are provided in claim <NUM>.

The mobile device may further comprise instructions that, when executed by the processor, cause the mobile device to renew validity of the token prior to it expiring.

The step instructions to authenticate may comprise instructions that, when executed by the processor, cause the mobile device to receive user input for authentication data and provide the authentication data to the authentication server.

The instructions to authenticate may comprise instructions that, when executed by the processor, cause the mobile device to collect biometric data of the user.

The authentication server may be a single sign-on server.

The instructions to obtain a lock identifier may comprise instructions that, when executed by the processor, cause the mobile device to obtain the lock identifier based on short-range wireless communication.

<FIG> is a schematic diagram illustrating an environment in which embodiments presented herein can be applied. A lock <NUM> is provided to secure access to a physical space <NUM>. The physical space <NUM> can e.g. be or be part of a home, office, factory, garden, drawer or any other suitable physical space which can be secured by an electronic lock <NUM> provided by a door, window, gate, hatch, drawer, etc..

The lock <NUM> is an electronic lock and can be opened on command from an access control device <NUM>. Optionally, the access control device <NUM> is integral to the lock <NUM>, i.e. the access control device <NUM> and the lock <NUM> are combined in a single device. Alternatively, the access control device <NUM> is implemented as a standalone device or on one or more local or remote servers, e.g. using a cloud service. As explained in more detail below, a mobile device <NUM> of a user <NUM> communicates with the access control device <NUM> to request access, i.e. to unlock the lock <NUM>. The mobile device <NUM> may be implemented as part of a mobile phone, a smartphone, a key fob, wearable device, smart phone case, access card, electronic physical key, etc. The mobile device <NUM> acts as an electronic key for the user <NUM> to unlock the lock <NUM>.

The mobile device <NUM> can communicate with the access control device <NUM> over local communication link. The local communication link can be any suitable short-range wired or short-range wireless communication, e.g. using Bluetooth, Bluetooth Low Energy (BLE), any of the IEEE <NUM> standards, Radio Frequency Identification (RFID), Near Field Communication (NFC).

The mobile device <NUM> is also connected to a wide area network (WAN) <NUM> over a WAN link. The WAN <NUM> can e.g. be based on Internet Protocol (IP) over WiFi or any suitable cellular network standard, and can form part of the Internet.

An authentication server <NUM> is provided, connected to the WAN <NUM>. This is often termed that the authentication server <NUM> forms part of the cloud, whereby the authentication server <NUM> is here illustrated forming part of the WAN <NUM>. The authentication server <NUM> can be implemented as a single server device or as part of multiple server devices, as known in the art per se, e.g. in a so-called cloud implementation.

The authentication server <NUM> can be a single-sign on server, e.g. conforming to OpenID or any other suitable scheme. The authentication server <NUM> can be used for access to network services, such as any one or more of network login services (e.g. corporate network), web services, remote storage services, etc. Additionally, as detailed below, the authentication server <NUM> is here also used for access to a physical space <NUM> secured by the lock <NUM>.

<FIG> is a sequence diagram illustrating communication between various entities of embodiments which can be applied in the environment of <FIG>.

First of all, the authentication server <NUM> provides a public key <NUM> to the access control device <NUM>. This will allow the access control device to verify cryptographic signatures by the authentication server <NUM>.

The user <NUM> triggers an authentication process with the mobile device <NUM> by providing appropriate user authentication user input <NUM>, e.g. a username and password and/or biometric credentials (e.g. face, finger, iris, retina, etc.). The mobile device sends an authentication request <NUM> comprising the user input to the authentication server <NUM>, in other words a login request.

If the authentication is successful, the authentication server <NUM> responds with a token <NUM>. Otherwise, if the authentication is not successful, the sequence ends. The token <NUM> contains an indication of one or more access groups to which the user <NUM> belongs and a validity time for the token. These access groups are used to control physical access. For instance, in an office setting, a user can belong to door group <NUM> and door group <NUM>. Door group <NUM> is defined elsewhere in the system to map to set of doors in the building. Door group <NUM> is mapped to another set of doors. The two sets may overlap, so that there can be doors that map to both door groups. The user has access to all the doors or locks that are mapped to any of the door groups present in the token.

For instance, in a residential multifamily setting, an access group could be tenant X or the landlord. Tenant X could be mapped to a particular apartment door and common facilities, while the landlord could be mapped to all doors in the building.

The mobile device <NUM> stores the token <NUM> until it is used. At some point in time, the user <NUM> approaches the lock <NUM> and obtains the lock ID <NUM> from the lock <NUM> over a local communication link. The mobile device <NUM> is now ready to send an access request <NUM> to the access control device <NUM>. The access request <NUM> comprises the token <NUM> and the lock ID <NUM>. The access control device <NUM> is now ready to check whether to unlock the lock <NUM>.

The access control device <NUM> verifies (using the public key <NUM>) that the token <NUM> (including its access group(s) and validity time) is validly signed by the authentication server <NUM>. The access control device <NUM> also checks the validity time of the token to ensure that the validity time has not expired. The one or more access groups are then extracted from the token <NUM>. If the lock id is mapped to at least one of the one or more access groups (e.g. company x), this indicates that the user <NUM> of the mobile device <NUM> is allowed to unlock the lock and the access request is granted. The access control device <NUM> obtains (from local or remote storage) a mapping between access groups and lock IDs, allowing the access control device to determine what lock ID belongs to certain access group. Each lock ID can be mapped to zero, one or more access groups. Optionally, there is an intermediate group of lock groups. In that case, there is a first mapping between the lock id and zero, one or more lock groups, as well as a second mapping between each lock group and zero, one or more access groups. In any case, the access control device is configured to determine if the lock id is mapped to the one or more access groups of the token.

Once access is granted, the access control device <NUM> sends an unlock command <NUM> to the lock <NUM>.

<FIG> is a flow chart illustrating embodiments of methods for requesting access to a physical space secured by a lock. The method is performed in the mobile device. The method essentially corresponds to actions performed by the mobile device in the sequence diagram of <FIG>, described above.

In an authenticate step <NUM>, the mobile device authenticates the mobile device with an authentication server. As part of the authentication, the user device can receive user input for authentication data to be included in the authentication request (<NUM> of <FIG>) to the authentication server. The authentication data can e.g. comprise a username and password and/or biometric credentials (e.g. face, finger, iris, retina, etc.).

The authentication, if deemed successful by the authentication server, results in a token (being a data item) indicating one or more access groups to which the user belongs. In other words, there is at least one association with the user and an access group. Each access group is configured to be associated with a plurality of users, e.g. at least two users. The token generated and cryptographically signed by the authentication server and received by the mobile device. The token can be in a format according to JWT (JSON (JavaScript Object Notation) Web Token). As mentioned above, the authentication server can be a single sign-on server. The one or more access groups may also be used for access to computer-based assets, such as one or more file system.

The token has a specific validity time, after which it expires unless it is renewed. Alternatively or additionally, the token has a validity schedule, e.g. that it is only valid between <NUM> a. and <NUM> p. on weekdays (Monday to Friday).

In a store token step <NUM>, the mobile device storing the token in the mobile device.

In an obtain lock id step <NUM>, the mobile device obtains a lock identifier of the lock. This obtaining can be based on short-range wireless communication or by reading an optical code comprising the lock id. When the access control device is implemented in a remote device, e.g. in a server, this step can also comprises obtaining a pointer to the access control device. The pointer can be in the form of a URI (Uniform Resource Indicator). In this case, the lock identifier and the URI can be separate data items. Alternatively, the lock identifier is included in the URI, e.g. as a HTTP (Hypertext Transfer Protocol) GET parameter, in which case the URI is specific for the particular lock.

In a transmit access request step <NUM>, the mobile device transmits an access request to an access control device. The access request comprises the token and the lock identifier.

In an execution sequence separate from steps <NUM>-<NUM> , the following steps are optionally performed. The separation of execution sequences can be implemented e.g. using separate threads, processes or even separate hardware processors.

In an optional conditional soon invalid step <NUM>, the mobile device determines if the validity time of the token is about to expire. For instance, remaining validity time can be compared to a threshold duration, whereby the token is determined to be invalid soon if the expiry time is less than the threshold duration. If it is determined that the token is invalid soon, the method proceeds to an optional renew validity step <NUM>. Otherwise, the optional conditional soon invalid step <NUM> is re-executed, optionally after a wait time (not shown). It is to be noted that the optional conditional soon invalid step <NUM> can be implemented by polling or trigger-based determination.

In an optional renew validity step <NUM>, the mobile device renews validity of the token. This is performed in communication with the authentication server <NUM>. The renew process is quicker and less resource demanding than re-executing the authenticate step <NUM>.

Using the embodiments presented herein where a token and lock id is used for access determination by the access control device, access rights for a user using a mobile device is managed by the authentication server. As described above, the authentication server can be a server that is also used for access to computer network related infrastructure, such as corporate network logins and servers. These embodiments allow the role of the authentication server to seamlessly expand into physical access.

When applied e.g. for a company with both network access and physical access (to office spaces, etc.), management of physical access is both intuitive and simple. Each access group can then be used both for user access to physical assets and computer-based assets. For instance, a user of an access group 'employees' will need access to both a corporate computer network and to an office location. Finer granularity is easily managed with additional access groups. For instance, a user of an access group 'IT department' can be given access to more network resources as well as a server room. Both of these resources should be accessible to all members of the 'employees'. The user of the access group 'IT department' can of course also be a member of the access group 'employees'.

If a user leaves the organisation (e.g. if an employee quits), all types of access rights are conveniently and securely revoked in one system.

The lock does not need to store anything regarding users or access rights. This improves security since even if a hacker were to gain access to the lock, access rights are not managed there.

<FIG> is a schematic diagram illustrating components of the mobile device <NUM> of <FIG> according to one embodiment. A processor <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions <NUM> stored in a memory <NUM>, which can thus be a computer program product. The processor <NUM> could alternatively be implemented using an application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc. The processor <NUM> can be configured to execute the method described with reference to <FIG> above.

The mobile device <NUM> further comprises an I/O interface <NUM> for communicating with external and/or internal entities. Optionally, the I/O interface <NUM> also includes a user interface.

Other components of the mobile device <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> shows one example of a computer program product <NUM> comprising computer readable means. On this computer readable means, a computer program <NUM> can be stored, which computer program can cause a processor to execute a method according to embodiments described herein. In this example, the computer program product is an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. As explained above, the computer program product could also be embodied in a memory of a device, such as the computer program product <NUM> of <FIG>. While the computer program <NUM> is here schematically shown as a track on the depicted optical disk, the computer program can be stored in any way which is suitable for the computer program product, such as a removable solid-state memory, e.g. a Universal Serial Bus (USB) drive.

Claim 1:
A method for requesting access to a physical space (<NUM>) secured by a lock (<NUM>), the method being performed in a mobile device (<NUM>) of a user (<NUM>), an authentication server (<NUM>) and an access control device (<NUM>), and comprising the steps of:
authenticating (<NUM>) the mobile device (<NUM>) with the authentication server (<NUM>), resulting in a token (<NUM>), being a data item, indicating one or more access groups (20a-b) to which the user (<NUM>) belongs, and comprising a validity time of the token, wherein the token (<NUM>) is cryptographically signed by the authentication server (<NUM>);
storing (<NUM>) the token (<NUM>) in the mobile device (<NUM>);
obtaining (<NUM>), by the mobile device (<NUM>), a lock identifier (<NUM>) of the lock (<NUM>); and
transmitting (<NUM>), by the mobile device (<NUM>), an access request (<NUM>) to the access control device (<NUM>), the access request (<NUM>) comprising the token (<NUM>) and the lock identifier (<NUM>);
verifying, by the access control device (<NUM>), that the token (<NUM>) is validly signed by the authentication server (<NUM>);
checking, by the access control device (<NUM>), the validity time of the token (<NUM>) to ensure that the validity time has not expired;
extracting, by the access control device (<NUM>), said one or more access groups (20a-b) from the token (<NUM>);
obtaining, by the access control device (<NUM>), a mapping between said one or more access groups (20a-b) and one or more lock identifiers (<NUM>), and if the lock identifier (<NUM>) of the access request (<NUM>) is mapped to said one or more access groups (20a-b), access is granted and:
sending, from the access control device (<NUM>), an unlock command (<NUM>) to the lock (<NUM>).