WO2006021047A1

WO2006021047A1 - An access control system and a method of access control

Info

Publication number: WO2006021047A1
Application number: PCT/AU2005/001285
Authority: WO
Inventors: Pareen Kumar Goel
Original assignee: Honeywell Limited
Priority date: 2004-08-27
Filing date: 2005-08-25
Publication date: 2006-03-02
Also published as: EP1807788A1; HK1113213A1; EP1807788A4; CN101052970A; CN101052970B

Abstract

An access control system (1) for two door access points (3, 4) that are selectively accessed by a plurality of users (5, 6). System (1) includes access tokens (7, 8) for respective users (5, 6) having memory (10) for containing a digital certificate and a token certificate change list (CCL). Each token is responsive to an interrogation signal for generating a token signal derived from the certificate. A computer network (11) contains information indicative of the certificates for the system, and allows system (1) to provide a central CCL that is indicative of changes that are required to one or more of those certificates. A connected access reader (15) is disposed adjacent to access point (3) and communicates with network (11) for maintaining a first local CCL that is merged in real time with the central CCL. Reader (15) generates an interrogation signal and is responsive to the corresponding token signal for: determining if access point (3) is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL.

Description

TITLE: AN ACCESS CONTROL SYSTEM AND A METHOD OF ACCESS CONTROL

FIELD OF THE INVENTION

The present invention relates to an access control system and a method of access control.

The invention has been developed primarily for multi-site large-scale installations of access control systems having many access points and many users, and will be described hereinafter with reference to that application. However, it will be appreciated that the invention is not limited to that particular field of use and is also suitable for single site installations and for those access system having only small numbers of access points and users.

DISCUSSION OF THE PRIOR ART

Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.

Known access control systems include a plurality of access readers that are disposed at or adjacent to respective access points at a given facility. Typically, the facility is a building, and the access points are respective doors in the building. The readers are connected with respective locking devices that are pulsed between a locked and an unlocked configuration. By default, the locking device is maintained in the locked configuration to prevent passage of the user through the access point and pulsed, upon an appropriate request being made, into the unlocked configuration. The "pulse" to the unlocked configuration is typically of a matter of seconds, after which the locking device returns to the locked configuration. Each user of the system is issued with a token, such as a pass card, which contains a unique identifier that is stored on the card. When the card is presented to the reader, the latter extracts the identifier from the card.

One type of prior art access control system includes a host server or servers that are part of a computer network. This network accommodates not only the access control system, but also other computer devices and software, including at least one database for containing records relevant to the access control system. The host server or servers read and write data to and from the database and other components of the system. Disposed between the host server or servers and the readers are a plurality of controllers, which are specialised computing devices that each control any where from about two to twenty readers and the associated locking devices. The controllers each include memory for holding all the necessary configuration information for the readers and locking devices, and are able to take access control decisions for the readers concerned.

While the readers will revert to the associated controllers for each instance of a card being presented to a reader, the controllers need not revert to the host server or server for each of those instances. In other words, the controllers are used to reduce the number of devices with which the host server directly communicates. That is, the host server does not need to communicate directly with all the readers, only directly with all the controllers. Accordingly, the host server is not polled during each access control decision, as those decisions are made at the controllers. Notwithstanding, due to the limited memory in the controllers to hold information about the users, the typical limitation on the number of users is several hundred. This severely compromises the scalability of such systems.

Once the number of readers and the number of users increase, there is considerable network traffic between the controllers the host server to ensure those controllers have, in real time, the information required to make accurate access control decisions. This network traffic increases as the scale of a given system increases, and the point is soon reached where the traffic compromises the network performance. This not only slows the operation of the access control system but also of the network as a whole.

Large-scale implementations using this architecture are also prohibitively expensive due to the relatively high costs of the controllers, the limited capacity of the memory available to the controllers, and the relatively low level of processing the controllers provide for the given cost. This is compounded by the fact that the controllers are physically electrically connected to the host server or servers. More particularly, this electrical connection limits the range between the host server and the controller, makes the controllers more susceptible to single point failure, has a high installation cost, and provides for weak authentication processes.

In an attempt to address these problems, alternative access control systems have been designed using smart cards. The primary focus of these systems is to improve the authentication process by storing information about the user's identity on the smart cards. The rationale being that a reader is then able to validate the person physically holding the card by comparing the person's knowledge or physical identification with the information held on the card. Notwithstanding, all the other limitations of the abovementioned prior art systems continued to apply. Moreover, the increased cost of the card over the earlier systems is not often justifiable given there is only an incremental improvement in functionality achieved. hi a further attempt to address these limitations, some more recent smart card based access control systems, in addition to holding authentication information, also hold and transfer to the reader, upon request, authorisation information for the user. This information is indicative of the level of access rights available to the user. Typically, this information is placed on the smart card to compensate, in part, for the limited memory capacity of the controllers and to avoid the need for those controllers to resort to the host server as often. In some systems the authorisation information and the authentication information collectively define a digital certificate for the user that is held on the card. This system can, in some instances, allow limited continuity of operation notwithstanding a temporary break in the communication link between the controller and the reader failed. However is also has a considerable disadvantage, in that the user authorisation information recorded on the smart cards is inaccessible to the host servers and the controllers. Accordingly, if there is a need to change the authorisation information recorded on the respective cards - which, in large systems, occurs frequently - this cannot be achieved by the system until the cards are interfaced with the system. For large systems this can considerably compromises the accuracy of the access control decisions that are made. An attempt to at least partially address this considerable problem includes the use of a Certificate Revocation List (known as a CRL). Conceptually, the CRL is a description of the certificates on the system that are no longer valid for use, and is held by the controllers. As a result, when a card is presented to a reader, and the reader passes the identification information and/or the authorisation information to the controller, the controller is able to cross check the validity of the authorisation information and make a correct access control decision. While this may at face value appear to present a workable solution, to be effective it requires constant real time access between the controller and the host server to ensure the CRL is most current. - A -

That being so; it ultimately suffers from the many disadvantages set out above. This includes, amongst other things, being particularly difficult to apply to large-scale installations.

In any practical system the number of records in the CRL continues to grow over time. This results in the size of the CRL quickly exceeding the available capacity of the tokens to be able to carry that CRL. One attempt to address this conundrum is to provide an access control system having certificates on the respective cards that are each valid for only a short period. More particularly, the CRL is re-commenced or re¬ initialised at the start of each short period, while all the certificates issued in any preceding period are no longer valid, hi one prior proposed system the authorisation information expires daily, while in others it expires every few hours. While this allows the use of disconnected readers, it is also subject to considerable scalability issues. For example, if all users have to obtain a new certificate each day, say, this creates a bottleneck at the peak time for those readers where those certificates are downloaded to the cards. Moreover, the downloading only occurs at connected readers, for disconnected readers will not have access to the controller or host server to know of the most recent authorisation information. Where there are many users such systems generally result in time delays and the inevitable frustrations of personnel that accompany such delays. Where the issue period is shorter, this can exacerbate such disadvantages.

As a whole, the prior art systems are not well suited to providing flexible large- scale implementations due to the inherent limitations of the architectures used.

DESCRIPTION OF THE INVENTION

It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

According to a first aspect of the invention there is provided an access control system for at least one access point that is selectively accessed by a plurality of users, the access point being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the system including: an access token for each of the users, each token including memory for containing a certificate and a token certificate change list (token CCL), each token being responsive to an interrogation signal for generating a token signal derived from the certificate; a computer network for containing information indicative of the certificates and for providing a central CCL that is indicative of changes that are required to one or more of those certificates; and an access reader for each access point that communicates with the network for maintaining a local CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: determining if the respective access point is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL.

In an embodiment, the memory contains other information. For example, in some embodiments, the memory contains identification information for the user, hi other embodiments, the memory contains information about one or more characteristics of the token. Examples of such characteristics include: the organisation issuing the token; the owner of the token; the unique identifier for the token; and the like.

Preferably, the token signal is derived from the certificate and the token CCL. In an embodiment, each certificate includes for the respective user authorisation information. In other embodiments, each certificate includes for the respective user authorisation information and one or more of: authentication information; and identification information. For example, in one embodiment, each certificate includes for the respective user identification information, authentication information and authorisation information. In further embodiments the certificate include information in addition to the above types of information. hi an embodiment, each CCL includes a plurality of records wherein each record is one of: a change request record that is indicative of a certificate that is to be changed; a change completion record that is indicative of confirmation that a particular certificate has been changed; a timestamp for the CCL; and a base creation date for the certificates that are valid.

Preferably, the central CCL does not include a change completion record. In an embodiment, the changes of which the central CCL is indicative include one or more of: a revocation of the one or more certificates; a change to the authentication information for the one or more certificates; and a change to the authorisation information for the one or more certificate. In an alternative embodiment, the changes of which is the CCL is indicative is only a revocation of the one or more certificates. In an embodiment the certificate includes validity information indicative of creation and/or expiry conditions for the certificate. Preferably, the validity information is indicative of one or more dates and/or times. In other embodiments, however, the validity information is indicative of the order of creation or expiry of a certificate - that is, the validity information is a set of one or more numbers in a sequence of numbers. Preferably, the central CCL, the local CCL and the token CCL include respective validity information indicative of the time of creation for the respective CCL. More preferably, the CCL includes information indicative of a base creation date for all valid certificates. This latter feature allows blanket changes to certificates issued prior to the base creation date. Preferably, the identification information is indicative of a unique identifier associated with user. More preferably, the authentication information is indicative of one or more reference points for confirming the authenticity of the user presenting the token to the reader. Even more preferably, the authorisation information is indicative of one or more groups of which the user is a member. In the preferred embodiments, the groups are based upon the role or roles of the respective user within an organisation.

In an embodiment, the reader contains configuration information that is indicative of one or more of: time schedules; and access control information. More preferably, the time schedules are indicative of segments of time. For example, one segment is defined by: Monday to Friday (excluding holidays), from 9 AM to 5 PM local time. Other segments are defined differently, and include more complex data structures.

In an embodiment, the access control information is responsive to the time schedules for indicating which group or groups are authorised when the reader determines if the respective access point is to be pulsed - that is, when the authorisation decision is made by the reader. In some embodiments the access control information includes other information for allowing more sophisticated access control decisions to be made. For example, decisions about access control for a plurality of threat levels. In some embodiments, the threat level defines the overall security threat to the access points as perceived typically by an administrator of the system. hi a preferred embodiment, the token CCL includes a plurality of records, hi an embodiment, each record is either: a change request record that is indicative of a certificate that is to be changed; or a change completion record that is indicative of confirmation that a particular certificate has been changed.

It will be appreciated that the central CCL has only change request records. Preferably, the or at least one of the readers communicates with the network and the merging of the token CCL and local CCL includes the respective reader: reading from the token CCL any change completion records; and writing the local CCL to the token CCL. hi a preferred form, the writing the local CCL to the token CCL includes overwriting the token CCL. hi an embodiment the change completion record is provided to the network prior to writing the local CCL to the token CCL. It will be understood that the change completion record is only sent to the network if there is a corresponding change request in the local CCL. This results in the server: deleting the change request from the central CCL to define a new central CCL; and then making the new central CCL available to the connected readers. hi an embodiment, the merging of the local CCL and the token CCL occurs prior to the determining if the access point is to be pulsed. Preferably, the local CCL and the central CCL are merged. More preferably, the local CCL and the central CCL are merged in real time. That is, the local CCL - held at the or each connected reader - is the most recent CCL available to the network. hi an embodiment the access control system also includes access points which do not have an associated reader. For example, an access point which allows the users to exit but not enter a given site. In other embodiments, the access system includes disconnected readers that communicate with the network via the tokens. hi a preferred embodiment, the reader or readers upon interrogating the token generate respective transaction logs that are communicated to the network. Preferably, the system includes one or more readers that do not communicate with the network — that is, disconnected readers — wherein those readers, upon interrogating the token, generate respective transaction logs. More preferably, the transaction logs are indicative of one or more actions of respective readers. In this embodiment, each of the one or more readers that do not communicate with the network write to the memory of the token the respective transaction log. When the token is interrogated by a reader that does communicate with the network - that is, a connected reader - the transaction logs are read from the memory of the token. More preferably, once the transaction logs are read they are deleted from the memory of the token. It will be appreciated that in the preferred embodiments the connected readers, following an interrogation of the token, provide a transaction log to the network. As a disconnected reader is unable to do that directly, the transaction log is generated and written to the token. When the token is subsequently presented to a connected reader the stored transaction log is read, passed to the network, and then deleted from the token memory. This allows transaction logs for all readers to be provided to the network, while also ensuring any given log is deleted so as to not be provided more than once, and to minimise usage of the token memory. In some embodiments the transactions log or logs stored in the memory of a token relate to transactions for that particular token. In other embodiments, however, logs for transactions related to other tokens are able to be stored in the memory of that particular token. Preferably, the transaction logs include alarm conditions and the like. More preferably, any such logs are written to the first token presented to the disconnected reader and then deleted from the memory of the reader. In some embodiments the reader writes the records to those tokens presented to the reader within a given time period.

According to a second aspect of the invention there is provided an access control system for at least one access point that is selectively accessed by a plurality of users, the access point being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the system including: an access token for each of the users, each token including memory for containing:

(a) a certificate having identification information, authentication information, and authorisation information, and

(b) a token certificate change list (CCL), wherein each token is responsive to an interrogation signal for generating a token signal derived from the certificate; a computer network for containing information indicative of the certificates for the system and for providing a central CCL that is indicative of changes that are required to one or more of those certificates; and an access reader for each access point that communicates with the network for maintaining a local CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: determining if the respective access point is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL.

Preferably, the token signal is derived from the certificate and the token CCL. In an embodiment, the merging occurs prior to the determining if the access point is to be pulsed. Preferably, the local CCL and the central CCL are merged. More preferably, the local CCL and the central CCL are merged in real time. That is, the local CCL - held at the or each reader - is the most recent CCL available to the network.

In an embodiment, the interrogation signals and the token signals are wireless signals. However, in other embodiments, the interrogation signals and/or the token signals are conveyed by one or more conductive paths and/or optical paths that extend between the reader and the token. For example, in one embodiment, the token includes conductive contacts that are physically engaged with corresponding conductive contacts of the reader to create one or more electrical connections between the two. Preferably, the certificates are unique for each token.

In an embodiment, the reader is, or the readers are, connected to the network and the merging of the local CCL and the central CCL occur in real time. In another embodiment the system includes at least one other reader that is disconnected from the network. It will be appreciated that this other reader, being a disconnected reader, does not directly merge the local CCL with the central CCL. Rather, for a disconnected reader, the local CCL is merged with the token CCL for each token that is presented to the reader to initiate a request for access. That being so: this other reader does not, or readers do not, merge with the central CCL in real time.

According to a third aspect of the invention there is provided an access control system for a plurality of access points that are selectively accessed by a plurality of users, the access points being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the system including: an access token for each of the users, each token including memory for containing a certificate and a token certificate change list (CCL), each token being responsive to an interrogation signal for generating a token signal derived from the certificate; a computer network for containing information indicative of the certificates and for providing a central CCL that is indicative of changes that are required to one or more of those certificates; an access reader for at least one of the access points that communicates with the network for maintaining a connected CCL that is merged in real time with the central CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: determining if the respective access point is to be pulsed to the unlocked configuration; and merging the connected CCL and the token CCL; and an access reader for the or each of the remainder of the access points that communicates with the respective tokens for maintaining a disconnected CCL that is merged with the corresponding token CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for determining if the respective access point is to be pulsed to the unlocked configuration. According to a third aspect of the invention there is provided a method of access control for at least one access point that is selectively accessed by a plurality of users, the access point being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the method including: providing an access token for each of the users, each token including memory for containing a certificate and a token certificate change list (token CCL), each token being responsive to an interrogation signal for generating a token signal derived from the certificate; containing on a computer network information indicative of the certificates, the network providing a central CCL that is indicative of changes that are required to one or more of those certificates; and providing an access reader for each access point that communicates with the network for maintaining a local CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: deteraiining if the respective access point is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL.

According to a fifth aspect of the invention there is provided a method of access control for at least one access point that is selectively accessed by a plurality of users, the access point being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the method including: providing an access token for each of the users, each token including memory for containing: (a) a certificate having identification information, authentication information, and authorisation information, and (b) a token certificate change list (CCL), wherein each token is responsive to an interrogation signal for generating a token signal derived from the certificate; containing on a computer network information indicative of the certificates for the system, the network providing a central CCL that is indicative of changes that are required to one or more of those certificates; and providing an access reader for each access point that communicates with the network for maintaining a local CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: determining if the respective access point is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL.

According to a sixth aspect of the invention there is provided method of access control system for a plurality of access points that are selectively accessed by a plurality of users, the access points being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the method including: providing an access token for each of the users, each token including memory for containing a certificate and a token certificate change list (CCL), each token being responsive to an interrogation signal for generating a token signal derived from the certificate; containing on a computer network information indicative of the certificates, the network providing a central CCL that is indicative of changes that are required to one or more of those certificates; providing an access reader for at least one of the access points that communicates with the network for maintaining a connected CCL that is merged in real time with the central CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: determining if the respective access point is to be pulsed to the unlocked configuration; and merging the connected CCL and the token CCL; and providing an access reader for the or each of the remainder of the access points that communicates with the respective tokens for maintaining a disconnected CCL that is merged with the corresponding token CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for determining if the respective access point is to be pulsed to the unlocked configuration. According to a seventh aspect of the invention there is provided an access control system for a plurality of access points between respective pairs of zones that are selectively accessed by a plurality of users, the access points being selectively pulsed between a locked and an unlocked configuration for granting or denying the users access between zones in the respective pairs of zones, the system including: an access token for each of the users, each token including memory for containing a zone record indicative of at least one of the zones, each token being responsive to an interrogation signal for generating a token signal derived from the record; and an access reader for each access point, the readers having respective reader records indicative of one of the pairs of zones, the reader generating an interrogation signal and being responsive to the corresponding token signal and the reader record for determining if the access is to be granted or denied.

In an embodiment, the reader record designates one of the zones as an exit zone in which the user is located when polling the access point, and an entry zone to which the user will progress if access is granted. Preferably, the reader record is also indicative of a pair of anti pass-back (APB) zones. More preferably, the pair of APB zones includes an exit APB zone in which the user is disposed when polling the access point, and an entry APB zone to which the user will progress if access is granted. In an embodiment, the reader is responsive to one or both of the entry APB zone and the exit APB zone for determining if access is to be granted or denied.

Preferably, the entry zone and the exit zone are physical spaces. However, in other embodiments, one or more of the zones are virtual zones. That is, one or more the zones are, in some embodiments, computer environments.

Preferably also, the reader record is indicative of: an exit anti pass-back (APB) zone in which the user is located when polling the access point; and an entry APB zone to which the user will progress if access is granted. In an embodiment, the reader is responsive to the entry APB zone and the exit APB zone for determining if the access is to be granted or denied.

In an embodiment, the zone record is indicative of one or both of: the APB zone to which the token was last granted access ("the last APB zone"); and the zone to which the token was last granted access ("the current zone"). Both of these zones are selectively written to the token by the readers at the time of polling if access is granted. In an embodiment, if the reader has an exit APB zone that is different to the entry APB zone, the reader is responsive to the token signal for determining whether the last APB zone matches the exit APB zone. If the result of this determination is true, access is granted. Otherwise no action occurs and the access is denied.

In an embodiment, if the access is granted, the reader updates the zone record. Preferably, the reader updates the zone record to change both of the last APB zone and the current zone.

In an embodiment, the token stores user information in the memory, and the token signal is derived from the user information. More preferably, the reader extracts the user information from the token signal and makes a user determination as to whether or not the access point should be pulsed between the locked and the unlocked configuration. Preferably, the reader extracts the zone record from the token signal and makes an APB determination as to whether or not the access point should be pulsed between the locked and the unlocked configuration. In the preferred embodiment, the user determination is made prior to the APB determination. However, in other embodiments, the user determination is made after the APB determination. In further embodiments, substantially all the action required to make a first of the determinations is taken prior to the actions required to make a second of the determinations. Preferably, the user information includes one or more of: identification information for the respective user; authentication information for the respective user; and other forms of information such as a token certificate or the like.

According to an eighth aspect of the invention there is provided a method of access control system for a plurality of access points between respective pairs of zones that are selectively accessed by a plurality of users, the access points being selectively pulsed between a locked and an unlocked configuration for granting or denying the users access between zones in the respective pairs of zones, the method including: providing an access token for each of the users, each token including memory for containing a zone record indicative of at least one of the zones, each token being responsive to an interrogation signal for generating a token signal derived from the record; and providing an access reader for each access point, the readers having respective reader records indicative of one of the pairs of zones, the reader generating an interrogation signal and being responsive to the corresponding token signal and the reader record for determining if the access is to be granted or denied.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic representation of an access control system of an embodiment of the invention;

Figure 2 is a schematic representation of a smart card for use in the system of Figure 1;

Figure 3 is an enlarged view of the processing circuitry on the card of Figure 2; Figure 4 is a flowchart illustrating the steps for enrolling a user in the system of

Figure 1;

Figure 5 is a schematic diagram illustrating the flow of information between components of the system of Figure 1 during a typical enrolment of a new token holder in the system of Figure 1; Figure 6 is a schematic diagram illustrating the flow of information between components of the system of Figure 1 to implement a typical change in access rights of an existing token holder where the token holder presents the respective token to a connected reader; Figure 7 is a schematic diagram illustrating the flow of information between components of the system of Figure 1 to implement a typical change in access rights of an existing token holder where the token holder presents the respective token to a disconnected reader; Figure 8 (a) is a flowchart illustrating the typical steps of adding a change record to the local CCL of a connected reader of the system of Figure 1;

Figure 8(b) is a flowchart of the sub-steps within one of the steps of Figure 8(a); Figure 9 is a flowchart of the typical steps of merging a token CCL and a local CCL of the system of Figure 1; Figure 10 is a flowchart of the typical steps undertaken by the system of Figure

1 to authenticate a user;

Figure 11 is a flowchart of the typical steps undertaken by the system of Figure 1 to validate a certificate;

Figure 12 is a flowchart of the typical steps undertaken by the system of Figure 1 to determine whether or not the token holder is authorised to access the desired access control point;

Figure 13 is a schematic overview of the APB functionality provided by the system of Figure 1;

Figure 14 is a flow chart exemplifying the APB logic used to provide the APB functionality of Figure 13 ;

Figure 15 is a schematic overview similar to Figure 13 for further enunciating the configuration of the readers;

Figure 16 is a schematic representation of an alternative reader for use in the system of Figure 1; Figure 17 is a flowchart illustrating the steps for enrolling a user in the system of

Figure 1 configured as an alternative embodiment of the invention, where the enrolment differs from that in Figure 4;

Figure 18 is a sequence diagram illustrating the enrolment of a new user in the alternative embodiment of the invention; Figure 19 is a sequence diagram illustrating the active management of certificate change requests for the alternative embodiment of the invention; Figure 20 is a sequence diagram illustrating for the alternative embodiment of the invention the information flows resulting from a change in the access rights of a user where that user, following the change, first presents their token to a connected reader;

Figure 21 is a sequence diagram illustrating for the alternative embodiment of the invention the information flows resulting from a change in the access rights of a user where that user, following the change, first presents their token to a disconnected reader;

Figure 22 is a flow chart illustrating the steps used in the alternative embodiment to updating the central CCL; Figure 23 is a flow chart illustrating the steps used in the alternative embodiment to merge CCLs; and

Figure 24 is a flow chart illustrating the steps used by the readers in the alternative embodiment to write to the token CCL.

DETAILED DESCRIPTION OF THE EMBODIMENTS CROSS REFERENCES

The disclosures included within Australian provisional patent applications 2004904895 filed 27 August 2004 and 2004905346 filed 16 September 2004 are incorporated herein by way of cross reference. GLOSSARY OF TERMS Before progressing to a more detailed description of an embodiment of the invention, some guidance is provided on the following terms as used in the description:

(a) The term "user" refers to an individual person, an organisation, corporation, group of individuals, or otherwise who are to be selectively granted access rights to at least one access point - be that a physical or logical access point - of at least one facility, network, site, building or other asset controlled by the access control system.

(b) The term "access token" refers to an information carrying device that is typically issued to a user for use by that user only. The token typically includes information, as will be set out below, relevant to the user. It is preferred that each user is issued with a single token only. A token is, in the described embodiments, a contact-less smart card. However, in other embodiments, use is made of other tokens such as smart cards with contacts, hybrid smart cards having both contacts and contact-less components, magnetic strip cards, RPID cards, USB tokens, and the like.

(c) The term "identification" refers to the process of obtaining a code or other identifier - typically from an access token - that is indicative of the identity of a user that is seeking to gain access to an access control point. That is, the process of the user answering the question "Who do you say you are?"

(d) The term "identification information" refers to that information which is provided as being indicative of the identity of the user. Identification information includes typically a code or character string, whether encrypted or not, that is most often unique to an access token and which is allocated to a specific user during an enrolment process. In some embodiments, the identification information is minimal, and is part of the encryption key for a token signal.

(e) The term "authentication" refers to the process of verifying that the person providing the identification information is entitled to provide that information.

That is, the process of answering the question "Are you, the user providing the identification information, who you say you are?"

(f) The term "authentication information" refers to the information that is provided by the user to assist in the verification of the user as the appropriate person. Authentication information includes typically a PIN, password, signature, one or more biometric templates, and one or more digital certificates or other digital signatures. This information is, in some embodiments, stored on the token.

(g) The term "group" refers to a set of one or more users having common access rights, as a member of that group, to one or more access points. That is, each user in a group is able to gain access via given access point or points based upon one or more time schedules for the access control system. A user is included in one or more groups and, as such, two users, notwithstanding they are in one group, may have different access rights, (h) The term "time schedule" refers to a set of one or more discrete segments of time. For example, one segment is defined by those time segments on Monday to Friday (excluding holidays) from 9 AM to 5 PM local time. Other segments are defined differently, and include more complex data structures. A time schedule is deemed to be "active" if the current time of day is included within at least one of the segments in the respective schedule. For example, the abovementioned time schedule is "active" whenever the current time of day is determined to be between 9 AM to 5 PM and the current day of the week is determined to be Monday to Friday, but the current day of the year is deemed not to be a holiday. (The reader is configured with information indicative of which days of the year are holidays), (i) The term "authorisation" refers to the process of determining if the person identified and/or authenticated is entitled to access at a given access point. That is, the process of answering the question "Are you entitled to do what you are seeking to do?"

(j) The term "authorisation information" refers to the information that is assessed to determine the authorisation for a user. Authorisation information includes typically a character string and/or a list of numbers, whether encrypted or not. hi the embodiments of the invention described below, the authorisation information for a given user is stored on the respective token and is indicative of the group or groups to which that user has been made a member, (k) The term "access reader" refers collectively to the hardware and software that are associated with an access point and which communicate directly to a host server. In some embodiments an access reader includes a locking device, a door contact, any user input device or devices - such as a biometric reader, a keypad, a button, or a touch screen - I/O hardware and software, memory (referred to as "local memory") and the like. The access reader is provided with the required information - be that identification information, and/or authentication information, and/or authorisation information — to make a determination on a request for access from a user without, in most cases, having to resort to intermediate communication with the host server. It will be appreciated that in the embodiments described below there is no separate or additional controller disposed between the access reader and the host server. (1) The term "certificate" refers to an electronic record that is allocated to a user for allowing that user to interact with the system. In the described embodiments, each certificate is a digital record that is stored in the memory of a respective token, and which includes identification information, authentication information and authorisation information for the token (and, hence, for the user who has been allocated that token). It will be appreciated that in other embodiments the certificate includes additional or alternative information. For example, in one embodiment, the certificate includes only authorisation information, (m) The term "certificate change list" - having the abbreviation "CCL" - refers to a list of one or more records indicative of respective certificates that are required to be changed. An example of a record in the CCL is an identifier for a certificate that is no longer valid for use with the access control system - that is, a certificate that is to be revoked or otherwise changed. (This record is referred to as a "change request record"). Another example of a record in the CCL is an identifier for a certificate where the revocation or other change has been executed but not yet communicated to a central host server. (This record is referred to as a "change completion record"). In some embodiments there is also a time limit applied to the change request records in the CCL. For example, should a change completion record not be presented to the central CCL to effect removal of the change request record from the central CCL within a predetermined period - typically in the order of days -the system raises an alarm for manual intervention and correction. This functionality is tailored for different embodiments, (n) The term "token CCL" refers to the CCL stored or otherwise held on the token and which includes none, one or more change request records, and none, one or more change completion records. It will be appreciated that the token CCL, having the ability to contain these two types of records, allows two-way communication between the central host server and the readers. That is, the change request records facilitate communication outwardly from the server, while the change completion records facilitate communication inwardly to the server.

(o) The term "local CCL" refers to the CCL stored or otherwise held on the reader. It will be appreciated that in the described embodiments of the invention both connected readers and disconnected readers include respective CCL' s. For connected readers the local CCL is, in effect, equivalent to the central CCL due to the real time connection between the connected readers and the host server included within the network. Due to this connection, local CCL' s for a connected reader will not, for practical purposes, contain change completion records, as these will be communicated in real time to the server. However, the local CCL for a disconnected reader stores change completion records until such time as they are overwritten by a more up-to-date token CCL. It will be appreciated that, like the token CCL, the local CCL for a disconnected reader is less reliable as both the disconnected readers and the tokens do not have a real time connection with the host server. For ease of reference, disconnected readers are said to have disconnected CCL' s, while connected readers are said to have connected CCL' s. If a connected reader temporarily looses the real time connection with the server there is a risk that the local CCL will differ from the central CCL. Similarly, if a real time connection is established between the server and an otherwise disconnected reader, there is a high risk that the local CCL will differ from the central CCL. hi the preferred embodiment these risks are mitigated by the readers having the capability to detect the establishment or the re-establishment of the real time connection with the server. Further, the readers are able to request the central server to make available the central CCL to allow the readers to synchronise the local CCL with the central CCL. (p) The term "central CCL" refers to the CCL stored or otherwise held by the network, (q) The terms "merge" or "merging", when used in the context of two CCL' s, refers to the updating of one or both of those CCL' s with each other to ensure the records in both CCL' s reflect the most recently available information. While the merging occurs in one of a number of ways it does, in the described embodiments, include broadly a two-step process. Particularly, the first step is to process any change completion records - to progressively return information to the central host server — while the second step is the overwriting of the remainder of the records of one of the CCL' s with the records of the other — that is, the progressive transfer of information from the central host server to the disconnected readers. In some instances the second step of the merging includes a comparison of the two CCL 's being merged — for example, when merging a token CCL and a local CCL of a disconnected reader the comparison is to determine which of the CCL' s is most recent. However, in other instances, the second step of the merging is by way of sequentially transmitted changes of one CCL to another - for example when merging the local CCL of a connected reader with the central CCL. (r) The term "access control decision" refers to a decision that is made as to whether or not a request for access at a given access point will be granted. In the described embodiments of the invention, the access control decisions are made by the respective readers regardless of whether those readers are connected readers or disconnected readers, (s) The term "real time", in the context of communication with readers, refers to the communication being sufficiently contemporaneous to allow for a connected reader the respective local CCL to correspond with the central CCL prior to that reader having to make a subsequent access control decision, (t) The term "pulsed", in the context of an access point, refers to the progression from a locked configuration to an unlocked configuration. For physical access points this typically involves a door having a locking device that progresses between the locked and the unlocked configuration, and then back to the locked configuration after a predetermined delay. In the context of a virtual access point, the term "pulsed" refers to the virtual lock being progressed to the unlocked configuration and the relevant computer access being provided to the user. The virtual lock returns to the locked configuration either periodically or once the user logs off from the computer or network to which the access was granted.

(u) The term "zone", in the context of readers and tokens, refers to a secured area or space - be that a physical area or a virtual area such as a computing environment - which is accessed only via one or more access points. If access is granted to the area by any of those access points, no further access control is applicable until the user leaves that area via any controlled or uncontrolled access point. It will be appreciated that the physical and the virtual environments coexist in parallel, but are interrelated, as required.

(v) The term "anti pass-back zone" or "APB zone", in the context of readers and tokens, refers to a secured area or space - be that a physical area or a virtual area such as a computing environment - which is accessed only via one or more access points. If the access is granted to the area by any of those access points no further access control is applicable until the user leaves the area via any access point controlled by respective reader that is disposed in the area. It will be appreciated by those skilled in the art that, in some embodiments, an APB zone wholly contains within its area one or more zones or APB zones. OVERVIEW OF THE ARCHITECTURE OF THE ACCESS CONTROL SYSTEM Referring to Figure 1 there is schematically illustrated an access control system

1 for two door access points 3 and 4 that are selectively accessed by a plurality of users that are representatively shown as users 5 and 6. The access points are pulsed between a locked and an unlocked configuration for respectively preventing and allowing users 5 and 6 access at the access points 3 and 4. System 1 includes access tokens, in the form of two contact-less smart cards 7 and 8, for respective users 5 and 6. As best shown in Figure 2 and Figure 3, each smart card includes memory 10 for containing a digital certificate and a token certificate change list (CCL). Each token is responsive to an interrogation signal for generating a token signal derived from the certificate. A computer network 11 includes many components - that will be described in more detail below - that contain information indicative of the certificates for the system, and which allow system 1 to provide a central CCL that is indicative of changes that are required to one or more of those certificates. A connected access reader 15 is disposed adjacent to access point 3 and communicates with network 11 for maintaining a first local CCL that is merged in real time with the central CCL. Reader 15 generates an interrogation signal and is responsive to the corresponding token signal for: determining if access point 3 is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL. A disconnected access reader 16 is disposed adjacent to access point 4 and communicates with smart card 8 for maintaining a second local CCL that is merged with the corresponding token CCL. Reader 16 generates an interrogation signal and is responsive to the corresponding token signal from smart card 8 for determining if access point 4 is to be pulsed to the unlocked configuration.

In this embodiment, access point 3 is an external front door that provides the main entrance to a building 17. Access point 4, on the other hand, is an internal door of building 17. In this embodiment there are many other access points within building 17 also accommodated by system 1 - via respective readers (not shown) - but have been omitted from Figure 1 for the sake of clarity. Some of these other readers are connected readers, while the balance of the other readers are disconnected readers. In other embodiments, access points 3 and 4 are disposed in different buildings or facilities. For example, in one embodiment, a first plurality of access points is disposed in a given facility, and a second plurality of access points is disposed in a further facility. In some embodiments the facilities are adjacent to each other, while in other embodiments the facilities are spaced apart. In still further embodiments, there are more than two facilities accommodated by system 1. hi this embodiment, network 11 is disposed within building 17. However, in other embodiments, the network is disposed remotely from the building. Where system 1 is implemented over multiple buildings or multiple facilities, network 11 is typically spread between those facilities.

Reader 15, being a connected reader, is electrically linked with network 11 by a physical cable 18, while reader 16 is disconnected from the network, hi other embodiments, reader 15 is connected to network 11 by either a physical cable or a wireless connection. While the connected readers are continually connected with the network, in other embodiments they are configured to tolerate temporary disconnection, and during such periods will act as disconnected readers. Upon restoration of the connection between the readers and the network, the readers will revert to acting as connected readers. Similarly, while disconnected readers are typically continuously disconnected from the network, they are configured for connected operation, should that occur. For example, in some embodiments, a disconnected reader includes a wireless connection to the network that is only active periodically due to bandwidth and cost limitations. That is, the connection between the reader and the network does not establish a real time connection. Network 11 includes a database 21 for containing a variety of records for administering system 1, and this will be described in further detail below. The records on this database are tightly controlled, and integrity is important for the proper operation of system 1. Accordingly, there is a need to ensure high levels of both physical and virtual security for database 21. Examples of the information contained within the database include:

• Identification information for each of the users, which in this embodiment is in the form of a character string. This is supplemented also by information about the time of enrolment of the user, the date for review of the user's enrolment details.

• Authentication information for each of the users, which in this embodiment includes a variety of data. For example, a PIN, a password, a digital signature, and a plurality of biometric templates for the user. The templates include one or more iris templates, one or more fingerprint templates, one or more face templates, and one or more hand geometry templates. The variety of templates for a given biometric are needed to accommodate the different standards required by the different biometric input devices used within system 1. (In an alternative embodiment, database 21 only includes a high quality image of the relevant biometric from which the relevant template is able to be derived).

• Authorisation information, which in this embodiment is a character string and/or list of numbers.

• Addresses for all the access readers in system 1, whether those readers are connected or disconnected.

• The certificates that have been issued by system 1, and validity information about those certificates. This validity information being indicative of creation and/or expiry conditions for the certificate. For example, this includes in some embodiments the timing of the issue of each certificate, and the timing of the expiry of the certificates. In other embodiments, however, the validity information is indicative of the order of creation or expiry of a certificate - that is, the validity information is a set of one or more numbers in a sequence of numbers.

• The central CCL, which is a list of records, including change request records, timestamp that is indicative of the time of the last change to the CCL, and a timestamp that is indicative of the base creation date of all valid certificates.

• Time stamped logs that are indicative of the interaction between the readers and the tokens that have been communicated to network 11. These interactions are known as transactions. These logs are indicative of, in some embodiments, one or more of: the identity of the user seeking access; the identity of the token used; the timing of requests for access; the outcome of the corresponding access control decision; change completion records. Although the typical access operation is for a user to attempt to gain access to a space or area - be that a physical space or, say, a virtual space on a computer network - the access control also extends, in some embodiments, to release a physical lock to allow someone else to enter a space, or allow someone to access to logical or physical resources defining the infrastructure of an organization.

Also included in network 11 is an enrolment terminal 22 for facilitating the enrolment of new users to system 1, and the modification of existing users to account for status changes, upgrades, downgrades, and changes to access rights available to each user. In other embodiments the functionality of terminal 22 is provided by any suitably configured desktop or laptop.

A host server 23 interacts with database 21 and terminal 22 for allowing the overall control and administration of system 1 and is typically overseen by a system administrator (not shown) or other suitably authorised personnel. All communication between server 23 and the connected readers, such as reader 11, uses secure encrypted communication. For example, in some embodiments, use is made of the IPSEC IPv6 protocol, while in other embodiments, alternative protocols are used.

Network 11 also includes a domain controller 24 for managing the network and the logical access to that network. In alternative embodiments the functionality of controller 24 is provided by other devices, for example server 23. The components of network 11 are linked by any suitable Ethernet cable 25.

However, in other embodiments, other forms of intra-network connections are used.

System 1 is shown, for the sake of clarity, with only two readers, two cards and a relatively minimalist network 11. It will be appreciated, however, that system 1, in use, accommodates many thousands of cards and many thousands of readers, whether those cards and readers be associated with one or many separate buildings distributed across a variety of jurisdictions.

In other embodiments, system 1 is implemented at a facility other than a building to which access rights are desired to be controlled or regulated. Examples of such facilities include one or more of: • A fenced and gated compound.

• A site - such as an industrial site - having a perimeter fence and one or more access openings.

• A computer network. • A prison.

• A safe or safety deposit box.

It will be appreciated that a plurality of nested readers are provided in some embodiments to provide multiple levels of access control, and this is combined with the anti pass-back functionality described below to provide further levels of security.

In further embodiments, system 1 is implemented to control and/or regulate the use of equipment such as computer devices such as desktops computers, laptop computers, PDA's, cellular telephones, measurement equipment, power tools, and the like. As will be described in more detail below, this control and/or regulation takes one or more forms, including determining whether a user has access to a storage space containing the equipment, and then determining either ad hoc or periodically, whether the user is able to commence or continue use of a particular piece of equipment obtained from the storage space. For example, the authorisation information in some embodiments is derived from data indicative of the currency or extent of the user's training. That being so, if the training for that user is not at a level required to operate a particular piece of equipment, access to that equipment will be denied. In instances where a piece of equipment requires two users to be present, system 1 is configured to only allow access if two such users separately and sequentially present their access cards to a given reader within a predefined timeframe. Typically, this functionality is managed through the allocation of users to groups. For example, those users with common technical certification are included within a given group.

The identification information contained on the separate cards is unique and, once extracted, allows the identification of the respective users. In this embodiment, the certificate as a whole is PKI encrypted using 1024 bit encryption keys, although alternative embodiments make use of different levels of encryption, be that 1060 bit keys or other sizes. In other embodiments, however, alternative methods and levels of encryption are used. Due to the slowness of processing PKlI encrypted code, other embodiments symmetrically encrypt the certificate as a whole. Further embodiments additionally include a digital signature, either as part of or packaged within the certificate.

As best shown in Figure 2, card 7 is in the ID-OO format, and includes a generally rectangular substrate 30 having dimensions of about 33 mm x 66 mm x 0.76 mm. Where other formats are used the substrate is of alternative dimensions. Card 7 includes processing circuitry 31 that is on substrate 30 adjacent to one corner. In other embodiments, circuitry 7 is disposed more centrally on the substrate. Card 7 also includes an antenna 32 that is comprised of a plurality of serially connected conductive loops that are connected to circuitry 31 for allowing wireless communication between circuitry 31 and readers 15 and 16.

Circuitry 31 includes two parallel arrays of contacts 33 and 34 for engaging with external contacts (not shown) should direct communications - as opposed to wireless communication - be required between circuitry 31 and another device (not shown).

Also included within circuitry 31 is a processor 35. In other embodiments use is made of cards without processors. It will also be appreciated that card 7 includes other circuitry such as power supply circuitry, transceiver circuitry, and other circuitry that has not been explicitly included within the drawings for the sake of more clearly enunciating the features that are shown.

Card 7 is a hybrid card that is enabled for contact and contact-less operation. Li other embodiments the tokens are one or more smart cards that are enable for contact operation only. That is, such cards are not equipped with means for contact-less operation. As presently envisaged, the preference is to the use of contact-less cards. These latter cards, while having similar circuitry to the hybrid cards, typically have that circuitry substantially fully embedded within the card. That is, the circuitry is not visible to the naked eye.

In other embodiments the system makes uses one or a combination of contact- less cards, hybrid cards, contact cards or tokens other than smart cards to which the reader is able to read and write data.

A host server 23, together with database 21, holds, amongst other things: • The identification information for all users.

• The authorisation information for all access points.

• The authorised users presently accessing system 1.

• A transaction log of where various users have attempted to gain access and whether they were denied or granted access along with any reason for that access control decision being made. Other transaction logs include one or more records indicative of: an alarm condition such as a forced entry, door held open unexpectedly; a reader fault; other inappropriate or unexpected system conditions; and other such events. It will be appreciated that in the preferred embodiments the connected readers, following an interrogation of the token, provide a transaction log to the network. As a disconnected reader is unable to do that directly, the transaction log is generated and written to the token involved in the transaction. When that token is subsequently presented to a connected reader the stored transaction log is read, passed to the network, and then deleted from the token memory. This allows transaction logs for all readers to be provided to the network, while also ensuring any given log is deleted so as to not be provided more than once, and to minimise usage of the token memory. In some embodiments the transactions log or logs stored in the memory of a token relate to transactions for that particular token. In other embodiments, however, logs for transactions related to other tokens are able to be stored in the memory of that particular token. It will be appreciated that in those embodiments where the transaction logs include alarm conditions and the like, any such records are written to the first token presented to the disconnected reader and then deleted from the memory of the reader. In some embodiments the reader writes the records to those tokens presented to the reader within a given time period.

In the embodiment of Figure 1, an attempt to gain access includes:

• Attempts to open - that is, to "pulse" — a physical lock to allow someone to enter a space. • Attempts to allow someone to access logical or physical resources defining the infrastructure of an organisation. For example, an IT resource. Reader 15 includes I/O circuitry to drive a number of components, hi this embodiment, those components include:

• A sensor 15a for the door contact. This sensor has a first state when the door is open, and a second state when the door is closed. In other embodiments use is made of a sensor with additional states.

• A lock 15b for the door. That is, reader 15 actuates the lock to pulse it between a locked and an unlocked configuration.

• A biometric sensor 15c for the reader for gathering biometric input from a user requesting access via the reader. This sensor is not typically included on all readers.

• A Request to EXit (REX) sensor, which in this embodiment takes the form of an infrared sensor 15d. In other embodiments a REX sensor in the form of a wall- mounted button is included. In further embodiments there is no REX sensor, as the user simply operates a door handle to allow an exit, hi the latter case sensor 15a is used to monitor the return of the door to the closed configuration. • An auxiliary I/O channel 15e, for including any additional sensors or operating devices. For example, to accommodate the retrospective installation of an additional biometric sensor or operating device (such as a keypad). It will be appreciated that reader 16 includes similar components, and these are designated with corresponding suffixes. OPERATION OF THE ACCESS CONTROL SYSTEM When enrolling a new user, use is made of terminal 22 to create records indicative of that user's identification and his or her biometric parameters. These records are submitted to server 23 and merged with the necessary access groups and other access control information for the token holder, hi turn, server 23 generates a certificate for the token that is to be provided to the new user, and has the certificate sent to terminal 22 for writing onto the respective token. The process of enrolment used in system 1 is illustrated in the flowchart of Figure 4 and will be described below in more detail. An alternative enrolment process will be described separately with reference to Figure 17. hi other embodiments additional or alternative forms of information are gathered about the user. For example, in some embodiments no biometric parameters are gathered, while in additional embodiments, many biometric images are gathered. Similar options exist for PINs, passwords, and the like.

With reference to Figure 4, the initial step is to obtain identity information for the user, typically in the form of text, and to have this entered into terminal 22 at step 36. Contemporaneously, a token having a unique serial number is selected for the user. This token, in this embodiment, takes the form of a smart card that is to be physically carried by the user. The serial number is read from the card by terminal 22 at step 37, also as text. Alternatively, the serial number is manually entered into terminal 22. All this gathered textual information is collectively stored at step 38 into database 21. Additionally, at step 39, additional identity information is obtained in the form of one or more high quality biometric images of the user. hi this embodiment, the hardware for gathering that or those images is connected to and driven by terminal 21. However, in other embodiments, alternative connections and drivers are used. The images are one or more of: one or more fingerprint images; facial image; iris image; one or more handprint images; or other biometric images.

In some embodiments, such as the present one, cross-enrolment is accommodated. Cross-enrolment is the process by which the high quality biometric image or images is or are taken and saved - at step 40 - along with all other identification and access control information for that user in database 21. The saved image or images is or are available to be later converted to biometric templates suitable for the installed variety of biometric readers, and to allow new templates to be created from the stored image should subsequently installed biometric readers require a template other than that presently used. This further reduces any bottlenecks associated with enrolment by minimising the need for re-enrolment.

The biometric templates are created from the captured image at step 41. The resultant templates are stored at step 42 in database 21. Where cross-enrolment is not supported, or not required, or the image storage is not permitted by local law, the earlier captured image or images are discarded following the creation of the templates. In other embodiments, where local laws require, the images are transported electronically or physically to the relevant agencies.

The enrolment process also includes a step 43 where access information for the user is entered into terminal 21. Typically, this step involves including the user into one or more predefined groups each of which have predetermined access rights that are time and location specific. The access information for that user is then saved at step 44 into database 21.

Steps 36 to 44, the steps of obtaining the identity information and the access information for the user, occur to create credentials for that user. This is referred to as "provisioning" the user with the necessary means to perform his/her functions within a given role and organisation.

The identity information collected during the enrolment process - which is typically a larger set of information than the combination of the identification information and the authentication information - is intended to provide a number of possible unique identifiers and authenticators for the user, such as name, address, sex, department, location, biometric information, and others. The access information collected during the enrolment process - which is typically a larger set of information than the authorisation information - is intended to provide a history of authorisations for that user.

All of the information collected by server 23 during enrolment is stored in database 21. Some of this information belongs to the IT infrastructure of the organisation and hence is held and managed by the IT systems. However, rather than requiring separate IT enrolment, terminal 22 passes the required information to the relevant IT systems, thus affecting single point provisioning. In other embodiments where the required information already exists on the IT systems, terminal 22 requests that information from the IT systems and thereby eliminating the need for re-entering the information. This allows for a reduction of organisational costs involved with provisioning users at various locations for various functions.

The next step in the enrolment process, step 45, involves the creation of a new certificate for the user. This is undertaken by server 23, which combines:

• A subset of the identity information. • The biometric templates. These are typically compressed.

• A subset of the access information, which defines the authorisation information. The former being indicative of the available access rights, while the later is indicative of the access groups to which the user has been assigned.

• Other user specific access control information. The first two items collectively define the identification information for the user.

A sub-step in step 45 include further strengthening the certificate with the physical token identification - that is, the serial number of the card obtained at step 37 - into a predefined data structure and a hash calculated with a predefined hash algorithm and encrypted using private part of an asymmetric PKI key. The output of this sub-step is a certificate that is stored in a certificate store segment 46 of database 21 and made available to all connected readers. In practice, the public part of the asymmetric key and the hashing algorithm identifier have been distributed previously to the readers as part of their configuration. This allows the readers to decode and validate the certificates. As the certificate is made available to the connected readers this allows those readers to access the certificate from the network for subsequent uploading to the card. It will be appreciated that the certificate is not sent to all readers, only to that reader which requests the certificate to upload to the card following presentation of that card to the reader. Consider the example of a card Tl, or other token, that is issued to Fred. When this card is presented to a connected reader which, in this example, is reader 15, the card will be interrogated by reader 15. In response, card Tl provides an identification signal. This identification signal will alert reader 15 to the fact that card Tl does not contain a valid certificate, and the reader will request the certificate from server 23 and have it written to the card. hi other embodiments the certificates include additional or alternative information. For example, in one embodiment, the certificates include only a small amount of information, such as only the authorisation information and some basic identification information (such as the serial number for the card or whatever token is being used). hi another embodiment the server broadcasts the new certificates to all connected readers, and the certificate is stored locally at the readers until the certificate has to be issued to a card (or other token). In this embodiment, as exemplified in Figure 4 and 5, when reader 15 is alerted that the card does not have a certificate, it uses the identification signal to ascertain which certificate stored in local memory is to be written onto card Tl. In this instance, certificate Cl is found, and the corresponding data accessed from the local memory and transmitted as a certificate write signal 54 to card Tl . The card is responsive to signal 54 for storing certificate Cl in memory on the card for later retrieval. Following the downloading of certificate Cl to card Tl, reader 15 generates and sends a certificate request signal 55 to server 23 in respect of that certificate. In response to the certificate request event, server 23 broadcasts to all connected readers a certificate delete request 56 for certificate Cl. Once request 56 is received by the readers, certificate Cl is deleted from the respective local memory as there is no longer a need to store it at the readers. This provides Fred - and the administrator of system 1 - with the flexibility of allowing the initial presentation of card Tl to any connected reader. Accordingly, the risks of bottlenecks due to enrolment are reduced.

Some network communication protocols - such as IPSEC - make broadcasting impractical. Additionally, where local memory is relatively small, then the storage of a large number of certificates in local memory creates scalability problems. These limitations are addressed by the alternative embodiments of the invention not using broadcast techniques. For convenience, the memory of the respective readers is referred to as "local memory", in that it is local to the reader and distinct from the memory capacity that is directly available to server 23.

In other embodiments, the enrolment of new users occurs in proximity to a dedicated connected reader associated with terminal 22. This dedicated reader allows card Tl to be presented to the reader, and the certificate to be downloaded onto card Tl, as soon as the certificate becomes available. Preferably, server 23 provides an alarm to terminal 22 in response to signal 52 to alert the operator that certificate Cl is now available. This allows the total number of certificates held at the readers to be contained due to the short period between the creation of a given certificate C 1 , and the presentation of the required token to the dedicated reader.

In further embodiments, alternative methodologies are used to contain the amount of information held at individual readers due to the enrolment process. For example, in one such embodiment, the token for a newly enrolled user must be presented to one of one or more predetermined readers as the certificate Cl is only broadcast to those one or more predetermined readers. That is, those one or more readers comprise a subset of all the connected readers in system 1 which, in turn, minimises the risk of the memory capacity at the remaining readers being exceeded. In the event that the digital certificate stored at reader 15 is for a pre-existing user having a pre-existing card that has been enrolled in system 1 , there is a need to revoke the earlier certificate that is relevant to the user and card. That revocation occurs at step 48 in Figure 4, and will be described in more detail below. In summary, the features of enrolment are:

• The host server (server 23) enrols new users, as well as revokes or changes their access rights.

• The enrolment process is undertaken primarily via terminal 22, where all the necessary user information is entered.

• The serial number of the card (or other token) is retrieved either from the enrolment reader - that is, the reader interrogating the card prior to enrolment of the user - or manually entered by an enrolment operator.

• Optionally, the biometric image, or images, is read from the enrolment reader.

• If cross-enrolment is required the image is saved in the image database, otherwise it is discarded after converting into the relevant templates. • Access information for the user is also provided by the enrolment operator via terminal 22.

• For re-enrolments or changes to access rights for existing users, the relevant information is retrieved from database 21. • All necessary information used to create a new certificate is saved in database

21.

• All certificates that become obsolete because changes are revoked by generating a respective "change request" that is included within the central CCL. In other embodiments the certificates which expire are also separately revoked and corresponding change requests are included in the central CCL.

• In some embodiments the new certificates are broadcast to all connected readers to allow those certificates to be written to the relevant card or other token, hi other embodiments the certificates are centrally stored. hi this embodiment, the identification information and authorisation information contained within the certificate includes encrypted data indicative of:

^■ The serial number for the token.

^■ A certificate number that is determined by the host server, that is, server 23.

^■ The user's identity.

^■ One or more predetermined biometric templates. " An identifier for one or more access groups.

^■ Access control flags, including:

♦ Long access required.

♦ Two-person rule.

♦ Supervisor required. ♦ Supervisor.

♦ Guard.

^■ Date of expiry of certificate.

^■ SHn hash of 1-7.

Li other embodiments the certificate includes encrypted data indicative of different types or forms of information. hi the event that an existing user has a change in his or her authorisation - due to a change in status within the organisation, such as a change in his or her role or duties - there is a need for this to be entered into and propagated through system 1. An example of the steps as applied to a system using broadcasting, and the relevant information flows, for changing the enrolment of a user are set out illustratively in Figure 6. Particularly, the user - again being "Fred" - having been issued with certificate Cl, now requires his access rights to be amended to correctly match a new role he has been assigned within a given organisation. The change in the access rights are reflected by an operator - such as an enrolment officer - selecting, via terminal 22, the group or groups to which Fred is to be a member. It will be appreciated that the group or groups selected correspond entirely, to some extent, or not at all with the originally selected groups depending upon the nature of the change of the role. Once the operator has made the appropriate selections - that is, once the operator has performed step 43 of

Figure 4 - the newly created access information is stored in database 21 - that is, at step 44 of Figure 4. In response to this, an enrolment request or an authorisation change request 60 is sent to server 23 which, in turn, initiates steps 46 to 48 of Figure 4. That is, a new certificate is created - which is referred to as certificate C2 - and a reference to certificate Cl is added to the central CCL. This reference is held in the central CCL as a certificate change request record. Referring once again to Figure 6, following the creation of certificate C2, server 23 broadcasts a certificate signal 61 - that contains data indicative of certificate C2 - to all connected readers. Contemporaneously, and in real time for system 1, the certificate change request record 62 for certificate Cl is broadcast to the connected readers. This broadcast is a result of a new change request record being entered in the central CCL, and results in the local CCL' s for all the connected readers being updated to include record 62.

The connected readers are responsive to request 61 for storing that certificate in local memory. The inclusion of change request record 62 being stored in the local CCL' s ensure that all those readers include a reference to a need to revoke Cl once it is presented to any one of those readers. The local CCL' s for all connected readers all correspond, in real time, to the central CCL.

If, prior to Fred presenting his card Tl to a connected reader, another user of the system - referred to in this example as "Peter" - presents his card T2 to a connected reader, there occurs a further sequence of steps. Initially, this includes card T2 providing an identification signal 63 in response to an interrogation signal provided by reader 15. Signal 63 contains data indicative of the certificate held on card T2, amongst other things, which are used by reader 15 in determining whether or not access is to be granted to Peter at that access point at that given instant in time. Next, the token CCL on card T2 is merged with the local CCL of reader 15. The merging of a token CCL with the local CCL of a connected reader involves the initial processing of any change completion records from the token CCL (which is discussed further below), and then the writing of the local CCL over the token CCL. The precedence of the local CCL over that of the token CCL — with the exception of the change completion record - is due to the local CCL being up-to-date with the central CCL, while the token CCL is of lesser reliability. The result of this hierarchy, in this example, is that the token CCL now includes a change request record for certificate Cl. In Figure 6, the writing from the local CCL to the token CCL of the change request records is designated as signal 64. Following the merging of the CCL's, reader 15 makes an access control decision for Peter at the given access point. As referred to above, card T2 includes a certificate, which was issued to Peter during an earlier enrolment process. This certificate has not been identified or referred to in the drawings as it is not germane to the steps of two way propagation of records between the central CCL, the local CCL's of the disconnected readers and the token CCL's.

If, subsequent to the above steps, Peter presents card T2 to disconnected reader 16 - and in the absence of any other relevant intervening events - that reader interrogates card T2 in the normal way to access the relevant certificate for Peter that is stored on card T2. Similarly to the above example for reader 15, reader 16, prior to making an access control decision, will access the respective token CCL and merge that with the local CCL. In this case, however, as reader 15 is a disconnected reader, the merging of the CCL's occurs only once the relative ages of those CCL's is ascertained. The merging of the CCL's includes first ensuring any change completion records from the local CCL are read from the token CCL by the reader, as a means for conveying the record, or records, to a connected reader and, hence, to the central CCL. The inclusion of the change completion records and the change request records within the CCL, and the systematic processing of CCL's through merging, allows effective two-way communication between the disconnected readers and server 23.

The hierarchy within system 1 includes server 23 at its apex. Below this sit all the connected readers. Below connected readers sit any disconnected devices, which includes both disconnected readers and tokens. As changes to the central CCL are made - typically to instruct the revocation of a given certificate when it is next presented to a reader - these are propagated to the local CCL's for the connected readers. This operation is a downward passage of information through the hierarchy, which occurs sequentially from the central sever 23 to the connected readers 15, from the connected readers to the tokens 7 and 8, and from the tokens to the disconnected readers 16.

System 1 also provides for sequential communication back up through the hierarchy, in the reverse order to that given above. The communication back up through the hierarchy occurs by conveying records - that is, the change completion records - that are indicative of a completion of a change for a given certificate. In system 1, when a token interacts with a connected reader, these change completion records are processed prior to the merging of the remaining change request records. This ensures that the change completion records, unlike the other records in the token CCL, are processed prior to the token CCL being overwritten due to the relative hierarchical positioning of the token and the connected reader. As server 23 sits higher in the hierarchy, all changes to the central CCL are reflected by corresponding records being included, in real time, in the local CCL's of all the connected readers. Accordingly, in the instance where there is included within the central CCL a new record indicative of a certificate to be revoked, the local CCL's for all the connected readers are merged with the central CCL. When the merging occurs, the timestamp for that local CCL is updated to the current time. The timestamp for the CCL is also updated when a change completion transaction is sent by a connected reader to server 23. The completed change request is deleted from the local CCL and the central CCL.

When tokens are presented to a disconnected reader, and following the initial interaction of the reader writing the change completion records to the token, there occurs a comparison of the timestamp applied to the token CCL and the local CCL. The merging of the change request records then occurs on the basis of the records from the more recent CCL of the two is used to overwrite the records of the other CCL. Importantly, the timestamp for the CCL is not changed but, rather, both the token CCL and the local CCL will have a timestamp that is the most recent of the those two timestamps included in the respective CCL's prior to the merging.

The collective result of this process - which occurs with all other cards or tokens that are presented to connected readers in this intervening period prior to the presentation of card Tl to a connected reader - is that the disconnected readers will be informed of certificate change requests. The only exception will be for disconnected readers that cards are not presented to in that period, hi large systems, such as the present embodiment, where there are many users, it has been found that there are typically only small delays in all the readers being updated. To further reduce the risks of having disconnected readers that are left with less reliable local CCL' s, care is taken in designing system 1. For example, by replacing some disconnected readers with connected readers. Importantly, this improves the performance of the system not only because there are less disconnected readers requiring updating of respective local CCL' s, but also because there are more connected readers to update the token CCL' s.

The tokens used in system 1 - in this case cards 7 and 8 - allow the local CCL' s for disconnected readers to be updated. This operation is facilitated by the two-step process of merging that is referred to above. That is, the initial processing of the change completion requests ensures that those requests are appropriately propagated back to server 23, while the second step of merging the remaining items in the CCL - in this embodiment the change request records - ensures that both the local CCL and the token CCL contain the most up-to-date information that shared between them.

Returning to the example provided in Figure 6, it will be appreciated that following the broadcast of certificate C2 to all the connected readers, Fred presents card Tl to one of those readers, in this example reader 15. The presentation is primarily performed by Fred to request access at the respective access point, and initially the process is the same, in that certificate Cl is read from token Tl by reader 15 to allow the reader to commence with the determination of whether or not access is to be granted or denied to Fred at that location and time. The reading by reader 15 is comprised of an identification signal 65 that contains, amongst other things, data indicative of certificate Cl . Next, any change completion records on the token CCL are processed, in that they are transmitted to server 23. In this example there are no such requests and, as such, the merging of the local CCL and the token CCL continues. This results in the change request records in the token CCL being overwritten by the change request records in the local CCL. hi effect, the local CCL - being the CCL of a connected reader - is up-to- date and takes precedence over the token CCL which, being only as recent as the last merge with a connected reader, is of lesser reliability. Once the reader identifies certificate Cl as one for which there exists a change request record within the local CCL, the reader sends a signal 66 to card Tl that results in the certificate Cl being revoked and deleted from or overwritten on card Tl . In the same circumstance for a disconnected reader, certificate Cl is not deleted but, rather, left in the memory of card Tl as there is no copy of the new certificate C2 held at the disconnected reader. However, the status of certificate Cl is changed to a "revoked" status and is, to some extent, still useable within system 1. The extent of the use is determined by the configuration of system 1, and ranges from full authorisation, to no authorisation. More typically, the authorisation will be limited, and time periods for obtaining the certificate C2 will be applied.

To confirm the revocation of certificate Cl from card Tl, reader 15 then sends a change completion record 67 to server 23. In response, server 23 generates change complete record 68 for certificate Cl that is broadcast to all connected readers, and which is processed by those readers to remove the corresponding change request record for certificate Cl from the local CCL' s of all the connected readers.

Reader 15 then generates a write signal 69 that writes certificate C2 onto card Tl and, following this, sends to server 23 a certificate completion signal 70 to confirm that certificate C2 has been issued to Fred. The reader then merges the local CCL with the token CCL to ensure the latter is brought up-to-date with the local CCL and, hence, the central CCL. This merge ensures that the token CCL for card Tl is up-to-date. In this example, the latest version of the local CCL reflects the recent removal of the change request record for certificate Cl from the local CCL. Following the completion of the merge, the token CCL will also no longer include the change request record for certificate d. Server 23 is responsive to signal 70 for generating an issue complete signal 71 for certificate C2 that is broadcast to all connected readers. This signal is processed by those readers to delete certificate C2 from the respective local memory. It will be appreciated that certificate C2 is no longer required at any of the readers as it has now been downloaded into card Tl . It will be appreciated that, at this point in time, reader 16, being disconnected, will not be in receipt of signal 68 and, as such, will still include a change request record for certificate Cl in the local CCL. However, for typical systems of the invention this is usually a shortly lived phenomenon. Particularly, where there are many cards or other tokens in use, it is usually only a short time before a card with a more recent token CCL is presented to reader 16. What is meant by the token CCL being more recent is that the respective card has been presented to a connected reader following the removal of a reference to certificate Cl from the central CCL. Accordingly, the token CCL does not include a change request for certificate Cl and, hence, nor will the local CCL following the merge with that more recent token CCL.

Figure 7 illustrates, for a further example, the steps and the information flows for changing the enrolment of a user, and corresponding features are denoted with corresponding designations. Particularly, the user - again being exemplified as "Fred" - having been issued with certificate Cl, now requires his access rights to be amended to correctly match a new role he has been assigned within a given organisation. In this example, following the enrolment change and the propagation of the relevant records by Peter from the connected reader 15 to the disconnected reader 16, Fred first presents card Tl to the disconnected reader 16. It will be recalled that in the Figure 6 example, following the change in the enrolment, Fred first presented card Tl to the connected reader.

An important difference arises in the Figure 7 example due to the fact that certificate C2 will not be available at reader 16 to download to card Tl. Notwithstanding, the local CCL of reader 16 will contain a certificate change request for certificate Cl, and this will be processed, with the end result being that the status of certificate Cl is changed to a "revoked" status. Additionally, a change completion record is generated by reader 16 and written to the token CCL on card Tl.

When card Tl is later presented to a connected reader, the change completion record will be read by that connected reader and sent to server 23, and the certificate C2 written to card Tl. rn the circumstances set out in Figure 7, certificate Cl remains valid for use, at least for a predefined period, notwithstanding the revoked status. In other embodiments, however, system 1 immediately invalidates certificate Cl if it is presented to a disconnected reader. Figure 8(a) and Figure 8(b) illustrate the steps of having a new change request record sent to and included within the local CCL of a connected reader. In summary: • The host (server 23) broadcasts the relevant change request (be that a change request record or an executed change record) to all the connected readers. • The readers each add the new requests to the CCL and delete the executed requests from the CCL.

• In all cases, the timestamp of the local CCL is updated.

• While adding records to the local CCL' s, if there is no space available in the local memory then executed records are deleted (oldest first) until there is sufficient space within the memory.

Figure 9 illustrates the steps of merging a token CCL and a local CCL. In summary:

• The CCL timestamp for the token CCL and the local CCL for disconnected readers are used to determine which is the more current CCL. For connected readers, it is assumed that the local CCL is current.

• Execution status of request records from the older CCL (SCCL) is merged into the newer CCL (DCCL).

• SCCL request records not existing in the DCCL are simply ignored (in that they are not carried to the DCCL).

• Connected readers look for any change completion records and send them back to server 23 and delete them from the CCL. If such entries are found the CCL timestamp is updated.

• The resulting CCL becomes the new local CCL for the reader and is also written to the token CCL.

Figure 10 illustrates the steps typically taken to authenticate a user. In summary:

• After verifying a valid token, the reader reads the certificate from the token.

• The certificate is decoded using the encryption key allocated for the purpose. • For the embodiments employing digital signatures, the reader calculates the digital signature and compares it with the signature on the certificate to verify it.

• If the signature is verified, the reader matches the token serial number with the one on certificate. If the match fails, the token is rejected.

• If the reader is equipped with a biometric device, it prompts the user for a corresponding biometric impression, image or other biometric measurement.

• The received biometric impression is converted to a template and compared with one or more biometric templates stored on the certificate. • In case of failure, the reader retries up to three times to get a biometric match. In other embodiments a different number of retries are used.

• On a successful match, or if the reader is not configured to have a biometric device, the token holder is authenticated. • Otherwise the token holder is rejected.

• If configured, the reader is able to destroy or revoke a rej ected tokens.

Once the token and the corresponding certificate are validated, the reader checks for any relevant known changes. This process is illustrated in Figure 11 and, includes, in summary: • The CCL from the token being merged with the local CCL of the reader, and the resulting local CCL being written to the memory of the token to define a new token CCL.

• The resulting local CCL (that is, the CCL on the reader) - which is equivalent to that now contained on the token - is used to check if the certificate is to be revoked.

• The local certificate store held by the memory of the reader is searched to determine if a new certificate is available for the token holder. If so, the new certificate is validated and updated on the token.

• The last two steps are repeated until no more new certificates are available for the user.

• If the final certificate is revoked, the token is rejected. Otherwise the token is accepted.

• In some embodiments, the readers are configured to keep the revoked certificates current for a limited period of time. That is, notwithstanding a certificate has a revoked status, it is able to be used for a limited time, or for limited purposes.

Once a token is accepted, the relevant reader extracts the access groups list from the certificate. This process is illustrated in Figure 12 and includes in summary:

• Each of the groups in the access groups list is searched for in the reader's access schedules.

• If any of the access schedule entry is found for the group, whose time schedule is active for the current time, the token is authorised.

• If no access group has any active time schedule, the token is rejected. An alternative reader 100 for system 1 is illustrated in Figure 16, where corresponding features are denoted by corresponding reference numerals. Reader 100, unlike readers 15 and 16, includes a dedicated I/O module 101 for interfacing with a sensor 101a for the door contact, a lock 15b for the door, and an infrared REX sensor 101d. Module 101 also provides a number of auxiliary I/O channels 101e. In other embodiments, modulelOl interfaces with additional and/or alternative external devices. hi an alternative embodiment system 1 is configured to operate differently, as will be described below. It will be appreciated by those skilled in the art, given the teaching herein, that system 1 is also able to be operated in other ways depending upon the specific circumstances of the site at which it is installed. hi this alternative embodiment the certificates for the users, as a minimum, are indicative of the authorisation information for the respective users. That is, the certificates in this embodiment are not necessarily indicative of identification information or authentication information. The tokens each include some form of identification information for the respective users and this is held in the memory of the token. Moreover, the tokens each include some form of authentication information for the respective users and this is held in the memory of the token.

This alternative embodiment only allows changes to the CCL to be made at the central CCL, with the result that those changes are propagated from there. For example, when a change completion request is received from a token CCL by a connected reader, that completion request is communicated to the server where the change request is removed from the central CCL. The central CCL is then merged with the local CCLs of the connected readers. That merging occurs either by: the server communicating with the readers to initiate the merge; or the readers communicating with the server to individually initiate the merge. That is, the former is a "push" communication outwardly from the server, while the latter is a "pull" by and toward the readers.

It will be appreciated by those skilled in the art, given the teaching contained herein, that a connected reader communicates the change completion requests to the server as the change requests are executed by that reader. This ensures that all executed change requests are communicated to the server, whether those requests were executed by a connected reader or a disconnected reader. Change requests that are competed at connected readers will be communicated to the server with little or no delay, while for disconnected readers there will be typically some delay. Some readers, particularly those in high security areas, require additional identification or authentication than is held in the memory of the token. In such instances, the readers of these alternative embodiment either includes a store of the required information - for example, where only very few users are actually authorised access at that access point - or seeks that information from network 11 on an "as- needed" basis.

For the alternative embodiment, change requests are only generated by server 23, and all executed change requests are communicated back to server 23. For connected readers that is relatively straightforward. For disconnected readers, however, the executed change requests are communicated from the relevant reader to the token, from the token to a connected reader, and then from the connected reader to server 23. It has been found that the most efficient means of managing the central CCL was by the connected readers sending all known executed requests back to the central server - which is then able to reliably update the central CCL by deleting the executed requests and adding new requests. Li addition, following every change to the central CCL, server 23 updates the CCL' s time stamp. The updated CCL is communicated back to the readers by server 23 either on demand or on command. For example, in some embodiments, server 23 sends the updated central CCL to all connected readers periodically if there is a change in the previous period. Alternately, the connected readers request for a CCL update from server 23 prior to processing a newly presented token. Li a further embodiment, the connected readers periodically request an update of the CCL. Whenever the connected readers receives a new CCL from server 23 the previous version held as the local CCL is discarded. This later function is based - as is stated at the top of this paragraph —that for all completed requests known to the connected readers a communication has already been sent to server 23.

As there are no individual change requests sent to the connected readers by server 23 the readers do not update the timestamps for the respective local CCLs. Accordingly, the central CCL will always have the most recent timestamp and when communicated to the connected readers will result in the local CCL being overwritten. With the above functionalities in place, there is an improved level of certainty that the local CCL held by the connected readers is up to date. Hence when a token is presented to and interrogated by a connected reader, the reader need have regard only to any completed requests on the token CCL, while discarding all others. The completed requests are processed by sending communications to server 23 and also updating the local CCL pending any central CCL update from server 23. The connected reader only need write the unexecuted requests on the token CCL. Otherwise, the logic of merging the CCL at disconnected readers essentially remains the same as described previously in this document.

The enrolment process for this alternative embodiment is illustrated in Figure 17, and this substitutes for the enrolment process of Figure 4 for the earlier described embodiment. It will be appreciated that corresponding steps in Figures 4 and 17 are denoted by corresponding reference numerals. The initial steps are similar to those of Figure 4, as substantially the same information is being compiled and saved. However, when creating the certificate at step 46 in Figure 17, regard is had only to the access information. As with the earlier described embodiment, the access information is indicative of the groups to which the user has membership.

Some other points to note about the process of Figure 17 are: • The host or server enrols a new user, as well as revoking or changing the access rights of that and other users. Any revocation or change of rights results in the revocation of an existing certificate and, for a change of rights only, the issuing of a new certificate for the user. Accordingly, the central CCL will for each change have a change request included. As the central CCL is merged with the respective local CCLs of the connected readers this change request will appear also at the local CCLs.

• The enrolment process gets all necessary identity information from the enrolment terminal 22, whether that be from direct capture of data at the time of enrolment, or from accessing previously stored data. An example of the latter includes cross-enrolment, where the user has already been enrolled to allow access to other functions of network 11.

• The token serial number is retrieved either from the enrolment reader or, alternatively, is manually entered by operator.

• The biometric image and relevant template is read from the enrolment reader. If cross enrolment is required the image is saved in the image database, otherwise it is discarded.

• Access information is also provided by the operator. • For re-enrolments or changes the relevant information is retrieved from the database.

• All necessary information is used to create a new certificate, which is saved in the database. • All certificates that become obsolete because of expiry or changes are revoked.

That is, rather than change a certificate, the old certificate is revoked and a new one issued. Once a new certificate is issued it is made available for updating on the respective token.

While the certificate includes primarily only authorisation information, the other information is used to allow operation of system 1. For example, in some embodiments, some identification information, such as an employee code, is included in the memory of the token, hi another embodiment, an encrypted record of one or more of the biometric templates for the user is stored in the memory of the respective token, hi this embodiment the connected readers communicate with server 23 to obtain additional authorisation information only for implementing advanced access control functionality such as supervisor required control, or minimum occupancy or maximum occupancy control.

Figure 18 illustrates schematically the sequence of steps and information flows following the enrolment of a new user who, in this embodiment, is referred to as "Fred". Following the creation of a certificate for Fred - that is, a certificate Cl - it is stored on server 23. Fred, having been issued with a token Tl, will at some time wish to be granted access at one of the access points. In doing so, token Tl is presented to a reader. Li this embodiment, the initial presentation of the token of a newly enrolled user must be to a connected reader. Once Fred presents token Tl to reader 100, the reader interrogates token Tl . This interrogation results in reader 100 providing a certificate Cl request event to server 23 which, in response, provides certificate Cl to the reader. The reader then writes certificate Cl to token Tl . At this point, token Cl is operable for allowing access control decisions to be made.

Figure 19 schematically illustrates the active management of change requests that is provided by the alternative embodiment of the invention. As mentioned above, a change request is only able to be entered to the central CCL, and when this occurs the timestamp for the central CCL is updated. Referring to Figure 19, once the change request is added to the central CCL, the local CCLs for connected readers are all updated to correspond to the central CCL. In this embodiment the local CCLs are updated periodically or on demand using one or more of the "push" and "pull" mechanisms described elsewhere in this document.

When a token is presented to a connected reader, the reader reads from the memory of that token the token CCL, extracts any change completion requests from the token CCL, and then merges the local CCL and the token CCL. Any change completion requests (or other executed request events) are communicated to server 23 which, in turn, updates the central CCL by deleting the relevant change request. The connected reader then writes the local CCL to the memory of the token to define the token CCL. At that instant, and because system 1 operates in real time, the token CCL is up-to-date. Importantly, the connected reader is not able to change the timestamp of the local CCL, as that functionality is reserved for server 23. Accordingly, in this example, the timestamp of the local CCL and the token CCL will both be the time and date at which the local CCL was last synchronised with - that is, overwritten by - the central CCL.

As also illustrated in Figure 19, when the token is presented to a disconnected reader the operation is as described above. That is, the token CCL is read by the disconnected reader and, on the basis of the timestamps of the local CCL and the token CCL, a merging of the CCLs occurs. If this results in any changes to the local CCL, the token CCL is overwritten by the new local CCL.

Figure 20 illustrates the sequence of actions and information flows resulting from a change in the access rights for the user Fred, and where Fred, following that change, first presents token Tl to connected reader 100. In this embodiment, a change in the access rights is dealt with by revoking the certificate Cl which is indicative of the earlier access rights and generating a new certificate C2 which is indicative of the new access rights. Once the relevant entries have been made - typically via terminal 22 or a like terminal - the central CCL is updated to include a change request to revoke certificate Cl, while the central store of certificates is updated to include certificate C2. If a user other than Fred, in this case a user referred to as "Peter", presents their token T2 to a connected reader prior to Fred having done so, the token CCL for token T2 will be changed to reflect change request for Fred. If, in turn, Peter presents token T2 to a disconnected reader, the change request will be propagated to that disconnected reader as the token CCL will merge with the local CCL. That is, the disconnected readers are progressively updated to include the most recent requests.

When Fred does present token Tl to reader 100, certificate Cl will be deleted, and certificate C2 retrieved from the central certification store and written to token T2. The token is then configured to allow access control decisions to be made on the basis of the new access rights that have been assigned to Fred.

Figure 21 is similar to Figure 20 with the exception that following the change of access rights Fred presents the card initially to disconnected reader 16.

Reference is now made to Figure 22 which illustrates the steps used in this alternative of the invention to updating the central CCL. Li particular:

• The enrolment system (in the form of terminal 22) sends change requests to server 23 to be included in the central CCL.

• The connected readers send executed change requests to sever 23 which, in response, deletes these executed requests from the central CCL. • The timestamp of the central CCL is updated if there is any change to the central

CCL.

Figure 23 is a flow chart illustrating the steps used in the alterative embodiment o merge CCLs. hi particular:

• A reader, whether a connected reader or a disconnected reader, merges the local CCL with the token CCL when the corresponding token is interrogated by that reader.

• Connected readers have a local CCL that is synchronised with the central CCL.

• The timestamps of the token CCL and the local CCL are used to decide which is the more current CCL. Moreover, readers cannot update timestamp of any CCL. • The execution status of a request from an older CCL (SCCL) is merged into the newer CCL (DCCL).

• SCCL requests not existing in DCCL are simply ignored. That is, they are not carried into the DCCL).

• A connected reader looks for any executed change requests and sends them back to server 23 as events, and then deletes them from the local CCL.

• The resulting CCL becomes the new local CCL for the reader and is also written to the Token Figure 24 is a flow chart illustrating the steps used by the readers in the alternative embodiment to write to the token CCL. In particular:

• The readers update the token CCL with a copy of their updated local CCL.

• The token CCL is of limited size. • The newest unexecuted entries are written first.

• Executed entries are written if space permits.

• The CCL timestamp is copied unchanged.

• The base certificate issue date is copied unchanged.

The steps of authenticating a user in the alternative embodiment is substantially the same as the earlier described embodiment. For the sake of completeness it is mentioned that this includes:

• After validating a token, the reader reads the certificate from the token.

• The certificate is decoded using the relevant key allocated for that purpose.

• If a digital signature is being used, the reader then calculates the digital signature and compares it with the signature on the certificate to verify the signature. If the signature is not verified, the token is rejected.

• If a signature is used, and verified, the reader matches the token serial number with the one on the certificate. If this fails, the token is rejected.

• If the reader is equipped with a biometric device, it prompts the user and subsequently obtains a sample of the relevant biometric information.

• The received biometric template is compared with templates stored on the certificate.

• In case of failure, the reader retries up to three times to get a biometric match. In other embodiments an alternative number of retries is used. • On a successful match, or if the reader is not configured to have a biometric device, the token holder is authenticated.

• Otherwise the token holder is rejected.

• If configured, the reader can destroy the rejected tokens or revoke them. Once the token and the certificate are validated, the reader checks for any relevant known changes. For connected readers this includes a request for the most recent CCL from server 23. The CCL from the token is then merged with the local CCL, and the certificate issue date is checked with the base system issue date. Any certificates that were issued prior to the base system date are revoked. The resulting CCL is used to check if the certificate read from the token is revoked and, if so, the connected readers try to get new certificate for the token. If a new certificate is obtained, this too is checked to determine if it is valid. If not, the new certificate is also revoked, and a further certificate is sought. This process is repeated either until a valid certificate is obtained, or no new certificate is available for the token. As a disconnected reader does not have access to server 23 to obtain any new certificates, if a token containing a revoked certificate is presented to that reader it will still be accepted as current, although typically only for a limited period of time. In some embodiments, however, disconnected readers are configured to reject a token having a revoked certificate.

Once the token is accepted, the reader extracts the access groups list from the certificate. Each of the groups in the access groups list is searched for in the reader's access schedules. If any of the access schedule entries are found for the group, whose time schedule is active for the current time, the token is authorized. Alternatively, if no access group has any active time schedule, the token is rejected.

The alternative embodiment particularly provides for active access rights management, which includes the following:

• The host server provides a central CCL that is the reference CCL for connected readers. Only the server adds new requests to and deletes executed requests from the central CCL. The local CCL of the connected readers is regularly updated from the central CCL.

• The tokens carry certificate change lists between connected and disconnected readers.

• The readers merge the local CCLs with token CCLs as described previously in this document.

The active access rights management is, in effect, allowing the size of the CCLs to be contained, hi typical embodiments, this allows the entire CCL to be easily stored in the memory of a token and thus allowing it to be conveniently communicated to all disconnected readers. As all readers ,are aware of substantially up-to-date change requests the preferred embodiments of the invention are able to provide:

• A long expiry period for certificates.

• Protection against peak period bottlenecks, as certificates do not have to be reloaded onto the cards regularly. • Strong Audit Trail is provided due to a history of all transactions being recorded. The tokens carry transactions logs from the disconnected readers; and connected readers extract the history from the tokens and transfer the records to the host server along with their own transactions. • Identity Management is enhanced, as tokens are able to carry multi-factor identification and authentication for both physical and logical access. The broad functionalities provided by the preferred embodiments include:

• The readers themselves, in combination with the information obtained from the token, are sufficiently well informed to make access control decisions. • Eliminate the need for access control panels.

• Accommodates disconnected readers. That is, the readers do not have to be connected to allow the functionality to be achieved. (It does, however, assume each system has at least one connected reader).

These broad functionalities give rise to the following advantages: • A reduced total life cycle costs for the system.

• A disconnected architecture.

• Reduced wiring and installation costs.

• Installation of readers on a moving vehicle or other places which are not in communication (or continuous communication) with the host server. • Ease of maintenance.

• Highly scalable to many thousands of access points and many thousands of users spread across facilities in multiple jurisdictions.

• Unlike prior art controllers, the readers do not hold any data indicative of token users. • The tokens carry their own configuration data.

• Unlimited number of tokens accommodated.

• Unlimited number of readers accommodated.

• Unlimited number of nested Anti pass-back zones (which will be described in more detail below). • Strong multi-factor authentication..

• Secure anti-playback communication between the reader and the token. — ^9 —

ANTI PASS-BACK (APB) FUNCTIONALITY

System 1 is configured to provide anti pass-back (APB) functionality between selected access points. By way of example, reference is made to Figure 13 where there is illustrated a facility, in the form of a site 80, at which system 1 (of which only some elements are shown) is installed. Site 80 is defined by a perimeter fence and includes a plurality of zones, some of which are nested, and some of which are anti pass-back (APB) zones. It will be appreciated that an APB zone is one that requires the user to request and be granted access by a reader to progress into that zone, and to leave that zone. That is, once a user has entered an APB zone, it is necessary for the system to be notified of the user's exit from that zone prior to that same user being allowed subsequent entry to that zone.

The system includes a plurality of access points between respective pairs of zones that are selectively accessed by a plurality of users. As with the earlier described embodiment, the access points are pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access between zones in the pairs of zones.

The zone that lies beyond the perimeter fence of site 80 is defined as Zone 0. The zone that lays within the perimeter fence and which is not bound by a nested zone is defined as Zone A. In this embodiment, Zone A and Zone C are APB zones, while Zone B and Zone D are not APB zones. Zone B is wholly included within APB zone A and hence, if a user has access to Zone A or Zone B, he or she is considered to be in APB zone A. Similarly, if a user has access to Zone C or Zone D, he or she is considered to be in APB zone C. It will be appreciated by those skilled in this art that the "last APB zone" in the zone record of the token is indicative of this information. Site 80 includes two access points (not shown) adjacent to which are disposed respective readers 81 and 82. Users of the system present access tokens to reader 81 and reader 82 to seek access to Zone A from Zone 0 and to Zone 0 from Zone A respectively. Typically, for an APB zone, the readers for determining if access is to be granted from one zone to the other zone are installed at a different access point to a reader that determines if access is to be granted from the other zone to the one zone. That said: in some embodiments a single access point includes two readers, one of which is disposed in respective ones of the zones in the respective pair of zones. Located at site 80, and within Zone A, are two spaced apart secure buildings 83 and 84 the interiors of which respectively define a Zone B and a Zone C. These latter zones are nested within Zone A. Zone C is an APB zone, while Zone B is not.

Building 83 includes a reader 85, and building 84 includes two spaced apart readers 86 and 87 that are disposed adjacent to corresponding access points (not shown) for allowing users to seek access to and from those buildings. As Zone B is not an APB zone, the access point associated with reader 85 includes a request to exit (REX) device. It will be appreciated that reader 85 is disposed adjacent to the access point in Zone A, while the REX device is disposed adjacent to the same access point, but in Zone B. When a user triggers the REX device, the access point is pulsed to the unlocked configuration to allow the user to progress from Zone B to Zone A.

The REX device typically takes the form of a button or switch that is manually actuated by the user, or an infrared sensors or other sensor that detects the likely presence of a user approaching the access point from the relevant one of the zones in the pair of zones associated with that access point. In other embodiments, the REX device is located at an exit (not shown) other than the access point at which reader 85 is disposed. In this case, the exit is typically an "exit only" peripheral door. Alternatively, the REX device includes a door handle for an exit door, where the handle is, in normal use, accessible and manually operable only by users within Zone B. Building 84 includes an internal room 89, the interior of which defines a Zone D that is not an APB zone. A reader 90 is disposed adjacent to an access point (not shown) for allowing selective passage of users between Zone C and Zone D. Similarly to reader 85, reader 90 includes a corresponding REX device for facilitating the automated granting of access to users desiring to progress from Zone D to Zone C. While in this embodiment all of readers 81, 82, 85, 86, 87 and 90 are disconnected readers, in other embodiments one or more of those readers are connected readers. It will be appreciated from the teaching herein that the APB functionality provided by the embodiments of the invention are independent of the connected or disconnected configuration of the readers. As such, alternative embodiments accommodate different combinations of connected and disconnected readers.

It will be appreciated that while Figure 13 only provides minimal access points between adjacent pairs of zones, that this is for illustrative purposes only. While some embodiments include only the minimal number of access point, more typically, and especially within larger installations, some of or each zone will have multiple readers and associated access points through which users are able to enter and exit a given zone.

System 1, as exemplified in Figure 13, offers infinite levels of nested APB functionality. That is, infinite levels of nested APB zones are possible. Moreover, the APB functionality is achieved in systems having only disconnected readers, such as that illustrated in Figure 13, or in systems having a combination of connected and disconnected readers.

The APB functionality means that if a user enters a given zone, then he or she cannot re-enter that same zone unless system 1 has a record of that user leaving the zone after having entered the zone. The purpose of the APB functionality is to prevent users from unwittingly or knowingly sharing their respective smart cards or other tokens with other users or unauthorised personnel. For example, in a system with no APB functionality, an unscrupulous or ill-disciplined user is able to enter a zone and then throw the token to a fellow user - for example, through an external window of a building - to allow the fellow user or other individual to enter the same zone.

The APB functionality also makes it awkward for users to enter a zone without individually presenting their respective tokens and, hence, provides an improved environment for encouraging proper and complete use of system 1. For example, if two authorised users who are known to each other — referred to as a first user and a second user - simultaneously approach an access point, it is not unusual for only one of those users - say, the first user - to present their respective token to pulse the access point. That is, both the first and the second user will have gained access to a given zone, notwithstanding that the information contained on system 1 would evidence only that the first user has entered that zone. While the second user has access to the zone, as soon as that second user attempts to enter a nested zone, or to exit the present zone, the relevant reader will disallow access due to the operation of the APB logic. This functionality has particular efficacy when applied to the combination of physical access - for example, at the entrance to a building - and virtual access - for example, the ability to log onto a computer network. That is, system 1 is able to be configured to only allow access to the network for those users who system 1 indicates as being within a given building or other facility. This applies not only to a user logging onto the network via a cable or other physical connection, but also to those logging on via a wireless connection. Normally, APB functionality is used for peripheral doors of buildings. However, in some embodiments, it is used internally particularly for high security areas.

The term "zone", in the context of Figure 13, means a bounded area or space having one or more access points and corresponding readers. An access point will be either an entry access point - where a user seeks entry into a zone - or an exit access point - where a user seeks exit from a zone. The entry access points and the exit access points include corresponding entry readers and exit readers respectively. Accordingly, an APB zone and a non APB zone will each have at least one access point having a corresponding entry reader. An APB zone will have, in addition, at least one access point having a corresponding exit reader. A user must use an entry reader to enter a given zone. If an exit reader is included, the user must use that exit reader to leave that zone. This allows system 1 to acquire records for each entry into, as well as each exit from, the zone. hi those instances where an access point does not have an exit reader there is typically included an automatic request to exit buttons or motion sensors for triggering a pulse of the access point between the locked to the unlocked configurations.

Conventional wisdom dictates that the implementation of APB functionality requires entry readers and exit readers to communicate with each other directly or via a controller or the server. This being on the basis that the readers require information about which users went in and which users went out, for otherwise, it becomes impossible to make the correct access control decision. The embodiment in Figure 13, however, avoids the need for such communication between the entry readers and the exit readers by:

• Configuring each reader - be that an entry reader or an exit reader - to have a reader record that is indicative of the pairs of entry zones and exit zones and pairs of entry APB zones and exit APB zones (which are described further below).

• Holding on each token a zone record that is indicative of at least one of the zones, m this embodiment, the zone record is indicative of: the APB zone to which the token was last granted access ("the last APB zone"); and the zone to which the token was last granted access ("the current zone"). In this embodiment, the reader record designates one of the zones as an entry zone in which the user is located when polling the access point, and the other of the zones as an entry APB zone to which the user will progress if access is granted.

The reader record is also indicative of a pair of anti pass-back (APB) zones which comprise: an exit APB zone in which the user is disposed when polling the access point; and an entry APB zone to which the user will progress if access is granted. The reader is responsive to one or both of the entry APB zone and the exit APB zone for if access is to be granted or denied.

In an embodiment, the reader is responsive to the entry APB zone and the exit APB zone for determining if the access is to be granted or denied.

The entry zone and the exit zone for a reader are the two zones in the pair of zones relevant to that reader. For example, reader 81 includes a reader record with the exit zone defined as Zone 0, and the entry zone defined as Zone A. The exit APB zone is defined as Zone 0, and the entry APB zone is defined as Zone A. Similarly, reader 82 includes a reader record with the exit zone defined as Zone A, and the entry zone defined as Zone 0. The exit APB zone is defined as Zone A, and the entry APB zone is defined as Zone 0. However, Zone B in not an APB zone but, rather, is included within the APB zone A. In this case the entry reader 85 includes a reader record with the exit zone defined as Zone A, and the entry zone defined as Zone B. The entry APB zone, as well as the exit APB zone, are both defined to be Zone A.

When a token is presented to a reader, and access is granted, the reader writes to the token to update the zone record. That is, to update at least the current zone to be the entry zone for that reader, that being the zone to which the user was just granted access.

Additionally, if the entry APB zone is different to the exit APB zone, the zone record is also updated to ensure that the last APB zone on the token equates to the entry APB zone of the reader. In another embodiment, both the current zone and the last APB zone are updated following each instance of access being granted.

The zone records, and other information contained on the token, are encrypted to protect their integrity and security. However, in other embodiments, no encryption is used, or only some of the information is encrypted.

The current zone is indicative of the zone where the token should be, based on the history of reader interrogations that has occurred. As mentioned above, the current zone is derived from the entry zone record of the reader that last granted access to the token.

In an embodiment, if the exit APB zone is different to the entry APB zone, the reader determines whether the last APB zone matches the exit APB zone. If the result of this determination is true, the access is granted, otherwise the access is denied.

The above steps are referred to as the APB logic, and are set out schematically in the flowchart of Figure 14.

As mentioned above, the area outside site 80 is configured as Zone 0. Accordingly, all the tokens are initialised with the current zone as Zone 0, and the last APB zone as Zone 0, before the first request for entry to Zone A. This is on the basis that the tokens are configured and issued away from site 80. hi other embodiments where the token is configured and first issued to a user within site 80, the configuration corresponds to the zone and APB zone in which the token is disposed at that time. That is, in all the preferred embodiments, newly issued tokens are initialised with the current zone and the APB zone corresponding to the respective zones where the card is issued.

If, for example, a user is first trying to enter site 80, his or her token has the current zone = 0 and last APB zone = 0. Reader 81 will be configured with exit zone = 0, and entry zone = A. Also, reader 81 is configured with exit APB zone = 0, and entry APB zone = A. When the token is presented at reader 81, because the exit APB zone is different to the entry APB zone, system 1 checks to ensure that the last APB zone held on the token matches the exit APB zone of the reader. If that holds true, and all other access tests being met, access is granted to the user. As part of that process, reader 81 writes to the token to set the current zone = A, and the last APB zone = A.

In the absence of other changes to the information held by the token, if it is presented to reader 81 to again request access to Zone A, the above APB logic will fail, and the user will not be granted access. That is, the last APB zone = A, and this is not the same as the exit APB zone of the reader which is configured to be 0.

It will be appreciated that the entry APB zone and the exit APB zone for a reader record are the same if the reader is disposed at an access point which controls access to a non-APB zone.

When the token is presented to reader 82 to request an exit from Zone A, the above APB logic when applied to the information held on the token will succeed. On the basis that all other requisite determinations are positively carried out, the exit is allowed. (That is, the requested access is granted). During that process, reader 82 updates the token to include current zone = 0. That is, to update the current zone to equate to the entry zone of reader 82. Additionally, the last APB zone is updated to 0. With the above steps followed, the user will be allowed to enter site 80 again. The APB functionality has only been described with reference to a passage from

Zone 0 to Zone A, and back to Zone 0. Notwithstanding, it will be appreciated from the teaching herein that a passage between any of the zones in Figure 13 is regulated with similar steps, and the application of the same APB logic of Figure 14 holds.

As long as the APB zones are nested - which is always so in the embodiments of the invention - the above APB logic will work infinitely. Accordingly, infinite levels of APB functionality are provided by the embodiments, even when use is made of disconnected readers.

The APB functionality provides filtering of users and their ability to gain access at the access points on the basis of a given token being presented to a given reader. The identification information and/or the other information carried on the token - such as the certificate, and/or the authorisation information - provide another filtering of users and their ability to gain access via that same access point and on the basis of that same token being presented to that same reader. For convenience, these two filters are respectively said to allow an APB determination and a user determination. In this embodiment, the reader makes the user determination prior to making the APB determination. However, in other embodiments, the user determination is made after the APB determination. In further embodiments, substantially all the action required to make a first of the determinations is taken prior to the actions required to make a second of the determinations. In the embodiment illustrated in Figure 13 the APB functionality is operational on all relevant readers for all normal operational periods of system 1. However, in other embodiments, the APB functionality only applies at given times in a day, or to given users, or due to different threat or alert levels.

Byway of summary, the following applies to the embodiment of Figure 13: • Unlike normal zones, anti pass-back (APB) zones have no Request To Exit

(REX) device. A valid token must be used to exit from an APB zone, just as for entering a zone. • All Readers are configured with entry zones and exit zones, as well as entry APB zones and exit APB zones.

• Non-APB zones are considered to be included in the immediately enclosing APB zone (if any). For example, in this Figure Zone A and Zone C are APB zones. Zone B is included in APB Zone A, and Zone D is included in APB

Zone C.

• Tokens hold information (records) about the current zone, and the last APB zone.

• If the entry APB zone of the reader is different to the exit APB zone of the reader then the last APB zone of the token must match the exit APB zone of the token for access to be granted.

Another embodiment of the invention is schematically illustrated in Figure 15. The system includes a plurality of readers, the configuration for each of which is provided in the following table.

Reader No. Entry Zone Exit Zone Entry APB Zone Exit APB Zone

Reader 1 A 0 A 0

Reader 2 0 A 0 A

Reader 3 B A A A

Reader 4 C A C A

Reader 5 A C A C

Reader 6 D C C C

The embodiments of the invention described above allow scalability to be advantageously achieved through the active management of the central CCL, the local CCL's and the token CCL's. This management provides two-way communication between readers, tokens and the host server in a structured way. The hierarchy of the CCL's within system 1 is one element contributing to the functionality of the embodiments. Another element is the inclusion within the CCL of not only certificate change request records, but also the certificate change completion records. These, in combination with a structured processing of the change completion records and the change request records, allow the connected and disconnected elements of system 1 to communicate effectively. The active management provided by the system of the preferred embodiments avoids the need for any re-initialising of the CCL as its size is automatically contained. Accordingly, the certificates are able to have long issue periods which, in this embodiment, are up to about one year or more. The limitation of the period is more typically the anticipated safe working life of an encryption key used by the system, and not the storage capacity of the readers or other components within the system.

The APB logic provided by the system of the preferred embodiments avoids the need for the entry and exit readers of an APB zone to be physically connected to each other via any of several commercially available wired or wireless means. Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that it may be embodied in many other forms.

Claims

1. An access control system for at least one access point that is selectively accessed by a plurality of users, the access point being pulsed between a locked and an unlocked configuration for respectively preventing and allowing the users access at the access point, the system including: an access token for each of the users, each token including memory for containing a certificate and a token certificate change list (token CCL), each token being responsive to an interrogation signal for generating a token signal derived from the certificate; a computer network for containing information indicative of the certificates and for providing a central CCL that is indicative of changes that are required to one or more of those certificates; and an access reader for each access point that communicates with the network for maintaining a local CCL, the or each reader generating respective interrogation signals and being responsive to the corresponding token signals for: determining if the respective access point is to be pulsed to the unlocked configuration; and merging the local CCL and the token CCL.

2. A system according to claim 1 wherein the memory contains other information.

3. A system according to claim 1 wherein the token signal is derived from the certificate and the token CCL.

4. A system according to claim 1 wherein each certificate includes for the respective user authorisation information.

5. A system according to claim 1 wherein each certificate includes for the respective user authorisation information and one or more of: authentication information; and identification information.

6. A system according to claim 1 wherein the changes of which the central CCL is indicative include one or more of: a revocation of the one or more certificates; a change to the authentication information for the one or more certificates; and a change to the authorisation information for the one or more certificate.

7. A system according to claim 1 wherein the certificate includes validity information indicative of creation and/or expiry conditions for the certificate.

8. A system according to claim 1 wherein each CCL includes a plurality of records.

9. A system according to claim 8 wherein each record is one of: a change request record that is indicative of a certificate that is to be changed; a change completion record that is indicative of confirmation that a particular certificate has been changed; a timestamp for the CCL; and a base creation date for the certificates that are valid.

10. A system according to claim 9 wherein the central CCL does not include a change completion record.

11. A system according to claim 9 wherein the or at least one of the readers communicates with the network and the merging of the token CCL and local CCL includes the respective reader: reading from the token CCL any change completion records; and writing the local CCL to the token CCL.

12. A system according to claim 11 wherein the writing the local CCL to the token CCL includes overwriting the token CCL.

13. A system according to claim 1 wherein the reader or readers upon interrogating the token generate respective transaction logs that are communicated to the network.

14. A system according to claim 1 including one or more readers that do not communicate with the network wherein those readers, upon interrogating the token, generate respective transaction logs.

15. A system according to claim 13 or claim 14 wherein the transaction logs are indicative of one or more actions of respective readers.

16. A system according to claim 14 wherein each of the one or more readers that do not communicate with the network write to the memory of the token the respective transaction log.

17. A system according to claim 16 wherein when the token is subsequently interrogated by a reader that does communicate with the network the transaction log is read from the memory of the token and communicated to the network.

18. An access control system for a plurality of access points between respective pairs of zones that are selectively accessed by a plurality of users, the access points being selectively pulsed between a locked and an unlocked configuration for granting or denying the users access between zones in the respective pairs of zones, the system including: an access token for each of the users, each token including memory for containing a zone record indicative of at least one of the zones, each token being responsive to an interrogation signal for generating a token signal derived from the record; and an access reader for each access point, the readers having respective reader records indicative of one of the pairs of zones, the reader generating an interrogation signal and being responsive to the corresponding token signal and the reader record for determining if the access is to be granted or denied.

19. A system according to claim 18 wherein the reader record designates one of the zones as an exit zone in which the user is located when polling the access point, and an entry zone to which the user will progress if access is granted.

20. A system according to claim 19 wherein the entry zone and the exit zone are physical spaces.

21. A system according to claim 19 wherein the reader record is indicative of: an exit anti pass-back (APB) zone in which the user is located when polling the access point; and an entry APB zone to which the user will progress if access is granted.

22. A system according to claim 21 wherein the reader is responsive to the entry APB zone and the exit APB zone for determining if the access is to be granted or denied.

23. A system according to claim 18 wherein at least one of the zones is an anti pass- back (APB) zone.

24. A system according to claim 23 wherein the zone record is indicative of whether or not the one or more zones is an APB zone.