WO2006021047A1 - Systeme et procede de commande d'acces - Google Patents

Systeme et procede de commande d'acces Download PDF

Info

Publication number
WO2006021047A1
WO2006021047A1 PCT/AU2005/001285 AU2005001285W WO2006021047A1 WO 2006021047 A1 WO2006021047 A1 WO 2006021047A1 AU 2005001285 W AU2005001285 W AU 2005001285W WO 2006021047 A1 WO2006021047 A1 WO 2006021047A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
ccl
reader
access
zone
Prior art date
Application number
PCT/AU2005/001285
Other languages
English (en)
Inventor
Pareen Kumar Goel
Original Assignee
Honeywell Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2004904895A external-priority patent/AU2004904895A0/en
Application filed by Honeywell Limited filed Critical Honeywell Limited
Priority to CN2005800363714A priority Critical patent/CN101052970B/zh
Priority to EP05773644A priority patent/EP1807788A4/fr
Publication of WO2006021047A1 publication Critical patent/WO2006021047A1/fr
Priority to HK08103363.5A priority patent/HK1113213A1/xx

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00817—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the lock can be programmed
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/27—Individual registration on entry or exit involving the use of a pass with central registration
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00817—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the lock can be programmed
    • G07C2009/00849—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys where the code of the lock can be programmed programming by learning
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
    • G07C9/25—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition
    • G07C9/257—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition electronically

Definitions

  • TITLE AN ACCESS CONTROL SYSTEM AND A METHOD OF ACCESS CONTROL
  • 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.
  • Known access control systems include a plurality of access readers that are disposed at or adjacent to respective access points at a given facility.
  • 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.
  • 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.
  • the controllers need not revert to the host server or server for each of those instances.
  • 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.
  • This information is indicative of the level of access rights available to the user.
  • 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.
  • 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.
  • the user authorisation information recorded on the smart cards is inaccessible to the host servers and the controllers.
  • CRL Certificate Revocation List
  • 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.
  • 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.
  • the memory contains other information.
  • 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.
  • each certificate includes for the respective user authorisation information.
  • each certificate includes for the respective user authorisation information and one or more of: authentication information; and identification information.
  • each certificate includes for the respective user identification information, authentication information and authorisation information.
  • the certificate include information in addition to the above types of information.
  • 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.
  • the central CCL does not include a change completion record.
  • 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.
  • the changes of which is the CCL is indicative is only a revocation of the one or more certificates.
  • the certificate includes validity information indicative of creation and/or expiry conditions for the certificate.
  • the validity information is indicative of one or more dates and/or times.
  • 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, the local CCL and the token CCL include respective validity information indicative of the time of creation for the respective CCL.
  • 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.
  • the identification information is indicative of a unique identifier associated with user.
  • the authentication information is indicative of one or more reference points for confirming the authenticity of the user presenting the token to the reader.
  • 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.
  • 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.
  • 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.
  • 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.
  • the threat level defines the overall security threat to the access points as perceived typically by an administrator of the system.
  • 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.
  • the central CCL has only change request records.
  • 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.
  • the writing the local CCL to the token CCL includes overwriting the token CCL.
  • 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.
  • 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.
  • the merging of the local CCL and the token CCL occurs prior to the determining if the access point is to be pulsed.
  • 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.
  • 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.
  • the access system includes disconnected readers that communicate with the network via the tokens.
  • the reader or readers upon interrogating the token generate respective transaction logs that are communicated to the network.
  • 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.
  • 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.
  • the transaction logs are deleted from the memory of the token.
  • 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.
  • 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.
  • the transactions log or logs stored in the memory of a token relate to transactions for that particular token.
  • logs for transactions related to other tokens are able to be stored in the memory of that particular token.
  • 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.
  • 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 token certificate change list (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.
  • CCL token certificate change list
  • the token signal is derived from the certificate and the token CCL.
  • the merging occurs prior to the determining if the access point is to be pulsed.
  • 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.
  • the interrogation signals and the token signals are wireless signals.
  • 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.
  • 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.
  • the certificates are unique for each token.
  • 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.
  • 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.
  • 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 token for each of the users, each token including
  • 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 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.
  • token CCL token certificate change list
  • 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 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the entry zone and the exit zone are physical spaces.
  • one or more of the zones are virtual zones. That is, one or more the zones are, in some embodiments, computer environments.
  • 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.
  • 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 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.
  • the reader 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.
  • the reader updates the zone record.
  • the reader updates the zone record to change both of the last APB zone and the current zone.
  • 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.
  • 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 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
  • FIG 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
  • Figure 24 is a flow chart illustrating the steps used by the readers in the alternative embodiment to write to the token CCL.
  • 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.
  • 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.
  • 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?"
  • 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.
  • authentication refers to the process of verifying that the person providing the identification information is entitled to provide that information.
  • 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.
  • 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)
  • 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.
  • 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)
  • 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?"
  • 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.
  • 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.
  • access reader refers collectively to the hardware and software that are associated with an access point and which communicate directly to a host server.
  • 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.
  • 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”).
  • 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.
  • 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.
  • 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.
  • disconnected readers are said to have disconnected CCL' s
  • 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.
  • 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.
  • central CCL refers to the CCL stored or otherwise held by the network
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 "pulsed”, in the context of an access point, refers to the progression from a locked configuration to an unlocked configuration.
  • 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.
  • 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.
  • anti pass-back zone or "APB zone”
  • APB zone 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a PIN a password
  • a digital signature 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • controller 24 is provided by other devices, for example server 23.
  • the components of network 11 are linked by any suitable Ethernet cable 25.
  • 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.
  • system 1 is implemented at a facility other than a building to which access rights are desired to be controlled or regulated.
  • 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 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.
  • 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.
  • equipment such as computer devices such as desktops computers, laptop computers, PDA's, cellular telephones, measurement equipment, power tools, and the like.
  • 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.
  • the authorisation information in some embodiments is derived from data indicative of the currency or extent of the user's training.
  • 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.
  • 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.
  • 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.
  • 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).
  • circuitry 31 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an attempt to gain access includes:
  • 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.
  • REX REX sensor
  • a REX sensor in the form of a wall- mounted button is included.
  • 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.
  • 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.
  • 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.
  • the serial number is manually entered into terminal 22. All this gathered textual information is collectively stored at step 38 into database 21.
  • additional identity information is obtained in the form of one or more high quality biometric images of the user.
  • the hardware for gathering that or those images is connected to and driven by terminal 21.
  • 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.
  • 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.
  • the earlier captured image or images are discarded following the creation of the templates.
  • 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.
  • terminal 22 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.
  • step 45 involves the creation of a new certificate for the user. This is undertaken by server 23, which combines:
  • 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.
  • 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.
  • 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.
  • a card Tl or other token, that is issued to Fred.
  • the card will be interrogated by reader 15.
  • 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.
  • the certificates include additional or alternative information.
  • 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).
  • 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).
  • reader 15 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.
  • reader 15 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.
  • server 23 broadcasts to all connected readers a certificate delete request 56 for certificate Cl.
  • 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.
  • local memory In that it is local to the reader and distinct from the memory capacity that is directly available to server 23.
  • 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.
  • 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.
  • alternative methodologies are used to contain the amount of information held at individual readers due to the enrolment process.
  • 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.
  • 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.
  • the features of enrolment are:
  • the host server (server 23) enrols new users, as well as revokes or changes their access rights.
  • 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.
  • the biometric image, or images is read from the enrolment reader.
  • 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:
  • One or more predetermined biometric templates " An identifier for one or more access groups.
  • ⁇ Access control flags including:
  • the certificate includes encrypted data indicative of different types or forms of information.
  • 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.
  • FIG 4 - the newly created access information is stored in database 21 - that is, at step 44 of Figure 4.
  • 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.
  • 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.
  • 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.
  • the writing from the local CCL to the token CCL of the change request records is designated as signal 64.
  • reader 15 makes an access control decision for Peter at the given access point.
  • 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.
  • 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.
  • 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.
  • 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.
  • the local CCL's for all the connected readers are merged with the central CCL.
  • 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.
  • 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.
  • 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.
  • 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.
  • reader 15 sends a change completion record 67 to server 23.
  • 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.
  • the latest version of the local CCL reflects the recent removal of the change request record for certificate Cl from the local CCL.
  • 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.
  • 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.
  • Fred 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.
  • Fred first presented card Tl to the connected reader.
  • FIG. 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.
  • the host server 23
  • the readers each add the new requests to the CCL and delete the executed requests from the CCL.
  • Figure 9 illustrates the steps of merging a token CCL and a local CCL.
  • Figure 10 illustrates the steps typically taken to authenticate a user.
  • 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.
  • the reader 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.
  • the token holder 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.
  • the reader is able to destroy or revoke a rej ected tokens.
  • 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 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.
  • 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.
  • modulelOl interfaces with additional and/or alternative external devices.
  • system 1 is configured to operate differently, as will be described below.
  • system 1 is also able to be operated in other ways depending upon the specific circumstances of the site at which it is installed.
  • the certificates for the users 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.
  • 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.
  • 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.
  • change requests are only generated by server 23, and all executed change requests are communicated back to server 23.
  • 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.
  • 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.
  • server 23 sends the updated central CCL to all connected readers periodically if there is a change in the previous period.
  • the connected readers request for a CCL update from server 23 prior to processing a newly presented token.
  • 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.
  • 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 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.
  • 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.
  • the certificate includes primarily only authorisation information, the other information is used to allow operation of system 1.
  • some identification information such as an employee code
  • an encrypted record of one or more of the biometric templates for the user is stored in the memory of the respective token
  • 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.
  • FIG 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".
  • 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.
  • 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 .
  • 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.
  • 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.
  • the local CCLs for connected readers are all updated to correspond to the central CCL.
  • the local CCLs are updated periodically or on demand using one or more of the "push" and "pull" mechanisms described elsewhere in this document.
  • the reader 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.
  • the token CCL is up-to-date.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the enrolment system (in the form of terminal 22) sends change requests to server 23 to be included in 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.
  • 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 reader 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.
  • 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.
  • the reader can destroy the rejected tokens or revoke them.
  • 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.
  • disconnected readers are configured to reject a token having a revoked certificate.
  • 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 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.
  • all readers are aware of substantially up-to-date change requests the preferred embodiments of the invention are able to provide:
  • System 1 is configured to provide anti pass-back (APB) functionality between selected access points.
  • APB anti pass-back
  • 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.
  • 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.
  • 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.
  • Zone A The zone that lies beyond the perimeter fence of site 80 is defined as Zone 0.
  • Zone A and Zone C are APB zones
  • 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.
  • Zone C or Zone D he or she is considered to be in APB zone C.
  • 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.
  • 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.
  • Zone A 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.
  • Zone B is not an APB zone
  • the access point associated with reader 85 includes a request to exit (REX) device.
  • REX request to exit
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • APB functionality is used for peripheral doors of buildings. However, in some embodiments, it is used internally particularly for high security areas.
  • 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.
  • 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.
  • 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).
  • 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”).
  • 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.
  • 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.
  • 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.
  • 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
  • the entry APB zone is defined as Zone 0.
  • Zone B in not an APB zone but, rather, is included within the APB zone A.
  • 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.
  • the reader 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • these two filters are respectively said to allow an APB determination and a user determination.
  • the reader makes the user determination prior to making the APB determination.
  • the user determination is made after the APB determination.
  • 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.
  • 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.
  • Non-APB zones are considered to be included in the immediately enclosing APB zone (if any).
  • Zone A and Zone C are APB zones.
  • Zone B is included in APB Zone A, and Zone D is included in APB
  • FIG. 15 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.
  • 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.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Lock And Its Accessories (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système de commande d'accès (1) destiné à deux points d'accès (3, 4) de portes auxquelles une pluralité d'utilisateurs (5, 6) accèdent sélectivement. Ledit système (1) comprend des jetons d'accès (7, 8) destinés à des utilisateurs (5, 6) respectifs renfermant une mémoire(10) qui contient un certificat numérique et une liste de changement de certificat (CCL) de jeton. Chaque jeton est sensible à un signal d'interrogation permettant de générer un signal de jeton dérivé du certificat. Un réseau informatique (11) contient des informations indicatrices des certificats du système, et permet à ce système (1) de fournir une CCL centrale indicatrice des changements nécessaires pour au moins l'un des certificats. Un lecteur d'accès (15) connecté est disposé adjacent à un point d'accès (3) et communique avec le réseau (11) afin de gérer une première CCL locale fusionnée en temps réel avec la CCL centrale. Le lecteur (15) génère un signal d'interrogation et est sensible au signal de jeton correspondant afin: de déterminer si le point d'accès (3) doit être amené par impulsion à une configuration déverrouillée, et de fusionner la CCL locale et le jeton CCL.
PCT/AU2005/001285 2004-08-27 2005-08-25 Systeme et procede de commande d'acces WO2006021047A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2005800363714A CN101052970B (zh) 2004-08-27 2005-08-25 访问控制系统
EP05773644A EP1807788A4 (fr) 2004-08-27 2005-08-25 Systeme et procede de commande d'acces
HK08103363.5A HK1113213A1 (en) 2004-08-27 2008-03-26 An access control system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AU2004904895 2004-08-27
AU2004904895A AU2004904895A0 (en) 2004-08-27 An access control system
AU2004905346 2004-09-16
AU2004905346A AU2004905346A0 (en) 2004-09-16 An access control system

Publications (1)

Publication Number Publication Date
WO2006021047A1 true WO2006021047A1 (fr) 2006-03-02

Family

ID=35967120

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2005/001285 WO2006021047A1 (fr) 2004-08-27 2005-08-25 Systeme et procede de commande d'acces

Country Status (4)

Country Link
EP (1) EP1807788A4 (fr)
CN (1) CN101052970B (fr)
HK (1) HK1113213A1 (fr)
WO (1) WO2006021047A1 (fr)

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010036471A1 (fr) * 2008-09-25 2010-04-01 Ge Security, Inc. Système de contrôle d’accès physique avec carte à puce et procédés d’exploitation
EP2207146A2 (fr) * 2007-10-03 2010-07-14 Talleres De Escoriaza, S.A. Système électronique programmable pour le contrôle des accès
EP2287811A1 (fr) * 2009-08-12 2011-02-23 REpower Systems AG Procédé et dispositif de réglage de l'accès sur des commandes d'installations d'éoliennes
CN102567697A (zh) * 2010-12-08 2012-07-11 中国电信股份有限公司 阅读器、rfid标签及其读取方法
US8232860B2 (en) 2005-10-21 2012-07-31 Honeywell International Inc. RFID reader for facility access control and authorization
US8341695B2 (en) 2008-05-01 2012-12-25 Honeywell International Inc. Method of access control implemented in an Ethernet switch
WO2013093070A1 (fr) * 2011-12-22 2013-06-27 Airbus Operations Gmbh Système d'accès pour véhicule et procédé de gestion d'accès à un véhicule
WO2014098760A1 (fr) 2012-12-21 2014-06-26 Nida Tech Sweden Ab Procédé, noeud, programme informatique et système d'outil à commande mécanique permettant de verrouiller et de déverrouiller un outil à commande mécanique
US8878931B2 (en) 2009-03-04 2014-11-04 Honeywell International Inc. Systems and methods for managing video data
US9019070B2 (en) 2009-03-19 2015-04-28 Honeywell International Inc. Systems and methods for managing access control devices
EP2958083A1 (fr) * 2014-06-17 2015-12-23 Burg-Wächter Kg Procédé de configuration de serrures électroniques
US9280365B2 (en) 2009-12-17 2016-03-08 Honeywell International Inc. Systems and methods for managing configuration data at disconnected remote devices
US9344684B2 (en) 2011-08-05 2016-05-17 Honeywell International Inc. Systems and methods configured to enable content sharing between client terminals of a digital video management system
US9704313B2 (en) 2008-09-30 2017-07-11 Honeywell International Inc. Systems and methods for interacting with access control devices
US9705861B2 (en) 2010-06-04 2017-07-11 Ubiqu B.V. Method of authorizing a person, an authorizing architecture and a computer program product
US9894261B2 (en) 2011-06-24 2018-02-13 Honeywell International Inc. Systems and methods for presenting digital video management system information via a user-customizable hierarchical tree interface
US10038872B2 (en) 2011-08-05 2018-07-31 Honeywell International Inc. Systems and methods for managing video data
US10054664B2 (en) 2015-04-07 2018-08-21 Nidatech Sweden Ab Enhanced time of arrival positioning system
US10362273B2 (en) 2011-08-05 2019-07-23 Honeywell International Inc. Systems and methods for managing video data
US10523903B2 (en) 2013-10-30 2019-12-31 Honeywell International Inc. Computer implemented systems frameworks and methods configured for enabling review of incident data
WO2020083750A1 (fr) * 2018-10-22 2020-04-30 Dormakaba Schweiz Ag Mise à jour de droits d'accès à bande ultra large (uwb)
EP4140655A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Jeton destiné à la commande par un utilisateur d'un outil
EP4140656A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Équipement diversifié d'artisan pourvu d'outils compatibles avec un jeton
EP4140657A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Appareil portatif pourvu de composants communicants de manière à être égaux au moyen d'une connexion omnibus universelle
EP4140654A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Jeton apte à la communication cryptographique permettant d'accoupler mécaniquement et de communiquer avec des appareils portatifs
WO2023030779A1 (fr) * 2021-08-31 2023-03-09 Adolf Würth GmbH & Co. KG Outil à main comportant des éléments aptes à communiquer d'égal à égal via une liaison par bus universelle

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017180563A1 (fr) * 2016-04-11 2017-10-19 Carrier Corporation Capture d'intention d'utilisateur lors d'une interaction avec plusieurs commandes d'accès
EP3562089A1 (fr) * 2018-04-23 2019-10-30 Siemens Aktiengesellschaft Gestion automatisée des certificats

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3857018A (en) * 1973-12-07 1974-12-24 Business Electronics Inc Controlled access systems
US3860911A (en) * 1973-11-01 1975-01-14 Pitney Bowes Inc Electronic combination lock and lock system
US3906447A (en) * 1973-01-31 1975-09-16 Paul A Crafton Security system for lock and key protected secured areas
US4095739A (en) * 1977-08-26 1978-06-20 A-T-O Inc. System for limiting access to security system program
US4213118A (en) * 1976-11-08 1980-07-15 Chromalloy Electronics Corporation Combination changing system and method
US4283710A (en) * 1978-10-25 1981-08-11 J.S. Lock Company Security system
EP0043270B1 (fr) * 1980-06-27 1984-03-21 Omron Tateisi Electronics Co. Système de déverrouillage utilisant des cartes
WO1984002786A1 (fr) * 1983-01-10 1984-07-19 Figgie Int Inc Lecteur de carte ameliore pour systeme de securite
EP0152678A2 (fr) * 1984-02-13 1985-08-28 James W. Raymond Serrure électronique pour hôtels et similaires
EP0122244B1 (fr) * 1983-04-08 1988-06-01 Besam Security Aktiebolag Sytème de serrure
GB2251266A (en) * 1990-12-03 1992-07-01 Trioving As Coded lock/key system with override
JPH0619911A (ja) * 1992-07-06 1994-01-28 Shimizu Corp カードによる入退管理システム及びそのカード読取装置
US5591950A (en) * 1992-11-04 1997-01-07 Talleres De Escoriaza, S.A. (Tesa) Programmable electronic lock
US20030071715A1 (en) * 1995-02-07 2003-04-17 Harrow Products, Inc. Door security system audit trail

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4887292A (en) * 1985-12-30 1989-12-12 Supra Products, Inc. Electronic lock system with improved data dissemination
EP1024239B1 (fr) * 1999-01-28 2005-03-23 International Business Machines Corporation Système de contrôle d'accès électronique et méthode
CN1233916C (zh) * 2002-08-05 2005-12-28 上海阿艾依智控系统有限公司 钥匙自动管理和监控系统
CN1261663C (zh) * 2002-12-31 2006-06-28 深圳市高科智能系统有限公司 无线集中控制门禁/门锁的方法及系统设备
ES2253971B1 (es) * 2004-02-05 2007-07-16 Salto Systems, S.L. Sistema de control de acceso.

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3906447A (en) * 1973-01-31 1975-09-16 Paul A Crafton Security system for lock and key protected secured areas
US3860911A (en) * 1973-11-01 1975-01-14 Pitney Bowes Inc Electronic combination lock and lock system
US3857018A (en) * 1973-12-07 1974-12-24 Business Electronics Inc Controlled access systems
US4213118A (en) * 1976-11-08 1980-07-15 Chromalloy Electronics Corporation Combination changing system and method
US4095739A (en) * 1977-08-26 1978-06-20 A-T-O Inc. System for limiting access to security system program
US4283710A (en) * 1978-10-25 1981-08-11 J.S. Lock Company Security system
EP0043270B1 (fr) * 1980-06-27 1984-03-21 Omron Tateisi Electronics Co. Système de déverrouillage utilisant des cartes
WO1984002786A1 (fr) * 1983-01-10 1984-07-19 Figgie Int Inc Lecteur de carte ameliore pour systeme de securite
EP0122244B1 (fr) * 1983-04-08 1988-06-01 Besam Security Aktiebolag Sytème de serrure
EP0152678A2 (fr) * 1984-02-13 1985-08-28 James W. Raymond Serrure électronique pour hôtels et similaires
GB2251266A (en) * 1990-12-03 1992-07-01 Trioving As Coded lock/key system with override
JPH0619911A (ja) * 1992-07-06 1994-01-28 Shimizu Corp カードによる入退管理システム及びそのカード読取装置
US5591950A (en) * 1992-11-04 1997-01-07 Talleres De Escoriaza, S.A. (Tesa) Programmable electronic lock
US20030071715A1 (en) * 1995-02-07 2003-04-17 Harrow Products, Inc. Door security system audit trail

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1807788A4 *

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8232860B2 (en) 2005-10-21 2012-07-31 Honeywell International Inc. RFID reader for facility access control and authorization
US8941464B2 (en) 2005-10-21 2015-01-27 Honeywell International Inc. Authorization system and a method of authorization
EP2207146A2 (fr) * 2007-10-03 2010-07-14 Talleres De Escoriaza, S.A. Système électronique programmable pour le contrôle des accès
US20100223662A1 (en) * 2007-10-03 2010-09-02 Talleres De Escoriaza, S.A. Programmable electronic access control system
EP2207146A4 (fr) * 2007-10-03 2011-07-27 Talleres Escoriaza Sa Système électronique programmable pour le contrôle des accès
US8341695B2 (en) 2008-05-01 2012-12-25 Honeywell International Inc. Method of access control implemented in an Ethernet switch
US8052060B2 (en) 2008-09-25 2011-11-08 Utc Fire & Security Americas Corporation, Inc. Physical access control system with smartcard and methods of operating
WO2010036471A1 (fr) * 2008-09-25 2010-04-01 Ge Security, Inc. Système de contrôle d’accès physique avec carte à puce et procédés d’exploitation
US9704313B2 (en) 2008-09-30 2017-07-11 Honeywell International Inc. Systems and methods for interacting with access control devices
US8878931B2 (en) 2009-03-04 2014-11-04 Honeywell International Inc. Systems and methods for managing video data
US9019070B2 (en) 2009-03-19 2015-04-28 Honeywell International Inc. Systems and methods for managing access control devices
US8397075B2 (en) 2009-08-12 2013-03-12 Repower Systems Ag Method and apparatus for access control to installation control systems of wind energy installations
EP3385921A1 (fr) * 2009-08-12 2018-10-10 Senvion GmbH Procédé et dispositif de réglage d'accès sur des commandes d'installations d'éoliennes
EP2287811A1 (fr) * 2009-08-12 2011-02-23 REpower Systems AG Procédé et dispositif de réglage de l'accès sur des commandes d'installations d'éoliennes
US9280365B2 (en) 2009-12-17 2016-03-08 Honeywell International Inc. Systems and methods for managing configuration data at disconnected remote devices
US9705861B2 (en) 2010-06-04 2017-07-11 Ubiqu B.V. Method of authorizing a person, an authorizing architecture and a computer program product
CN102567697A (zh) * 2010-12-08 2012-07-11 中国电信股份有限公司 阅读器、rfid标签及其读取方法
US9894261B2 (en) 2011-06-24 2018-02-13 Honeywell International Inc. Systems and methods for presenting digital video management system information via a user-customizable hierarchical tree interface
US10362273B2 (en) 2011-08-05 2019-07-23 Honeywell International Inc. Systems and methods for managing video data
US10863143B2 (en) 2011-08-05 2020-12-08 Honeywell International Inc. Systems and methods for managing video data
US9344684B2 (en) 2011-08-05 2016-05-17 Honeywell International Inc. Systems and methods configured to enable content sharing between client terminals of a digital video management system
US10038872B2 (en) 2011-08-05 2018-07-31 Honeywell International Inc. Systems and methods for managing video data
WO2013093070A1 (fr) * 2011-12-22 2013-06-27 Airbus Operations Gmbh Système d'accès pour véhicule et procédé de gestion d'accès à un véhicule
US9990785B2 (en) 2011-12-22 2018-06-05 Airbus Operations Gmbh Access system for a vehicle and method for managing access to a vehicle
WO2014098760A1 (fr) 2012-12-21 2014-06-26 Nida Tech Sweden Ab Procédé, noeud, programme informatique et système d'outil à commande mécanique permettant de verrouiller et de déverrouiller un outil à commande mécanique
US10523903B2 (en) 2013-10-30 2019-12-31 Honeywell International Inc. Computer implemented systems frameworks and methods configured for enabling review of incident data
US11523088B2 (en) 2013-10-30 2022-12-06 Honeywell Interntional Inc. Computer implemented systems frameworks and methods configured for enabling review of incident data
EP2958083A1 (fr) * 2014-06-17 2015-12-23 Burg-Wächter Kg Procédé de configuration de serrures électroniques
US10054664B2 (en) 2015-04-07 2018-08-21 Nidatech Sweden Ab Enhanced time of arrival positioning system
WO2020083750A1 (fr) * 2018-10-22 2020-04-30 Dormakaba Schweiz Ag Mise à jour de droits d'accès à bande ultra large (uwb)
EP4140655A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Jeton destiné à la commande par un utilisateur d'un outil
EP4140656A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Équipement diversifié d'artisan pourvu d'outils compatibles avec un jeton
EP4140657A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Appareil portatif pourvu de composants communicants de manière à être égaux au moyen d'une connexion omnibus universelle
EP4140654A1 (fr) * 2021-08-31 2023-03-01 Adolf Würth GmbH & Co. KG Jeton apte à la communication cryptographique permettant d'accoupler mécaniquement et de communiquer avec des appareils portatifs
WO2023030779A1 (fr) * 2021-08-31 2023-03-09 Adolf Würth GmbH & Co. KG Outil à main comportant des éléments aptes à communiquer d'égal à égal via une liaison par bus universelle
WO2023030778A1 (fr) * 2021-08-31 2023-03-09 Adolf Würth GmbH & Co. KG Équipement d'artisan diversifié comprenant des outils d'artisan compatibles avec des jetons
WO2023030776A1 (fr) * 2021-08-31 2023-03-09 Adolf Würth GmbH & Co. KG Jeton de communication cryptographique pour couplage mécanique et communication avec des appareils portatifs
WO2023030777A1 (fr) * 2021-08-31 2023-03-09 Adolf Würth GmbH & Co. KG Jeton pour commande liée à l'utilisateur d'un appareil à main

Also Published As

Publication number Publication date
CN101052970A (zh) 2007-10-10
HK1113213A1 (en) 2008-09-26
EP1807788A4 (fr) 2010-03-31
EP1807788A1 (fr) 2007-07-18
CN101052970B (zh) 2011-07-13

Similar Documents

Publication Publication Date Title
EP1807788A1 (fr) Systeme et procede de commande d'acces
US7822989B2 (en) Controlling access to an area
US8261319B2 (en) Logging access attempts to an area
EP1646937B1 (fr) Commande d'acces a une zone
US8941465B2 (en) System and method for secure entry using door tokens
US8015597B2 (en) Disseminating additional data used for controlling access
US7716486B2 (en) Controlling group access to doors
US7600129B2 (en) Controlling access using additional data
JP4668551B2 (ja) 個人認証デバイスとこのシステムおよび方法
US8907763B2 (en) System, station and method for mustering
US20140002236A1 (en) Door Lock, System and Method for Remotely Controlled Access
US20130214902A1 (en) Systems and methods for networks using token based location
US10964145B2 (en) Access control system using blockchain ledger
US9449443B2 (en) Logging access attempts to an area
US20050273444A1 (en) Access administration system and method for a currency compartment
JP4373314B2 (ja) 生体情報を用いる認証システム
US11373472B2 (en) Compact encoding of static permissions for real-time access control
SE1951056A1 (en) Method, locking system for controlling access to a resource and a locking device
WO2020013723A1 (fr) Procédé et système d'autorisation d'utilisateur sur la base de sa clé numérique
AU2006200187B2 (en) Controlling access to an area
AU2007231667A1 (en) A method of implementing anti-passback control in a partially connected physical access control system
JP2009112015A (ja) 個人認証デバイスとこのシステムおよび方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005773644

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2257/DELNP/2007

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 200580036371.4

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2005773644

Country of ref document: EP