Patent Description:
An access control system is typically operated by encoding data on a physical key card that indicates access rights. Some access control systems are online where the access control reader that reads key cards can use some means to communicate with the access control system. In online systems the access rights are usually a reference identifier. An example is a building entry system where an employee uses a RFID badge to access a door that has a reader with means to convey the badge id into a networked access control system that has means to permit or deny access based on access rights associated to the reference identifier and additionally based upon the time and date allowed for access. In this example, the reader does not have means to determine the time and date, but the access control system does. Other access control systems are offline and the access rights are encoded as data that can be decoded and interpreted by the offline access control lock to retrieve the access rights. An example is a hotel locking system where a front desk encodes a guest card and an offline, battery powered lock on a guest room door has the means to decode the key card and permit or deny access based on the encoded access rights and based on the time and date allowed for access. In this example, the door lock has means to determine time and date. Some methods of encoding access rights include sequencing where subsequent access rights have a sequence number that is greater than the prior access rights. Some other methods of encoding access rights include an expiration window where the access rights will not provide access before a certain date and time or after another certain date and time.

Conventional access control systems utilize encryption, i.e., AES, RSA, ECC, etc., to perform cryptographic operations to authenticate communications with physical cards or virtual cards passed over Near Field Communications (NFC) or Bluetooth. Additionally, encryption is also used to encode data on the key card where the access rights may be encoded as encrypted data or as a digital certificate which may also be encrypted. Sometimes the keys used for authenticating cards are different than the encryption keys used to encode data on the cards. Locks and readers and encoders require these various encryption keys to be programmed before entry into service or are occasionally changed as part of normal encryption key management. Management of these encryption keys requires a programming device and programming operation to program the encryption keys that are specific to the access control system being put into service. A conventional method of setting keys in a reader or lock is to use a programming device. Another conventional method is to use a single configuration card that has the new keys on the card rather than access rights. The card can be read by an online reader, but since the reader does not have a real time clock, it cannot expire the configuration card even if an expiration window is encoded on the card. In some cases, a reader that is part of a lock may not be able to expire the configuration card either as the reader is a module that doesn't have means to get the time and date from the lock. Because the configuration card may not expire, it needs to be carefully controlled. Another conventional cryptographic operation, is to preload the specific encryption keys in the factory and pre-configure the lock for the property before being put into service, however this creates an operational process that can be cumbersome for a factory to manage.

High security RFID systems are available to replace older, less secure technologies. For example, MIFARE Plus uses high security AES <NUM>-bit encryption keys and is an upgrade from MIFARE Classic which uses <NUM>-bit keys for a proprietary encryption algorithm. However locks and readers can be made that support both MIFARE Plus and MIFARE Classic. In some cases there is a need to switch the reader into a high security only mode and optionally to set the high security encryption keys.

It would be advantageous to be able to operate high-security locks with legacy software systems to minimize the operational impact of upgrading the entire system all at once. Additionally, it would be advantageous to have a secure process for upgrading or rolling keys that uses a card and is not dependent on a programmer or special device or required to be preconfigured in a factory. Additionally, it would be advantageous to have a configuration card that expires for all types of devices.

<CIT> discloses an electronic data access and retrieval system comprising first and second smart cards, the first card being encoded with digital data fields representative of predetermined information and the second card including authorization codes for enabling access to and authorized retrieval of selected information from the digital data fields of the first card.

<CIT> discloses an electronic and computer-based system wherein two or more data cards can be used to input a command into a system, wherein the command is determined based on the particular combination of the data cards.

<CIT> discloses a transaction method, system and apparatus that employs a first electromagnetically read card for accessing account data of a corresponding account and a second electromagnetically read card for effectively carrying identity data of the account holder of the first card.

<CIT> discloses a self-contained electronic lock with changeable master and slave codes.

According to a first aspect of the invention there is provided a method of programming an access control system, the method comprising: presenting an access card and a configuration card to an access control device, wherein the configuration card is encrypted with a diversified key based upon information from the access card such that the two cards are tied together, and when the access card expires, the configuration card also effectively expires, wherein the configuration card is usable only on the access control device that the access card is authorized to open, and, wherein if the two cards are separated or one of the cards is reprogrammed or destroyed, then the configuration card becomes unusable for configuring the access control device; determining a validity of the access card at the access control device; processing the configuration card at the access control device in response to the validity of the access card; decrypting a payload on the configuration card based upon the information from the access card; and using the payload from the configuration card to switch the access control device to a high security mode of operation such that the access control device will no longer accept low security cards, wherein the access control device is a door lock.

Optionally, the method includes using encryption keys from the payload on the configuration card for use with the access control device.

Optionally, presenting the access card and the configuration card includes presenting the access card and the configuration card as high security cards.

Optionally, presenting the access card and the configuration card includes presenting the access card as a low security card and the configuration card as high security card.

Optionally, presenting the access card and the configuration card includes presenting at least one of the access card and the configuration card via a mobile device.

Optionally, presenting the access card and the configuration card includes presenting the access card and the configuration card via a mobile device.

Optionally, switching the device to a high security mode of operation is a software based front desk system that is upgrading an old system and keys are being transferred from the old system to a new software system.

Optionally, processing the configuration card at the access control device in response to the validity of the access card comprises not processing the configuration card if the access card is expired.

Optionally, the method includes encoding a first card as the access card and a second card as the configuration card, wherein information from the access card is used to create the diversified encryption key by an encryption process that incorporates multiple information inputs and produces an encryption key that is related to all of the inputs which is then used to encrypt the contents of the configuration card.

Optionally, the method includes providing an indication of completion in response to the switch of the device to the high security mode of operation.

Optionally, the method includes presenting the access card and the configuration card simultaneously.

According to a second aspect of the invention there is provided a system for programming an access control according to the method of the first aspect, the system comprising: an encoder to encode an access card and a configuration card configured to program the access control when presented together to the access control.

Optionally, the access card and the configuration card are configured to be presented simultaneously.

Optionally, the access card and the configuration card are configured to be presented in sequence.

Optionally, the configuration card is not processed if the access card is expired.

<FIG> schematically illustrates an access control system <NUM>. The system <NUM> generally includes a mobile device <NUM>, a server <NUM>, and a plurality of access controls <NUM>, schematically illustrated as 16a, 16b,. , 16n along with a front desk interface <NUM> which communicates with an encoder <NUM> to encode guest cards <NUM> and/or communicates with a programmer <NUM> to program the access controls 16a, 16b,. In one embodiment, the front desk interface <NUM> is integrated with the programmer <NUM> to provide for an integrated platform. In another embodiment, the front desk interface <NUM> is integrated with the encoder <NUM> to provide for a portable check-in experience where an administrator can roam in a lobby area checking guests into rooms. It should be appreciated that, although particular systems are separately defined in the schematic block diagrams, each or any of the systems may be otherwise combined or separated via hardware and/or software.

The mobile device <NUM> may be a wireless capable handheld device such as a smart phone that is operable to communicate with the server <NUM> and the access controls <NUM>. The server <NUM> may provide credentials and other data to the mobile device <NUM>, such as firmware or software updates to be communicated to one or more of the access controls <NUM>. Although the server <NUM> is depicted herein as a single device, it should be appreciated that the server <NUM> may alternatively be embodied as a multiplicity of systems, from which the mobile device <NUM> receives credentials and other data.

Each access control <NUM> is a wireless-capable, restricted-access, door lock type access control reader for building entry. The mobile device <NUM> submits credentials to the access controls <NUM>, thereby selectively permitting a user to access or activate functions of the access controls <NUM>. A user may, for example, submit a credential to an electromechanical lock to unlock it, and thereby gain access to a restricted area. Some credentials may be used for multiple access controls <NUM>. For example, a plurality of electronic access controls <NUM> in a facility may respond to the same credential. Other credentials may be specific to a single access control <NUM>.

With reference to <FIG>, a block diagram of an access control 16a generally includes a lock actuator <NUM>, a lock controller <NUM>, a lock antenna <NUM>, a lock transceiver <NUM>, a lock processor <NUM>, a lock memory <NUM>, a lock power supply <NUM>, a lock card reader <NUM> and a credential module <NUM>. The lock card reader <NUM> may include a card reading subsystem <NUM>, a communication subsystem <NUM>, to communicate with the lock processor <NUM>, a feedback subsystem <NUM> such as a light, buzzer, etc. The lock card reader <NUM> reads physical cards and then sends the data to the lock processor <NUM> for decoding and determining if the access device <NUM> may be accessed. Alternatively, the reader <NUM> could be included in an embodiment as a lock for a door 16a, or in a reader 16b on a building where the door is controlled by a door controller component separate from the access control 16b with the reader <NUM> and where the communication subsystem <NUM> is used by the reader 16b to communicate with the networked access control system. Alternatively, the reader <NUM> or lock processor <NUM> could have means to determine date and time.

The access control 16a is responsive to credentials from a physical card and/or the mobile device <NUM>. Upon receiving and authenticating an appropriate credential from the mobile device <NUM> using the credential module <NUM>, or after receiving card data from lock card reader <NUM>, the lock controller <NUM> commands the lock actuator <NUM> to lock or unlock a mechanical or electronic lock. The lock controller <NUM> and the lock actuator <NUM> may be parts of a single electronic or electromechanical lock unit, or may be components sold or installed separately.

The lock transceiver <NUM> is capable of transmitting and receiving data to and from at least the mobile device <NUM>. The lock transceiver <NUM> may, for instance, be a near field communication (NFC), Bluetooth, or Wi-Fi transceiver, or another appropriate wireless transceiver. The lock antenna <NUM> is any antenna appropriate to the lock transceiver <NUM>. The lock processor <NUM> and lock memory <NUM> are, respectively, data processing, and storage devices. The lock processor <NUM> may, for instance, be a microprocessor that can process instructions to validate card data and determine the access rights contained in the card data or to pass messages from a transceiver to a credential module <NUM> and to receive a response indication back from the credential module <NUM> with card data. The lock memory <NUM> may be RAM, EEPROM, or other storage medium where the lock processor <NUM> can read and write data including but not limited to lock configuration options and the lock audit trail. The lock audit trail may be a unified audit trail that includes events initiated by accessing the lock via the lock card reader <NUM> or the mobile device <NUM>. The lock power supply <NUM> is a power source such as line power connection, a power scavenging system, or a battery that powers the lock controller <NUM>. In other embodiments, the lock power supply <NUM> may only power the lock controller <NUM>, with the lock actuator <NUM> powered primarily or entirely by another source, such as user work (e.g. turning a bolt).

The credential module <NUM> is in communication with the lock processor <NUM> and is operable to decrypt and validate a credential to extract virtual card data communicated into the lock controller <NUM> as a "virtual card read. " That is, the access control 16a has essentially two readers, one reader <NUM> to read a physical key card and the credential module <NUM> to communicate with the mobile device <NUM> via the lock processor <NUM> and the transceiver <NUM> and antenna <NUM>.

While the <FIG> shows the lock antenna <NUM> and the transceiver <NUM> connected to the processor <NUM>, this is not to limit other embodiments that may have additional antenna <NUM> and transceiver <NUM> connected to the credential module <NUM> directly. The credential module <NUM> may contain a transceiver <NUM> and antenna <NUM> as part of the credential module. Or the credential module <NUM> may have a transceiver <NUM> and antenna <NUM> separately from the processor <NUM> which also has a separate transceiver <NUM> and antenna <NUM> of the same type or different. In some embodiments, the processor <NUM> may route communication received via transceiver <NUM> to the credential module <NUM>. In other embodiments the credential module may communicate directly to the mobile device <NUM> through the transceiver <NUM>.

With reference to <FIG>, a method <NUM> of programing encryption keys and possibly other configuration data into high-security card readers is generally illustrated in a simplified block diagram format. The method follows the method of changing the encoder behavior when encoding an access card when two cards are detected in the RFID field (<FIG>). One card is an access card <NUM> such as a Hotel Master card, guest card, or other, such card while the other card is a configuration card <NUM> (<FIG>). The difference between the two cards is the semantics of the payload on the card and how the payload is encrypted on the card.

After encoding, with reference again to <FIG>, when presenting the two cards simultaneously to an access control <NUM> (step <NUM>), the access control <NUM> detects the two cards and will process the door access card <NUM> first (step <NUM>). On success it then decrypts the configuration card <NUM> (step <NUM>) and then uses the configuration card <NUM> payload to configure the access control <NUM> (step <NUM>), for example, to roll to new keys, to change operating modes, or set any other configurable parameter that is typically set in the access control <NUM>. In an embodiment where the access control <NUM> is a wall reader in an online access control system, processing the door access card <NUM> (again, step <NUM>) would include first reading the access rights from the card (encoded as a reference identifier), passing the access rights to the networked access control system, and receiving back at the access control <NUM> an indication that the access control system accepted the card. The indication from the access control system could be a message, or a signal line that indicates the reader <NUM> should give positive feedback (i.e. Green LED or positive beep tones, etc.) or negative feedback (i.e. Red LED or negative beep tones, etc.). Further, in this embodiment, the step <NUM> would then only proceed if the positive indicator was given. An alternate embodiment is where the access control <NUM> is a hotel door lock with components as shown in <FIG> as part of an offline access control system. In this embodiment, processing the door access card <NUM> (step <NUM>) could be the same as the previous embodiment where the reader <NUM> is like the wall reader with means to pass the encoded access rights data to the processor <NUM> which gives an indication back to the reader of success. A successful indication would mean that the access rights were accepted and not expired. Again, in this embodiment, the step <NUM> would then only proceed where the reader <NUM> then decrypts the configuration card payload and in step <NUM> the reader <NUM> processes the card payload if the access rights were accepted and not expired. In this embodiment the reader <NUM> securely stores the encryption keys for reading cards and the keys are not exposed to the lock processor <NUM>. Yet another embodiment is where the reader <NUM> passes all data and steps <NUM> and <NUM> are done by the lock processor <NUM> and in this embodiment the lock processor securely stores the encryption keys and configures the reader <NUM> with the keys so the reader can read cards. Yet another embodiment is where the reader <NUM> and lock processor <NUM> are combined. Yet another embodiment is where the reader <NUM> gets the date and time from the lock processor <NUM> so that the reader <NUM> can determine if a configuration card is expired.

The configuration card <NUM> is securely encrypted with a diversified key based upon information from the access card <NUM> so that the two cards are tied together. Thus, when the access card <NUM> expires, the configuration card <NUM> also effectively expires. Additionally, configuration card <NUM> can be used only on the access control <NUM> that the access card <NUM> is authorized to open. Finally, when finished, if the two cards are separated or one of the cards is reprogrammed or destroyed, then the configuration card <NUM> becomes unusable and thus the information contained on it is secure.

With reference to <FIG>, an encoder <NUM> can write to door access cards <NUM> and the access control <NUM> can read the cards to determine if guests, housekeepers, or other staff can gain access. Here, access control <NUM> is in 'classic' mode in which the readers <NUM> thereof are backwards-compatible in operation with older, less secure cards and technologies such as MIFARE Classic, for example. In this mode the encoder (HT22p) will only encode MIFARE Classic cards with room card data to be door access cards <NUM>. The access control <NUM> in classic mode will only read MIFARE Classic cards and process the room card data. In this mode, if a high security card is presented to the lock, the reading will fail with feedback <NUM> such as a red light or with a buzzer sound that indicates failure of the operation. This mode is offered for compatibility to existing installations and legacy systems.

With reference to <FIG>, when a system is desired to upgrade to high security mode, the dual card encoding method <NUM> may be performed as follows:
The encoder is prepared to encode (write) an access card (step <NUM>). The user may select a menu option on the encoder or via controlling PMS (Property Management System) software, Font Desk Software <NUM>, etc. The method of instructing the encoder to encode a card is well known.

The user then presents two cards (step <NUM>). For example, one card can be a lower security card, one can be a higher security card: e.g., a MIFARE Classic card and a MIFARE Plus card together simultaneously. Alternatively, first a MIFARE Classic card and immediately thereafter present a MIFARE Plus card subsequently within a short time. Alternatively, if two lower security cards are presented together or in sequence - encode the first as a door access card <NUM> but reject the second and not encode a configuration card. Alternatively, if two higher security cards are presented together or in sequence - encode the first as a high-security door access card <NUM> and encode the second as a configuration card <NUM> to be used to re-configure and roll or change the encryption keys in access control <NUM> that are already in high-security mode. Alternatively, if no high-security encryption keys are present in the encoder, randomly generate new high-security encryption keys when two cards are presented to the encoder.

Next, encode the first card as the door access card <NUM> (step <NUM>). If one card is low security and one is high security, the low security card should be encoded as the door access card <NUM>. This provides so that an access control <NUM> in low security mode can read this access card and then switch to the higher security mode using the method <NUM> (<FIG>).

Next, encode the second (higher security) card as the configuration card <NUM> (step <NUM>). The encoded data contains configuration information to change the access control <NUM> from low security mode to high security mode, including, but not limited to, the high-security encryption keys. The configuration data is encrypted with a process using information from the first door access card <NUM>, including but not limited to, a unique card ID, payload data from the access card, etc., so that the two cards are tied together and must be used together. A different door access card <NUM> would have a different unique card ID or different payload data and thus that different access card could not be used in conjunction with this configuration card <NUM>.

Alternatively, with reference to <FIG>, information from the door access card <NUM> is used to create a diversified encryption key by a hash or encryption process that incorporates multiple information inputs and produces an encryption key that is related to all of the inputs (<FIG>, step <NUM>). These key diversification algorithms are well known in the art of cryptography, for example NXP has published an application note for key diversification (http://www. com/documents/application_note/AN10922. This diversified encryption key is then used to encrypt the contents of the configuration card <NUM>.

The user then presents the two cards together to another device that can read the cards and the device reads the cards in sequence or together (step <NUM>). This step is the same as method <NUM> described in <FIG> where the device is an access control <NUM>. Both cards are identified and read to determine the type of card and information contained on the card (e.g. whether this is a door access card <NUM> a configuration card <NUM> or both and which is which).

For a door lock type device <NUM>, the access card is processed first. If the access card is valid: a) Authorized for this device, and b) Not expired, then the lock will process the configuration card by decrypting the payload based on information from the access card and then use the configuration data to switch to a high security mode of operation with the specified encryption keys.

The access control device <NUM> in step <NUM> will enter a high-security mode after processing the configuration card. This means the door lock would no longer accept low-security cards. So, if after switching modes, the same low-security door access card was presented to the lock, it would no longer be read but would be rejected with e.g. a red light.

If the access control <NUM> was already in high-security mode and the two cards presented were both high-security cards, the card with access data would be processed first and then the configuration card would be processed. In this case, the lock is already in high-security mode and so would not change modes. The configuration data could change some other operating parameter in the access control <NUM>. For example, the configuration data could include new high-security encryption keys and the lock would roll or change its encryption keys to these new ones. The rolling or changing of encryption keys could happen immediately. Optionally, to minimize disruption to an actively used access control system, the new encryption keys could be stored in the access control <NUM> and access cards <NUM> could be encoded using the old keys (if an encoder was not upgraded yet) or new keys (if it was upgraded) and the access control <NUM> could use either old or new keys for some amount of time until the old keys would expire. Or, optionally, the encoder would provide an indication in the access card <NUM> that the old keys should no longer be used and the lock would then delete the old keys. Or, optionally, the lock only stores the new keys and the encoder would put both access rights encoded using the old keys and access rights encoded using the new keys on the access card <NUM>. In this case, locks that had not yet rolled to new keys would use the access rights encoded with old keys and locks that had rolled would use the access rights encoded with new keys. The encoder could then only put access rights encoded using the new keys on cards after all the locks had been rolled.

On a successful configuration step, the device (lock <NUM> or encoder <NUM>) could indicate feedback to the user via Audio, or LED light sequence, etc. that the operation was completed (step <NUM>). In one example, a distinctive indication may be utilized so that the user can differentiate normal operations from a successful (or failed) configuration operation.

An alternate embodiment of the method is where the encoder <NUM> has a menu option to encode a configuration card or the front desk software <NUM> that controls the encoder has a menu option. The encoder would <NUM>) cache the previously encoded access card <NUM> or <NUM>) could read an access card <NUM> and then follow steps <NUM>-<NUM> above to create the associated configuration card. Or, another option is to <NUM>) provide menu options to re-encode a specified access card and then would follow all steps <NUM>-<NUM> above in sequence with both cards. One benefit of this alternate embodiment is so that the creation of configuration cards could be controlled based on user permissions in the encoder <NUM> or front desk software <NUM>.

Another alternate embodiment is where the encoder <NUM> is a software application running locally at the hotel or in the cloud and communicating with an encoding device that can encode physical cards. This would apply to either the case where the application and encoder are performing steps <NUM>-<NUM>, or encoding access cards <NUM>, or configuration cards <NUM>. Or this could apply to the case in step <NUM>, for example, where an older system is being upgraded to a new software based system that needs to retrieve the old keys from the old encoders. By reading the access card and configuration card encoded by old encoders, the new software-based system is operable to securely receive the keys and can then participate in the hotel system without requiring a new encryption key to be programmed into all the access controls <NUM>.

With reference to <FIG>, the system is now operating in Plus Mode or High Security mode. The encoder will encode MIFARE Classic OR MIFARE Plus cards, but doors will only accept MIFARE Plus cards.

With reference to <FIG>, an encoder perspective of the method described above begins with <NUM>) a Factory mode where it is compatible with 'classic' devices and cards. Then, after <NUM>) using the method <NUM> above, it switches to <NUM>) a Plus mode where it only encodes high security cards (unless the configuration method <NUM> above is used again and in that case it creates a classic access card for the sole purpose of upgrading a lock that is still in factory mode, for example a replacement lock from the factory for another lock that failed). Then, the method <NUM> above can be used again to <NUM>) Roll keys in the property so that it can still operate in a <NUM>) Plus mode with new keys.

With reference to <FIG>, a lock perspective of the method described above begins with <NUM>) Factory mode where the lock only reads low security cards but can be switched to a high security mode using <NUM>) The methods <NUM> and <NUM> above. In <NUM>) Plus mode, the lock then would reject a classic / low-security card and only read high-security cards. But, it could also read a high-security access card and configuration card to <NUM>) Roll the keys to a different set of high-security keys and then <NUM>) Operate in a high security mode with new keys.

Another embodiment is to utilize a mobile device <NUM> (<FIG>) as either the access card or configuration card or both. When used as one of the cards, the mobile device <NUM> would be presented to the encoder <NUM> (<FIG>, <FIG>) along with another card. The encoder <NUM> writes using the standard RFID protocols to the card or to the mobile device. The mobile device <NUM> would emulate a card to the encoder and the encoder would not know that the mobile device <NUM> is not a card. Then, the mobile device <NUM> could be presented with the card to the lock to complete the two card presentation. Again, the lock would not know that the mobile device <NUM> is not a card. In the case when the mobile device <NUM> is both cards, it would present itself as first one card and then as a second card, presenting two different card types and UIDs to the encoder <NUM>. The mobile device <NUM> would use the sequence embodiment of the method where the cards are presented in rapid sequence. The mobile device <NUM> would then present both cards in sequence to the access device <NUM> to affect the method of programming.

Optionally, the card data on the mobile device <NUM> could be over the air downloaded from a remote service and the mobile device could present the card data as two cards to the encoder <NUM> to change the encoder into a high security mode and then be presented as two cards to a lock 16a to change the lock into a high security mode.

Optionally, the mobile device <NUM> could be encoded with an access card by an encoder with the mobile device <NUM> in card emulation (this is part of the NFC standard), and then the mobile device <NUM> could utilize the access card along with over the air downloaded information to create a configuration card on the mobile device that could be presented as the second card. Optionally, the access card data could be uploaded to a service that then creates the configuration card based on the access card and downloads the configuration card to the mobile device so that the encryption keys and process of creating the configuration card is done by a secure service and not exposed on the mobile device. The mobile device <NUM> could then present the two cards together in sequence as emulated cards to be read by an encoder <NUM> or access device <NUM>.

Yet another additional embodiment is where the encoder <NUM> and the mobile device <NUM> are combined into a single device. An administrator would program the access device <NUM> using the mobile device <NUM> which would simulate an access card <NUM> and a configuration card <NUM> using card emulation mode (again, part of NFC) when presented to the access device <NUM>.

The use of the terms "a," "an," "the," and similar references in the context of description (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or specifically contradicted by context. The modifier "about" used in connection with a quantity is inclusive of the stated value and has the meaning dictated by the context (e.g., it includes the degree of error associated with measurement of the particular quantity). All ranges disclosed herein are inclusive of the endpoints, and the endpoints are independently combinable with each other.

Although the different non-limiting embodiments have specific illustrated components, the embodiments of this invention are not limited to those particular combinations. It is possible to use some of the components or features from any of the non-limiting embodiments in combination with features or components from any of the other non-limiting embodiments.

It should be appreciated that like reference numerals identify corresponding or similar elements throughout the several drawings. It should also be appreciated that although a particular component arrangement is disclosed in the illustrated embodiment, other arrangements will benefit herefrom.

Claim 1:
A method (<NUM>) of programming an access control system, the method comprising:
presenting (<NUM>) an access card (<NUM>) and a configuration card (<NUM>) to an access control device (<NUM>), wherein the configuration card (<NUM>) is encrypted with a diversified key based upon information from the access card (<NUM>) such that the two cards (<NUM>, <NUM>) are tied together, and when the access card (<NUM>) expires, the configuration card (<NUM>) also effectively expires, wherein the configuration card (<NUM>) is usable only on the access control device (<NUM>) that the access card (<NUM>) is authorized to open, and, wherein if the two cards (<NUM>, <NUM>) are separated or one of the cards is reprogrammed or destroyed, then the configuration card (<NUM>) becomes unusable for configuring the access control device (<NUM>);
determining a validity of the access card (<NUM>) at the access control device (<NUM>);
processing (<NUM>) the configuration card (<NUM>) at the access control device (<NUM>) in response to the validity of the access card (<NUM>);
decrypting (<NUM>) a payload on the configuration card (<NUM>) based upon the information from the access card (<NUM>); and
using (<NUM>) the payload from the configuration card (<NUM>) to switch the access control device (<NUM>) to a high security mode of operation such that the access control device (<NUM>) will no longer accept low security cards;
wherein the access control device (<NUM>) is a door lock.