SE538543C2

SE538543C2 - Access control method, and associated proxy device and access control system

Info

Publication number: SE538543C2
Application number: SE1551022A
Authority: SE
Inventors: Bliding Olle
Original assignee: Phoniro Ab
Priority date: 2012-12-18
Filing date: 2013-12-18
Publication date: 2016-09-13
Also published as: WO2014098755A1; SE1551022A1

Abstract

46 ABSTRACT A proxy device (300) is disclosed for use in an access control system Whichcomprises a lock device (140) and a key device (100) being a mobile terrninal, Whereinthe lock device (140) is operatively connected to a lock (150) and the key device (100)is associated With a user (2). The proxy device (300) has controller means (310); aproxy device identifier (PD_ID); and at least one short-range communication interface(330, 340). The controller means (310) is configured for causing said at least one short-range communication interface (330) to establish a first connection (14A) With the keydevice (100) and receive an authentication, possibly including a key device identifier(KD_ID) for the key device (100). The controller means (310) is also configured forcausing said at least one short-range communication interface (340) to establish asecond connection (14B) With the lock device (140) and provide to the lock device(140) an identifier (KD_ID, PD_ID, KD+PD_ID) Which allows the lock device (140) todetermine Whether or not access should be granted to the lock. The second connection isestablished on behalf of the key device (100), and said proxy device (300) acts as adevice identifier tunnel between the key device (100) and the lock device (140). In oneembodiment the short-range communication interface comprises a Bluetooth® interface With Which said second connection With said lock device is established Without pairing. To be published With Figure 3

Description

ACCESS CONTROL METHOD, AND ASSOCIATED PROXY DEVICE ANDACCESS CONTROL SYSTEM Field of the Invention The present invention relates to access control, and more particularly to aproxy device for use in an access control system in which a key device is incompatiblewith a lock device. The invention also relates to an access control method in which aproxy device provides a communication channel between a lock device and a keydevice. The invention also relates to an access control system which involves a plurality of lock devices, a plurality of key devices and at least one proxy device.

Background of the Invention The most common way to lock and unlock an access-controlling object such asa door, a gate or a window is probably by using a mechanical key. This solution is costefficient and easy to use, and a sophisticated mechanical lock is hard to force. However,there are two drawbacks with this solution: the user always has to bring the key, and thekey does not have any restrictions, i.e. it always works. These drawbacks might seemlike minor disadvantages, which might be true in situations with one user and one door,but in situations with a large number of users and a large number of doors thedrawbacks are of considerable importance. In more particular, if a large number of usersmust have access to a large number of doors, a large number of keys has to be made forthe different doors. For several reasons, this is not only unhandy but also a considerablesecurity risk and costly.

Firstly, in order to reduce the security risk, some sort of key administration isnecessary. This type of administration is costly.

Secondly, a user who receives a key might abuse it, and even if the user is aresponsible person, the key might be stolen or lost. Since there are no built-inrestrictions in a mechanical key the security risk becomes significant. Consequently,handing out a large number of keys is a security risk.

Thirdly, if one of the keys is lost or stolen the corresponding lock has to be substituted, as well as all the other corresponding keys, in order to maintain the security.

The administration costs, locksmith costs and all interruptions due to these keysubstitutions imply considerable costs for a lost key.A mechanical key system is hencenot suitable for situations with a large number of users and a large number of doors. Anexample of such a situation is the elderly home care or home nursing, where thedomestic help personnel has a key to each of the caretakers. In such services, there maybe a vast number of doors that need to be handled resulting in thousands of key and lockcombinations. In such systems it is necessary to carry a great number of keys, which iscumbersome, or use a master key, which is unsafe if many master keys need to beprovided (which is the case when there are many nurses). Furthermore, there is aproblem in selecting the correct key for a specific lock, and this manual procedure maytake a very long time and be quite frustrating for a nurse if she handles many caretakers,thereby having a great number of keys.

In order to solve this problem another type of locking system is necessary. InWO 02/31778 Al a wireless lock system is presented. When the lock of the systemdetects a nearby electronic key carried by a user, a random signal is generated. The keyencrypts the signal and retums it to the lock. The lock decrypts the signal and comparesit to the original to determine if the lock should be unlocked.

In order to ﬁanction, the wireless lock system mentioned above must alwaysestablish a two-way wireless communication link between the key and the lock. This isa drawback, since the establishment of a two-way communication link is not madeinstantly. Hence, a user has to wait for a period of time until the establishment of thetwo-way communication link is completed, and thereafter the user has to wait until thecomparison is completed. When a wireless lock system, like the one shown in WO02/31778 Al, is implemented with the de facto standard for short-range wireless datacommunication for mobile devices, namely RF communication in accordance with theBluetooth® standard on e.g. the 2.45 GHz ISM band, one must expect at least about 5seconds, and possibly up to as much as 15 seconds, for the establishment of the two-way Bluetooth® link alone; to this one must add the time required for performing thedata exchange and comparison.

Users who are used to mechanical keys are not used to wait at the door, which will make the aforementioned waiting period into a source of irritation. In addition, if a large number of doors is to be opened every day the unlocking process must be smoothand easy. Hence, it is desired to reduce the time that lapses from the lock's detection of anearby electronic key until the unlocking of the lo ck, or more particularly the delay thata user may experience Waiting in front of the lock for it to unlock.

The intemational patent application WO 2006/098690 discloses an accesscontrol system that proposes a solution to overcome these problems. In WO2006/098690, the electronic key devices are capable of short-range wireless datacommunication with the lock devices. Each key device has a key device identifier whichis used for the short-range wireless data communication, and the lock device isconfigured to perform authentication of an appearing key device by detecting the keydevice identifier of the key device and using the detected key device identifier, togetherwith some other parameters, to determine whether access shall be granted. Each lockdevice is a stand-alone device with its own intemal power source and requires no wiringto its surroundings. When a key device approaches and seeks access, the lock devicewill communicate with the key device using short-range wireless data communication,but it will typically not need any further communication with other, more remoteelements in the system, such as a central server. In order to operate autonomously, thelock device uses local access control data which is stored within the lock device anddefines the key device identifiers of key devices which are allowed to access theprotected environment. In one embodiment, the key devices are mobile terrninals orother similar types of portable communication devices being equipped with short-rangewireless data communication interfaces in the form of Bluetooth® transceivers. Hence,the key device identifier of each key device is the unique Bluetooth® address assignedto the Bluetooth® transceiver in the key device.

However, although this solution reduces the time to get access granted from upto 30 seconds to a mere 2-4 seconds, it does require that the key device is capable ofestablishing at least a one-way Bluetooth® connection. Also, for the key device to beable to communicate with a central server, such as an administrative server, the keydevice also has to have some form of long range communication interface. Due to thislatter requirement a mobile phone or other mobile terminal, for example a personal digital assistant arranged with mobile communication capabilities, is a good choice of key device. Most persons already have access to a mobile phone anyway. However, aBluetooth® device typically requires pairing with a second device in order to allowconnection with it. To pair two devices, a passcode has to be entered into both devices.The same passcode must be entered into both devices, and since a stand-alone lockdevice typically does not have a user interface, a norrnal user can not easily input such apasscode. Instead, an administrator would have to visit the lock device and connectsome sort of set-up device in order to enter the required passcode and complete thepairing. Lately, more and more manufacturers of mobile phones and/or operatingsystems for mobile phones have started requiring that their products must be paired toestablish a Bluetooth® connection with another device. Thus, many mobile phonessuffer from an incompatibility with the kind of lock device seen for instance in WO2006/098690, since it can not easily be paired with the lock device.

To overcome the problem of entering a passcode in the lock device, the lockdevice may be hard-coded to a speciﬁc code. Such a hard-coded code may be generic,such as “0000°, or specific to the lock device, for example the tail portion of itsBluetooth® address. Such solutions suffer from the drawback of reduced security (inthe case of a generic code) or that the mobile phone is not configured to handle a vastnumber of Bluetooth® devices, as will be the case for applications such as in a homenursing service where there may be thousands of doors that need to be locked/unlocked(in the case of a specific code).

A further problem that exists in some prior art mobile phones is an inherentdifficulty in retrieving the BluetoothTM address of the device. This is difficult not onlyfor a user, but also for a designer in some cases, whereby such mobile phones areincompatible with a BluetoothTM operated lock in that it will be difficult and/or timeconsuming to establish a connection with the lock.

Hence, a problem with access control systems of the type shown for instance inWO 2006/098690, is that mobile phones fail to qualify as suitable key devices, sincethey have an incompatible communication interface and hence cannot connect to thelock device using the lock device°s preferred communication interface. Therefore, anoperator of an access control system cannot benefit from the widespread use and distribution of mobile phones.

Summary of the Invention In view of the above, an objective of the invention is to solve or at least reducethe problems discussed above.

On a conceptual level, the invention is based on the inventive insight that in anaccess control system where a lock device is arranged with a short range interface suchas a Bluetooth® interface and the key device is arranged with another interface which isin some way incompatible for establishing a connection with the lock device, a proxydevice can be introduced to establish a communication channel between the key deviceand the lock device, wherein the proxy device will serve as a proxy for the key deviceand act as a data tunnel between the key device and the lock device.

In view of the above, a first aspect of the present invention therefore is a proxydevice for use in an access control system which comprises a lock device and a keydevice being a mobile terminal, said lock device being operatively connected to a lockand said key device being associated with a user. The proxy device comprises controllermeans; a proxy device identifier; and at least one short-range communication interface.The controller means is configured for causing said at least one short-rangecommunication interface to establish a first connection with said key device and receivean authentication, possibly including a key device identifier for said key device. Thecontroller means is further configured for causing said at least one short-rangecommunication interface to establish a second connection with said lock device andprovide to said lock device an identiﬁer which allows said lock device to determinewhether access should be granted to said lock or not, wherein said second connection isestablished on behalf of said key device and wherein said proxy device thereby acts as adevice identifier tunnel between said key device and said lock device. In oneembodiment the short-range communication interface comprises a Bluetooth® interfacewith which said second connection with said lock device is established without pairing.

By realizing that a proxy device can be introduced to act as a tunnel betweenthe lock device and the key device, the incompatibility issues are resolved and it ispossible to establish a connection quickly and easily between the key device and the lock device without initial pairing. Furthermore, there is no longer any requirement to pair the lock device, as the proxy device can be paired with the key device in the caseswhere the key device requires to be paired before communicating. Also, it is alsopossible to increase the safety of the lock system as both a proxy device and a keydevice may be required to be presented to the lock device.

The use of a proxy also simplifies the selection of the correct key to be used, aseach proxy is able to handle a vast number of locks. Instead of finding the correct keyfor a specific lock manually, the proxy device is arranged to do this automatically,thereby simplifying the door opening process and reducing the frustration and stress of auser.

In one embodiment said controller means is further configured for receiving amessage from either of said key device and said lock device and forwarding saidmessage to the other of said lock device and said key device, thereby acting as a datatunnel between said key device and said lock device.

In one embodiment the authentication includes indication of an authenticationtime period (ATP), and, in one embodiment, the proxy device is further configured toterrninate said first connection with said key device before establishing said secondconnection.

By introducing the proxy device, a communication tunnel for data can also beachieved between the lock device and the key device, thereby allowing the two devicesto exchange data despite any incompatibility issues they may have had.

In one embodiment the controller means is further configured for causing saidat least one short-range wireless communication interface to establish said secondconnection initially as a one-way connection. This allows for a connection to beestablished quickly, as the proxy device may be broadcasting some identifier datacontinuously and the lock device does not need to communicate back to the key deviceto ascertain whether access should be granted or not in cases where only an identifier isneeded.

In one embodiment the controller means is further configured for deterrniningif said received message is to be adjusted and if so, adjusting said received messagebefore forwarding it. Also, in one embodiment the controller means may be further configured for adjusting the content of said received message to reﬂect the original sender and/or receiver. Additionally, in one embodiment the controller means may befurther configured for adjusting the recipient and/or sender of said received message.This allows the proxy device to act as a transparent communication tunnel between thelock device and the key device, which do not need to know that they are in factcommunicating with a proxy device. This allows the proxy device to be used in analready installed access control system without making any change to the lock devices.

In one embodiment, the identifier provided to said lock device, allowing it todetermine whether access should be granted or not, is said received identifier of saidkey device. Altematively, in one embodiment, the identifier provided to said lockdevice, allowing it to determine whether access should be granted or not, is said proxydevice identifier of said proxy device. Altematively, in one embodiment, the identifierprovided to said lock device, allowing it to determine whether access should be grantedor not, is a combination of said proxy device identifier of said proxy device and saidreceived identifier of said key device. This allows the proxy device to control the ﬂowof data being tunneled between the key device and the lock device, always making surethat each recipient knows who to respond to.

In one embodiment, said at least one short-range communication interfacecomprises a Bluetooth® interface with which said second connection with said lockdevice is established. In such an embodiment, the proxy device identifier of said proxydevice (300) may advantageously the Bluetooth® address of said Bluetooth® interface.

In one embodiment, said at least one communication interface comprises anyof a Bluetooth® interface, an IrDA interface, an NFC interface, a WLAN interface or aUSB interface, with which said first connection (l4A) with said key device (l00) isestablished. If Bluetooth® is used, a single Bluetooth® transceiver may advantageouslybe used both as the interface to the lock device and as the interface to the key device,thereby saving components, power and cost. On the other hand, by providing anotherkind of interface than Bluetooth® for said first connection, the proxy device can beenabled to communicate with key devices not having a Bluetooth® interface, therebysolving an apparent incompatibility between the lock device and the key device.

In one embodiment the message comprises updated access control data, emanating from a central server and to be stored in a local database in the lock device.

By allowing the key device to push updated access control data to the lock device, itbecomes easier to update the access rights for any existing user, and also to add ordelete a user without having to send a special operator person, such as an administrator,to visit each lock.

In one embodiment the message comprises log and/or status data, emanatingfrom the lock device and to be forwarded by said key device to a central server. Thisallows for a lock device to communicate back to such a central server more frequentlyand alleviates the requirement for a lock device to wait for a special operator person tocome by to collect the log and/or status data.

In one embodiment, the proxy device further comprise input means forreceiving a user input, wherein said controller means is conf1gured for causing said keydevice to contact an emergency service in response to said input means receiving saiduser input. Also, in this or another embodiment, the proxy device further comprisesinput means for receiving a user input, wherein said controller means is conf1gured forcausing an audible alarm to be generated in response to said input means receiving saiduser input. This allows the proxy device to be used as an alarm button which allows anemployer to provide employees with extra security. This becomes particularly useful inenvironments where access rights are granted such as in care taking environments, andallows a user to quickly contact an emergency service should he discover that one caretaker is in need of emergency help.

A second aspect of the present invention is an access control systemcomprising a proxy device according to the first aspect of the present invention, and alock device, where the lock device comprises a short-range wireless communicationinterface, controller means, memory means associated with the controller for storing alocal database containing access control data, and a lock actuator. The controller meansis conf1gured for: receiving an identifier from said proxy device via said short-rangewireless communication interface, matching said received identifier against the accesscontrol data in said database, and, if a match is found, causing said lock actuator tounlock a lock operatively connected to the lock actuator. In such a system the lockdevice does not have to communicate directly with the key device but is rather arranged to communicate with a proxy device, should the key device not be able to establish a communication channel with the lock device. This allows for greater ﬂexibility inselecting key devices and provides for a greater range of key devices to be used.

In one embodiment, said lock device is configured for further matching ofadditional verification data received from said proxy device against said access controldata before causing said lock actuator to unlock said lock. This allows for greatersecurity to be built into the access control system by requiring that a code such as a PINcode should be entered before access is granted.

In one embodiment, the access control system further includes a key devicebeing a mobile terminal which comprises controller means, memory means, and short-range communication interface means for communicating with said proxy device. Inone embodiment, the access control system further comprises a central server whichallows for data to be communicated between a lock device and a central server.

In one embodiment the key device is housed in or implemented as a softwaremodule of the central server.

In one embodiment the lock device is configured for detecting a vibration (orknocking) pattem and, in response thereto, activate said short-range wirelesscommunication interface, wherein said vibration pattem is specific to the lock deviceand/or corresponds to one or several knocks possibly in a speciﬁc rhythm.

A third aspect of the present invention is a method for controlling a lock in anaccess control system which comprises a key device being a mobile terminal, a proxydevice and a lock device. The method comprises: establishing a first connectionbetween said proxy device and said key device; in said proxy device, receiving anidentifier for said key device; establishing a second connection between said proxydevice and said lock device, and from said proxy device, providing to said lock devicean identifier which allows said lock device to determine whether access should begranted to said lock or not, wherein said second connection is established on behalf ofsaid key device and wherein said proxy device acts as a device identifier tunnel betweensaid key device and said lock device. In one embodiment the second connection is a Bluetooth® connection which is established without pairing.

One benefit of introducing the proxy device is that the user does not need toleam a new user interface. The user will still use his key device and use it in the way hedid before.

In one embodiment the method further comprises detecting a first lock devicehaving a first priority, detecting a second lock device having a second priority, anddeterrnining whether said first priority is higher than said second priority, and, if so,establishing said second connection with said first lock device, and, if not, establishingsaid second connection with said second lock device.

Another benefit is that a proxy device can be introduced to an existing oralready installed system without changing the system, since the proxy device acts as atunnel between the key device and the lock device and the two units do not need to beaware that they are in fact communicating via a proxy device.

Yet another benefit is that the security of the system is increased as access isonly granted if the two devices are present. In other words, not only the key device, butalso the proxy device must be presented to the lock device.

Other objectives, features and advantages of the present invention will appearfrom the following detailed disclosure as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to theirordinary meaning in the technical field, unless explicitly defined otherwise herein. Allreferences to "a/an/the [element, device, component, means, step, etc]" are to beinterpreted openly as referring to at least one instance of said element, device,component, means, step, etc., unless explicitly stated otherwise. The steps of anymethod disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. ll Brief Description of the Drawings The above, as well as additional objectives, features and advantages of thepresent invention, will be better understood through the following illustrative and non-limiting detailed description of embodiments of the present invention, reference beingmade to the appended drawings.

Figure l is a schematic view of an access control system in whichembodiments of the present invention may be exercised.

Figure 2 illustrates an access control method which may be performed in theaccess control system of Figure l.

Figure 3 is a schematic block diagram of a proxy device which may interactwith both a key device and a lock device in the access control system of Figure l.

Figure 4 is a schematic block diagram of a key device which may interact witha proxy device in the access control system of Figure l.

Figure 5 is a schematic block diagram of a lock device which may interact witha proxy device in the access control system of Figure l.

Figures 6A-6C, 7A-7C and 8A-8C are each a schematic ﬂowchart diagram ofan access control method according to different embodiments.

Figure 9 is a schematic block diagram of an embodiment of the access controlsystem of Figure l comprising a proxy device which may interact with both a keydevice and a lock device in combination with a time graph of the communication between the proxy device and the key device and the lock device.

Detailed Description of Embodiments The present invention is advantageously implemented in a mobiletelecommunications system, one example of which is illustrated in Figure l. The mobiletelecommunications system comprises a mobile telecommunications network ll0.Central elements in Figure l are a wireless key device (KD) l00 and a wireless lockdevice (LD) 140. The purpose of the lock device l40 is to control some sort of lockmechanism in a lock, which in the illustrated example is a door lock on a door l52. InFigure l, a second door l52a is also shown, indicating that the manner herein may be used with a plurality of doors, each door l52, l52a having its respective lock device 12 140, 140a. In turn, the lock device 140 is operated by the key device 100 when broughtin the vicinity of the lock device. In more particular, the lock device 140 is enabled forshort-range wireless data communication in compliance with a communicationstandard. In the preferred embodiment, this communication standard is Bluetooth®.Having been the de facto standard for short-range wireless data communication formobile devices during several years, Bluetooth® is believed to be very well known tothe skilled person, and no particulars about Bluetooth® as such are consequently givenherein. As will be described in more detail later, a proxy device (PD) 300 is provided asan interrnediate tunneling device between the key device 100 and the lock device 140.

The mobile telecommunications network 110 is operatively connected to awide area network 120, which may be Intemet or a part thereof. Various clientcomputers and server computers, including a central server 122, may be connected tothe wide area network 120. A public switched telephone network (PSTN) 130 isconnected to the mobile telecommunications network 110 in a familiar manner. Varioustelephone terrninals, including a stationary telephone 132, may be connected to thePSTN 130.

An embodiment of the key device KD 100 is shown in Figure 4.Correspondingly, an embodiment of the proxy device PD 300 is shown in Figure 3 andan embodiment of the lock device LD 140 is shown in Figure 5.

In a real life implementation of the invention there is typically more than onelock device 140 (e.g. the lock device 140 and the lock device 140a of figure 1), morethan one key device 100 and more than one proxy device 300. Together with the centralserver 122 (having a system database 124 in which central access control data is stored),these devices 100, 140, 300 will form an access control system. In a real lifeembodiment of such an access control system there will also be key devices 100 that donot suffer from incompatibility issues with the lock device and therefore may not need acorresponding proxy device 300. In such a case, the key device 100 and the lock device140 will be communicating directly with one another. This is indicated by the dashedline 14 in Figs 4 and 5.

In the embodiment disclosed in Figure 4, the key device 100 is a mobile terminal, e.g. a cellular telephone (mobile phone), personal digital assistant (PDA), 13 internet tablet, smart phone, etc., which is capable of communicating with atelecommunications system, such as the one shown in Figure 1. Thus, a user 2 may usethe key device 100 for Various telecommunication services, such as voice calls, Intemetbrowsing, video calls, data calls, facsimile transmissions, still image transmissions,video transmissions, electronic messaging, and e-commerce. Generally, thesetelecommunication services are not central within the context of the present invention;there are no limitations to any particular set of services in this respect. Therefore, onlycomponents which are somehow pertinent to the inventive ﬁ.1nctionality are shown inFigure 4.

The key device 100 may also be implemented as a server, a computer or asoftware module in a server which is capable of communicating with a network system,possibly being a telecommunications system such as in Figure 1. This will be describedin more detail with reference to Figure 9 in a later part of this document.

As seen in Figure 4, the key device 100 has a network interface 430 forconnecting to the Intemet/telecommunications network(s) 110, 120. The networkinterface 430 may comply with any commercially available mobile telecommunicationsstandard or specification, including but not limited to GSM, UMTS, LTE, D-AMPS,CDMA3000, FOMA and TD-SCDMA. Altematively or additionally, the networkinterface 430 may comply with a wireless data communication standard such as WLAN(Wireless Local Area Network).

The key device 100 also has a man-to-machine interface (MMI), or userinterface (UI) 420, which may include a display 422 and a set of keys 424 or other inputdevice, as well as other known UI elements like a speaker and a microphone. The user 2may control the operation of, and exchange data with, the key device 100 over the userinterface 420.

Further, the key device 100 has an interface 440 for short-range datacommunication. In the disclosed embodiment of Figure 4, the interface 440 comprises aBluetooth® transceiver, by means which the key device 100 can communicate with, forinstance, the proxy device 300 (to be described in more detail later), over a first connection or Bluetooth® link 14A (if there is no incompatibility issue between the key device 100 and the lock device 140, the key device 100 could communicate directly 14 With the lock device 140 over a Bluetooth® link 14). The Bluetooth® transceiver isassigned a unique Bluetooth® address KD_ID, Which serves as a key device identiﬁer ofthe key device 100. Altematively or additionally, the interface 440 may for instancecomprise transceiver components for IrDA (Infrared Data Association), WLAN or NFC(Near Field Communication). In one altemative emboidment, the key device 100 doesnot comprise any interface for short-range Wireless communication, but a connectorinterface such as a Universal Serial Bus interface, i.e. a USB port. It should be notedthat a key device 100 may comprise both a short-range Wireless interface and aconnector interface. In Figure 4, any connector interface is seen to be part of the shortrange communication interface 440, and any communication emanating from thatcommunication interface is part of the communication link 14A.

A processing unit 410 is overall responsible for the operation and control of thedifferent components of the key device 100. The processing unit 410 may beimplemented in any knoWn controller technology, including but not limited to aprocessor (PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or analoguecircuitry capable of performing the intended functionality. The processing unit 410constitutes an implementation of the key device°s controller means, as referred to in theSummary section of this document.

Finally, the key device 100 has a memory 450 Which is operatively connectedto the processing unit 410. The memory 450 may be implemented by any knoWnmemory technology, including but not limited to E(E)PROM, S(D)RAM and flashmemory, and it may also include secondary storage such as a magnetic or optical disc.Physically, the memory 450 may consist of one unit or a plurality of units Whichtogether constitute the memory 450 on a logical level. In addition to storing variousprogram instructions and data for the various functions and applications Which aretypically available in a mobile terminal, the memory 450 also comprises programinstructions 452 and Work data for an access control software application executed inthe key device 100. Also, any updated access control data received from the centralserver 122 and to be forwarded to the lock device 140 Will be buffered in the memory 450, as seen at 456.

With reference to Figure 5, the lock device 140 generally comprises thefollowing main components. A processing unit 510 is overall responsible for theoperation and control of the different components of the lock device 140. Theprocessing unit 510 may be implemented in any known controller technology, includingbut not limited to a processor (PLC, CPU, DSP), FPGA, ASIC or any other suitabledigital and/or analogue circuitry capable of performing the intended ﬁ1nctionality. Theprocessing unit 510 constitutes an implementation of the lock device°s controller means,as referred to in the Summary section of this document.

The lock device 140 of this embodiment is a stand-alone, autonomouslyoperating device which requires no wire-based installations, neither for communicationnor for power supply. Instead, the lock device 140 is powered solely by a local powerunit 520 which comprises one or more long-life batteries. It interacts with key devices,as already mentioned, by wireless activities. The lock device 140 therefore has aninterface 540 for short-range wireless data communication. In the disclosed embodimentof Figure 5, the interface 540 comprises a Bluetooth® transceiver, by means which thelock device 140 can communicate with, for instance, the proxy device 300 over asecond connection or Bluetooth® link l4B (if there is no incompatibility issue betweenthe key device 100 and the lock device 140, the lock device 140 could communicatedirectly with the key device 100 over a Bluetooth® link 14). The Bluetooth® transceiveris assigned a unique Bluetooth® address LD_ID. Altematively or additionally, theinterface 540 may for instance comprise transceiver components for IrDA, WLAN orNFC.

The lock device 140 comprises a lock actuator 512 being operatively connectedto a lock, such as the lock 150 on the door 152 in Figure 1. Aﬁer successful verificationof an approaching proxy device 300/key device 100 in the way described in other partsof this document (as well as in the aforementioned WO 2006/098690), the processingunit 510 will control the lock actuator 512 to open the lock. This may involve actuatingan electric motor to displace a lock plunger or other mechanism to an unlocked position,or releasing a latch mechanism so that it will no longer prevent manual or automatic opening of the door 152. 16 The lock device 140 of the disclosed embodiment further includes a real-timeclock 530 capable of providing the processing unit 510 with an accurate value of thecurrent time. However, embodiments are also possible where no real-time clock isprovided.

Finally, the lock device 140 has a memory 550 which is operatively connectedto the processing unit 510. The memory 550 may be implemented by any knownmemory technology, including but not limited to E(E)PROM, S(D)RAM and flashmemory, and it may also include secondary storage such as a magnetic or optical disc.Physically, the memory 550 may consist of one unit or a plurality of units whichtogether constitute the memory 550 on a logical level. The memory 550 serves to storevarious program instructions and work data for ﬁlnctions to be performed by theprocessing unit 510 in order to carry out the tasks of the lock device 140.

Moreover, the memory 550 serves to store a local lock device database (LD-DB) 570, which includes access control data upon which the access control decisionsare based. The lock device database 570 may also store log and/or status data which arereferred to further below. In one embodiment the lock device 140 has a serial numberwhich was assigned during manufacturing, assembly, delivery or installation. This serialnumber is also stored in the memory 550.

For further implementation details and possible additional components of thelock device 140 and the key device 100, reference is made to the aforementioned WO2006/ 098690, which is fully incorporated herein by reference.

In one embodiment where the lock device 140 is arranged with a Bluetooth®interface 540 and the key device 100 is arranged with an interface 440 that is in someway incompatible for establishing a connection with the lock device, the inventors haverealized that by introducing the aforementioned proxy device 300 (see Figure 3), acommunication channel can still be established between the key device 100 and the lockdevice 140, using the proxy device 300 as a proxy for the key device 100 to act as atunnel between the two.

The proxy device 300, also referred to as PD hereafter, comprises at least oneshort-range communication interface 320. In one embodiment the short-range communication interface 320 comprises a first short-range communication interface 17 330, such as Bluetooth®, IrDA or NFC, or connector-based like USB, for establishingthe first communication link or connection 14A with the key device 100. Thecommunication interface 320 may also comprise a second interface 340 having aBluetooth® transceiver for establishing the second communication link or connectionl4B with the lock device 140. In one embodiment, the proxy device 300 is arranged tooperate a single Bluetooth® transceiver (not shown) to implement the first as well as thesecond communication interfaces 330, 340 for communication with both the lock device140 and the key device 100 using a technique commonly known as scattemet.

The proxy device 300 also comprises a processing unit 310 which is overallresponsible for the operation and control of the different components of the proxydevice 300. The processing unit 310 may be implemented in any known controllertechnology, including but not limited to a processor (PLC, CPU, DSP), FPGA, ASIC orany other suitable digital and/or analogue circuitry capable of performing the intendedfunctionality. The processing unit 310 constitutes an implementation of the proxydevice°s controller means, as referred to in the Summary section of this document.

In one embodiment the proxy device 300 also comprises a memory 350 whichis operatively connected to the processing unit 310. The memory 350 may beimplemented by any known memory technology, including but not limited toE(E)PROM, S(D)RAM and ﬂash memory, and it may also include secondary storagesuch as a magnetic or optical disc. Physically, the memory 350 may consist of one unitor a plurality of units which together constitute the memory 350 on a logical level. Thememory may be used to temporarily store data to be communicated between the lockdevice 140 and the key device 100. The memory 350 may also be used to storeidentification data for the key device 100, such as the key device identifier, KD_ID.

The proxy device 300 has a proxy device identifier PD_ID which can be used,in embodiments of the invention, by the lock device 140 when deterrnining whether ornot access shall be granted. For embodiments where the second interface 340 isBluetooth®-based, the proxy device identifier PD_ID may advantageously be the uniqueBluetooth® address of the Bluetooth® transceiver. Altematively, the proxy device identifier PD_ID may be stored in a readable form in the memory 350. 18 The proxy device should be designed to be small in size so that it can easilyaccompany a key device, being a mobile terminal. Furthermore, in one embodiment theproxy device does not comprise a long range communication interface such as a cellularcommunication interface.

In one embodiment the proxy device 300 does not have a user interface to keepits size very small. In an altemative embodiment the proxy device 300 comprises a verysimple user interface 370. In Figure 3, the user interface 370 is indicated to be optionalby being drawn with dashed lines. In one such embodiment, the user interface is a singlebutton.

In one embodiment, which will be described in more detail with reference toFigure 9, the user interface 370 comprises at least one lock/unlock button. In oneembodiment the lock/unlock button is conf1gured to cause a lock device (140) to togglebetween a locked and an unlock state.

In one embodiment, the user interface 370 comprises one lock and one unlockbutton (shown explicitly in Figure 9 and referenced 370a and 370b, respectively). In oneembodiment the lock button 370b is configured to cause a lock device (l40) to assume alocked state. In one embodiment the unlock button 370a is conf1gured to cause a lockdevice (l40) to assume an unlocked state.

In one embodiment, the user interface 370 comprises at least one light emittingdiode (LED) (shown explicitly in Figure 9 and referenced 376). The at least one LED376 may be used to indicate a status of the proxy device 300.

One embodiment of the proxy device 300 may preferably be shaped in such amanner that it can be attached to the key device l00 so that the two can be carriedconveniently as one combined device. This is particularly convenient if the firstcommunication interface 330 is extremely short-ranged (e.g. IrDA, NFC, USB).

The operation of the proxy device 300 in relation to the key device l00 and thelock device l40 will now be described with reference to Figure 2. In this example thekey device l00 is arranged with a Bluetooth® interface 440 that requires paring forestablishing a communication link with another device, whereas the lock device l40 is arranged with a Bluetooth® communication interface 540 that does not require pairing. 19 In an initial step 210 the user 2 acquires a proxy device 300 that is or will bepaired with or connected to the user°s key device 100. Typically, the operator of theaccess control system will associate the particular key device 100 and proxy device 300with the user 2 by storing some sort of association or link between the three in thesystem database 124. For instance, a database record representing the user 2 maycontain one or more data fields for storing the key device identifier KD_ID of the keydevice 100, the proxy device identifier PD_ID of the proxy device 300, or acombination thereof Also, the system database 124 will typically contain access controldata which defines the access rights given to the user 2/key device 100/proxy device300 as regards which lock devices 140 in the access control system that are allowed tobe accessed, and when and how they may be accessed. These access rights will also bestored in the local database LD_DB of the respective lock device 140.

As the user 2 most likely acquires the proxy device 300 at an early moment intime when use of the key device 100 for access purposes is not imminent, the pairingtime of up to 30 seconds is of no concem. During the initial pairing or connection, thekey device 100 authenticates the proxy device 300 and the key device 100 and the proxydevice 300 exchange data with each other in step 220. In one embodiment the keydevice 100 inforrns the proxy device 300 of its Bluetooth® address KD_ID, which theproxy device 300 stores in its memory 350 (as shown in Figure 3). In one embodimentthis is part of the authentication process. The proxy device 300 is now paired orconnected with the key device 100, and together they form a key and proxy device pair,hereafter referred to as a KPD which will be referenced as 100+300 in the drawings.

In one embodiment the proxy device 300 is configured to initiate a pairing withthe key device 100 when it receives an input, for example a long-press on a button 370,from a user indicating that the pairing should be initiated. The user is thus able toinitiate the establishment of the first communication link or first connection 14A.

As the user 2 later brings the KPD 100+300 in the vicinity of the lock device140, there are two possibilities. The first is that the lock device 140 senses that the keyand proxy device pair 100+300 is in the vicinity, identifies the KPD 100+300 (step230), and compares the identifier of the pair with its intemal database LD_DB in a step240 to determine whether the key and proxy device pair 100+300 should be granted access or not. The second possibility is that the key and proxy device pair 100+300senses that a lock device 140 is in the vicinity and initiates the lock device 140 bycommunicating their identifier in step 230 to the lock device 140, thereby allowing it todeterrnine whether the key and proxy device pair 100+3 00 is to be granted access or notin step 240. This is similar to how a key device 100 is granted access to a lock 150 by alock device 140 as has been disclosed in WO 2006/098690. In this latter possibility, thesensing of the lock device 140 may be done by either the key device 100, which theninstructs the proxy device 300 to establish a connection with the lock device 140, or bythe proxy device 300 that connects to the lock device 140 as it is found and inforrns thekey device 100 that a connection has been made. Notice that the connection between theproxy device 300 and the lock device 140 is established without pairing.

If the lock device 140 deterrnines that the key and proxy device pair 100+300is to be granted access, it unlocks the lock 152 in step 250.

As will be disclosed with reference to figure 9 below, the pair of the key device100 and the proxy device 300 may be a virtual pairing, wherein the key device 100authenticates the proxy device 300 to operate as if paired with the key device 100during an authentication time period even after the first connection has been terrninated.The key device 100 and proxy device 300 pair referenced KPD above is thus in such anembodiment represented by the proxy device 300 solely after having been authenticatedby the key device 100. Similarly, the same authentication of the proxy device 300 by thekey device 100 is possible to be implemented also for the other embodiments disclosedherein, even if not expressly described in conjunction with a specific embodiment.

Utilizing a user name and a password for establishing the first connection, ahistory log may be generated for the key device 100, thereby tracking which user had access to which proxy device 300 at what time.

The operation of the proxv device 300 Figure 2 shows the basic functionality of the proxy device 300, and the morespecific operation of the proxy device 300 will now be disclosed.There are at least three altematives of how to identify the proxy and key device pair 100+300 to the lock device 140. 21 In a first alternative the identifier PD_ID for the proxy device 300 isrepresented in the access control data in the LD-DB 570. When the proxy and keydevice pair 100+300 seeks access, the proxy device 300 communicates its PD_ID,which can be its Bluetooth® address as explained above, to the lock device 140. Thelock device 140 then compares the received PD_ID with a list of devices being allowedaccess according to the access control data stored in the LD_DB 570. In this alternativethe proxy device 300 thus substitutes the key device identifier KD_ID with its identifierPD_ID. This alternative has the benefit that no changes are required to be made to thelock device 140 to allow proxy devices into an already set up system, as disclosed inWO 2006/098690, apart from adding the identifiers PD_ID of the respective the proxydevices in the access control system to the lock device°s 140 database LD_DB 570. Thisaltemative may require some changes to be made to the communication protocolsbetween the devices to signify exactly for which device a request is made. This will beapparent from the discussion relating to Figure 6A below.

In a second altemative the proxy device 300 uses the key device identifierKD_ID as its own identifier, that is the proxy device 300 forwards the identifier for thekey device 100 KD_ID instead of its proxy device identifier to the lock device 140, inother words PD_ID = KD_ID. This has the benefit that no changes need to be made tothe list of allowed devices in the LD_DB in the lock device 140, if the identifier KD_IDfor the key device 100 is already distributed to and stored in the various lock devices140. This altemative is especially useful when the proxy device 300 is connected to thekey device 100 using a different interface than the one which the proxy device 300 isconnected to the lock device 140 with, since the messages can then be forwardeddirectly without having taking mechanisms such as scheduling into account.

In a third altemative the proxy device 300 is arranged to communicate acombination of the key device identifier KD_ID and the proxy device identifier PD_IDto the lock device in the form of KD+PD_ID. The received KD+PD_ID is thencompared by the lock device 140 to the identifiers stored in the database LD_DB. Inone such embodiment the identifier KD+PD_ID for the key and proxy device pair100+300 is the concatenation of PD_ID with KD_ID, or of KD_ID with PD_ID. By combining identifiers an increased security is introduced to the system, as access will 22 only be granted to a key device 100 if the correct proxy device 300 is used at the sametime. However, this alternative requires most changes to be made to the databases andhow they are searched, but it does not require the protocol for communicating betweendevices to be changed.

Which altemative that is used may depend on the interfaces used, and acombination of altematives can also be used. For example, if a dedicated connectionsuch as a USB port is used between the key device 100 and the proxy device 300, and aBluetooth® connection is used between the proxy device 300 and the lock device 140,the proxy device 300 can be arranged to substitute the key device identifier KD_ID withthe proxy identifier PD_ID when sending information to the lock device 140, but toforward the lock device identifier LD_ID instead of the proxy device identifier PD_IDwhen communicating with the key device 100.

Identifiers for the various devices may be identical to, generated from orrelated to for example their Bluetooth® addresses. Particularly for key devices in theform of mobile phones not having a Bluetooth® interface, an Intemational MobileEquipment Identifier (IMEI) or an Intemational Mobile Subscriber Identifier (IMSI) canbe used as KD_ID.

With reference to Figs 6A-C it will now be disclosed how the proxy device 300operates when additional data is to be communicated between the key device 100 andthe lock device 140. Three such cases will be investigated in detail. The first case (seeFigs 6A, 7A, 8A) is when additional information is required for allowing access, such asfor PIN verification for stage 2 access as disclosed in WO 2006/098690. The secondcase is when updated data is to be communicated to the lock device 140 from the keydevice 100, such as when additional identifiers are to be added to a lock device”s 140database LD_DB (see Figure 6B, 7B, SB). The third case is when a request is issued bythe lock device 100 to be processed by the key device 100 (see Figs 6C, 7C, SC).

Case 1 Additional information for access verification As is disclosed in WO 2006/098690, a lock device 140 can keep a record of key devices that require additional verification to be allowed access, a so-called stage 2access. One example given is when the lock device 140 also requires a PIN code to be given by the user 2 of the key device 100 to allow access. 23 In an initial step 610 in Figure 6A, the operations required to cause the lockdevice 140 to identify the proxy device 300 and/or the key device 100 are comparable tostep 210 and step 220 in Figure 2. In step 620, the lock device 140 requests data fromthe proxy device 300 by prompting the proxy device 300 to supply a PIN code for thekey device 100. As has been discussed above, the communication between the proxydevice and the lock device can be achieved in a number of ways with regards to whichidentifier that should be used. In the examples below, it will be assumed that the firstaltemative of substituting the key device identifier with the proxy device identifier isused. In Figs 6A-C the messages sent will be indicated as a data field where the headeris the identifier for the recipient and the tail is the identifier for the sender. The messageformat may not have the same structure in a real life implementation, but this modelgives an easy to understand illustration of the messages sent and the data they carry.Please note that the header is in the direction of the arrow and the tail is in the directionof the end of the arrow. This illustrates the way in which the message is sent in a moreintuitive manner.

In step 620 a message having the header PD_ID, the body or payload PINREQand the tail LD_ID is issued from the lock device 140. The proxy device 300 interceptsthe communication in step 630 and adjusts the header and the tail according to one ofthe three altematives discussed above. In this example the proxy device identifierPD_ID is substituted for the key device identifier KD_ID in the header, the lock deviceidentifier LD_ID is substituted for the proxy device identifier PD_ID in the tail, and therequest message is communicated to the key device 100. In step 640 the key device 100receives the request and processes it, which in this case is a request for the user 2 toenter a PIN code. As the key device 100 receives the PIN code from the user 2, the keydevice 100 sends a response message to the proxy device 300 carrying the PIN code(1234). This message is received by the proxy device 300 which adjusts the messageand forwards the message to the lock device 140 in step 650.

It should be noted that using this notification the message body may need somealterations in step 630 (and possibly 650) to allow the receiving key device 100 to knowfor which lock device 140 the PIN request is made. As seen in Figure 6A the message 24 body is changed from “PIN REQ” to “PINREQ LD_ID” to indicate that the PIN coderequest emanates from the lock device 140 having the identifier LD_ID.

The corresponding messages for the forwarding addressing alternative areshown in Figure 6B. It should be noted that no adjustments of the message is needed.

The corresponding messages for the combining addressing altemative areshown in Figure 6C.

Case 2 Adding an identifier to a lock database Figure 7A illustrates the case when the key device 100 carries informationregarding a new identifier to be added to the access control data in the database LD_DBof the lock device 140.

As the key devices 100 are capable of receiving and storing data from thecentral server 122 or from another administrator 106, a key device 100 can be used todistribute information to lock devices 140. This enables lock devices 140 to be updatedwithout a specific administrator having to physically visit the lock device 140.

In an initial step 710, the operations required to cause the lock device 140 toidentify the proxy device 300 and/or the key device 100 are comparable to step 210 andstep 220 in Figure 2. In step 720 the proxy device 300 sends a message to the keydevice 100 that the connection to a specific lock device 140 identified by LD_ID hasbeen successful (message body “CONSUC LD_ID”). The key device 100 then searchesits memory 450 in step 730 to see if there is any updated access control data 456 thatshould be communicated to the lock device 140. If such updated access control data 456exists in memory 450, a message with the updated data is generated and sent to theproxy device in step 740. The proxy device receives the update message in step 750,adjusts it and forwards it to the lock device 140. In step 760 the lock device 140receives and stores the updated access control data in its database LD_DB.

The corresponding messages for the forwarding addressing altemative areshown in Figure 7B. It should be noted that no adjustments of the message is needed.

The corresponding messages for the combining addressing altemative areshown in Figure 7C.

A case similar in principle to the one described with reference to Figs 7A-C is when a lock device 140 has recorded log and/or status data in its memory 550. In this case (not shown) the lock device 140 checks if any log and/or status data has beenstored in the memory 550, and, if so, Waits for a two-way connection to be establishedby the proxy device, or it initiates the establishment of such a two-way connection.When the connection is active, the lock device 140 sends a message with the log and/orstatus data (PD_ID | LOG DATA | LD_ID) to the proxy device 300. The proxy device300 receives the message, adjusts it if necessary and forwards it to the key device 100.The key device 100 then forwards the log and/or status data to the central server 122 orto another administrator 106. The log and/or status data can contain information onbattery status, failed attempts to gain access, successful attempts to gain access,successful stage 2 attempts to gain access, any physical abuse of the lock device 140, ifa forbidden or black listed device has attempted to gain access, to mention a fewexamples. A similar functionality is described in WO 2006/098690.

Case 3 Request issued bv lock device Figure 8A illustrates the case when the lock device 140 issues a request that isto be processed by the central server 122 or key device 100. This situation is similar tocase 1, which is a special instance of this case.

In an initial step 810 the operations required to cause the lock device 140 toidentify the proxy device 300 and/or the key device 100 are comparable to step 210 andstep 220 in Figure 2. In step 820 the lock device 140 issues a request to the proxy device300. The proxy device 300 intercepts the communication in step 830 and adjusts theheader according to one of the three altematives discussed above. In this example theproxy identifier PD_ID is substituted for the key identifier KD_ID and the requestmessage is communicated to the key device 100. In step 840 the key device 100receives the request. To process the request the key device 100 may have to initiatecommunication with the central server 122 over the mobile telecommunicationsnetwork 110 and send a request to the server 122. The key device 100 receives aresponse from the server and forwards the response to the proxy device 300. Thismessage is received by the proxy device 300 which forwards the message to the lockdevice 140 in step 850.

It should be noted that using this notification the message body may need some alterations in step 840 to allow the receiving key device 100 to know for which lock 26 device 140 the request is made. As can be seen in Figure 8A the body “REQ” isadjusted to “REQ LD_ID” to indicate which lock device 140 the request originatesfrom.

The corresponding messages for the forwarding addressing alternative areshown in Figure SB.

The corresponding messages for the combining addressing altemative areshown in Figure SC.

As has been noted above, which altemative addressing mode to use maydepend on the actual communication interfaces involved, and a combination ofaddressing altematives can also be used.

In one particular embodiment of the invention all adjustments to the recipients of a message is done in the proxy device 300.

Delayed access An altemative or additional manner of operating the proxy device 300 byenabling it to operate remotely from the key device 100 after an authentication will nowbe described with reference to figure 9. Figure 9 is a schematic block diagram of anembodiment of the access control system of Figure 1, comprising a proxy device whichmay interact with both a key device and a lock device in combination with a time graphof the communication between the proxy device and the key device and the lock device.

In one embodiment the proxy device 300 is arranged with at least onelock/unlock button. In the example embodiment shown in Figure 9 the proxy device isarranged with one lock button 370b and an unlock button 370a; however, a similarfunctionality may be achieved by using an unlock/ lock button as described in the above.The proxy device 300 is furtherrnore arranged with an LED 376. It should be noted thatthe proxy device 300 may be arranged with a plurality of LEDs 376, but for illustrationclarity purposes only one LED 376 is shown in Figure 9.

The proxy device is arranged to establish a first connection 14A with a keydevice 900 (as has been described above, this may be initiated by the user making, forexample, a long-press on the unlock/lock button or the unlock button 370a). As the first connection 14A is established the proxy device 300 is configured to authenticate itself 27 to the key device 900 and, in reponse thereto, be authenticated and receive an indicationof an authentication time period (ATP) and to store the indication of the authenticationtime period (ATP). The authentication time period indicates a time period Within Whichthe proxy device 300 is authenticated to operate or act on behalf of the key device 900.The ATP Will be discussed in further detail below. The indication of the ATP may beimplemented as a number, possibly time or date forrnatted, representing the ATP. Theproxy device 300 may further be conf1gured to receive other data (such as has beendisclosed in the above With reference to Figures 6, 7 and 8) from the key device 900.

In one embodiment the proxy device 300 is arranged With a Wired interface(such as a USB connection) for establishing the first connection 14A With the keydevice 900. In such an embodiment the Wired interface may also be used for chargingthe proxy device 300.

In one embodiment the ATP is transferred from the key device 900 to theproxy device 300 along With - or as part of- the key device identifier (KD_ID). In oneembodiment the ATP effectively authenticates the proxy device 300 for use While theATP is valid.

In one embodiment the processing unit (310) is conf1gured to enter an activatestate and start a timer that counts down from the ATP (altematively, the timer counts upto the ATP), and as the timer is done counting the processing unit (310) is conf1gured toenter an inactivate state. The current state may be indicated to a user via the LED 376.For example, While the proxy device 300 is in an active state the LED 376 is lit andWhile the proxy device 300 is in an inactive state the LED 376 is unlit. Altematively,the proxy device comprises one LED (for example green) to indicate an active state andone LED (red) to indicate an inactive state. Altematively, the LED may be arranged tobe ﬂashing in one state.

Additionally, the LED 376 may also be arranged to indicate that the ATP isabout to expire, possibly by ﬂashing, thus indicating to a user that any lock-relatedactions should be taken shortly.

To operate a lock 150 on, for example, a door 152 (through the lock device140), the user brings the proxy device 300 in close proximity to a lock device 140. The distance required to enable communication between a proxy device 300 and a lock 28 device 140 depends on the communication technology used, as Would be apparent to askilled person. The user operates the proxy device 300, for example by pressing theunlock button 370a, to cause the lock device 140 to unlock the lock 150 of the door 152.The proxy device 300 deterrnines Whether it is in an active state, When the user operatesit, and if it is in an active state the proxy device 300 is conf1gured to establish a secondconnection l4B With the lock device 140. As the second connection l4B is establishedWith the lock device 140, the lock device 140 is caused to operate the lock 150, andpossibly to exchange data.

This Will now be described in more detail.

As an alternative (or additionally for increased security) to the proxy devicedeterrnining if it is authenticated, the lock device 140 receives the ATP from the proxydevice 300 as the second connection l4B is established and deterrnines Whether theATP is still active or not before reacting to any lock/unlock command issued by theproxy device 300.

As the lock device 140 receives an unlock command from the proxy device300, it deterrnines the access rights, and if the proxy device 300 is authorized to accessthe lock device 140 (and is active) the lock device unlocks the lock 150 of the door 152.

Similarly, as the lock device 140 receives a lock command from the proxydevice 300, it deterrnines the access rights of the proxy device 300, and if the proxydevice 300 is authorized to access the lock device 140 (and is active) the lock devicelocks the lock 150 ofthe door 152.

In one embodiment the lock device 140 may be conf1gured to automaticallycause the lock 150 to lock in the absence of a further command Within a certain timeperiod after a lock or unlock command.

As the second connection l4B is established, the proxy device 300 and the lockdevice 140 may be arranged to exchange data (such as log and/or status data, updates toaccess rights or other data) as has been discussed in the above). This may be effectedboth When a lock command is communicated and/or When an unlock command is being communicated. 29 The deterrnination of access rights has been disclosed in various embodimentsand variants in the above and Will not be discussed in further detail in theseembodiments referring to Figure 9.

The use of an ATP provides the user With a time period Within Which he mayoperate the proxy device 300 to actuate lock device(s) 140. This is beneficial in that theuser does not need to carry the key device 900 on his person or keep it nearby at alltimes When operating the proxy device 300. For example, the key device 900 may beleft in a car or at an office. As such, this enables for the key device 900 to be remotefrom the proxy device 300 during operation of the proxy device 300. This is furtherbeneficial in that one key device 900 may be shared by more than one user, Whichreduces the cost of an overall lock controlling system. The use of an authenitcation timeperiod also provides increased security in that a user may only access a lock duringcertain time periods, thereby alloWing an operator to control the access even When thekey device 900 is not actively paired With the proxy device 300.

In one example the key device 900 is housed in a common room such as anoffice or despatch central. The key device then operates as a key management device(KMD) Which is used by users to activate (and/or deactivate) their respective proxydevices 300 in relation to a Work task or other event. In such an embodiment the key(management) device 900 may be housed in close proximity to the system server 122.In one embodiment the key (management) device 900 may incorporate the systemserver 122, thus effectively forming one unit (as is indicated by the dashed rectangle inFigure 9). In one such embodiment the key (management) device 900 is a softwaremodule being operated and executed by the system server 122, Wherein the key device900 is a virtual key device. In such an embodiment the key device identifier (KD_ID)may be specific to a user thereby providing a (unique) user-specific identifier even if thekey device module (or server acting as a key device) is used by more than one user.

The key device 900 (or the system server 122) is, in one embodiment,configured to determine the indication, i.e. a time value for the ATP. The ATP may, forinstance, be any of, or in any range of, 2, 4, 6, 8, 10, 12 and 24 hours. The length of theATP may be based on a distance between the key device 900 and the lock device 140.The length of the ATP may altematively or additionally be based on a schedule of a user of the proxy device 300. In one embodient the schedule denotes a working day and/or aspecific task that is to be performed at a specific time or within a specific time interval.

In one embodiment the ATP denotes a relative time (8 hours for example). Inone embodiment the ATP denotes an absolute time (before 20:00 hours for example).

In one embodiment the ATP indicates a number of accesses that the user isauthenticated to make. For example, the ATP may indicate that a user is allowed toaccess a specific door 2 times (possibly within a time period). As the user has accessedthe specific door the allowed number of times, the ATP is cleared and the user is thusno longer authenticated to enter that door without further authentication.

According to one aspect of the teachings herein, there is provided a proxydevice for use in an access control system which comprises a lock device and a keydevice, said lock device being operatively connected to a lock and said key device beingassociated with a user. The proxy device comprises controller means; a proxy deviceidentifier; and at least one short-range communication interface. The controller means isconfigured for causing said at least one short-range communication interface toestablish a first connection with said key device and receive an authentication, possiblyincluding a key device identifier for said key device. The controller means is furtherconfigured for causing said at least one short-range communication interface toestablish a second connection with said lock device and provide to said lock device anidentifier which allows said lock device to determine whether access should be grantedto said lock or not, wherein said second connection is established on behalf of said keydevice and wherein said proxy device thereby acts as a device identifier tunnel betweensaid key device and said lock device.

A method for controlling a lock in an access control system is also provided,the access control system comprising a key device, a proxy device and a lock device.The method comprises: establishing a first connection between said proxy device andsaid key device; in said proxy device, receiving an identifier for said key device;establishing a second connection between said proxy device and said lock device; andfrom said proxy device, providing to said lock device an identifier which allows saidlock device to determine whether access should be granted to said lock or not, wherein said second connection is established on behalf of said key device and wherein said 31 proxy device acts as a device identifier tunnel between said key device and said lockdevice.

There is also provided an access control system comprising a proxy deviceaccording to the first aspect of the present invention, and a lock device, where the lockdevice comprises a short-range wireless communication interface, controller means,memory means associated with the controller for storing a local database containingaccess control data, and a lock actuator. The controller means is configured for:receiving an identifier from said proxy device via said short-range wirelesscommunication interface, matching said received identifier against the access controldata in said database, and, if a match is found, causing said lock actuator to unlock alock operatively connected to the lock actuator.

One embodiment of such an access control system further includes a keydevice which comprises controller means, memory means, and short-rangecommunication interface means for communicating with said proxy device. In oneembodiment, the access control system further comprises a central server which allows for data to be communicated between a lock device and a central server.

Differentiating between multiple doors Retuming to Figure l, a second door l52a is also shown having a lock devicel40a. If it should happen that both lock devices l40, l40a are active and detectable atthe same time, they may both be detected by the proxy device 300. To enable a user toselect the correct door to be opened even when using the limited user interface 370 ofthe proxy device 300, the locking devices l40, l40a are arranged to receive a wake upinput. In one embodiment the wake up input is received as a tactile input, for example aknock or a vibration. In one embodiment the wake up input is received throughactuation of a button (not shown) on or connected to the locking device l40, such as adoor bell operatively connected to the lock device l40.

In one embodiment the lock device l40 is configured to activate the shortrange communication interface upon receiving the wake up input. In one altemative oradditional embodiment the lock device l40 is configured to accept a connection through the second connection l4B upon receiving the wake up input. 32 A user is thereby able to select a door 152 (and the corresponding lock device140) by for example (manually) knocking on the door 152 or ringing a door bell. Thishas the added benefit that any person on the other side of the door 152 Will be madeaware that a user is about to open the door 152, thereby increasing both the securityaspects as Well as the integrity aspects of the access control system disclosed herein.

In one embodiment the lock device 140 is configured to detect a vibrationpattem. The vibration pattem may be generated by a vibrator housed in the key device100 and/or in the proxy device 300. By associating different lock devices 140, 140aWith different vibration pattems a further security aspect is provided as Well as a moreparticular selection scheme. This provides for additional security in that each lockdevice 140, 140a may be expressly and individually identified for example to beactivated.

The user is thus able to select a door 152 by simply setting the key device 140or the proxy device 300 to vibrate and placing it againt the door 152, the lock 150 or thelock device 140.

In one embodiment the lock device 140 may be configured to detect aknocking sequence or pattem Where a number of knocks is received in a specificrhythm. In one such embodiment the proxy device 300 may be configured to ﬂash theLED to indicate the knocking pattem. The user may thus easily remember and/or learnthe correct knocking pattem to be used.

In one embodiment, as has been disclosed above, the lock device 140 isconf1gured to activate its close range communication interface in response to receivingthe Wake up input. This enables a lock device 140 to save power as it does not need toremain active for long periods of time and it is easy to activate the lock device 140 With,for example, a single knock or knock sequence.

By enabling a user to Wake up or initiate a lock device 140 by providing aknocking or vibration pattem, either manually or through the use of a vibrator, on thedoor 152 or the lock device 140, the user is able to select Which door 152 among aplurality of doors should be opened. This solves the problem of identifying Which door152 to open When a plurality of doors 152 are active and in range of the short range communication interface. 33 The knocking or vibration pattern may be arranged to differentiate from normaleveryday sounds or tactile events such as a person walking past a door, a door beingshut or, for additional security, a normal knock on a door or a tuming of a handle.

As has been discussed above, the proxy device 300 is configured to detect anylock devices 140, l40a that are in range. As more than one door 152, 152a may be inrange at the same time it may be difficult to make a selection using the proxy device°ssimple user interface 370 (especially if the key device 100/900 is not in the proximity inwhich case the user could simply select a door 152, 152a from a list on a display of thekey device 100/900). The manner described above regarding detecting a wake up inputin the lock device 140 overcomes this difficulty.

Altematively and/or additionally, the lock device 140 may be automaticallyactivated (awaken) when the user manually tums a door knob or handle on the (inside ofthe) door 152.

To further differentiate between different doors 152, 152a, for example a mainentrance 152a and an intemal door 152, the proxy device 300 may be configured toperform a prioritized selection of a plurality of detected doors 152, 152a. The prioritizedselection is effected by the processing unit selecting the door or rather lock device 140,l40a corresponding to the highest prioritized door 152, 152a and establishing aconnection with that lock device 140, 140a.

In one example embodiment a first door 152 is a door 152 having a lock device140 without an extemal power source. The lock device 140 will then be configured tonot be active all the time to save power. A second door 152a is a main entrance having alock device 140a being connected to an exemal power source (not shown). In thisexample embodiment the first door 152 has a higher priority than the second door 152a.This enables a user to arrive at a house or building and simply operate the proxy device300 to open the main entrance door 152a. As no other lock devices 140 have beenactivated (awaken) the lock device l40a of the main entrance door 152a is the only onethat is detected and thus there is only one choice. As the user enters the building hearrives at an apartment door 152. He activates the apartment door 152, possibly byknocking on it, and, as a consequence, the proxy device 300 will now detect two doors, the apartment door 152 and the main entrance 152a (assuming that the proxy device 300 34 is still in range of the lock device 140a of the main entrance 152a). The proxy device300 will now select the higher prioritized apartment door 152 and the user is able toenter the apartment. The proxy device 300 is thus enabled to be operated with a pluralityof doors and select the correct door even with a limited user interface.

In one embodiment the lock device 140 is configured to assume an active stateor an inactive state. These states may both be assumed while the short range interface isactivated. In such an embodiment the lock device 140 is configured to enter the activestate when it receives the wake up input. The lock device 140 may be configured toremain in an active state until the second connection is terrninated or for a time period.The time period may be for example 5 to 30 seconds. It should be noted that other timeperiods are also possible and within the scope of the teachings of this application. Thelock device 140 is further configured to only establish the second connection if it is inan active state.

This enables a user to select a door 152 from a plurality of doors, all havingdetectable lock devices, by for example knocking on the door to be selected.

The knocking may be achieved manually by hand or by using a tool, such as avibrator.

In one embodiment the lock devices 140, 140a may be grouped in for exampletwo groups. Each group may have a priority assigned to it to enable a prioritizedopening of the doors 152, 152a. In one embodiment the proxy device 300 is configuredto receive a long press on the unlock button 370a to open the lock 150 corresponding toa lock device 140a in a first group and to receive a short press on the unlock button370a to open the lock corresponding to a lock device 140 in a second group. A similararrangement may be applied to the locking procedure. In one such embodiment the mainentrance 152a may be in the first group and the door 152 may be in the second group,thereby enabling an easy identification of which door 152, 152a to open using the proxydevice 300.

In one embodiment the doors 152, 152a may be grouped altematingly in a firstand a second group. This provides for an easy manner of ensuring that the correct doorsis opened especially if the distance between two doors 152a of a first group having a door 152 of the second group in between is on the same order as the range of the short range communicaiton interface, thereby leaving only one door from each group in rangefor the short range communicaiton interface.

The operation of the access control system according to some of theembodiments disclosed herein Will now be further described through five exemplary usecases together describing the operation of a proxy device 300 over a Workday.

Use case 1: Checking out a proxy device 1) A user perfornis a long-press on the unlock button 370a as the proxy device300 is brought in close proximity to a key device 900. 2) The proxy device indicates its status through the LED 376. 3) The proxy device 300 establishes a connection With the key device 900. 4) The proxy device 300 and the key device 900 exchanges data, such asauthentication data, for example an ATP of 8 hours. 5) The LED 376 ﬂashes three times to indicate that the authentication iscompleted. 6) The key device 900 displays logging information regarding thecommunication and authentication of the proxy device 300.

Use case 2: Unlocking a door 7) The user selects a lock 150/lock device 140 by knocking (a number of times,for example three times, in a specified rhythm), Whereupon the lock device 140 assumesan active state. 8) The user presses (short press) the unlock button 370a. 9) The LED 376 ﬂashes to indicate that the unlock command has been sent. 10) The lock device 140 actuates the lock 150 to disengage. 11) The lock device 140 and the proxy device 300 exchange data, such as logand/or status data and/or updates as disclosed in the above.

Use case 3: Locking a door 12) The user selects a lock 150/lock device 140 by knocking (a number oftimes, for example three times, in a specified rhythm), Whereupon the lock device 140assumes an active state. 13) The user presses (short press) the lock button 370b. 14) The LED 376 ﬂashes to indicate that the lock command has been sent 36 15) The lock device 140 causes the lock 150 to engage.16) The lock device 140 and the proxy device 300 exchange data, such as logand/or status data and/or updates as disclosed in the above.

Use case 4: Unlocking a door With a power supply, such as a main entrance 17) The user presses (long press) the unlock button 370a. 18) The LED 376 ﬂashes to indicate that the unlock command has been sent 19) The proxy device 300 deterrnines that no other lock devices l40a aredetected. 20) The lock device 140 causes the lock 150 to disengage. 21) The lock device 140 and the proxy device exchange data, such as log/andor status data and/or updates as disclosed in the above.

Use case 5: Checking in a proxv device 22) A user performs a long-press on the lock button 370b When the proxydevice 300 is in close proximity to the key device 900. 23) The proxy device indicates its status through the LED 376. 24) The proxy device 300 establishes a connection With the key device 900. 25) The proxy device and the key device exchange data, such as any log dataand/or status data received in the aforementioned steps 11, 16 or 21. 26) The LED 376 is turned off to indicate that it is no longer authenticated. 27) The key device displays logging inforrnation regarding the communication and authentication of the proxy device 300.

Alarrn button In one embodiment, Where the proxy device has a simple user interface in theform of at least one button 370, Wherein at least one button is associated With an alarmfunction,, the proxy device 300 may be arranged to take advantage of the long rangecommunication capabilities of the key device 100 (i.e. the network interface 430). Theprocessing unit 310 is arranged to detect that the button 370 is depressed and inresponse thereto cause that an emergency service is contacted, for example by sending arequest to the key device 100 to contact the emergency service. In one embodiment the processing unit 310 is arranged to detect that the button 370 is depressed for a long 37 time, a so-called long press, and in response thereto cause that an emergency service iscontacted. In such an embodiment, the proxy device is not required to have a buttonspecifically associated with an alarrn function, but the alarrn ﬁanction can be associatedwith any button(s) 370, such as the lock/unlock button. The request from the proxydevice 300 to the key device 100 can be sent via the Bluetooth® tranceiver 340. Theemergency service or emergency service number can either be pre-stored in the keydevice 100 or it can be communicated with the request. This enables the proxy device300 to also ﬁ.1nction as an alarrn button by pressing the button 370 to cause a call to anemergency service.

In one embodiment the proxy device 300 or the key device 100 is arranged tosend a current location along with the request to contact an emergency service. In oneembodiment, where the key device 100 is arranged with a location finding apparatussuch as a GPS device, the key device 100 is arranged to retrieve a current position andinclude this position when contacting the emergency service. In one embodiment theproxy device 300 or key device 100 is arranged to extract a current position from theidentifier of a lock device 140 last communicated with and include this position whencontacting the emergency service.

In one embodiment the key device 100 is arranged to extract a current positionfrom the cell location that the key device 100 is currently operating in.

In one embodiment the key device 100 is arranged to contact the emergencyservice by sending a message such as a text message carrying text information regardingthe emergency, a multimedia or electronic mail message carrying text, image and/orsound information regarding the emergency, or to initiate a voice call to an emergencynumber and relay a computer generated or pre-recorded message.

In one embodiment the key device 100 is arranged to place a call to theemergency service and thereby enable a communication channel between the user andthe emergency service. This allows a user to quickly and conventiently contact anemergency service by simply pressing a button. It also enables the emergency service toaquire a location of the user 2 of the key device 100 and proxy device 300.

In one embodiment the proxy device also comprises an emergency beacon or distress radio beacon (not shown) that can be tracked. Such a distress beacon can be any 38 ELT or EPIRB device commonly known to a skilled person. This allows the emergencyservice responders to pinpoint the location of the proxy device 300 even if the locationprovided by the proxy device 300 or key device 100 is unavailable or not accurate.

In one embodiment the proxy device 300 also comprises a sound generatingdevice (not shown) that is activated and sounded as the alarm button 370 is pressed. Inan altemative embodiment the processing unit 310 is configured to cause the key device100 to sound an audible alarm as the alarm button 370 is pressed. This enables theproxy device to act as a close-counter alarm device calling the attention of any personsstanding nearby when the button 370 is pressed.

All or a portion of the exemplary embodiments can be implemented by thepreparation of application-specific integrated circuits, or by interconnecting anappropriate network of conventional component circuits, or by programming aprocessing device, or any combination thereof, as will be appreciated by those skilled inthe electrical art(s).

It should be noted that although various ﬁanctionalities and characteristics ofthe manner of an access control system has been disclosed in different sections of thedetailed specification, it should be understood that the embodiments are intended to becombined across the sections herein according to a designer°s requirements.

It is apparent to a person skilled in the art that with the advancement oftechnology, the basic idea may be implemented in various ways. The invention and itsembodiments are thus not limited to the examples described above; instead they may vary within the scope of the claims.

Claims

1. A proxy device (300) for use in an access control system Which comprises alock device (140) and a key device (100, 900), said lock device (140) being operativelyconnected to a lock (150) and said key device (100, 900) being a mobile terrninal (100)and being associated With a user (2), said proxy device (300) comprising controller means (310); a proxy device identifier (PD_ID); and at least one short-range communication interface (330, 340), said proxy device being characterized in that: said controller means (310) is configured for causing said at least one short-range communication interface (330) to establish a first connection (14A) With said keydevice (100, 900) and receive an authentication, possibly including a key deviceidentifier (KD_ID) for said key device (100, 900), and said controller means (310) is configured for causing said at least one short-range communication interface (340) to establish a second connection (14B) With saidlock device (140) and provide to said lock device (140) an identifier (KD_ID, PD_ID,KD+PD_ID) Which allows said lock device (140) to determine Whether access shouldbe granted to said lock or not, Wherein said second connection is established on behalfof said key device (100, 900) and Wherein said proxy device (300) acts as a deviceidentifier tunnel between said key device (100, 900) and said lock device (140), Whereinsaid at least one short-range communication interface (340) comprises a Bluetooth®interface With Which said second connection (14B) With said lock device (140) is established Without pairing.

2. A proxy device (300) according to claim 1, Wherein said authentication includes indication of an authentication time period (ATP).

3. A proxy device (300) according to claim 1 or 2, further configured toterrninate said ﬁrst connection (14A) With said key device (100, 900) before establishing said second connection (14B).

4. A proxy device (300) according to any of claims 1 to 3, wherein saidcontroller means (310) is further conf1gured for receiving a message from either of saidkey device (100, 900) and said lock device (140) and forwarding said message to theother of said lock device (140) and said key device (100, 900), thereby acting as a datatunnel between said key device (100, 900) and said lock device (140).

5. A proxy device (300) according to any of claims 1 to 4, wherein saidcontroller means (310) is further conf1gured for causing said at least one short-rangecommunication interface (340) to establish said second connection (14B) initially as a one-way connection.

6. A proxy device (3 00) according to claim 4, wherein said controller means(310) is ﬁarther configured for deterrnining if said received message is to be adjusted and, if so, adjusting said received message before forwarding it.

7. A proxy device (300) according to claim 6, wherein said controller means(310) is ﬁarther configured for adjusting the content of said received message to reflect the original sender and/or receiver.

8. A proxy device (300) according to claims 6 and/or 7, wherein said controllermeans (310) is further conf1gured for adjusting the recipient and/or sender of said received message.

9. A proxy device (300) according to any preceding claim, wherein saididentifier provided to said lock device (140), allowing it to determine whether accessshould be granted or not, is said received identifier (KD_ID) of said key device (100,900).

10. A proxy device (300) according to any preceding claim, wherein said identifier provided to said lock device (140), allowing it to determine whether access 41 should be granted or not, is said proxy device identifier (PD_ID) of said proxy device (300).

11. A proxy device (300) according to any preceding claim, Wherein saididentifier (KD+PD_ID) provided to said lock device (140), allowing it to deterrnineWhether access should be granted or not, is a combination of said proxy device identifier(PD_ID) of said proxy device (300) and said received identifier (KD_ID) of said keydevice (100, 900).

12. A proxy device (300) according to claim 10-11, Wherein said proxy deviceidentifier (PD_ID) of said proxy device (300) is the Bluetooth® address of saidBluetooth® interface (340).

13. A proxy device (300) according to claim 4, Wherein the message comprisesupdated access control data, emanating from a central server (122) and to be stored in a local database (LD_DB) in the lock device (140).

14. A proxy device (300) according to claim 4, Wherein the message compriseslog and/or status data, emanating from the lock device (140) and to be forWarded by said key device (100, 900) to a central server (122).

15. A proxy device (300) according to any preceding claim, Wherein saidcontroller means (310) is further for: detecting a first lock device (140) having a first priority; detecting a second lock device (140a) having a second priority; and deterrnining Whether said first priority is higher than said second priority, and,if so, establishing said second connection (14B) With said first lock device (140), and, if not, establishing said second connection (14B) With said second lock device (140a).

16. A proxy device (300) according to any preceding claim, Wherein said lock device (140) is associated With a lock device group and said controller means (310) is 42 further for: receiving a long press on the at least one button (370a, 370b) to actuate saidlock device (140a) in a first group and for receiving a short press on the at least one button (370a, 370b) to actuate a lock device (140) in a second group.

17. A proxy device (300) according to any preceding claim, ﬁarther comprising a vibrator for providing a vibration pattern.

18. A proxy device (300) according to any preceding claim, ﬁarther comprisinginput means (370) for receiving a user input, Wherein said controller means (310) isconfigured for causing said key device (100) to contact an emergency service in response to said input means (370) receiving said user input.

19. A proxy device (300) according to any of claims 1-18, ﬁarther comprisinginput means (370) for receiving a user input, Wherein said controller means (310) isconfigured for causing an audible alarrn to be generated in response to said input means (370) receiving said user input.

20. An access control system comprising a proxy device (300) according to anypreceding claim and a lock device (140), said lock device (140) comprising: a short-range Wireless communication interface (540); controller means (510); memory means (550) associated With the controller (510) for storing a localdatabase (LD_DB) containing access control data; and a lock actuator (512), Wherein said controller means (510) is configured for: receiving an identifier from said proxy device (300) via said short-rangeWireless communication interface (540), matching said received identifier against the access control data in saiddatabase (LD_DB), and, if a match is found, causing said lock actuator (512) to unlock a lock (150) operatively connected to the lock actuator (512), 43 Wherein said at least one short-range communication interface (540) comprisesa Bluetooth® interface With Which a connection (14B) With said proxy device (300) is established Without pairing for receiving said identifier.

21. An access control system according to claim 20, Wherein said lock device(140) is configured for further matching of additional Verification data received fromsaid proxy device (300) against said access control data (LD_DB) before causing said lock actuator (512) to unlock said lock (150).

22. An access control system according to claim 20 or 21, Wherein said lockdevice (140) is configured for detecting a vibration or knocking pattem and in responsethereto activate said short-range Wireless communication interface (540), Wherein saidvibration pattem is specific to the lock device (140) and/or corresponds to one or several knocks possibly in a specific rhythm.

23. An access control system according to any of claims 20 to 22, furthercomprising a key device (100, 900) being a mobile terminal (100), said key device (100,900) comprising: controller means (410), memory means (450), and short-range communication interface means (440) for communicating With said proxy device (300).

24. An access control system according to claim 23, further comprising a central server (122).

25. An access control system according to any of claims 20 to 24, Wherein saidcontroller means (310) of said proxy device (300) is configured for:detecting a first lock device (140) having a first priority; detecting a second lock device (140a) having a second priority; and 44 deterrnining whether said first priority is higher than said second priority, and,if so, establishing said second connection (14B) with said first lock device (140), and, if not, establishing said second connection (14B) with said second lock device (140a).

26. An access control system according to any of claims 20 to 25, wherein saidlock device (140) is associated with a lock device group and said controller means (310)of said proxy device (3 00) is further for: receiving a long press on the at least one button(370a, 370b) to actuate said lock device (140a) in a first group and for receiving a short press on the at least one button (370a, 370b) to actuate a lock device (140) in a second group .

27. A method for controlling a lock in an access control system whichcomprises a key device (100, 900) being a mobile terminal (100), a proxy device (300)and a lock device (140), said method comprising: establishing a first connection (14A) between said proxy device (300) and saidkey device (100, 900); in said proxy device (300), receiving an authentication, possibly including anidentifier (KD_ID) for said key device (100, 900); establishing a second connection (14B) between said proxy device (300) andsaid lock device (140), and from said proxy device (300), providing to said lock device (140) an identifier(KD_ID, PD_ID, KD+PD_ID) which allows said lock device (140) to determinewhether access should be granted to said lock or not, wherein said second connection isestablished on behalf of said key device (100, 900) and wherein said proxy device (300)acts as a device identifier tunnel between said key device (100, 900) and said lockdevice (140), wherein said second connection (14B) is a Bluetooth® connection which is established without pairing.

28. The method according to claim 27, wherein said authentication includes indication of an authentication time period (ATP).

29. The method according to claim 27 or 28, further comprising:terrninating said first connection (14A) With said key device (100, 900) before establishing said second connection (14B).

30. The method according to any of claims 27 to 29, further comprising: detecting a first lock device (140) having a first priority; detecting a second lock device (140a) having a second priority; and deterrnining Whether said first priority is higher than said second priority, and,if so, establishing said second connection (14B) With said first lock device (140), and, if not, establishing said second connection (14B) With said second lock device (140a).

31. The method according to any of claims 27 to 30, Wherein said lock device(140) is associated With a lock device group and said method further comprises:receiving a long press on the at least one button (370a, 370b) to actuate said lock device(140a) in a first group and for receiving a short press on the at least one button (370a, 370b) to actuate a lock device (140) in a second group.