Access control methods and systems are previously known in which electronic lock devices are installed at doors, gates, etc., so as to provide conditional access to protected environments. A user that seeks access to such a protected environment will use an electronic key device which will communicate with the lock device in question. Based on this communication, the lock device will decide whether or not to allow the user to access the protected environment, for instance by controlling an electro-mechanical lock which is included in or coupled to the lock device.
Generally, there are two distinctly different categories of access control systems. In the first category, the key device acts as an intermediate device to allow communication between the lock device and a remote central server. Such communication may take place over existing wide-area data and/or telecommunication networks. The outcome of this communication will determine whether or not the key device—and the user carrying it—shall be granted access to the environment protected by the lock device at any given moment.
WO 2006/098690 discloses an access control system of a second category. In WO 2006/098690, the electronic key devices are capable of short-range wireless data communication with the lock devices. Each key device has a key device identifier which is used for the short-range wireless data communication, and the lock device is configured to perform authentication of an appearing key device by detecting the key device identifier of the key device and using the detected key device identifier, together with some other parameters, to determine whether access shall be granted. Each lock device is a stand-alone device with its own internal power source and requires no wiring to its surroundings. When a key device approaches and seeks access, the lock device will communicate with the key device using short-range wireless data communication, but it will typically not need any further communication with other, more remote elements in the system, such as a central server. In order to operate autonomously, the lock device uses local lock access data which is stored within the lock device and defines the key device identifiers of key devices which are allowed to access the protected environment. In one embodiment, the key devices are mobile terminals or other similar types of portable communication devices being equipped with short-range wireless data communication interfaces in the form of Bluetooth® transceivers. Hence, the key device identifier of each key device is the unique Bluetooth® address assigned to the Bluetooth® transceiver in the key device.
In an access control system of the above second category, where the lock devices operate autonomously on locally stored lock access data, there will be an issue when it comes to providing the lock access data into the lock devices. Initially, when a new lock device is to be installed at the intended protected environment, the lock device may be programmed with certain initial lock access data, either during the manufacturing procedure, or by service personnel before or during the actual installation. This initial lock access data will then define an arbitrary number of key devices which are authorized to access the protected environment, these key devices being identified in the lock access data by their respective key device identifier (Bluetooth® address).
Once installation is completed, the autonomously operating lock device has no other contact with the surroundings, except when an appearing key device seeks access to the environment protected by the lock device. The access control system of WO 2006/098690 is therefore configured to exchange various data between key device and lock device, once the key device has been successfully authorized and a bi-directional Bluetooth® link has been established between the devices. The types of data exchanged include log file and status data recorded by the lock device regarding for instance previous attempts by key devices to access the environment protected, as well as updated lock access data intended to replace or upgrade the existing lock access data in the lock device. Such updated lock access data will have been generated by an administrator at a remote administration server and sent in advance to the key device over one or more existing communication networks such as the Internet and/or a telecommunications network. Upon receipt, the key device will have buffered the updated lock access data, waiting for an opportunity when the user of the key device approaches the lock device in question to forward the updated lock access data to the lock device.
In this way, service personnel do not have to visit the premises where the lock device is installed in order to update the lock access data. Instead, updated lock access data may be sent via the key device over existing communication networks, as mentioned above. However, this requires that the key device which visits the lock device is indeed authorized to access the protected environment; otherwise there will be no Bluetooth® link established between the devices and, consequently, no opportunity for the key device to forward the updated lock access data to the lock device. In turn, in order to be considered as authorized by the lock device, the key device identifier of the key device must be included in the current lock access data in the lock device. In other words, the key device must already be known to the lock device. Actually, in real-world implementations, not all key devices are typically allowed to bring updated lock access data to lock devices. Rather, a subset of particularly trusted key devices is designated as ambassadors; only these will be allowed to bring updated lock access data to the lock devices. Ambassador key devices may for instance be possessed and used by managers, security personnel or other trusted users in the access control system.
As time passes, any real-world implementation of an access control system will experience needs to add new users/key devices to the system, to change which particular key devices that shall be able to access each particular lock device, to remove users/key devices from the system, etc. These needs will be all the more frequent and complicated, the bigger and more complex the access control system grows. This will be considered in more detail in a later section of this document with reference to FIG. 1.
One particularly problematic situation which needs to be handled is when a whole set of key devices, which has hitherto been defined as authorized according to the current lock access data in one or more lock devices, no longer shall be authorized but instead be replaced by a new group of key devices. If none of the key devices in the new group is previously known to a lock device, then that lock device will not be prepared to communicate with any such unknown key device and will therefore not be able to receive the updated lock access data.
Another particularly problematic situation is when a new key device is to be added to the list of authorized key devices for a particular lock device, but that lock device is only visited by an ambassador key device at infrequent occasions. This may mean that the new key device's access to the particular lock device is considerably delayed by as much as a week, month or even more.
Generally, the invention seeks to find a trade-off between two opposing interests—to allow for a flexible way of distributing sets of updated lock access data to all relevant lock devices, while maintaining security at an acceptable level.