Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
ACCESS CONTROL METHOD, AND ASSOCIATED PROXY DEVICE AND ACCESS CONTROL SYSTEM
Document Type and Number:
WIPO Patent Application WO/2014/098755
Kind Code:
A1
Abstract:
A proxy device (300) is disclosed for use in an access control system which comprises a lock device (140) and a key device (100) being a mobile terminal, wherein the 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); a proxy 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 key device (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 for causing said at least one short-range communication interface (340) to establish a second 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) to determine whether or not access should be granted to the lock. The second connection is established on behalf of the key device (100),and said proxy device (300) acts as a device identifier tunnel between the key device (100) and the lock device (140). In one embodiment the short-range communication interface comprises a Bluetooth ® interface with which said second connection with said lock device is established without pairing.

Inventors:
BLIDING OLLE (SE)
Application Number:
PCT/SE2013/051563
Publication Date:
June 26, 2014
Filing Date:
December 18, 2013
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
PHONIRO AB (SE)
International Classes:
E05B47/00; G07C9/00
Domestic Patent References:
WO2006098690A12006-09-21
WO2003063091A12003-07-31
Foreign References:
EP2434461A12012-03-28
US20080148369A12008-06-19
US20110311052A12011-12-22
US20120218075A12012-08-30
Attorney, Agent or Firm:
STRÖM & GULLIKSSON AB (Malmö, SE)
Download PDF:
Claims:
CLAIMS

1. A proxy device (300) for use in an access control system which comprises a lock device (140) and a key device (100, 900), said lock device (140) being operatively connected to a lock (150) and said key device (100, 900) being a mobile terminal (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 key device (100, 900) and receive an authentication, possibly including a key device identifier (KDJD) 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 said lock 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 should be granted to said lock or not, wherein said second connection is established 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 lock device (140), wherein said 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 to terminate said first 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 said controller means (310) is further configured for receiving a message from either of said key device (100, 900) and said lock device (140) and forwarding said message to the other of said lock device (140) and said key device (100, 900), thereby acting as a data tunnel 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 said controller means (310) is further configured for causing said at least one short-range communication interface (340) to establish said second connection (14B) initially as a one-way connection.

6. A proxy device (300) according to claim 4, wherein said controller means (310) is further configured for determining 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 further 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 controller means (310) is further configured for adjusting the recipient and/or sender of said received message. 9. A proxy device (300) according to any preceding claim, wherein said identifier provided to said lock device (140), allowing it to determine whether access should 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 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 said identifier (KD+PD_ID) provided to said lock device (140), allowing it to determine whether 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 key device (100, 900).

12. A proxy device (300) according to claim 10-11 , wherein said proxy device identifier (PD_ID) of said proxy device (300) is the Bluetooth® address of said

Bluetooth® interface (340).

13. A proxy device (300) according to claim 4, wherein the message comprises updated 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 comprises log 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 said controller 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 determining 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 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.

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

18. A proxy device (300) according to any preceding claim, further comprising input means (370) for receiving a user input, wherein said controller means (310) is configured 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, further comprising input means (370) for receiving a user input, wherein said controller means (310) is configured for causing an audible alarm 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 any preceding 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 local database (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-range wireless communication interface (540),

matching said received identifier against the access control data in said database (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), wherein said at least one short-range communication interface (540) comprises a 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 from said proxy device (300) against said access control data (LD_DB) before causing said lock actuator ( 12) to unlock said lock (150).

22. An access control system according to claim 20 or 21, wherein said lock device (140) is configured for detecting a vibration (or knocking) pattern and in response thereto activate said short-range wireless communication interface (540), wherein said vibration pattern 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, further comprising 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 said controller 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 determining 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 said lock device (140) is associated with a lock device group and said controller means (310) of said proxy device (300) 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 which comprises 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 said key device (100, 900);

in said proxy device (300), receiving an authentication, possibly including an identifier (KD ID) for said key device (100, 900);

establishing a second connection (14B) between said proxy device (300) and said 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 determine whether access should be granted to said lock or not, wherein said second connection is established 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 lock device (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:

terminating 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

determining 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.

Description:
ACCESS CONTROL METHOD, AND ASSOCIATED PROXY DEVICE AND

ACCESS CONTROL SYSTEM

Field of the Invention

The present invention relates to access control, and more particularly to a proxy device for use in an access control system in which a key device is incompatible with a lock device. The invention also relates to an access control method in which a proxy device provides a communication channel between a lock device and a key device. 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 as a door, a gate or a window is probably by using a mechanical key. This solution is cost efficient 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 the key does not have any restrictions, i.e. it always works. These drawbacks might seem like 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 the drawbacks are of considerable importance. In more particular, if a large number of users must have access to a large number of doors, a large number of keys has to be made for the different doors. For several reasons, this is not only unhandy but also a considerable security risk and costly.

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

Secondly, a user who receives a key might abuse it, and even if the user is a responsible person, the key might be stolen or lost. Since there are no built-in restrictions 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 key substitutions imply considerable costs for a lost key. A mechanical key system is hence not suitable for situations with a large number of users and a large number of doors. An example of such a situation is the elderly home care or home nursing, where the domestic help personnel has a key to each of the caretakers. In such services, there may be a vast number of doors that need to be handled resulting in thousands of key and lock combinations. In such systems it is necessary to carry a great number of keys, which is cumbersome, or use a master key, which is unsafe if many master keys need to be provided (which is the case when there are many nurses). Furthermore, there is a problem in selecting the correct key for a specific lock, and this manual procedure may take 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. In WO 02/31778 Al a wireless lock system is presented. When the lock of the system detects a nearby electronic key carried by a user, a random signal is generated. The key encrypts the signal and returns it to the lock. The lock decrypts the signal and compares it to the original to determine if the lock should be unlocked.

In order to function, the wireless lock system mentioned above must always establish a two-way wireless communication link between the key and the lock. This is a drawback, since the establishment of a two-way communication link is not made instantly. Hence, a user has to wait for a period of time until the establishment of the two-way communication link is completed, and thereafter the user has to wait until the comparison is completed. When a wireless lock system, like the one shown in WO 02/31778 Al, is implemented with the de facto standard for short-range wireless data communication for mobile devices, namely RF communication in accordance with the Bluetooth ® standard on e.g. the 2.45 GHz ISM band, one must expect at least about 5 seconds, 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 the data 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 smooth and easy. Hence, it is desired to reduce the time that lapses from the lock's detection of a nearby electronic key until the unlocking of the lock, or more particularly the delay that a user may experience waiting in front of the lock for it to unlock.

The international patent application WO 2006/098690 discloses an access control system that proposes a solution to overcome these problems. In WO 2006/098690, the electronic key devices are capable of short-range wireless data communication with the lock devices. Each key device has a key device identifier which is used for the short-range wireless data communication, and the lock device is configured to perform authentication of an appearing key device by detecting the key device identifier of the key device and using the detected key device identifier, together with some other parameters, to determine whether access shall be granted. Each lock device is a stand-alone device with its own internal power source and requires no wiring to its surroundings. When a key device approaches and seeks access, the lock device will communicate with the key device using short-range wireless data communication, but it will typically not need any further communication with other, more remote elements in the system, such as a central server. In order to operate autonomously, the lock device uses local access control data which is stored within the lock device and defines the key device identifiers of key devices which are allowed to access the protected environment. In one embodiment, the key devices are mobile terminals or other similar types of portable communication devices being equipped with short-range wireless data communication interfaces in the form of Bluetooth ® transceivers. Hence, the key device identifier of each key device is the unique Bluetooth ® address assigned to the Bluetooth ® transceiver in the key device.

However, although this solution reduces the time to get access granted from up to 30 seconds to a mere 2-4 seconds, it does require that the key device is capable of establishing at least a one-way Bluetooth ® connection. Also, for the key device to be able to communicate with a central server, such as an administrative server, the key device also has to have some form of long range communication interface. Due to this latter 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, a Bluetooth ® device typically requires pairing with a second device in order to allow connection 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 lock device typically does not have a user interface, a normal user can not easily input such a passcode. Instead, an administrator would have to visit the lock device and connect some sort of set-up device in order to enter the required passcode and complete the pairing. Lately, more and more manufacturers of mobile phones and/or operating systems for mobile phones have started requiring that their products must be paired to establish a Bluetooth ® connection with another device. Thus, many mobile phones suffer from an incompatibility with the kind of lock device seen for instance in WO 2006/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 lock device may be hard-coded to a specific code. Such a hard-coded code may be generic, such as ΌΟΟΟ', or specific to the lock device, for example the tail portion of its Bluetooth® address. Such solutions suffer from the drawback of reduced security (in the case of a generic code) or that the mobile phone is not configured to handle a vast number of Bluetooth® devices, as will be the case for applications such as in a home nursing 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 inherent difficulty in retrieving the Bluetooth™ address of the device. This is difficult not only for a user, but also for a designer in some cases, whereby such mobile phones are incompatible with a Bluetooth™ operated lock in that it will be difficult and/or time consuming to establish a connection with the lock.

Hence, a problem with access control systems of the type shown for instance in WO 2006/098690, is that mobile phones fail to qualify as suitable key devices, since they have an incompatible communication interface and hence cannot connect to the lock device using the lock device's preferred communication interface. Therefore, an operator 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 reduce the problems discussed above.

On a conceptual level, the invention is based on the inventive insight that in an access control system where a lock device is arranged with a short range interface such as a Bluetooth ® interface and the key device is arranged with another interface which is in some way incompatible for establishing a connection with the lock device, a proxy device can be introduced to establish a communication channel between the key device and the lock device, wherein the proxy device will serve as a proxy for the key device and 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 proxy device for use in an access control system which comprises a lock device and a key device being a mobile terminal, said lock device being operatively connected to a lock and said key device being associated with a user. The proxy device comprises controller means; a proxy device identifier; and at least one short-range communication interface. The controller means is configured for causing said at least one short-range

communication interface to establish a first connection with said key device and receive an authentication, possibly including a key device identifier for said key device. The controller means is further configured for causing said at least one short-range communication interface to establish a second connection with said lock device and provide to said lock device an identifier which allows said lock 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 proxy device thereby acts as a device identifier tunnel between said key device and said lock device. In one embodiment the short-range communication interface comprises a Bluetooth ® interface with 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 between the lock device and the key device, the incompatibility issues are resolved and it is possible 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 cases where the key device requires to be paired before communicating. Also, it is also possible to increase the safety of the lock system as both a proxy device and a key device 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, as each proxy is able to handle a vast number of locks. Instead of finding the correct key for 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 a user.

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

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

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

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

In one embodiment the controller means is further configured for determining if said received message is to be adjusted and if so, adjusting said received message before forwarding it. Also, in one embodiment the controller means may be further configured for adjusting the content of said received message to reflect the original sender and/or receiver. Additionally, in one embodiment the controller means may be further 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 the lock device and the key device, which do not need to know that they are in fact communicating with a proxy device. This allows the proxy device to be used in an already installed access control system without making any change to the lock devices.

In one embodiment, the identifier provided to said lock device, allowing it to determine whether access should be granted or not, is said received identifier of said key device. Alternatively, in one embodiment, the identifier provided to said lock device, allowing it to determine whether access should be granted or not, is said proxy device identifier of said proxy device. Alternatively, in one embodiment, the identifier provided to said lock device, allowing it to determine whether access should be granted or not, is a combination of said proxy device identifier of said proxy device and said received identifier of said key device. This allows the proxy device to control the flow of data being tunneled between the key device and the lock device, always making sure that each recipient knows who to respond to.

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

In one embodiment, said at least one communication interface comprises any of a Bluetooth ® interface, an IrDA interface, an NFC interface, a WLAN interface or a USB interface, with which said first connection (14A) with said key device (100) is established. If Bluetooth ® is used, a single Bluetooth ® transceiver may advantageously be 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 another kind of interface than Bluetooth ® for said first connection, the proxy device can be enabled to communicate with key devices not having a Bluetooth® interface, thereby solving 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, it becomes easier to update the access rights for any existing user, and also to add or delete 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, emanating from the lock device and to be forwarded by said key device to a central server. This allows for a lock device to communicate back to such a central server more frequently and alleviates the requirement for a lock device to wait for a special operator person to come by to collect the log and/or status data.

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

A second aspect of the present invention is an access control system comprising a proxy device according to the first aspect of the present invention, and a lock device, where the lock device comprises a short-range wireless communication interface, controller means, memory means associated with the controller for storing a local database containing access control data, and a lock actuator. The controller means is configured for: receiving an identifier from said proxy device via said short-range wireless communication interface, matching said received identifier against the access control data in said database, and, if a match is found, causing said lock actuator to unlock a lock operatively connected to the lock actuator. In such a system the lock device 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 flexibility in selecting 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 of additional verification data received from said proxy device against said access control data before causing said lock actuator to unlock said lock. This allows for greater security to be built into the access control system by requiring that a code such as a PIN code should be entered before access is granted.

In one embodiment, the access control system further includes a key device being a mobile terminal which comprises controller means, memory means, and short- range communication interface means for communicating with said proxy device. In one embodiment, the access control system further comprises a central server which allows 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 software module of the central server.

In one embodiment the lock device is configured for detecting a vibration (or knocking) pattern and, in response thereto, activate said short-range wireless communication interface, wherein said vibration pattern is specific to the lock device and/or corresponds to one or several knocks possibly in a specific rhythm.

A third aspect of the present invention is a method for controlling a lock in an access control system which comprises a key device being a mobile terminal, a proxy device and a lock device. The method comprises: establishing a first connection between said proxy device and said 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, and from said proxy device, providing to said lock device an identifier which allows said lock 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 proxy device acts as a device identifier tunnel between said 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 to learn a new user interface. The user will still use his key device and use it in the way he did before.

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

In one embodiment the method further comprises detecting a first lock device having a first priority, detecting a second lock device having a second priority, and determining 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, establishing said second connection with said second lock device.

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

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

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

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the [element, device, component, means, step, etc]" are to be interpreted openly as referring to at least one instance of said element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. Brief Description of the Drawings

The above, as well as additional objectives, features and advantages of the present invention, will be better understood through the following illustrative and non- limiting detailed description of embodiments of the present invention, reference being made to the appended drawings.

Figure 1 is a schematic view of an access control system in which embodiments of the present invention may be exercised.

Figure 2 illustrates an access control method which may be performed in the access control system of Figure 1.

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

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

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

Figures 6A-6C, 7A-7C and 8A-8C are each a schematic flowchart diagram of an access control method according to different embodiments.

Figure 9 is a schematic block diagram of an embodiment of the access control system of Figure 1 comprising a proxy device which may interact with both a key device 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 mobile telecommunications system, one example of which is illustrated in Figure 1. The mobile telecommunications system comprises a mobile telecommunications network 110. Central elements in Figure 1 are a wireless key device (KD) 100 and a wireless lock device (LD) 140. The purpose of the lock device 140 is to control some sort of lock mechanism in a lock, which in the illustrated example is a door lock on a door 152. In Figure 1, a second door 152a is also shown, indicating that the manner herein may be used with a plurality of doors, each door 152, 152a having its respective lock device 140, 140a In turn, the lock device 140 is operated by the key device 100 when brought in the vicinity of the lock device. In more particular, the lock device 140 is enabled for short-range wireless data communication in compliance with a communication standard. In the preferred embodiment, this communication standard is Bluetooth ® . Having been the de facto standard for short-range wireless data communication for mobile devices during several years, Bluetooth ® is believed to be very well known to the skilled person, and no particulars about Bluetooth ® as such are consequently given herein. As will be described in more detail later, a proxy device (PD) 300 is provided as an intermediate tunneling device between the key device 100 and the lock device 140.

The mobile telecommunications network 110 is operatively connected to a wide area network 120, which may be Internet or a part thereof. Various client computers and server computers, including a central server 122, may be connected to the wide area network 120. A public switched telephone network (PSTN) 130 is connected to the mobile telecommunications network 1 10 in a familiar manner. Various telephone terminals, including a stationary telephone 132, may be connected to the PSTN 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 and an 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 one lock device 140 (e.g. the lock device 140 and the lock device 140a of figure 1), more than one key device 100 and more than one proxy device 300. Together with the central server 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 life embodiment of such an access control system there will also be key devices 100 that do not suffer from incompatibility issues with the lock device and therefore may not need a corresponding proxy device 300. In such a case, the key device 100 and the lock device 140 will be communicating directly with one another. This is indicated by the dashed line 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), internet tablet, smart phone, etc., which is capable of communicating with a telecommunications system, such as the one shown in Figure 1. Thus, a user 2 may use the key device 100 for various telecommunication services, such as voice calls, Internet browsing, video calls, data calls, facsimile transmissions, still image transmissions, video transmissions, electronic messaging, and e-commerce. Generally, these telecommunication 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, only components which are somehow pertinent to the inventive functionality are shown in Figure 4.

The key device 100 may also be implemented as a server, a computer or a software 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 described in 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 for connecting to the Internet/telecommunications network(s) 110, 120. The network interface 430 may comply with any commercially available mobile telecommunications standard or specification, including but not limited to GSM, UMTS, LTE, D-AMPS, CDMA3000, FOMA and TD-SCDMA. Alternatively or additionally, the network interface 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 user interface (UI) 420, which may include a display 422 and a set of keys 424 or other input device, as well as other known UI elements like a speaker and a microphone. The user 2 may control the operation of, and exchange data with, the key device 100 over the user interface 420.

Further, the key device 100 has an interface 440 for short-range data communication. In the disclosed embodiment of Figure 4, the interface 440 comprises a Bluetooth ® transceiver, by means which the key device 100 can communicate with, for instance, 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 with the lock device 140 over a Bluetooth' 5 link 14) The Bluetooth' * transceiver is assigned a unique Bluetooth ® address KD_ID, which serves as a key device identifier of the key device 100. Alternatively or additionally, the interface 440 may for instance comprise transceiver components for IrDA (Infrared Data Association), WLAN or NFC (Near Field Communication). In one alternative emboidment, the key device 100 does not comprise any interface for short-range wireless communication, but a connector interface such as a Universal Serial Bus interface, i.e. a USB port. It should be noted that a key device 100 may comprise both a short-range wireless interface and a connector interface. In Figure 4, any connector interface is seen to be part of the short range communication interface 440, and any communication emanating from that communication interface is part of the communication link 14 A.

A processing unit 410 is overall responsible for the operation and control of the different components of the key device 100. The processing unit 410 may be implemented in any known controller technology, including but not limited to a processor (PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or analogue circuitry capable of performing the intended functionality. The processing unit 410 constitutes an implementation of the key device's controller means, as referred to in the Summary section of this document.

Finally, the key device 100 has a memory 450 which is operatively connected to the processing unit 410. The memory 450 may be implemented by any known memory technology, including but not limited to E(E)PROM, S(D)RAM and flash memory, 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 which together constitute the memory 450 on a logical level. In addition to storing various program instructions and data for the various functions and applications which are typically available in a mobile terminal, the memory 450 also comprises program instructions 452 and work data for an access control software application executed in the key device 100. Also, any updated access control data received from the central server 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 the following main components. A processing unit 510 is overall responsible for the operation and control of the different components of the lock device 140. The processing unit 510 may be implemented in any known controller technology, including but not limited to a processor (PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or analogue circuitry capable of performing the intended functionality. The processing 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, autonomously operating device which requires no wire-based installations, neither for communication nor for power supply. Instead, the lock device 140 is powered solely by a local power unit 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 an interface 540 for short-range wireless data communication. In the disclosed embodiment of Figure 5, the interface 540 comprises a Bluetooth ® transceiver, by means which the lock device 140 can communicate with, for instance, the proxy device 300 over a second connection or Bluetooth ® link 14B (if there is no incompatibility issue between the key device 100 and the lock device 140, the lock device 140 could communicate directly with the key device 100 over a Bluetooth ® link 14). The Bluetooth ® transceiver is assigned a unique Bluetooth ® address LD_ID. Alternatively or additionally, the interface 540 may for instance comprise transceiver components for IrDA, WLAN or NFC.

The lock device 140 comprises a lock actuator 512 being operatively connected to a lock, such as the lock 150 on the door 152 in Figure 1. After successful verification of an approaching proxy device 300/key device 100 in the way described in other parts of this document (as well as in the aforementioned WO 2006/098690), the processing unit 510 will control the lock actuator 512 to open the lock. This may involve actuating an 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. The lock device 140 of the disclosed embodiment further includes a real-time clock 530 capable of providing the processing unit 510 with an accurate value of the current time. However, embodiments are also possible where no real-time clock is provided.

Finally, the lock device 140 has a memory 550 which is operatively connected to the processing unit 510. The memory 550 may be implemented by any known memory technology, including but not limited to E(E)PROM, S(D)RAM and flash memory, 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 which together constitute the memory 550 on a logical level. The memory 550 serves to store various program instructions and work data for functions to be performed by the processing 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 decisions are based. The lock device database 570 may also store log and/or status data which are referred to further below. In one embodiment the lock device 140 has a serial number which was assigned during manufacturing, assembly, delivery or installation. This serial number is also stored in the memory 550.

For further implementation details and possible additional components of the lock device 140 and the key device 100, reference is made to the aforementioned WO 2006/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 some way incompatible for establishing a connection with the lock device, the inventors have realized that by introducing the aforementioned proxy device 300 (see Figure 3), a communication channel can still be established between the key device 100 and the lock device 140, using the proxy device 300 as a proxy for the key device 100 to act as a tunnel between the two.

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

The proxy device 300 also comprises a processing unit 310 which is overall responsible for the operation and control of the different components of the proxy device 300. The processing unit 310 may be implemented in any known controller technology, including but not limited to a processor (PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or analogue circuitry capable of performing the intended functionality. The processing unit 310 constitutes an implementation of the proxy device'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 which is operatively connected to the processing unit 310. The memory 350 may be implemented by any known memory technology, including but not limited to E(E)PROM, S(D)RAM and flash memory, and it may also include secondary storage such as a magnetic or optical disc. Physically, the memory 350 may consist of one unit or a plurality of units which together constitute the memory 350 on a logical level. The memory may be used to temporarily store data to be communicated between the lock device 140 and the key device 100. The memory 350 may also be used to store identification 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 determining whether or not access shall be granted. For embodiments where the second interface 340 is Bluetooth ® -based, the proxy device identifier PD ID may advantageously be the unique Bluetooth ® address of the Bluetooth ® transceiver. Alternatively, the proxy device identifier PD ID may be stored in a readable form in the memory 350. The proxy device should be designed to be small in size so that it can easily accompany a key device, being a mobile terminal. Furthermore, in one embodiment the proxy device does not comprise a long range communication interface such as a cellular communication interface.

In one embodiment the proxy device 300 does not have a user interface to keep its size very small. In an alternative embodiment the proxy device 300 comprises a very simple user interface 370. In Figure 3, the user interface 370 is indicated to be optional by being drawn with dashed lines. In one such embodiment, the user interface is a single button.

In one embodiment, which will be described in more detail with reference to

Figure 9, the user interface 370 comprises at least one lock/unlock button. In one embodiment the lock/unlock button is configured to cause a lock device (140) to toggle between a locked and an unlock state.

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

In one embodiment, the user interface 370 comprises at least one light emitting diode (LED) (shown explicitly in Figure 9 and referenced 376). The at least one LED 376 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 a manner that it can be attached to the key device 100 so that the two can be carried conveniently as one combined device. This is particularly convenient if the first communication interface 330 is extremely short-ranged (e.g. IrDA, NFC, USB).

The operation of the proxy device 300 in relation to the key device 100 and the lock device 140 will now be described with reference to Figure 2. In this example the key device 100 is arranged with a Bluetooth ® interface 440 that requires paring for establishing a communication link with another device, whereas the lock device 140 is arranged with a Bluetooth ® communication interface 540 that does not require pairing. In an initial step 210 the user 2 acquires a proxy device 300 that is or will be paired with or connected to the user' s key device 100. Typically, the operator of the access control system will associate the particular key device 100 and proxy device 300 with the user 2 by storing some sort of association or link between the three in the system database 124. For instance, a database record representing the user 2 may contain one or more data fields for storing the key device identifier KD_ID of the key device 100, the proxy device identifier PD_ID of the proxy device 300, or a combination thereof. Also, the system database 124 will typically contain access control data which defines the access rights given to the user 2/key device 100/proxy device 300 as regards which lock devices 140 in the access control system that are allowed to be accessed, and when and how they may be accessed. These access rights will also be stored 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 in time when use of the key device 100 for access purposes is not imminent, the pairing time of up to 30 seconds is of no concern. During the initial pairing or connection, the key device 100 authenticates the proxy device 300 and the key device 100 and the proxy device 300 exchange data with each other in step 220. In one embodiment the key device 100 informs the proxy device 300 of its Bluetooth ® address KD_ID, which the proxy device 300 stores in its memory 350 (as shown in Figure 3). In one embodiment this is part of the authentication process. The proxy device 300 is now paired or connected 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 with the 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 to initiate 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 device 140, there are two possibilities. The first is that the lock device 140 senses that the key and proxy device pair 100+300 is in the vicinity, identifies the KPD 100+300 (step 230), and compares the identifier of the pair with its internal database LD DB in a step 240 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+300 senses that a lock device 140 is in the vicinity and initiates the lock device 140 by communicating their identifier in step 230 to the lock device 140, thereby allowing it to determine whether the key and proxy device pair 100+300 is to be granted access or not in step 240. This is similar to how a key device 100 is granted access to a lock 150 by a lock device 140 as has been disclosed in WO 2006/098690. In this latter possibility, the sensing of the lock device 140 may be done by either the key device 100, which then instructs the proxy device 300 to establish a connection with the lock device 140, or by the proxy device 300 that connects to the lock device 140 as it is found and informs the key device 100 that a connection has been made. Notice that the connection between the proxy device 300 and the lock device 140 is established without pairing.

If the lock device 140 determines that the key and proxy device pair 100+300 is 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 device 100 and the proxy device 300 may be a virtual pairing, wherein the key device 100 authenticates the proxy device 300 to operate as if paired with the key device 100 during an authentication time period even after the first connection has been terminated. The key device 100 and proxy device 300 pair referenced KPD above is thus in such an embodiment represented by the proxy device 300 solely after having been authenticated by the key device 100. Similarly, the same authentication of the proxy device 300 by the key device 100 is possible to be implemented also for the other embodiments disclosed herein, even if not expressly described in conjunction with a specific embodiment.

Utilizing a user name and a password for establishing the first connection, a history 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 proxy device 300

Figure 2 shows the basic functionality of the proxy device 300, and the more specific operation of the proxy device 300 will now be disclosed.

There are at least three alternatives of how to identify the proxy and key device pair 100+300 to the lock device 140. In a first alternative the identifier PD ID for the proxy device 300 is represented in the access control data in the LD-DB 570. When the proxy and key device 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. The lock device 140 then compares the received PD_ID with a list of devices being allowed access according to the access control data stored in the LD DB 570. In this alternative the proxy device 300 thus substitutes the key device identifier KD_ID with its identifier PD ID. This alternative has the benefit that no changes are required to be made to the lock device 140 to allow proxy devices into an already set up system, as disclosed in WO 2006/098690, apart from adding the identifiers PD_ID of the respective the proxy devices in the access control system to the lock device's 140 database LD_DB 570. This alternative may require some changes to be made to the communication protocols between the devices to signify exactly for which device a request is made. This will be apparent from the discussion relating to Figure 6A below.

In a second alternative the proxy device 300 uses the key device identifier

KD_ID as its own identifier, that is the proxy device 300 forwards the identifier for the key device 100 KD_ID instead of its proxy device identifier to the lock device 140, in other words PD ID = KD ID. This has the benefit that no changes need to be made to the list of allowed devices in the LD DB in the lock device 140, if the identifier KD ID for the key device 100 is already distributed to and stored in the various lock devices 140. This alternative is especially useful when the proxy device 300 is connected to the key device 100 using a different interface than the one which the proxy device 300 is connected to the lock device 140 with, since the messages can then be forwarded directly without having taking mechanisms such as scheduling into account.

In a third alternative the proxy device 300 is arranged to communicate a combination of the key device identifier KD ID and the proxy device identifier PD ID to the lock device in the form of KD+PD ID. The received KD+PD ID is then compared by the lock device 140 to the identifiers stored in the database LD DB. In one such embodiment the identifier KD+PD_ID for the key and proxy device pair 100+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 only be granted to a key device 100 if the correct proxy device 300 is used at the same time. However, this alternative requires most changes to be made to the databases and how they are searched, but it does not require the protocol for communicating between devices to be changed.

Which alternative that is used may depend on the interfaces used, and a combination of alternatives can also be used. For example, if a dedicated connection such as a USB port is used between the key device 100 and the proxy device 300, and a Bluetooth ® 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 with the proxy identifier PD_ID when sending information to the lock device 140, but to forward the lock device identifier LD ID instead of the proxy device identifier PD ID when communicating with the key device 100.

Identifiers for the various devices may be identical to, generated from or related to for example their Bluetooth ® addresses. Particularly for key devices in the form of mobile phones not having a Bluetooth ® interface, an International Mobile Equipment Identifier (IMEI) or an International Mobile Subscriber Identifier (EVISI) can be used as KD ID.

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

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 2 access. 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. In an initial step 610 in Figure 6 A, the operations required to cause the lock device 140 to identify the proxy device 300 and/or the key device 100 are comparable to step 210 and step 220 in Figure 2. In step 620, the lock device 140 requests data from the proxy device 300 by prompting the proxy device 300 to supply a ΡΓΝ code for the key device 100. As has been discussed above, the communication between the proxy device and the lock device can be achieved in a number of ways with regards to which identifier that should be used. In the examples below, it will be assumed that the first alternative of substituting the key device identifier with the proxy device identifier is used. In Figs 6A-C the messages sent will be indicated as a data field where the header is the identifier for the recipient and the tail is the identifier for the sender. The message format may not have the same structure in a real life implementation, but this model gives 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 direction of the end of the arrow. This illustrates the way in which the message is sent in a more intuitive manner.

In step 620 a message having the header PD ID, the body or payload PINREQ and the tail LD_ID is issued from the lock device 140. The proxy device 300 intercepts the communication in step 630 and adjusts the header and the tail according to one of the three alternatives discussed above. In this example the proxy device identifier PD ID is substituted for the key device identifier KD ID in the header, the lock device identifier LD ID is substituted for the proxy device identifier PD ID in the tail, and the request message is communicated to the key device 100. In step 640 the key device 100 receives the request and processes it, which in this case is a request for the user 2 to enter a PIN code. As the key device 100 receives the PIN code from the user 2, the key device 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 message and forwards the message to the lock device 140 in step 650.

It should be noted that using this notification the message body may need some alterations in step 630 (and possibly 650) to allow the receiving key device 100 to know for which lock device 140 the PIN request is made. As seen in Figure 6A the message body is changed from "PIN REQ" to "PINREQ LD ID" to indicate that the PIN code request emanates from the lock device 140 having the identifier LD_ID.

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

The corresponding messages for the combining addressing alternative are shown in Figure 6C.

Case 2 Adding an identifier to a lock database

Figure 7 A illustrates the case when the key device 100 carries information regarding a new identifier to be added to the access control data in the database LD DB of the lock device 140.

As the key devices 100 are capable of receiving and storing data from the central server 122 or from another administrator 106, a key device 100 can be used to distribute information to lock devices 140. This enables lock devices 140 to be updated without 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 to identify the proxy device 300 and/or the key device 100 are comparable to step 210 and step 220 in Figure 2. In step 720 the proxy device 300 sends a message to the key device 100 that the connection to a specific lock device 140 identified by LD_ID has been successful (message body "CONSUC LD_ID"). The key device 100 then searches its memory 450 in step 730 to see if there is any updated access control data 456 that should be communicated to the lock device 140. If such updated access control data 456 exists in memory 450, a message with the updated data is generated and sent to the proxy 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 140 receives and stores the updated access control data in its database LD DB.

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

The corresponding messages for the combining addressing alternative are shown 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 been stored in the memory 550, and, if so, waits for a two-way connection to be established by 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/or status data (PD ID | LOG DATA | LD ID) to the proxy device 300. The proxy device 300 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 or to another administrator 106. The log and/or status data can contain information on battery 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, if a forbidden or black listed device has attempted to gain access, to mention a few examples. A similar functionality is described in WO 2006/098690.

Case 3 Request issued by lock device

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

In an initial step 810 the operations required to cause the lock device 140 to identify the proxy device 300 and/or the key device 100 are comparable to step 210 and step 220 in Figure 2. In step 820 the lock device 140 issues a request to the proxy device 300. The proxy device 300 intercepts the communication in step 830 and adjusts the header according to one of the three alternatives discussed above. In this example the proxy identifier PD ID is substituted for the key identifier KD ID and the request message is communicated to the key device 100. In step 840 the key device 100 receives the request. To process the request the key device 100 may have to initiate communication with the central server 122 over the mobile telecommunications network 1 10 and send a request to the server 122. The key device 100 receives a response from the server and forwards the response to the proxy device 300. This message is received by the proxy device 300 which forwards the message to the lock device 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 device 140 the request is made. As can be seen in Figure 8A the body "REQ" is adjusted to "REQ LD_ID" to indicate which lock device 140 the request originates from.

The corresponding messages for the forwarding addressing alternative are shown in Figure 8B.

The corresponding messages for the combining addressing alternative are shown in Figure 8C.

As has been noted above, which alternative addressing mode to use may depend on the actual communication interfaces involved, and a combination of addressing alternatives 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 alternative or additional manner of operating the proxy device 300 by enabling it to operate remotely from the key device 100 after an authentication will now be described with reference to figure 9. Figure 9 is a schematic block diagram of an embodiment of the access control system of Figure 1, comprising a proxy device which may interact with both a key device 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.

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

The proxy device is arranged to establish a first connection 14A with a key device 900 (as has been described above, this may be initiated by the user making, for example, 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 to the key device 900 and, in reponse thereto, be authenticated and receive an indication of an authentication time period (ATP) and to store the indication of the authentication time period (ATP). The authentication time period indicates a time period within which the 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 be implemented as a number, possibly time or date formatted, representing the ATP. The proxy device 300 may further be configured to receive other data (such as has been disclosed 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 key device 900. In such an embodiment the wired interface may also be used for charging the proxy device 300.

In one embodiment the ATP is transferred from the key device 900 to the proxy device 300 along with - or as part of- the key device identifier (KD ID). In one embodiment the ATP effectively authenticates the proxy device 300 for use while the ATP is valid.

In one embodiment the processing unit (310) is configured to enter an activate state and start a timer that counts down from the ATP (alternatively, the timer counts up to the ATP), and as the timer is done counting the processing unit (310) is configured to enter 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 and while the proxy device 300 is in an inactive state the LED 376 is unlit. Alternatively, the proxy device comprises one LED (for example green) to indicate an active state and one LED (red) to indicate an inactive state. Alternatively, the LED may be arranged to be flashing in one state.

Additionally, the LED 376 may also be arranged to indicate that the ATP is about to expire, possibly by flashing, thus indicating to a user that any lock-related actions should be taken shortly.

To operate a lock 150 on, for example, a door 152 (through the lock device 140), 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 device 140 depends on the communication technology used, as would be apparent to a skilled person. The user operates the proxy device 300, for example by pressing the unlock button 370a, to cause the lock device 140 to unlock the lock 150 of the door 152. The proxy device 300 determines whether it is in an active state, when the user operates it, and if it is in an active state the proxy device 300 is configured to establish a second connection 14B with the lock device 140. As the second connection 14B is established with the lock device 140, the lock device 140 is caused to operate the lock 150, and possibly to exchange data.

This will now be described in more detail.

As an alternative (or additionally for increased security) to the proxy device determining if it is authenticated, the lock device 140 receives the ATP from the proxy device 300 as the second connection 14B is established and determines whether the ATP is still active or not before reacting to any lock/unlock command issued by the proxy device 300.

As the lock device 140 receives an unlock command from the proxy device 300, it determines the access rights, and if the proxy device 300 is authorized to access the 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 proxy device 300, it determines the access rights of the proxy device 300, and if the proxy device 300 is authorized to access the lock device 140 (and is active) the lock device locks the lock 150 of the door 152.

In one embodiment the lock device 140 may be configured to automatically cause the lock 150 to lock in the absence of a further command within a certain time period after a lock or unlock command.

As the second connection 14B is established, the proxy device 300 and the lock device 140 may be arranged to exchange data (such as log and/or status data, updates to access rights or other data) as has been discussed in the above). This may be effected both when a lock command is communicated and/or when an unlock command is being communicated. The determination of access rights has been disclosed in various embodiments and variants in the above and will not be discussed in further detail in these embodiments referring to Figure 9.

The use of an ATP provides the user with a time period within which he may operate the proxy device 300 to actuate lock device(s) 140. This is beneficial in that the user does not need to carry the key device 900 on his person or keep it nearby at all times when operating the proxy device 300. For example, the key device 900 may be left in a car or at an office. As such, this enables for the key device 900 to be remote from the proxy device 300 during operation of the proxy device 300. This is further beneficial in that one key device 900 may be shared by more than one user, which reduces the cost of an overall lock controlling system. The use of an authenitcation time period also provides increased security in that a user may only access a lock during certain time periods, thereby allowing an operator to control the access even when the key 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 an office 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 proxy devices 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 system server 122, thus effectively forming one unit (as is indicated by the dashed rectangle in Figure 9). In one such embodiment the key (management) device 900 is a software module being operated and executed by the system server 122, wherein the key device 900 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 the key 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, for instance, be any of, or in any range of, 2, 4, 6, 8, 10, 12 and 24 hours. The length of the ATP may be based on a distance between the key device 900 and the lock device 140. The length of the ATP may alternatively 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 a specific 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). In one 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 is authenticated to make. For example, the ATP may indicate that a user is allowed to access a specific door 2 times (possibly within a time period). As the user has accessed the specific door the allowed number of times, the ATP is cleared and the user is thus no longer authenticated to enter that door without further authentication.

According to one aspect of the teachings herein, there is provided a proxy device for use in an access control system which comprises a lock device and a key device, said lock device being operatively connected to a lock and said key device being associated with a user. The proxy device comprises controller means; a proxy device identifier; and at least one short-range communication interface. The controller means is configured for causing said at least one short-range communication interface to establish a first connection with said key device and receive an authentication, possibly including a key device identifier for said key device. The controller means is further configured for causing said at least one short-range communication interface to establish a second connection with said lock device and provide to said lock device an identifier which allows said lock 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 proxy device thereby acts as a device identifier tunnel between said 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 and said 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; and from said proxy device, providing to said lock device an identifier which allows said lock 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 proxy device acts as a device identifier tunnel between said key device and said lock device.

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

One embodiment of such an access control system further includes a key device which comprises controller means, memory means, and short-range communication interface means for communicating with said proxy device. In one embodiment, 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

Returning to Figure 1, a second door 152a is also shown having a lock device 140a. If it should happen that both lock devices 140, 140a are active and detectable at the same time, they may both be detected by the proxy device 300. To enable a user to select the correct door to be opened even when using the limited user interface 370 of the proxy device 300, the locking devices 140, 140a are arranged to receive a wake up input. In one embodiment the wake up input is received as a tactile input, for example a knock or a vibration. In one embodiment the wake up input is received through actuation of a button (not shown) on or connected to the locking device 140, such as a door bell operatively connected to the lock device 140.

In one embodiment the lock device 140 is configured to activate the short range communication interface upon receiving the wake up input. In one alternative or additional embodiment the lock device 140 is configured to accept a connection through the second connection 14B upon receiving the wake up input. A user is thereby able to select a door 152 (and the corresponding lock device 140) by for example (manually) knocking on the door 152 or ringing a door bell. This has the added benefit that any person on the other side of the door 152 will be made aware that a user is about to open the door 152, thereby increasing both the security aspects 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 vibration pattern. The vibration pattern may be generated by a vibrator housed in the key device 100 and/or in the proxy device 300. By associating different lock devices 140, 140a with different vibration patterns a further security aspect is provided as well as a more particular selection scheme. This provides for additional security in that each lock device 140, 140a may be expressly and individually identified for example to be activated.

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

In one embodiment the lock device 140 may be configured to detect a knocking sequence or pattern where a number of knocks is received in a specific rhythm. In one such embodiment the proxy device 300 may be configured to flash the LED to indicate the knocking pattern. The user may thus easily remember and/or learn the correct knocking pattern to be used.

In one embodiment, as has been disclosed above, the lock device 140 is configured to activate its close range communication interface in response to receiving the wake up input. This enables a lock device 140 to save power as it does not need to remain 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 a knocking or vibration pattern, either manually or through the use of a vibrator, on the door 152 or the lock device 140, the user is able to select which door 152 among a plurality of doors should be opened. This solves the problem of identifying which door 152 to open when a plurality of doors 152 are active and in range of the short range communication interface. The knocking or vibration pattern may be arranged to differentiate from normal everyday sounds or tactile events such as a person walking past a door, a door being shut or, for additional security, a normal knock on a door or a turning of a handle.

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

Alternatively and/or additionally, the lock device 140 may be automatically activated (awaken) when the user manually turns a door knob or handle on the (inside of the) door 152.

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

In one example embodiment a first door 152 is a door 152 having a lock device

140 without an external power source. The lock device 140 will then be configured to not be active all the time to save power. A second door 152a is a main entrance having a lock device 140a being connected to an exernal power source (not shown). In this example 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 device 300 to open the main entrance door 152a. As no other lock devices 140 have been activated (awaken) the lock device 140a of the main entrance door 152a is the only one that is detected and thus there is only one choice. As the user enters the building he arrives at an apartment door 152. He activates the apartment door 152, possibly by knocking 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 is still in range of the lock device 140a of the main entrance 152a). The proxy device 300 will now select the higher prioritized apartment door 152 and the user is able to enter the apartment. The proxy device 300 is thus enabled to be operated with a plurality of 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 state or an inactive state. These states may both be assumed while the short range interface is activated. In such an embodiment the lock device 140 is configured to enter the active state when it receives the wake up input. The lock device 140 may be configured to remain in an active state until the second connection is terminated or for a time period. The time period may be for example 5 to 30 seconds. It should be noted that other time periods are also possible and within the scope of the teachings of this application. The lock device 140 is further configured to only establish the second connection if it is in an active state.

This enables a user to select a door 152 from a plurality of doors, all having detectable 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 a vibrator.

In one embodiment the lock devices 140, 140a may be grouped in for example two groups. Each group may have a priority assigned to it to enable a prioritized opening of the doors 152, 152a. In one embodiment the proxy device 300 is configured to receive a long press on the unlock button 370a to open the lock 150 corresponding to a lock device 140a in a first group and to receive a short press on the unlock button 370a to open the lock corresponding to a lock device 140 in a second group. A similar arrangement may be applied to the locking procedure. In one such embodiment the main entrance 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 proxy device 300.

In one embodiment the doors 152, 152a may be grouped alternatingly in a first and a second group. This provides for an easy manner of ensuring that the correct doors is 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 range for the short range communicaiton interface.

The operation of the access control system according to some of the embodiments disclosed herein will now be further described through five exemplary use cases together describing the operation of a proxy device 300 over a workday.

Use case 1 : Checking out a proxy device

1) A user performs a long-press on the unlock button 370a as the proxy device 300 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 as authentication data, for example an ATP of 8 hours.

5) The LED 376 flashes three times to indicate that the authentication is completed.

6) The key device 900 displays logging information regarding the communication 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 assumes an active state.

8) The user presses (short press) the unlock button 370a.

9) The LED 376 flashes 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 log and/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 of times, for example three times, in a specified rhythm), whereupon the lock device 140 assumes an active state.

13) The user presses (short press) the lock button 370b.

14) The LED 376 flashes to indicate that the lock command has been sent 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 log and/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 flashes to indicate that the unlock command has been sent

19) The proxy device 300 determines that no other lock devices 140a are detected.

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/and or status data and/or updates as disclosed in the above.

Use case 5 : Checking in a proxy device

22) A user performs a long-press on the lock button 370b when the proxy device 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 data and/or status data received in the aforementioned steps 1 1, 16 or 21.

26) The LED 376 is turned off to indicate that it is no longer authenticated. 27) The key device displays logging information regarding the communication and authentication of the proxy device 300.

Alarm button

In one embodiment, where the proxy device has a simple user interface in the form of at least one button 370, wherein at least one button is associated with an alarm function,, the proxy device 300 may be arranged to take advantage of the long range communication capabilities of the key device 100 (i.e. the network interface 430). The processing unit 310 is arranged to detect that the button 370 is depressed and in response thereto cause that an emergency service is contacted, for example by sending a request 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 time, a so-called long press, and in response thereto cause that an emergency service is contacted. In such an embodiment, the proxy device is not required to have a button specifically associated with an alarm function, but the alarm function can be associated with any button(s) 370, such as the lock/unlock button. The request from the proxy device 300 to the key device 100 can be sent via the Bluetooth ® tranceiver 340. The emergency service or emergency service number can either be pre-stored in the key device 100 or it can be communicated with the request. This enables the proxy device 300 to also function as an alarm button by pressing the button 370 to cause a call to an emergency service.

In one embodiment the proxy device 300 or the key device 100 is arranged to send a current location along with the request to contact an emergency service. In one embodiment, where the key device 100 is arranged with a location finding apparatus such as a GPS device, the key device 100 is arranged to retrieve a current position and include this position when contacting the emergency service. In one embodiment the proxy device 300 or key device 100 is arranged to extract a current position from the identifier of a lock device 140 last communicated with and include this position when contacting the emergency service.

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

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

In one embodiment the key device 100 is arranged to place a call to the emergency service and thereby enable a communication channel between the user and the emergency service. This allows a user to quickly and conventiently contact an emergency service by simply pressing a button. It also enables the emergency service to aquire 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 ELT or EPIRB device commonly known to a skilled person. This allows the emergency service responders to pinpoint the location of the proxy device 300 even if the location provided 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 generating device (not shown) that is activated and sounded as the alarm button 370 is pressed. In an alternative embodiment the processing unit 310 is configured to cause the key device 100 to sound an audible alarm as the alarm button 370 is pressed. This enables the proxy device to act as a close-counter alarm device calling the attention of any persons standing nearby when the button 370 is pressed.

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

It should be noted that although various functionalities and characteristics of the manner of an access control system has been disclosed in different sections of the detailed specification, it should be understood that the embodiments are intended to be combined across the sections herein according to a designer's requirements.

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