Field of the invention

The present invention relates to a secure access system which maintains records of individuals who have attempted to access location protected by the secure access system.

Background of the invention

It is well known to provide access to a secure facility using a door equipped with a lock mechanism under the control of a security device. The security device may, for example, be a keypad for receiving a secret passcode. The passcode is compared with a list of one or more passcodes stored in a memory (either located within the security device, or at a remote server which is in communication with the security device) and in case of a match, the security device controls the lock mechanism to enable the door to be opened. Instead of a keypad, it is known to provide a biometric sensor, such as a finger- or hand-print sensor, or a camera, which may be a still camera or video-camera, for capturing imaging from which a user's identity can be automatically identified. Alternatively, it is known to provide an RFID contact or contact-less smart card, or other wireless token to be carried by the user. Data captured by the biometric sensor and/or camera and/or from the wireless token is compared with a library (again stored in the security device itself of the remote server), and in case of a match, the security device controls the lock mechanism to permit the door to be opened. In such systems it is known for the security device or remote server to maintain records of "access events ^' " in which users interact with the security device to attempt to gain access to the secure facility, for example a record of which individuals did so and at what times. Frequently, the door and security device are in a location which is also under view by a surveillance system, such as a video camera.

Summary of the invention The present invention aims to provide a new and useful secure, authentication access system.

In general terms, a first aspect of the invention proposes that a secure authentication access system includes one or more security devices which selectively permit opening of one or more door(s), and one or more cameras, preferably video cameras. Each security device is associated with one or more of the cameras. Upon an access attempt (whether successful or not), an access event (as defined below) occurs which is synchronized with at least one image taken by at least one of the cameras, such as the real time video stream. A record (e.g. at a central server) of the access attempt is created, which is uniquely associated with at least one image (e.g. a synchronized real time video stream) at or near the time of the authentication event, together with index data characterizing the access attempt. The records can be associated with the images by actually including the images, or by including data which indicates the location of the images within one or more . databases of images captured by the cameras. Thus, in either case the record is usable to access the corresponding image(s).

A first type of access event is an event in which an individual interacts with one of the security devices to try to gain access to the facility. In this case, the portion of video footage may be stored in association with index data such as the time of the access event, data registered by the security device (e.g. the data received from the user to try to gain access) and/or an identity of the individual who triggered the access event (which may be derived from the data registered by the security device).

A second type of access event is an event in which the presence of an individual is detected in a location which is expected to be within the field of view of one of the video cameras, irrespective of whether the individual interacts with the associated secunty device. The presence of the individual may be detected using a form of a sensor capable of detecting human presence (motion sensor, infra-red, laser, etc), or a wireless device associated with the security device for detecting the presence of a wireless token. In fact, the video camera(s) may be used as motion detector(s) by detecting motion from the output of the video camera(s). The index data in this case may just be the time of the access event.

Thus, in either case, the access event is associated with one or more of the video cameras: either because it involves the security device associated with one of the video cameras, or/and one of the wireless devices for wirelessly detecting a token, or because it is expected to be due to the presence of an individual within the field of view of one of the cameras. Note that certain embodiments of the invention may be reactive to only one of the two types of access event.

Thus, as multiple access events occur, a database is built up including sections of video footage associated with the respective access events, and the associated index data. This database can be searched using the index data, so as to find the associated video footage. This makes it possible to avoid a problem of some currently known systems, that large amounts of video footage are shot (typically by a security camera which is not a portion of the secure access system), and it is time-consuming to find the footage corresponding to a given access event.

The portion of video footage may include a period before the access event (e.g. 30 seconds before), the period in which the access event occurs and/or a period (e.g. one minute) after the access event.

Optionally, the video camera and secure device are both connected to a remote server which includes the data storage device which the portions of video footage and the index data are collected. The video camera may collect video footage continually, or it may be triggered by the access event. Similarly, the remote server may receive the video footage continuously, or at times depending on the times of corresponding access events.

In cases in which the remote server receives the video footage continuously, it may either store all the video footage, while labeling portions of the footage which are associated with access events with any index data describing those access events. Alternatively, the only portions of the video footage stored by the server may be the portions of the video footage associated with corresponding access events. In the latter case, each portion of the video footage is labeled with any index data describing the corresponding access event.

Typically, the secure access system includes not just one security device, but a plurality of them, each associated with at least one corresponding video camera for recording video footage of a location in which the security device is located. Typically, the field of view of the video camera includes a location in which an individual stands when interacting with the security device, but it may alternatively or additionally show a location including or proximate the door to which the security device grants access and/or a portion of the secure facility to which an individual gains access via the door.

The security device may comprise any one or more of the following data input devices: a biometric sensor (which may be a finger- or hand-print, or vein- or sub-veinous, or iris or facial (or other anatomical) sensor; or indeed any other form of biometric sensor); a camera (which may be the same camera which records the footage, or a different camera; in the latter case, it may be either a video camera or a still camera); or a reader for communicating a security token, such as a smartcard or a RFID keycard or other wireless devices carried by an individual. In all these cases, the security device registers this data. The process by which access is selectively granted based on this registered data may be performed at the security device or at the server. As noted above, the registered data may be included in the index data, or data derived from the registered data may be included in the index data. For example, in the case that the biometric sensor is a facial (or other anatomical) recognition sensor, the index data may include data indicating the identity of the individual whose face or other anatomical feature has been recognized.

The secure access system may employ a people counting algorithm, which produces a measure of the number of individuals passing through the door(s) during the access event. This data can be stored as part of the index data. The security device may optionally contain other sensor devices which are used by the security device in determining whether an access event has occurred and/or whether to permit opening of at least one of the door(s) . These devices may include any an audio sensor, a heat sensor, a humidity sensor, a vibration sensor, a shock sensor, and a smoke sensor, or indeed any other suitable sensor.

A particularly interesting possibility is that the security device includes a heat sensor for making a measurement of the body temperature of a user. This possibility would permit the security device to determine if the user has a raised body temperature, and in this case to deny opening of the door. This possibility may be of particular interest, for example, during an epidemic of a dangerous disease, in which there is a significant risk that a raised body temperature is associated with the dangerous disease (rather than a less dangerous disease, such as a common cold) .

The concept of a secure access S3'stem which permits or denies access using an algorithm which employs (among other factors) the body temperature of a user provides a second, independent aspect of the invention which is freely combinable with the first aspect.

In many embodiments, the "door" of the system is a portal through which the individual may pass when permitted by the security device. However, embodiments of the invention are also possible in which the door is the door of a safe in which items may be stored. The present security system may also be used to selectively grant access to equipment, such as a computer system.

Brief description of the figures

Embodiments of the invention will now be described for the sake of example only with reference to the accompanying drawings, in which:

Fig. 1 shows a schematic view of a secure access system which is an embodiment of the invention; Fig. 2 shows a graphical user interface of a server which is an element of the embodiment of Fig. 1 ; and

Fig. 3 shows a flow-chart for the operation of a unit of the secure access system of

Fig. 1.

Detailed description of the embodiments

Referring to Fig. 1, an embodiment of the invention is illustrated. The embodiment includes a server 1 for recording data concerning access to a plurality of doors 3. The server 1 is connected over a communication network (which may included tangible communication channels such as wires and/or wireless communication channels) with a plurality of secunty stations 2 associated with the respective doors 3. The security stations 2 may have identical construction.

The internal structure of one of the security stations 2 is shown. The security station 2 includes a security device 21 for controlling a lock device 23. The security station 2 further includes a video camera 22. arranged so that its field of view includes a location proximate or including the corresponding security device 21 and/or the corresponding door 3. Conceivably a single video camera 22 might be shared by multiple ones of the security stations 2. if those security stations 2 happen to be close to each other.

The security device 21 may be of a known form. It includes a camera 211 (which may be a still or video camera) for taking a picture of an individual (a "user") interacting with the security device 21. The camera 21 1 is shown as internal to the security device but it may alternatively be external. Particularly if it is external, it may include a data storage device. The security device 21 further includes a biometric sensor 212, such as a finger- or handprint, or vein- or sub-veinous. or iris or facial or other forms of biometrics sensor. It further includes a reader 213 for communicating with a security token (not shown) carried by the user. For example, the security token may be a security card, such as a contact or contactless smartcard or RFID security card (some RFID cards count as smartcards), and the reader 213 may be an RFID reader for receiving an ID code from the security card. Alternatively, the reader 213 may be a reader for a security token of a sort which requires physical contact with the device 213. The security device 21 further includes a keypad 214 for registering key-presses made by a user. The keypad may have any number of keys, for example 10 keys corresponding to the digits 0 to 9, or even be a full QUERTY keyboard. The camera 211, biometrics sensor 212, reader 213 and keypad

214 are arranged to transmit the data they register to a control device 215 which is in two- way communication with the server 1. Other sensors such as smoke, or audio or heat, or humidity, or pressure or vibration sensors when detecting such signal can also trigger the beginning of the recording, or open or close the door and audio alarm. The control device

215 is arranged to control the corresponding lock device 23, so as to grant access to the corresponding door 3. Optionally, the security device may include any one or more additional sensors such as: an audio sensor, a heat sensor, a humidity sensor, a vibration sensor, a shock sensor, a smoke sensor, etc. Of these, only a heat sensor 216 is shown in Fig. 1. Its operation is explained below.

A user accesses a secure region via the door 3 by interacting with the security device 21 in a first type of access event. During this process the control device 215 registers data transmitted by the user to the control device 215 using one or more of the camera 211, biometrics sensor 212, reader 213 or keypad 214. In one possibility, the control device 215 is enabled to compare the registered data with a library of data of security

information relating to multiple authorized users, and upon detecting a match, to operate the lock device 23 to unlock the door 3. In an alternative possibility, the control device 215 transmits the registered data to the server 3 where the comparison is made, and in the event of a match the server 1 signals the control device 215 to operate the lock device 23 to unlock the door 3. Indeed, in one form the control device can be merely an interface which transmits signals from the various devices 211, 212, 213, 214 and the server 1, and controls the lock device 23 by relaying control signals generated in the server 1.

In some forms of the embodiment, there may be a sensor for registering the presence of an individual, and an access event of a second type occurs when such presence is detected. The index data in this case comprises the time of the access event. The sensor may be a motion sensor, and it may employ the output of the video camera. This could for example by implemented by software running in the security device 21 , the server 1 or a further processor (not shown) associated with the camera.

In either type of access event, the server 1 receives video data from the camera 22, and stores at least a portion of the video data corresponding to each access event. Each portion of the video data is stored with the index data characterizing the access event.

If the camera 22 continuously transmits video footage to the server 1. the server may store all this video data, and additionally builds a separate list of records. Each records is associated with a respective access event, and includes data indicating the location within the stored video footage of the portion of the video footage corresponding to the access event, so that (as described below) for any given access event the corresponding portion of the video footage may be extracted. Alternatively, the server 1 may store only portions of the video footage associated with corresponding access events; this reduces the total volume of data the server 1 is required to store, and therefore the reduces the required size of the server's data storage device. In some embodiments, the camera 22 transmits video footage to the server 1 continuously, but the server 1 stores only portions of the video footage corresponding to respective access events. Each portion of the video footage may include data captured during the corresponding access event, and typically also video footage captured dunng a predetermined time after the corresponding access event. The portion may also include video footage captured during a time period (e.g. a predetermined period) prior to the access event. Thus, the server 1 may discard video footage it has received if, within that time period not access event occurs.

In other embodiments, the camera 22 is controlled only to transmit video data to the server 1 at times following an access event. For example, when it is determined by the server 1 (or the control device 215) that an access event is occurring, the server 1 (or control device 215) may signal to the camera 22 that a portion of video footage is to be transmitted to the server 1, and the camera 22 then begins transmitting this video footage. The video footage may be transmitted for a time period (e.g. a predetermined duration) following the access event (for example, including at least the time that the corresponding door 3 is open). Furthermore, the camera 22 may be associated with a video data cache (not shown) for caching video data, so that upon an access event, video footage captured during a time period (e.g. of predetermined length) before the access event can be transmitted from the cache to the server 1 for storage, as part of the portion of video footage associated with the access event.

For access events of the first type, the index data includes a data specifying the time at which the access event occurred. However, it typically includes also either some or all of the registered data received by the control device 215 from the user via the camera 211. biometrics sensor 212, reader 213 and/or keypad 214. and/or further data obtained from the registered data and or further data received by the one of the optional additional sensors. For example, the registered data may include a codeword entered by a user using the keypad 214, and the index data may include that codeword, and/or the codeword may be used (by the control device 215 or the server 1) to look up an identify of the user using a look-up table, and then information specifying the user' s identity made by included in the index data. In another example, the biometrics sensor may be a facial recognition sensor, and an image of the face (received data) can be used to determine the identity of the user using pre-stored facial data. Data indicating that identity can then be included as part of the index data.

The secure access system may include a people counting algorithm, for discerning the number of users (people) that cross a door/portal threshold as a consequence of a valid access authentication. The algorithm would be operative to confirm that only one user crossed the door/portal threshold for one authentication event. In one implementation, a virtual line is set on the camera image (along the door/threshold) and a real time video analysis (DSP algorithms) is used to track movement of figures/people within the range of the camera (the camera position is fixed so that a static reference is achieved for the threshold position). When an access event is initiated, the "people-counting" function is interrogated to ensure that for the period the door is open, only one person crosses the threshold. If more than one person crossed the threshold (tail-gating for an entrance or avoidance of a secure exit) an alarm can be set and/or door disabled. Alternatively or additionally, the access event can be labeled with the number of people counted.

A number of variations to the above scheme are possible within the scope of the invention. For example, in some embodiments one or more of the security stations may be associated with a plurality of doors 3 (wtiich happen to be close to each other) and/or a plurality of video cameras 22 (for example, a respective camera for each of multiple doors, or a plurality of cameras per door such as video cameras viewing a location proximate the door from different respective directions).

Typically, the index data is stored in the same database as the corresponding video data, but it would also be possible to store the index data and video data in different databases. In a further variation of the embodiment, the portions of video footage may be stored at the security stations 2 where they were captured, in a data storage device provided there.

We now turn to methods for employing the database generated by the server 1. A supervisor typically does this using a graphical user interface (GUI) as shown in Fig. 2, which may be displayed on a screen controlled by the server 1 and/or the screen of a terminal (not shown) accessing the data stored in the sever, e.g. over the communication network. The GUI includes an area 101 for selecting one of the security stations 2 (or, especially in cases in which there is no one-to-one correspondence between security stations 2 and doors 3, the area 101 may alternatively be used to select one of the doors 3) and an area 102 for selecting one of the users. Upon indicating one of the areas 101 , 102, the user may be presented respectively with a list of the security stations 2, or of the users who are authorized to access secure area(s) protected by the secure access system. The supervisor may then select one or more of the displayed security stations 2 and/or one or more of the users. Note that area 102 of the GUI may be replaced, or supplemented, by a plurality of icons corresponding to the security stations 2, such that a supervisor can select one or more of the security stations 2 by clicking on the corresponding lcon(s). A portion 103 of the GUI permits the supervisor to enter a time range.

Upon the supervisor selecting one or more of the security stations and/or user(s) and/or a time range, the server performs a search, and presents the supervisor with a list in area 104 of access event(s) for which the index data matches these search criteria. Each item in the list may be presented together with at least a part of the index data, such as the time when it occurred. Fig. 2 shows a case in which the supervisor has selected to display a list of the video portions associated with security station number 3, between times 9:20 and 9.45. There were three access events during this period. Two were by access events of the first type in which individuals (with initials ARB and PAL) passed through the

corresponding door during that time range. The third access event was of the second type, so the identity of the individual who triggered it is not known. The supervisor can select one of the access events listed in area 104, e.g. by clicking on it. and cause the

corresponding portion of video footage to be played in a region 105. The above operation may be repeated multiple times using different successive search criteria. It will be appreciated that the supervisor is able to gain access to portions of video footage and/or event logs corresponding to access events rapidly and without reviewing video footage extending over the whole of the time range of interest. As noted above, the index data for an access event may include the number of people who passed through the corresponding door or other portal. In this case, the search criteria may be to search for access events for which this number is plural, since these access events are more likely to be associated with security violations. Note that the access events of the first type may only comprise successful interactions with the secunty devices 21, i.e. interactions which lead to the security devices 21 opening the corresponding door(s) 3. Alternatively, they may include also unsuccessful attempts by a user to interact with the security devices 21 to open corresponding door(s) 3. For example, a portion of video footage may be stored whenever a finger is pressed against biometric device 212, irrespective of whether the registered fingerprint is such as to permit unlocking of the door 3.

Reverting to Fig. 1, the operation of the heat sensor 2 6 will now be described. This heat sensor 216 is of a type suitable for detecting the body temperature of a user who interacts with the security device. The control device 215 uses the output of the heat sensor 216 in determining whether to operate the lock device 23 to unlock the door 3. For example, the control device 215 may determine whether the body temperature of the user is above a predetermined temperature threshold. In the case that the detected bod)' temperature of the user is above the predetermined threshold, the control device 215 may decline to operate the lock device 23 to unlock the door 3 even if the data transmitted by the user to the control device 215 using one or more of the camera 211, biometrics sensor 212, reader 213 or keypad 214 matches the security information in the library.

Fig. 3 shows a possible flow diagram for the operation of the control device. In a step 41 the control device 215 determines whether the data transmitted b3' the user to the control device matches the security information. If so, in a step 42, the control device 215 determines whether the body temperature of the user is below the threshold. Only if the determination is positive in both steps 41 and 42 is the door unlocked in step 43. In other embodiments, the order of steps 41 and 42 may be reversed. Note that in other embodiments either or both of these determinations may be carried out by the server 1.

The predetermined temperature threshold may optionally be controllable, e.g. at the server 1.

The control device 215 may include an override system which causes the control device 215 to operate the lock device 23 to unlock the door 3 even if a user has an elevated temperature, provided that some additional security test is met, for example that the user is determined to be a supervisor. Optionally, the feature of using the output of the heat sensor 216 to control the control device 215 may be disabled selectively, e.g. by commands input to the server 1. For example, in periods when there is an epidemic of a disease (e.g. a potentially fatal disease) associated with increased temperatures in patients, it may be sensible to implement this feature of the control device 215, whereas at other times (e.g. when an increased body temperature is more likely to be due to some other cause), it may be preferable not to implement the feature.