Method and system for the configuration of small locking systems

Abstract

The present invention relates to a method and a system for the configuration of small locking systems with electronic locks, preferably electronic locking cylinders, which can preferably communicate with passive RFID cards. The present invention particularly relates to a method and a system which not only allows the easy configuration of locks/locking cylinders, but also of corresponding RFID cards, preferably by using a smartphone.

Claims

1. A method for the configuration and administration of a locking system comprising at least one electronic locking and at least one identification medium for operating the locking, wherein the method comprises the following steps: a) providing a smartphone with an administration software for the administration and configuration of the at least one locking and the at least one identification medium wherein the smartphone may communicate with the locking and the identification medium via a wireless communication link; b) allocating access rights of the identification medium to the locking via the administration software of the smartphone and locally storing said allocation of access rights in the smartphone, wherein the allocation of access rights from identification media to corresponding lockings may be visualized and configured by means of a locking-identification-media-matrix on the display of the smartphone; c) reading out the identification data which are specific for the locking/identification medium and transmitting said data as well as the access rights from step b) to a cloud, d) generating programming data, preferably encoded programming data, and/or key data in the cloud by means of a server in the cloud on the basis of said transmitted allocations; e) receiving the programming data or the encoded programming data and/or key data from the cloud using the smartphone; and f) transmitting the key data from the smartphone to the at least one identification medium and/or transmitting the programming data from the smartphone to the locking.

2. The method according to claim 1, wherein the locking system comprises a plurality of electronic lockings and a plurality of identification media.

3. The method according to claim 1, wherein i) a locking may be a device from the group of: electronic locking cylinder, electronic lock and electronic fitting; and/or ii) an identification medium may be a device from the group of: RFID card, key card, smartphone with RFID functionality and transponder.

4. The method according to claim 1, wherein the smartphone communicates with the locking and/or the identification medium by means of an adapter.

5. The method according to claim 1, wherein the cloud provides a dataset service and a cloud-LSM-service wherein the smartphone communicates with the cloud-LSM-service and the cloud-LSM-service communicates with the dataset service, wherein the key data and programming data preferably form part of a dataset which is generated by the dataset service.

6. The method according to claim 5, wherein the mobile key server is an OverTheAir mobile key server and the key data are sent wirelessly, preferably via the mobile communications network to a smartphone having a corresponding software (mobile key app).

7. The method according to claim 1, wherein user data are stored or generated on the basis of the allocations by means of the cloud-LSM-service.

8. The method according to claim 1, wherein the cloud additionally comprises a mobile key server for storing and distributing the key data, wherein the key data are used by an identification medium for opening a locking, and the mobile key server transmits the key data to a smartphone with a corresponding software (mobile key app).

9. The method according to claim 1, wherein between step a) and b) the step a1) for inventorying the at least one locking and/or the at least one identification medium is carried out, in which the at least one locking and/or the at least one identification medium is recorded and unambiguously identified and in step c) data regarding the recorded lockings and/or identification media are additionally transmitted to the cloud.

Description

SHORT DESCRIPTION OF THE FIGURES

(1) In the following, preferred embodiments of the present invention are described, thereby referring to the Figures:

(2) FIG. 1 shows a schematic overview of the basic structures of the locking system according to the invention;

(3) FIG. 2 shows a locking-identification-media-matrix as it is shown on a display of a smartphone;

(4) FIGS. 3, 4 and 5 show a preferred design of a locking-identification-media-matrix as it is shown on a display of a smartphone;

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

(5) FIG. 1 shows as first embodiment according to the invention a schematic overview of the basic structures of a system according to the invention. One advantage of the invention is that the locking system—which preferably comprises a plurality of electronic lockings—may be installed and/or administrated preferably by using an admin-app 1, which may preferably be executed on a smartphone, a tablet computer and/or a computer. In particular, the admin-app may be seen as a realization of a system component according to the invention, which is a user interface. The admin-app preferably provides at least one of the following functionalities:

(6) Login or Registration

(7) Preferably, at first an authentication of an administrator by the admin-app is preferred, in order to prevent manipulations. For example, an administrator may authenticate himself in a login window with input field for username and password (login-password), wherein the password may simultaneously be the password for the locking system. Alternatively, the login-password and the password for the locking system may be different passwords/code words. When registering for the first time, for example an input field for the generation of a user name plus password and repetition of the password appears. If a secure element is available on the smartphone, for example a secure element for NFC, on which the admin-app is executed, the password may be stored in the secure element so that for example a short PIN for authentication may be considered sufficient for subsequent logins.

(8) The user (administrator) who is thereby authenticated may now for example generate identification media (for example key card 11 in FIG. 1) or lockings (for example lock 10 in FIG. 10). In other words, the lockings of the locking system are firstly registered with the corresponding identification media. Furthermore, the administrator may determine which lockings may be opened by which identification media, i.e. access authorisations of the identification media may be allocated to the lockings, which are for example visualized in a lockings-identification-media-matrix. A lockings-identification-media-matrix in general is shown for example in FIG. 2 and more specific in FIG. 3. Preferably, the allocation of locking to identification medium is (at first) only intermediately stored locally on the smartphone.

(9) If a “Save to Cloud” command (for example in the matrix window, see FIG. 3) is executed later, new “accounts” are generated corresponding to the allocations in the cloud, preferably on a SOHO-cloud-server 101.

(10) The method according to the invention generates, after the generation of lockings, a “success” pop-up and generates subsequently the locking-identification-media-matrix and shows identification media but also inventoried lockings and identification media. After successful login on the admin-app, for example a lockings-identification-matrix opens on a display of the smartphone (see FIGS. 2 and 3). Here, additionally two symbols may be shown, “Add Lock” and “Add Key”. The lockings-identification-media-matrix may subsequently be changed by adding new lockings (Add Lock) or new identification media (Add Key).

(11) According to a preferred embodiment it can/must be checked at the SOHO cloud server, after each successful login, whether there already exist locking system data for said account. If so, they are downloaded and visualized in the matrix. In this case, a successful download preferably is the requirement for subsequent working at the locking plan.

(12) If it is tipped on one of the “Add” symbols (Add Key, Add Lock), an additional empty column or row is firstly generated and the lower half of the display shows a keyboard so that now a name can be allocated to the locking/identification medium to be added (see FIG. 4). The name should preferably be inserted at the right place in the matrix. Therefor, the matrix is automatically scrolled such that the name field to be recorded is visible. After the name has been inserted, one pushes “return” (or “ready”), the keyboard disappears and the view of FIG. 3 appears again. Preferably, the locking which has newly been generated is marked (for example in blue color) and the font is for example in italics (this is the note that the locking is not yet inventoried). Now, the user/administrator may choose whether he subsequently taps said marked locking with the smartphone or whether he tips again one of the “Add” symbols. If a locking is tapped, i.e., a wireless communication between the smartphone and the locking is generated, the locking is inventoried with name and UID/PHI and then preferably appears in normal font in the matrix, which symbolizes a finished process. If, however, it has not been tapped, the font remains in italics, which shows that the locking has not yet been inventoried. The inventory may be made up for preferably at any time, by marking the name of the locking to be inventoried via tipping on the smartphone (which for example causes a blue highlighting). Subsequently the respective locking has to be tapped, which causes an unambiguous allocation of the hardware identifier (UID of cards, PHI of lockings) to the name chosen by the admin. Said inventory of lockings may correspondingly be carried out for identification media, i.e., the method described in the section above may also be applied when the term locking is replaced by identification medium. Preferably, the process of generating and inventorying is repeated as often as necessary to register the complete locking system.

(13) A locking system generated by the method above may be visualized easily on the display of the smartphone via the locking-identification-media-matrix according to the invention (see FIG. 5). For example, in FIG. 5 the following is shown: the locking system's name (“Peter's locking plan”); the lockings/locks (“Main Entrance”, Door lock no. 1, . . . ), the identification media (“master key”, Peter Martens, . . . ), the authorisation structure (see further below), markings (for example highlighting), programming requirement (lightning flash), possible time limits for identification media (clock symbol). Said matrix is preferably scrollable via “touch and drag”. If one scrolls for example to the right or to the left, the locking system's names (in the example above “Peter's locking plan”), as well as the names of the lockings remain at the same place whereas the names of the keys (identification media) follow the movement of the matrix window. If one scrolls for example upwards or downwards, the names of the locks correspondingly follow the movement of the matrix window, whereas the name of the locking system and the names of the keys remain at the same place. Preferably, the matrix may be drawn up such that the input fields may be enlarged such that authorisation crosses may be set or removed comfortably via tipping with the finger.

(14) The allocation of authorisation accesses is preferably carried out via tipping the authorisation fields in the matrix. The removal of the access authorisations is preferably carried out via a second tipping. This usually generates a programming requirement which is visualized after a “save to cloud” (see FIG. 3) and automatic download of the programming data (see further below) with programming requirement flashes. The programming requirement is preferably shown with regard to the respective lockings as well as with regard to the respective identification media.

(15) The matrix according to the invention also enables a clear visualization of programming target and actual states. Preferably, four possibilities exist regarding the authorisation state, which may be visualized as follows: (i) no cross is shown, identification medium is not supposed to be authorized and is not authorized either (no programming requirement); (ii) cross is shown in italics or thin, identification medium is supposed to be authorized regarding corresponding locking, however, is not yet authorized (programming requirement); (iii) cross is shown bold, identification medium is supposed to be authorized and is also authorized (no programming requirement); (iv) cross is shown inversely, identification medium is not supposed to be authorized, but is still authorized (programming requirement).

(16) One further advantage of the locking system according to the invention is the allocation of device-specific properties, i.e. the allocation of specific properties for individual locking(s) and/or individual identification medium/media. The allocation of device-specific properties is carried out for example after tipping the devices (lockings or identification media) in the matrix twice (alternatively: long tipping). After tipping the name of a device for the first time, said device is for example deposited (in the state which is achieved after tipping once, a device which is not yet inventoried might be inventoried by tapping on, see further above). If the name of the marked device is tipped on for a second time, preferably the following specific properties may be allocated.

(17) A pop-up window with editable input fields can be opened for a locking, in said pop-up window the name of the locking and/or the indication how long the locking should remain open after opening, may be inserted. In case the locking is already inventoried and a “save to cloud” was already carried out, additionally for example a question mark symbol appears which opens, after clicking on it, a transparent information field with locking data.

(18) For an identification medium similar pop-up windows may be edited, i.e., for example the name of the locking (“name of key”) and/or time periods when the identification medium may access the locking (“Key shall be valid from”, “Key shall expire”). If the identification medium is already completely inventoried and the system has recognized a smartphone, further input fields may appear, which determine how long the identification medium is valid after a download (“Key shall be valid for hours after download of key data”).

(19) Storing locking system data in the cloud and transmitting key datasets for smartphones received from the cloud to the OTA key server is preferably carried out after tipping the button “Save to Cloud” in the matrix basic view. After tipping “Save to Cloud” in the matrix basic view, for example a pop-up window appears which shows the process progress with progress bar. During said process, for example web-service-based functionalities of all locking system data generated by the admin may be deposited in the SV locking system database of the SOHO cloud server. Said functionalities form the so-called SIK (software integration kit) interface for already administered locking system data. Vice versa, after successful login of the admin, all data may be downloaded from the cloud for a visualization in the matrix. Additionally, a service preferably is available which can detect all programming requirements.

(20) After successful upload of the locking system data (“Save to Cloud”), a central service (dataset service 102) detects or calculates programming datasets for all lockings and identification media, said programming data sets then being sent back to the admin's smartphone and stored there. For example, also key data (data for the identification media) for smartphones may be sent to the OTA-key-server 103, where they may be accessed at any time from the mobile key users (mobile key app). In FIG. 1 this is shown for example by the arrow “depositing key data”. Alternatively or additionally, the key data may also be sent from the SOHO-cloud-LSM-service 101 directly back to the OTA key server 103 (not explicitly shown in FIG. 1).

(21) The SOHO-Cloud-LSM-service is a central service of the system according to the invention. Said service allows depositing and administrating user data and user profiles (admin access data, authorisation matrix etc.) of the SOHO users on a central database server. One may comfortably administrate a SOHO locking system via different devices due to the central storage of the data “in the cloud”. Data which are relevant for safety as for example the locking system password, are, however, not stored in the cloud. The SOHO-Cloud-LSM-service is accessed via the admin-app and communicates with the dataset service.

(22) The invention also comprises the exact expressions, features, numeric values or ranges etc, if said expressions, features, numeric values or ranges are mentioned before or after in the context with terms like for example “approximately, about, substantially, generally, at least” etc (i.e. “approximately 3” also comprises “3” or “substantially radial” also comprises “radial”).