WO2022096870A1

WO2022096870A1 - Augmented access control system

Info

Publication number: WO2022096870A1
Application number: PCT/GB2021/052845
Authority: WO
Inventors: Christian HOPKINS; Matthew Weeks; Steve MELEKA
Original assignee: Tio Point Ltd
Priority date: 2020-11-03
Filing date: 2021-11-03
Publication date: 2022-05-12
Also published as: GB202017409D0; GB2600696B; GB2600696A

Abstract

The present techniques relate to a method and access control system for controlling access using two factor authentication, and in particular a sanitiser system for providing one factor in the authentication process. The method comprises determining that a user has been authenticated in response to a user attempt to gain access through the access point and detecting that a user has activated a sanitiser. In response to detecting that the user has activated the sanitiser, obtaining an activation code for the access point and transmitting the activation code to an access controller whereby the access controller is able to use the activation code to obtain an approval message which determines whether access through the access point is granted.

Description

Augmented Access Control System

Field

[0001] The present techniques relate to a method and access control system for controlling access using two factor authentication, and in particular a sanitiser system for providing one factor in the authentication process.

Background

[0002] Controlling access to buildings or locations within buildings is often used in settings such as hospitals or medical clinics. Access may be controlled based on the identity of the user. Two factor authentication is a long established mechanism to verify the identity of a user trying to gain access to a system, service or property. Typically, two factor authentication requires the presence of more than one form of identity, e.g. a security badge, personal identification number (PIN), text message and/or dongle. As illustrated in the table below, each of these types of identification has strengths and weaknesses. Accordingly, ideally of more than one type is used in two factor authentication, because it becomes increasingly difficult to compromise multiple forms of identity verification. Requiring a combination of any of the two methods of authentication in the table below gives a greatly increased level of authentication over a system requiring just one.

[0003] Access may also be controlled based on whether a user has sanitised their hands. For example, GB2469482 and GB2458118 both describe a door lock which is controlled by a dispenser unit. US2007/222554 describes a hand cleaning apparatus which dispense passes which are used for access control within medical facilities.

[0004] The present applicant has recognised the need for a new technique for access control which facilitates checking that sanitisation by a user has occurred. Summary

[0005] According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

[0006] We describe apparatus in the form of a sanitiser system for an access control system controlling access through an access point. The sanitiser system comprises a sanitiser and a processor which is connectable to an access controller having an access interface which is configured to release the access point on receipt of an approval message which grants access through the access point. The processor is configured to determine that a user has been authenticated in response to a user attempt to gain access through the access point; detect that the user has activated the sanitiser; in response to detecting that the user has activated the sanitiser, obtain an activation code for the access point; and transmit the activation code to the access controller whereby the access controller is able to use the activation code to obtain an approval message, e.g. from an authentication server.

[0007] We also describe a method of controlling access through an access point, the method comprising determining that a user has been authenticated in response to a user attempt to gain access through the access point; detecting that a user has activated a sanitiser; in response to detecting that the user has activated the sanitiser, obtaining an activation code for the access point; and transmitting the activation code to an access controller whereby the access controller is able to use the activation code to obtain an approval message which determines whether access through the access point is granted.

[0008] We also describe a system comprising the sanitiser system above and an access controller which is connected to the sanitiser system and which has an access interface which is configured to release the access point in response to an approval message granting access through the access point.

[0009] As explained in more detail below, both the activation code obtained in response to activation of the sanitiser and a user identifier used in determining that a user has been authenticated may be used to determine whether to issue an approval message granting access through the access point. The approval message may be obtained from an authentication server or within the access controller and both the activation code and the user identifier may be used for obtaining approval to gain access through an access point. Such two factor authentication by the authentication server (or the access controller) may be a standard process. The use of activation code and user identifiers to grant access through an access point may also use standard techniques. Accordingly, the sanitiser system may be retrofitted to existing access control systems at access points by reprogramming the sanitiser system or otherwise adapting and reusing a known access interface. In particular, the access control system adapts two factor authentication to include a first factor (activation code) which is obtained in response to activation of a sanitiser, i.e. in response to identifying an act has happened and a second factor (user identifier) which identifies the user. As set out above, the sanitiser system obtains the activation code in response to detecting that the hand sanitiser is activated and this step may be done in response to the sanitiser system determining that the user is identified correctly and hence authenticated.

[0010] The following features apply to both the method and the systems.

[0011] The user identifier may be any suitable identification information, e.g. an identification number, a token ID, a personal identification number, a secret or a combination of these. One or all of the user identifiers may uniquely identify the user. The activation code may be a code which is associated with the access point. The code may be unique to the access point or may represent a plurality of access points, e.g. access points within a zone.

[0012] The sanitiser system may comprise memory or may be connected to memory which is remote from the sanitiser system and which is accessed via a network. The activation code may be stored within the memory and the activation code may be obtained from the memory. The sanitiser system may be connectable to a server (or another computing device) to allow the memory to be reprogrammed with the activation code(s) which are associated with the access point. This is another way in which the sanitiser system can be adapted or retrofitted to an existing system. The activation of the sanitiser thus generates an activation code. This activation code may be the same as an access code which would ordinarily be input using a keypad, and in this case the sanitiser may be considered to be virtualising such a keypad.

[0013] The sanitiser system may further comprise at least one pair of open collector buffers which are connected between the processor and the access interface of the access controller. The processor may be configured to send the activation code to the access interface via the pair of open collector buffers. The use of such open collector buffers may reduce the risks associated with high voltages on the clock and data. The processor may be configured to send the activation code as a series of multiple bit words between a header and footer which contain synchronisation information. When there is a falling edge on a signal to the open collector clock buffer, the processor may sample a signal on the data buffer to send the activation code.

[0014] The processor may determine that the user has been authenticated by receiving a message from the access interface. Alternatively, the processor may receive an input from a detector which detects an identification attempt by the user. For example, the access interface may comprise a visual indicator which indicates whether an identification attempt has been successful. The detector may detect a visual indicator on the access interface, e.g. a green LED may be lit in response to a positive authentication of the user. As noted above, authentication of the user is based on the user identifier(s) which are received in the identification attempt. The step of obtaining an activation code for the access point may be dependent on authentication of the user. In other words, the activation code may only be issued in response to the user being authenticated. Alternatively, the activation code may be obtained regardless of whether the user is authenticated but obtaining the approval message may be dependent on both the user identifier and the activation code. [0015] The processor may be configured to detect that the user has activated a hand sanitiser by receiving a signal from a microswitch, e.g. on a pump on the sanitiser. Alternatively, a signal may be received from an accelerator on the sanitiser. Vibrations may also be detected to detect that activation has occurred. The processor may also determine that activation has occurred within a prescribed time period after the user has attempted to gain access through the access point. The sanitiser may be adjacent the access point and the prescribed time period may be sufficient to allow activation and sanitisation just after a user identifies themselves to the access interface, e.g. a time period of approximately 30 seconds.

[0016] The processor may be configured to record a time when activation of the hand sanitiser is detected and transmit the time to the access controller which may then transmit the time to the authentication server.

[0017] We also describe an access control system comprising the sanitiser system described above. The access control system may also comprises an access controller which is connected to the sanitiser system and which has an access interface which is configured to release the access point on receipt of an approval message. The access controller may comprise a processor which is configured to receive a user identifier from the access interface; transmit the user identifier to an authentication server; and receive an authentication message from the authentication server indicating whether the user is authenticated. The user identifier may be received after detecting an attempt by a user to identify themselves, e.g. by presenting a security badge, an ID card or other token to the access interface or by typing in a PIN or other code.

[0018] The authentication message may indicate that that the user is authenticated. The sanitiser system may then be operated as described above. Alternatively, the authentication may indicate that the user is not authenticated. When a user is not authenticated, access may be denied and the sanitiser system may not then be operated to obtain the activation code. In response to the authentication message, the access controller may be configured to provide a visual indicator indicating whether the user is authenticated. For example, the visual indicator may be a red LED when not authenticated and a green LED when authenticated. Any suitable visual indicator may be used.

[0019] When the user is authenticated successfully, the processor of the access controller may be further configured to receive the activation code from the sanitiser system; transmit the activation code to the authentication server; and receive an approval message from the authentication server indicating whether the user is approved to gain access through the access point. In other words, the access controller may contact the authentication server twice, once to determine whether the user identification is correct and a second time to determine whether the authenticated user is granted access. It will be appreciated that the contact may be carried out at separate sequential times or simultaneously.

[0020] Alternatively, the access controller may be configured to internally determine whether the user is authenticated and/or granted access, e.g. by locally caching access policies. For example, the processor of the access controller may be configured to receive a user identifier from the access interface; and authenticate the user identifier by comparing the received user identifier(s) with those in a cache on the access controller. When there is a match with stored information, the user may be authenticated. The processor of the access controller may be configured to receive the activation code from the sanitiser system and determine, using the received activation code, whether the user is approved to gain access through the access point. For example, the processor may be configured to obtain the approval message by comparing the received activation code to locally cached access policies. The access controller may comprise a cache which stores access policies which specify rules which must be met if a user is to be approved for access through the access point; and the processor is configured to compare the received user identifier and activation code to the stored access policies; and determine whether to issue an approval message which grants access through the access point or which denies access through the access point.

[0021] The system may further comprise an authentication server for authenticating and/or granting access to the user using the information received from the access controller. The authentication server may store access policies which determine whether a user’s request to gain access is to be approved. The access policies may specify a set of rules which must be met if a user is to be approved for access through the access point. For example, the policies may define one or more of who, when (e.g. at what times of day), where (e.g. through which access point(s)) and how (e.g. any other restrictions such as prescribed time periods) may be granted access. For example, if both a user identifier and activation code are required, the authentication server may comprise a database comprising a plurality of user identifiers and activation codes. The authentication server may be configured to determine whether to grant access to the user by comparing the user identifier and activation code received from the access controller with the information stored in the database. When there is a match with information stored in the database, the authentication server may issue an approval message indicating that access should be granted. Alternatively, if there is no match, the authentication server may issue an approval message which denies access through the access point.

[0022] The processor of the authentication server may also be configured to receive a user identifier from the access controller; determine whether to authenticate the user based on the received user identifier; and transmit an authentication message to the access controller indicating whether the user is authenticated. More than one user identifier may be received, e.g. a token ID and a PIN. Authentication may be determined by comparing the received user identifier(s) with those in a database. When there is a match with information stored in the database, the authentication server may issue an authentication message indicating that the user is authenticated. Alternatively, if there is no match, the authentication server may issue an authentication message which denies access through the access point.

[0023] Approval of the access request by the user by the authentication server may be based on at least one recorded time together with the user identifier and activation code. The time may be stored in the authentication server. The processor may be configured to determine whether the activation code was obtained within a prescribed time period after the user identifier was obtained. For example, within 30 seconds if the sanitiser system is adjacent or nearby the access interface. Alternatively, the sanitiser system may be distant from the access point, e.g. adjacent another access point. The time period may be longer and may be based on an acceptable time for regular sanitisation cycles, e.g. an hour. In other words, a user may be able to pass through a second or additional access points without the need to sanitise again provided the prescribed period has not elapsed. This may allow movement within zones or around a building.

[0024] The release of the access point may be limited to a predefined time period, e.g. a few (perhaps 5) seconds, which is sufficient to allow the user through the access point.

[0025] Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

Brief description of drawings

[0026] For a better understanding of the present techniques, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which:

[0027] Figure 1 is a schematic diagram of the system adjacent an access point;

[0028] Figure 2 is a schematic block diagram of the system of Figure 1 ;

[0029] Figure 3 is a schematic block diagram of the sanitiser system in the system of Figure 1 ;

[0030] Figure 4 is a flow chart of a method carried out by the system; and

[0031] Figure 5 is an illustration of data which is transmitted within the system.

Detailed description of drawings

[0032] Figure 1 illustrates an access control system for an access point 12, e.g. a door to a building or room within a building. The access control system controls access by use of an access controller which implements a two factor authentication process which includes identity authentication and an action based authentication. It will be appreciated that the access point 12 may be any suitable entrance or exit, including for example a door, barrier or turnstile. Access may only be granted if a user identifies themselves to the system using the access interface 16 (the identification factor in the authentication process) and uses the hand sanitiser 14 (the task based factor in the authentication process) within a permitted time frame. In other words, only authorised people who have sanitised their hands are allowed access.

[0033] The identification access interface 16 may be any standard interface by which a user may request entry (or exit) using an access device, e.g. a token reader and/or a key pad for entering a personal identification number (PIN) or text message and/or a dongle reader. A token reader may generate a token ID when a token (e.g. a physical object such as a security badge, card, key fob) is presented to the reader. The token ID is a unique identification number which is pre-registered to the access control system and assigned to a unique user. A key pad is a type of access device which accepts a PIN or an access code and sends it to the access controller. A PIN is typically a 4 or 8 digit decimal number which is unique and preregistered to just one user and pre-registered with the system. The access code is a number associated with the access controller (and hence the access point) to release the access point. The access code may also be a 4 or 8 digit decimal number and is typically known by many users.

[0034] Only one form of identification may be required or two forms of identification, e.g. a token and a pin, may be required. A visual indicator, e.g. one or more lights such as red, green and/or amber LEDs, may be provided on the access interface 16 to illustrate that a user has successfully identified themselves to the access interface 16. The hand sanitiser 14 may be any suitable device or equipment which dispenses sanitising fluid or is used to clean a user’s hand. The hand sanitiser 14 may be part of a sanitiser system 14 which may also verify that the action or process of sanitising or cleaning has been completed to satisfaction and is within acceptable limits. As explained in more detail below, the sanitiser system stores an activation code which is presented to the access controller on activation of the sanitiser. The activation code may be a 4 or 8 digit number and may be the same as the access code.

[0035] Figure 2 is a schematic block diagram illustrating a possible implementation of the access control system of Figure 1 in which the components are connected and configured to provide security. The system 10 comprises an authentication server 20, an access controller 30, and a client server 40 which are all connected together via a network 44. The client server 40 may be remote from, i.e. in a different location to both the authentication server and the access controller 30. The network connection may be via any suitable network, e.g. WiFi, Bluetooth or a wired network. The system 10 also comprises a sanitiser system 50 which is connected to the access controller 30. The various elements of the system are described in more detail below and it will be appreciated that this is just one possible arrangement of the functionality and the functions may be combined into fewer separate components. As explained in more detail below, a possible advantage of the described arrangement is that it may more easily be added to existing systems which may have an authentication server and an access controller.

[0036] The authentication server 20 and the client server 40 may be any suitable computing device and may have the typical components associated with such computing devices, which include for example a processor 28, 42 as illustrated. The authentication server 20 may be used to authenticate the user who is attempting to gain access through the access point. The authentication server may contain databases and may receive and respond to authentication requests from the access controller 30. The client server 40 may be used to manage access for the user by managing user identifiers, credentials and/or access permissions. The user identifiers and credentials which are associated with a particular access point may be set in the client server 40 and sent to the authentication server 20. There may also be caching of information on the access controller to improve speed of access.

[0037] Access interfaces using authentication to open an access point are known. Such access interfaces are typically controlled by an access controller which is equipment that takes in user identifiers (e.g. tokens, PINs, access codes) and communicates with the authentication server to release the access point. The addition of the sanitiser system may be considered to be introducing a non-identity factor of authentication (NIFA) to known identity authentication systems. This may be achieved by using a sanitiser system 50 which presents itself to the access controller 30 as a PIN pad and thus transmits an activation code to the access controller. For example, the sanitiser system comprises a processor 52 for generating the activation code or accessing the activation code from memory as described below. PIN pads are commonly used in building control systems as a second factor of identity authentication alongside an access card reader or the like and access control systems may already use a combination of PIN and access token.

[0038] The sanitiser system 50 may be retrofitted to an existing system and it may be desirable that any existing access codes associated with the access controller 30 remain unchanged. Accordingly, it may be necessary to program the sanitiser system 50 so that the processor 52 is able to generate an activation code which corresponds to the required access code which is associated with the access point. This may be achieved, for example, by connecting the sanitiser system 50 to a host computer (not shown) for the necessary reprogramming. The host computer may be any suitable electronic or computing device and may be remote from, i.e. in a different location, or more normally local to the access controller and/or sanitiser system to provide a user interface to allow reprogramming as required.

[0039] The authentication server 20 comprises at least one database for confirming the identity of the user seeking to gain access through the access point (i.e. to authenticate the user) and at least one database storing any access policies which are associated with the access point and which determine whether an access point should be released. In this arrangement, the at least one database comprises a user database 22, a location database 24 and an event database 26. Examples of the data held in each database are set out in the tables below but it will be appreciated that other arrangements are possible. For example, the valid user database 22 may contain information to verify the identity of the user, e.g. the values associated with a user token, e.g. card, and an associated personal identification number (PIN) if one exists.

User database:

[0040] The location database 22 may comprise information which specifies the authentication or access information which is required for different access points, i.e. the access policies or rules. Example policies are shown in the table below:

[0041] For example, as shown in the table below, the front door into a particular location may be opened with any one of the factors, e.g. by using a token or by entering a PIN associated with the token or by entering the access code associated with the access point. In a standard system, both the PIN and access code may be generated by a user on the PIN pad, but in this augmented system the access code may also be generated as an activation code by use of the hand sanitiser as explained below. Accordingly, a user may gain access through the front door by presenting their token, entering their PIN/access code or activating the hand sanitiser to generate the activation code as described in more detail below. Thus, there is no requirement for sanitisation as well as identification - one or the other is sufficient.

[0042] Other locations may require both sanitisation and identification. In this example, the back door may be opened by using two factors, e.g. a token together with an activation code. Accordingly, a user may gain access through the back door by presenting their token and activating the hand sanitiser to generate the associated activation code. Finally, merely as a third example, the side door may be opened by using three factors, namely a token, a pin and an activation code. Accordingly, a user may gain access through the side door by presenting their token, typing in their PIN and activating the hand sanitiser to generate the activation code.

Location database (Access Policies):

[0043] The event database 26 may store information specific to individual users and the times at which they gained access via different access points. Both successful and unsuccessful attempts to gain access may be logged. For example,

Events database:

[0044] The access controller 30 may have an access interface 34 such as the one shown in Figure 1 which may be configured to receive inputs from a variety of access devices, including a token reader and a keypad (or the like). Such interfaces are typically used on entrances and may thus be termed entrance interfaces. The entrance interface of Figure 2 may also receive inputs from the sanitiser system 50 which as explained below is also behaving as an access device, i.e. equipment which connects to the access interface of the access controller.

[0045] The access controller 32 may also have access interfaces (not shown) for controlling access through the access point in the opposite direction to the entrance interface. Such an access interface may be termed an exit interface and may be same as the entrance interface, e.g. receives inputs from a token reader with/without a keypad together with an input from the sanitiser. However, it is possible that sanitisation may not be required on exiting and thus only inputs from a token reader with/without a keypad may be required to open the access point using the exit interface. Alternatively, the exit interface may comprise a door release button or a pin pad to input an access code associated with the door whereby a user can exit through the access point without confirming their identity. One or both of the entrance and exit interfaces may be termed access interfaces.

[0046] Additional details of one possible implementation of the sanitiser system are shown in Figure 3. For example, the sanitiser system 50 may comprise a micro controller 140 (or processor - the terms may be used interchangeably) which is configured to execute custom firmware 142 to implement the system described.

[0047] In this arrangement, the microcontroller 140 has four output pins each of which are connected to one of four external open collector buffers 144, 146, 154, 156. The four buffers form two pairs of buffers with a first buffer 144, 154 in each pair driving a clock interface and a second buffer 146, 156 in each pair driving a data interface. The first pair of buffers 144, 146 are connected to a first access interface 32 (for example an entrance interface of an access controller) and the second pair of buffers 154, 156 are connected to a second access interface 34 (for example the exit interface of an access controller). It will be appreciated that many microcontrollers are capable of driving output pins in open collector mode but it is possible that the voltages on the clock and data lines may rise to a level that may permanently damage the microcontroller. Thus, the use of buffers as described may be beneficial. [0048] The microcontroller 140 also receives inputs via input buffers 162, 164. One input may be received via input buffer 162 from a detector which is used to detect activation of the sanitiser and may be in the form of a circuit. For example, the circuit may detect activation, e.g. using a microswitch, accelerometer or vibration sensor, and generate an activation code. Another input may be received via input buffer 164 from a detector which is used to detect or receive a positive identification from the or each access interface. For example, the detector may detect or receive an output of the visual indicator (e.g. red, amber and green LEDs) associated with the entrance and/or exit interfaces. The visual indicator may be used to determine whether an ID token has been presented, rejected or accepted by the access interface. For example, a flashing red LED may be detected by a detector and this may indicate that the identification of the user is not recognised.

[0049] As summarised in the table below, if sanitisation and correct identification is required to open the access point as set out in the access policies of the authentication server, both inputs must be positive for the access point to be opened. For example:

When the authentication server confirms that the access point may be opened, the access controller may open the entrance or exit interface. The access controller may also cache information which is received from the authentication server whereby the access controller is able to determine whether the access point may be opened based on the information (e.g. user identifier and/or activation code) received at the access controller.

[0050] The sanitiser system 50 may also have an interface 166 which is connectable to a server (host computer) as described in relation to Figure 2. The interface 166 provides a connection which enables the system to be programmed with the activation code which is generated when activation of the sanitiser is detected, e.g. from the input received in buffer 162. When retrofitting the hand sanitiser to an existing system, it is desirable that any existing access codes associated with the access controller remain unchanged and thus the existing access codes must be programmed into the system and this example are stored in the memory 150. The stored access code associated with the access point may thus be generated as the activation code. The memory 150 may be any suitable memory, e.g. nonvolatile memory.

[0051] Figure 4 is a flowchart of the steps which may be carried out by the access control system. The process may be triggered when a user attempts to identify themselves to the access controller at step S100. The user may present a token or other identification (e.g. a biometric identifier) and/or type in a PIN to the access interface of the access controller to identify themselves. The access controller 30 obtains the or each user identifier associated with the attempt by the user to identify themselves at step S102.

[0052] In the next step S104, the access controller authenticates the user identifiers, for example by internally determining whether the user is authenticated or by sending the user identifier(s) to the authentication server. The authentication server then determines whether the user can be authenticated by checking against the policies and/or information stored in its database(s). For example, when the access controller transmits a token ID and a PIN, the authentication server compares the paired ID number and PIN with the paired ID numbers and PINs in the user database to verify that they are a match. The authentication server transmits the results of its determination to the access controller. If the user identification cannot be verified, the reply from the authentication server to the access controller may be access denied as at step S108. If the user identifier(s) are verified but the access point requires an additional factor of authentication based on the action of sanitisation, the process can move onto the steps carried out by the sanitiser system.

[0053] The sanitiser system may detect that there is a successful authentication of the user by receiving an approval message from the authentication server or the access controller. Alternatively, the system may detect that there is a successful authentication of the user based on a visual indication on the access interface. For example, where there is a plurality of LEDS, a green LED may be lit to indicate a successful identification. The next step is for the sanitisation system to detect activation of the sanitiser at step S110. The activation of the sanitiser may need to take place within a prescribed time limit (e.g. a few minutes) after the user ID has been verified.

[0054] After detecting the activation of the sanitiser, the sanitisation system obtains an activation code at step S112. The activation code may be obtained from memory which has been programmed into the sanitiser system. Depending on the set-up, the activation code may be the same as an access code which is a reference number associated with the location of the access point and which could also be typed into the access interface. The sanitiser system will then authenticate the activation code at step S114. For example, the sanitiser system may transmit the activation code to the access controller and the access controller may send the activation code to the authentication server for authentication. Alternatively, the access controller may be configured to internally determine whether the activation code is authenticated.

[0055] When an authentication server is used, the authentication server will then determine whether the user can be granted access based on the received activation code together with the previously received user identifiers. The determination is based on the access polices (who, when, where and how). If there is a positive result, access approval in the form of an approval message is transmitted from the authentication server to the access controller. Alternatively, the access policies may be applied by the access controller to obtain an approval message. Thus, the access controller obtains an approval message at step S120. The access point is then released by the access controller at step S122. The release may be for a prescribed period of time (e.g. a few seconds, minutes or hours) as determined by the policies in the database(s). Once the time frame has expired, movement through other access points, even if within the same building, could be restricted until after the user has sanitised again. In other words, the method may need to loop back to step S110.

[0056] Alternatively, if there is a negative result and the permission to open the access point cannot be granted, access is denied at step S118. Optionally, an alarm (e.g. a visual or an audible alarm) may be triggered to indicate that an attempt to access the access point has been denied. Optionally, it is possible to incorporate an emergency override, e.g. an access code, which allows the access point to be opened regardless of the outcome of the process.

[0057] The release of the access point may apply to a single access point or multiple access points within the same building or zone within a building. Thus, after the access point is released in step S122, a user attempt to gain access through another access point may be detected, e.g. by detecting a user identification attempt as in step S100. If the prescribed period of time has not yet elapsed, the steps of detecting activation of the sanitiser, obtaining the activation code and transmitting the activation code in steps S110 to S114 may not be required and the activation code which was obtained in the previous iteration loop may be used by the authentication server to determine whether to authenticate a user. Thus, the user may move through another access point based on their identification and previously obtained activation code.

[0058] This could be extended further by adding zoning policies so that a user may freely move through one or more access points which are located within a first zone (e.g. Zone A) without sanitising their hands again (provided the prescribed period of time has not elapsed). However, when a user attempts to gain access through an access point in a second zone (e.g. Zone B), the user has to use the sanitising system again. It will be appreciated that there may be multiple zones and one or more access points within each zone. Time and location of the sanitisation thus become additional factors of authentication and these may be stored, e.g. within the memory of the access controller or transferred to the authentication server for storage in an appropriate database.

[0059] The stored data may be used to gain additional insights into the user’s behaviour. For example, identity, events (e.g. sanitisation/access point triggering), location and time may be used to model the user’s behaviour. This may allow threats beyond identity to be tackled. It will be appreciated that other variations are also possible. These are enabled by the ability to pass non-identity factor authentication through standard interfaces into existing access control platforms.

[0060] Figure 5 illustrates the data which may be transmitted from the microcontroller 140 of the sanitiser system 50 to the access interface(s) of the access controller according to a first protocol known as the Wiegand protocol. It will be appreciated that other protocols may be used and that data which is appropriate to the protocol will be transmitted. As described above, the interfaces are connected to open collector buffers and are the interfaces are typically two-wire synchronous serial interfaces comprising a clock and data. This allows multiple devices (e.g. token readers, keypads) to be connected in parallel.

[0061] The data being sent comprises a header with synchronisation bits. The header is followed by a preamble having a fixed value. The activation code data may be sent in the appropriate form, e.g. a seven bit word may have two words which encode the unique key and 5 more words of meta data. Each 5 bit word may comprise 4 bits of a data and a parity bit. Following the data, there may be additional parity data and finally a footer which like the header comprises synchronisation information.

[0062] As illustrated in Figure 5, the format of the data being sent from the sanitiser system to the access controller mirrors the data being obtained from other access devices, e.g. a token reader or a key pad. Thus, there is also a header, a footer, parity data and a preamble. Where the identification is a token ID, the token ID data may be sent in an appropriate format, e.g. a plurality of fixed bit words representing the token ID and any additional words which are needed. For example, an 8 digit token ID may be sent as an eleven 5 bit words with eight words representing the 8-digit token ID and three additional meta-data words. Similarly, where the user identification is a PIN, the PIN data may be sent in the appropriate form, e.g. a seven bit word may have two words which encode the unique key and 5 more words of meta data. Each 5 bit word may comprise 4 bits of a data and a parity bit.

[0063] As shown in Figure 5, data transmission across the interface takes place when there is a falling edge on the open collector clock signal. The access controller uses this falling edge to sample the data signal. The access controller may use the falling edge to sample the data signal. The data may be transmitted as a series of data words of appropriate length, e.g. 4 bits plus an even parity bit.

[0064] Clearly there are many benefits to the method and system described above in infection sensitive environments such as hospitals and care homes but also more generally in other settings such as workplaces or homes now that Covid-19 poses a long term threat. In this scenario, it may be as important to keep out unwanted people as it is to ensure that the authorised personnel adhere to hygiene policy.

[0065] At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object- oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements.

[0066] Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others.

[0067] Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

[0068] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0069] The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

[0070] With so much identity infrastructure deployed and managed, adding additional NIFA to an existing authentication system could easily become proprietary, cumbersome and hard to manage. In the worst case scenario, a security “bolt-on” may even undermine the overall efficacy of the system by introducing unexpected loopholes or corner cases. The augmented system approve allows an NIFA to be added to an existing deployed system and can use established hardware interfaces, signalling, data and object types. Such an augmentation should ideally be able to feed seamlessly into the policies, process and management platform of the existing, host system. Moreover, for ease of integration and to accelerate uptake, a monitored hand sanitiser should be quick and simple to retrofit to the existing system.

Claims

1. A sanitiser system for an access control system controlling access through an access point, the sanitiser system comprising a sanitiser; and a processor which is connectable to an access controller having an access interface which is configured to release the access point on receipt of an approval message which grants access through the access point; wherein the processor is configured to determine that a user has been authenticated in response to a user attempt to gain access through the access point; detect that the user has activated the sanitiser; in response to detecting that the user has activated the sanitiser, obtain an activation code for the access point; transmit the activation code to the access controller whereby the access controller is able to use the activation code to obtain an approval message.

2. The sanitiser system of claim 1 , further comprising memory and the activation code is stored within the memory.

3. The sanitiser system of claim 2, wherein the sanitiser system is connectable to a server to allow the memory to be reprogrammed with the activation code associated with the access point.

4. The sanitiser system of any one of the preceding claims, comprising a pair of open collector buffers which are connected to the access interface of the access controller and wherein the processor is configured to send the activation code to the access interface via the pair of open collector buffers.

5. The sanitiser system of claim 4, wherein the pair of open collector buffers comprises a clock buffer and a data buffer.

6. The sanitiser system of claim 4 or claim 5, wherein the processor is configured to send the activation code as a series of multiple bit words between a header and footer which contain synchronisation information.

7. The sanitiser system of any one of the preceding claims, wherein the processor is configured to determine that a user has been authenticated by detecting a visual indicator on the access interface.

8. The sanitiser system of any one of the preceding claims, wherein the processor is configured to detect that the user has activated the sanitiser by receiving a signal from a microswitch.

9. A system comprising the sanitiser system of any one of the preceding claims; and an access controller which is connected to the sanitiser system and which has an access interface which is configured to release the access point on receipt of an approval message.

10. The system of claim 9, wherein the access controller comprises a processor which is configured to receive a user identifier from the access interface; and authenticate a user using the user identifier.

11 . The system of claim 10, wherein the processor of the access controller is configured to authenticate the user by transmitting the user identifier to an authentication server; and receiving an authentication message from the authentication server indicating whether the user is authenticated.

12. The system of claim 9 or 10, wherein, in response to authentication of the user, the access controller is configured to provide a visual indicator indicating whether the user is authenticated.

13. The system of any one of claims 9 to 12, wherein the processor of the access controller is further configured to receive the activation code from the sanitiser system; and obtain an approval message for the received activation code.

14. The system of claim 13, wherein the access controller is configured to obtain the approval message by transmitting the activation code to an authentication server; and receiving the approval message from the authentication server indicating whether the user is approved to gain access through the access point.

15. The system of claim 13, wherein the processor of the access controller is configured to obtain the approval message by comparing the received activation code to locally cached access policies. 18

16. The system of claim 13 when dependent on claim 10 or claim 11 , wherein the processor of the access controller is configured to obtain the approval message by comparing the received user identifier and the received activation code to locally cached access policies.

17. The system of claim 13 when dependent on claim 10 or claim 11 , further comprising an authentication server connected to the access controller and wherein the authentication server comprises a memory which stores access policies which specify rules which must be met if a user is to be approved for access through the access point; and a processor which is configured to compare the received user identifier and activation code to the stored access policies; and determine whether to issue an approval message which grants access through the access point or which denies access through the access point.

18. The system of claim 17, wherein the processor of the authentication server is configured to receive a user identifier from the access controller; determine whether to authenticate the user based on the received user identifier; and transmit an authentication message to the access controller indicating whether the user is authenticated.

19. The system of claim 17 or claim 18, wherein the processor of the authentication server is configured to determine whether that the activation code was obtained within a prescribed time period after the user identifier was obtained.

20. A method of controlling access through an access point, the method comprising determining that a user has been authenticated in response to a user attempt to gain access through the access point; detecting that a user has activated a sanitiser; in response to detecting that the user has activated the sanitiser, obtaining an activation code for the access point; and transmitting the activation code to an access controller whereby the access controller is able to use the activation code to obtain an approval message which determines whether access through the access point is granted.