System for security access control in multiple regions

[0002] The present invention relates to a system (and method) for providing security access control to areas in one or more buildings, and particularly to a system for providing security access control and management of badges (access enabling devices or codes, called badges herein, which are assigned to personnel) over multiple geographic regions. This invention is especially suitable for providing a master database which maintains a repository for the information used by each region for security access control and badge management, while allowing each region to operate independently of the master database in accordance with a regional database. The system may be applied for security access control for a company, university, or any other institution or entity having areas where access control is needed.

[0003] Conventional access control systems provide security to areas of a building by utilizing readers associated with locking mechanisms to doors which control entry to such areas. Persons, such as employees, are provided with security badges having data accessible by the reader. Access decisions are made in accordance with security information stored at a central database in response to badge data read from the readers with or without a keypad entered pin number, or access decisions may be made by other databases associated with the readers. Examples of prior access control systems are described in U.S. Pat. Nos. 4,839,640, and 4,218,690.

[0004] Many companies today have sites in different geographic regions, such as cities, states, or countries. To provide access control in each of the regions, early access control systems had a master computer system with a single central database containing all security information for the system, and each region used that central database in making access control decisions. Each of the regions was thus dependent on the central database, and if communication between the master computer system and a region was ever lost, access control in the region was severely degraded. More recently, each of the regions has their own system for security access control to areas of buildings at sites within that region, which may also provide managing of badges worn by personnel in the region. However, badges used in one region are often useless in other regions, since it is unlikely that badges have been associated with the security access systems of other regions. This is especially a problem for employees who work in more than one region, or travel to sites in other regions. Often such employees must be issued multiple badges in which each badge provides access to areas within a particular region. Thus, it would be desirable to provide access control system which enables a single badge to be used in multiple regions. However, as each region needs the capability to administer security access and badging for its own region, it is further desirable to provide such an access control system which allows each region to operate independently. Such independent operation is typically facilitated by each region utilizing its own database to maintain information used by the security access system of the region.

[0005] Further, information needed for managing badges in one region is unavailable to any other region. This may lead to security problems when changes in information made at one region affect access decisions to the areas which the personnel may enter or exit from. Thus, for example, if an employee is terminated in one region, the employee may be able to use one or more of his or her badges to access areas within other regions in which access had been established.

[0006] In addition, by using separate regional security access control systems, there is no readily available means for the headquarters (or main corporate office) of a company to monitor the operation of each region. Thus, the headquarters of a company typically cannot determine the status of security at any particular region or site. Furthermore, it is difficult for the headquarters to monitor the information being used to manage the badges of personnel in different regions, and to establish uniform procedures for generating badges in different regions.

[0007] It is the principal object of the present invention to provide an improved access control system which has a single master database for storing information used by multiple regions to provide security access control and management of badges in the region, while allowing each region to operate independent of the master database in accordance with a regional database.

[0008] Another object of the present invention is to provide an improved access control system which allows changes made at each region in information for managing badges to be distributed to a master database and to each other region.

[0009] A further object of the present invention is to provide an improved access control system having multiple regions in which each region has a regional database having information which is maintained identical to a master database.

[0010] A still further object of the present invention is to provide an improved access control system having multiple regions in which badges can be used in more than one region.

[0011] It is yet a further object of the present invention to provide an improved access control system which has one or more portable badging systems.

[0012] It is still another object of the present invention to provide an improved access control system having multiple regions in which each region has a regional database and when a change in information occurs in the regional database affecting access control decisions in the region, security information reflecting this change is automatically distributed to access control equipment in the region.

[0013] Briefly described, the system embodying the present invention includes multiple regions, in which each region comprises one or more sites having areas to which access is controlled, multiple regional databases, where each regional database is associated with one of the regions, and a master database for storing system information, cardholder information for the system, and access control information for each region. A master computer system is coupled to the master database, while a regional computer system, capable of data communication with the master computer system via a network, is each coupled to each regional database. The master computer system downloads the system information and cardholder information from the master database to each regional database, and each regional computer system uploads (or replicates) to the master database access control information from their respective regional database to provide the stored access control information at the master database for that region. The access control information for each region stored at its regional database is thus initially identical to the access control information for the region stored at the master database. Similarly, the cardholder information stored for each region at its regional database is initially identical to the cardholder information at the master database.

[0014] Each region operates independent of the master database in accordance with their respective regional database, and can change the cardholder information or access control information stored in their respective regional database. More specifically, each region manages badges worn by personnel to access areas in accordance with the cardholder information stored at the regional database of the region, and administers access control of the region in accordance with the access control information stored at the regional database of the region. The system information cannot be changed by a region at a regional database, since it represents information for maintaining uniformity in the operation of each region, while enabling each region to operate independently of the master database in changing cardholder or access control information stored at its regional database.

[0015] Periodically, the regional computer system of each region connects to the master computer system and any additions, modifications, or deletions in the access control information of the region's regional database are uploaded from the regional database to the master database. Also periodically, the regional computer system of each region connects to the master computer system and any additions, modifications, or deletions in the cardholder information of the region's regional database are uploaded to the master database. The master computer system then downloads from the master database to each of the regional databases cardholder information in accordance with any additions, modifications, or deletions in the cardholder information uploaded to the master database from other regional databases (or made at the master database), thereby distributing changes in cardholder information to the regions. Thus, the access control information and cardholder information stored at the regional databases are maintained identical to its corresponding information stored at the master database. Although system information cannot be changed at a regional database, system information may be also periodically downloaded from the master database to the regional database to update each region with changes in system information made at the master database. The periodic upload and download by each region may occur in one or more communication sessions between the region computer system of the region and the master computer system.

[0016] The cardholder information and access control information in the system each utilize unique identifiers to different parts of the cardholder information and access control information, respectively. The system information downloaded to each region comprises ranges of unused identifiers allocated to each of the regional databases for enabling each region to generate additional cardholder information and access control information in the regional database, which facilitates the independent operation of each region from the master database, and provides enhanced flexibility controlling access throughout integrated facilities.

[0017] The foregoing objects, features and advantages of the invention will become more apparent from a reading of the following description in connection with the accompanying drawings in which:

[0018] FIG. 1 is a block diagram of the system in accordance with the present invention;

[0019] FIG. 2 is a block diagram showing the regions of the system of FIG. 1 in more detail;

[0020] FIG. 3 is a flow chart showing the operation and programming of the system;

[0021] FIG. 4 is a flow chart showing the programming of FIG. 3 for uploading any changes (add, modify, or delete) in cardholder information from one of the regional databases of FIG. 1 to the master database of FIG. 1;

[0022] FIG. 5 is a flow chart showing the programming of FIG. 3 for downloading from the master database of FIG. 1 to one of the regional databases of FIG. 1 any changes (add, modify, or delete) in cardholder information made at the master database; and

[0023] FIG. 6 is a block diagram showing an example of the logical segmentation of a regional database and an example of a region having multiple subregions.

[0024] The access control system of the present invention includes multiple regions in which each region has one or more sites with buildings having areas in which access is controlled and monitored. Each of these regions may be a geographic region, such as cities, states, countries, or continents. In each region, card readers are associated with each area where access (entry or exit) is controlled to read information from badges worn by personnel. Information read from a badge by each card reader and other verifying information which may be provided by a cardholder to the reader, such as a pin number, is compared against stored records of a database which may be located in a central controller, one of several access controllers, or a card reader, to determine if entry to or exit from an area is granted to the badge holder. Each region further provides badging for personnel in that badges used in the system may be added, modified or deleted. Each region in the system operates independent of the other regions in providing badging and controlling access in accordance with a regional database for the region, while a master database provides a repository for information used by the regions in the system. The present invention is not limited to the use of any particular type of access control equipment in a region, so long as each region has a regional database which provides a repository for information used by the region.

[0025] Referring to FIG. 1, the access control system 10 of the present invention is shown having a master database 12 and multiple regional databases 14, where each regional database is associated with a different geographic region. A master computer system 16, such as a computer server (called hereinafter the master server), has a memory storage unit storing the master database 12. Each of the regional databases 14 is stored on a memory storage unit of a regional computer system 18, such as a computer server (called hereinafter the regional server). For example, the memory storage units of the master server 16 and each regional server 18 may be a hard drive. Although two regional servers 18 and databases 14 are illustrated in FIG. 1, any number of regional servers and databases may be included in system 10.

[0026] A communication network in system 10 provides data communication between the master server 16 and each of the regional servers 18, and hence between their respective databases 12 and 14. The master server 16 and regional server 18 each have communication interfaces, such as an Ethernet network card, through which such data communication can take place. The master server 16 and regional servers 18 each operate in accordance with software which can enable the transfer of data, such as files or records, between the master database 12 and regional databases 14, respectively. This software, for example, may be WindowsNT sold by Microsoft, but may be any other type of software enabling such transfer of data and files. The communication network may be WAN, Internet-based, or utilize any other type of wide area network. The communication protocol in providing network communication may be, for example, TCP/IP (Internet) protocol, or other WAN protocols may be used. Other types of communication networks may also be used, such as a telecommunication network, or LAN. The communication network in FIG. 1 is bidirectional between the master server 16 and regional servers 18 as illustrated by arrows 22. Connections between the master server 16 and each regional server 18 are established when data communication is required; however, permanent connections may alternatively be provided.

[0027] Master computer workstations 17, which may represent computer-based systems, can each log onto the master server 16 to allow users to interface with the master server 16 and the master database 12. The master computer workstation can also log into a regional server, if the user of the workstation has permission. Similarly, regional computer workstations 19 may represent computer-based systems. Each regional computer workstation 19 can log into the regional server 18 to which the workstation is associated with to allow users to interface with the regional server and the regional database 14. A regional computer workstation 19 can also log into other regional servers or the master server, if the user of the workstation has permission. The regional workstations will be discussed in further detail in connection with FIG. 2.

[0028] FIG. 2 shows the system of FIG. 1 in more detail. Each region has a regional server 18 with a regional database 14 coupled to access control equipment 21, such as access controllers, alarm panels, and readers. Multiple workstations 19 provide various functions in the region, such as region administration (e.g., for updating the configuration of access control equipment or access levels), alarm monitoring in the region, and badging. One or several workstations 19 may provide these functions. The workstations 19 may be connected to the regional server 18 and regional database 14 via a regional LAN 22. For purposes of illustration only region #1 (denoted as numeral 24) and region #N (denoted as number 24n) are shown, where N equals the number of regions in the system.

[0029] Also shown in FIG. 2 is an external computer system 26 having an external database 28 storing employee and/or badge information which is coupled to the master database 12, via the master server 16, for downloading security information to the master database 12, where the master database represents the central database for the system 10. This downloading of security information is described in patent application Ser. No. 09/135,822, filed Aug. 18, 1998, which is herein incorporated by reference, and assigned to the same assignee as the present application. In the case where the system 10 provides access control and monitoring for a company located in several regions, the external database 28 may represent the corporate headquarters human resource's database. Each region may similarly have its own external computer system 26 having an external database 28 coupled to its regional database 14, via its regional server 18, for downloading security information to the regional database as described in patent application Ser. No. 09/135,822, where the regional database of each region represents a central database with respect to that region.

[0030] The master server 16 and regional servers 18 utilize database software for building and maintaining their respective databases 12 and 14. This software must provide the capability of building relational-type databases, one-way database replication of records between two databases, tracking of changes occurring in a database, and updating changes of a database to another database such that their records are identical. For example, this software may be SQL Server sold by Microsoft, Inc., Informix sold by Informix, Inc., or Sybase sold by Sybase, Inc. Software is also stored at the master server 16 and regional servers 18 for operating the system in accordance with programmed instructions in accordance with the flow charts of FIGS. 3-5. The information and data structure of databases 12 and 14 is described below. The term replication as used herein generally refers to synchronization of specific parts of two distinct databases such that the parts are identical.

[0031] The master database 12 stores cardholder information for the entire system, access control information for each region, and system information. Cardholder information represents information used by each region to manage badges to personnel in any of the regions. The cardholder information includes records stored in four different tables: Personnel (employee) table, Badge table, Multimedia table, and Access Level Link table. The Personnel table has data fields for information relevant to all employees, contractors, faculty, students, or any person who may be issued a badge, such as name, site, status, employee type, department, phone, Employee ID (EMPID), and the like. The Badge table has fields for the Badge Numbers of all badges used by employees, contractors, or other persons, to access areas of one or more buildings or sites controlled by the system, and other badge specific information, such as pin numbers, issue number, and the like. Each record in the Badge table is linked to a record in the Personnel table by a field set to EMPID. The Multimedia table is an optional table which records information about a person who may be issued a badge, such as a digital photograph of the person's face. Each record in the Multimedia table is linked to a record in the Personnel table by a field set to EMPID. The Access Level Link table has an identifier to a row or record to another Access Level table of the access control information, which determines the access privileges for the badge. Each record in the Access Level Link table is linked to a field set to the Badge Number to which it is associated. The cardholder information uses identifiers, such as Badge Number and EMPID, to uniquely identify records in the tables of the cardholder information. The information and data structures defined herein may be such as described in cited patent application Ser. No. 09/135,822.

[0032] Each record in the Personnel table and Badge table also includes a Last Change Date field. When a record in first added to a database, the Last Change Date field is set to the date and time the record was created. When a record is changed, the Last Change Date of the record is updated to the time and date the change occurred. When a record is added or changed for either the Multimedia table or Access Level Link table, the date and time of the addition or change updates the Last Change Date of the linked Personnel or Badge record, respectively.

[0033] Access control information for each region represents records of tables pertaining to the hardware configuration of access control equipment for the region, such as access controllers, alarm panels, and card readers, and tables relating to their function. Further the access control information includes the Access Level table. Each access level in this table defines the particular card readers through which access may be granted, and the time periods (zones) in which access may be granted at such readers. Access control information may also include tables with any other types of region specific information affecting access decisions, such as holidays or plant shut down periods when access for certain levels should be restricted, or event history. The access control information utilizes unique identifiers for access control equipment, such as reader identifiers, access controller identifiers, and alarm panel identifiers, to identify such equipment and the records in multiple tables of access control information related to such equipment.

[0034] The system information stored in the master database represents information which is uniform at each region's regional database. The system information includes tables defining system wide information and the records contained therein, such as general information about the sites, building, and regions of the system. The system information also includes information for establishing network connections and data communication via such connections, and the layouts (i.e., data fields) of all the tables in which records of cardholder information and access control information are to be stored, the badge layouts, the badge types, card formats, the types of multimedia stored as cardholder information, event types, the format of templates used to generated reports, ranges of unused identifiers for cardholder information and access control information allocated to each region in the system, and general system-wide configuration options, such as the maximum number of badges for each cardholder.

[0035] The above illustrates the master database while the system is operating, at installation of the system only the system information may be included in the master database, while cardholder information and access control information is uploaded from each regional database to the master database. The master database may at installation contain an initial set of cardholder information containing information downloaded from an external database, such as shown in FIG. 2. When the system is operating, each regional database is similar to the master database, except the access control information stored at the regional database is associated only with the region associated with the regional database. Further, the master database also includes a master cardholder transaction table, and each regional database includes a regional cardholder transaction table. The records stored in these tables will be described later in connection with FIGS.4 and 5.

[0036] The master database 12 may also store configuration information for operating the system which does not require to be downloaded to each region. Such information may include the unique Database ID (identifier) of each of the regional databases and of the master database in the system, or their addresses on the network. The regional database may also store regional configuration information which is needed only by the region, and thus is not uploaded to the master database.

[0037] Referring to FIGS. 3, 4 and 5, the operation of system 10 will now be described. In FIG. 3, the first three steps 32, 34, and 36 provide installation of the system 10 in each region such that the identical cardholder information is stored in the master database 12 and each regional database 14, and that the master database 12 has stored all the access control information provided by each region. The system is configured at step 32 such that network connections can be established between the master server 16 and each regional server 18, and that database replication can take place between the master database 12 and each regional database 14. This requires identifying the master server 16 to each of the regions, such as by its network address or Database ID, and likewise identifying to the master server 16 each of the regions by their network address or Database ID. To establish proper communication by regional servers 18 in the network, part of the system information stored in the master database relating to data communication may be downloaded to each region at step 32 in order to synchronize communication between the master server 16 and each regional server 18 via their network connection. To establish database replication, the database software operating at each regional server 18 and the master server 16 is instructed as to which records of tables of the cardholder information and access control information are later to be replicated.

[0038] The configuration at step 32 also includes setting up in each region the operational software for administering of access control functions in the region for access control equipment in the region, and includes the monitoring of alarms in each region. The particular access control provided by each region is not critical, so long as each regional database 14 can store access control information for the region.

[0039] Optionally at step 32, if an external database having personnel information is present, such personnel information may be downloaded and stored as cardholder information in the master database. The downloading of personnel information and storing such information as cardholder information in a database is described in cited patent application Ser. No. 09/135,822.

[0040] Next, at step 34, the system information is downloaded from the master database 12 to each regional database 14 through their respective servers and then the cardholder information is downloaded. The downloaded system information is used by each regional server 18 to establish the data structure of tables and their data fields for storing cardholder information and access control information. This enables the downloaded cardholder information to be stored as records in the tables of the cardholder information at the regional database 14. This step is complete once each region stores the same system information and cardholder information as stored in the master database. If cardholder information has yet to be established, then none is downloaded at step 34.

[0041] When cardholder information is downloaded to a regional database from the master database, a set of default access levels may be assigned to each cardholder. Such default access levels to the Access Level table are defined in the access control information of each region, and may be based on the type of badge, where different categories of personnel, such as employees, contractors, faculty or students, or classifications of employees, may have different types of badges. Thus, each badge in the system can be used in each region of system 10 as defined by the entry or exit privileges for the access levels assigned for that badge for that region. If any of the cardholder information effects access control decisions in the region, then security information reflecting this change in the regional database is distributed automatically to the access control equipment of the region, as described in cited patent application Ser. No. 09/135,822.

[0042] At each region, with the tables now set up for the access control information (including the Access Level table), the region loads into these tables the configuration of the access control hardware and Access Levels. The configuration of the access control hardware and Access Level need not be complete at this time, since it can be updated later at the discretion of each region. At step 36, the access control information (tables and records in such tables) of each regional database 14 is replicated (or uploaded) to the master database, via their respective servers. This replication is facilitated by the database software operating at the master server and each regional server which was setup at step 32. Thus, the master database 12 stores the access control information from each regional database 14, which may be maintained under the Database ID of each region. This replication may be done simultaneously from each regional database 14 to the master database 12, or serially by each region server 18 in turn replicating its access control information to the master database 12.

[0043] Each region may add, modify, or delete any records stored in the access control information of its regional database 14 independent of the master database 12. The database software at each region keeps track of all changes (i.e., add, modify, or delete) of the access control information in a transaction log. This is a function of the database software setup earlier at step 32. On a predefined schedule, such as every 24 hours, each regional server 18 connects to the master server 16 and uploads (writes) the transactions in access control information stored in the transaction log to the master database (step 38), such that the access control information stored in the master database 12 is again identical to the access control information stored in each regional database 14. This upload of transactions is another function of the database software for replicating the part of the master database 12 and regional database 14 pertaining to the access control information.

[0044] After step 38, the system information is updated from the master database to each regional database (step 39). This is achieved by the regional server deleting all records in the regional database relating to system information, and then downloading the records for the system information from the master database to the regional database. Step 39 may occur periodically, or step 39 may occur only when a change in the system information at the master database must be distributed to all regional databases.

[0045] In addition to changing access control information, each region may add, modify, or delete any records stored in the tables of the cardholder information independent of the master database or any other region. After each change (i.e., add, modify, or delete) is completed, a transaction record is added to the regional cardholder transaction table for the region. The data structure for this transaction record includes, for example, data fields for the following: Time, Transaction ID, EMPID, Badge Number, Action Type (either add, modify, or delete), Object Type, and the Destination Database ID. Time is the time (date and time) that the transaction was made. Each server in the system 10 has a clock maintaining the date and time for the system, as typical of computer servers. The Transaction ID is a unique identifier for the transaction at the region. EMPID is an employee identifier associated with the record of a Personnel Table of the cardholder information effected. Badge Number is the badge identifier for the record effected, and is used if the change in cardholder information effected a record of either a Badge table or an Access Level Link table. Object Type represents the type of record effected by the change in cardholder information, either a Personnel record, Badge record, Multimedia record, or Access Level Link record, associated with the Personnel, Badge, Multimedia, or Access Level Link table, respectively. The Destination Database ID is the database to be updated in accordance with the transaction record. In the case of a regional transaction record, the Destination Database ID data field is set to the Database ID associated with the master database. Each transaction record is stored in the regional cardholder transaction table with an upload status flag. The upload status flag is initially set to a “not done” value to indicate that the upload of the transaction record to the master database has not yet occurred. The upload status flag may have one of three values indicating “not done”, “done”, and “failed”.

[0046] On a predefined schedule, such as every 24 hours, each regional server 18 connects to the master server 16 and uploads changes in cardholder information from the regional database 14 to the master database 12 in accordance with the transaction records stored in the regional cardholder transaction table (step 40). The process for uploading changes in cardholder information by the regional server for each region is shown in FIG. 4. First, all the transaction records in the regional cardholder transaction table not yet uploaded (i.e., upload status flags set to “not done”) are sorted chronologically in ascending order based on the time field of each transaction record (step 44). Second, the first transaction record in the sorted transaction records not yet uploaded is looked up in the regional cardholder transaction table (step 46). If the Action Type of this transaction record represents a modify action (step 48), the branch to step 52 is taken and the record referenced by Object Type and either EMPID, or Badge Number, of the transaction record is looked up (accessed) by the regional server at both the regional database and the master database. The regional server then checks if the Time data field of the transaction record is later than the Last Change Date of the record looked up in the master database (step 53). If not, then the no branch to step 58 is taken and no modification of the record in the master database is made. If the record looked up relates to a Multimedia or Access Level Link table, the Last Change Date of the associated Personnel or Badge record, respectively, is used at step 53. If the Time data field of the transaction record is later than the Last Change Date of the record looked up in the master database, the record at the master database is modified with any differences found in the record at the regional database (step 54), such that the record at the master database is identical to the record at the regional database. Thus, step 53 assures that the system maintains in the master database the most recently modified records of cardholder information. When a record in the master database is modified at step 54, the master server then creates in the master cardholder transaction table a transaction record for each of the other regions in the system recording the change (i.e., modify) made to the record of the cardholder information at the master database (step 56). The data structure for each transaction record in the master cardholder transaction table is identical to the data structure of the transaction record stored in the regional cardholder transaction table. Each transaction record added has the Destination Database ID data field set to the Database ID of the regional database to be updated in accordance with the transaction record. In other words, at step 56, multiple transaction records (equal to the number of regions minus one) are added to the master cardholder transaction table in which each transaction record is identical, except for the Destination Database ID. No transaction record is added in the master cardholder transaction database with the Database ID associated with the region which uploaded the change to the master database. A download status flag is included in each transaction record added. The download status flag is initially set to a “not done” value to indicate that the download of the transaction record to the regional database identified in the record has not yet occurred. The download status flag may have one of three values indicating “not done”, “done”, and “failed”.

[0047] Once the record is communicated to the master database, the regional server sets the upload status flag of the transaction record in the regional cardholder transaction table to a “done” value if the transaction record was successfully uploaded (step 58), otherwise, the upload status flag is set to a “failed” value. For example, a failed upload may be due to a problem in modifying, adding, or deleting a record at the master database. If all the transactions as identified by their transaction records in the regional cardholder transaction table have been uploaded, the upload of cardholder information for the region is complete (step 60), otherwise the branch to step 46 is taken to upload the next transaction record in the regional cardholder transaction table.

[0048] If at step 48 the transaction record has an Action Type for an add action, the branch to step 49 is taken. At step 49, the regional server looks up in the regional database the record referenced by Object Type and either EMPID, or Badge Number, of the transaction record and adds the record found in the regional database to the master database. After the record is added to the master database, a branch to step 56 is taken in which the master server creates in the master cardholder transaction table a transaction record for each of the other regions recording the change (i.e., add) of the new record to the master database, as described earlier. Thereafter, the regional server sets the upload status flag of the transaction record in the regional cardholder transaction table to a “done” value if the transaction record was successfully uploaded, otherwise, the upload status flag is set to a “failed” value (step 58). If all the transactions as identified by their transaction records in the regional cardholder transaction table have been uploaded (step 60), the upload of cardholder information for the region is complete, otherwise, the branch to step 46 is taken to upload the next transaction record in the regional cardholder transaction table.

[0049] If at step 48, the transaction record has an Action Type set to delete, the branch is taken to step 50. At step 50, the regional server looks up the record in the master database referenced by Object Type and either EMPID, or Badge Number, of the transaction record, and that record is deleted from the master database. After the record is deleted from the master database, a branch to step 56 is taken in which the master server creates in the master cardholder transaction table a transaction record for each other region recording to the change (i.e., delete) made to the record of the cardholder information at the master database, as described earlier. The regional server then sets the upload status flag of the transaction record in the regional cardholder transaction table to a “done” value if the transaction record was successfully uploaded, otherwise, the upload status flag is set to a “failed” value (step 58). If all the transactions as identified by their transaction records in the regional cardholder transaction table have been uploaded (step 60), the upload of cardholder information for the region is complete, otherwise, the branch to step 46 is taken to upload the next transaction record in the regional cardholder transaction table.

[0050] The regional server next downloads from the master database to the regional database changes in cardholder information in accordance with the transaction records stored in the master cardholder transaction table having a Destination Database ID for that regional database (step 42). The process for downloading changes in cardholder information by the master server to each regional database is shown in FIG. 5. First, all the transaction records in the master cardholder transaction table not yet downloaded (i.e., download status flags set to “not done”) are sorted chronologically in ascending order based on the time field of each transaction record (step 62). Second, the first transaction record in the sorted transaction records not yet downloaded is looked up in the master cardholder transaction table (step 64). If the Action Type of this transaction record represents a modify (step 66), the branch to step 70 is taken and the master server looks up the record referenced by Object Type and either EMPID, or Badge Number, of the transaction record at both the regional database and the master database. The master server then checks if the Time data field of the transaction record is later than the Last Change Date of the record looked up in the regional database (step 71). If not, then the no branch to step 76 is taken and no modification of the record in the regional database is made. If the record looked up relates to a Multimedia or Access Level Link table, the Last Change Date of the associated Personnel or Badge record, respectively, is used at step 71. If at step 71 the Time data field of the transaction record is later than the Last Change Date of the record looked up in the regional database, the record in the regional database is modified with any differences found in the record in the master database (step 72), such that the record at the master database is identical to the record at the regional database. Thus, step 71 assures that the system maintains in the regional database the most recently modified records of cardholder information. After step 72, if the change in the record of the cardholder information affects access control decisions in the region, then security information reflecting this change in the regional database is distributed automatically to the access control equipment of the region (step 74), as described in cited patent application Ser. No. 09/135,822. Once the record is successfully updated to the regional database, the master server sets the download status flag of the transaction record in the master cardholder transaction table to a “done” value if the transaction record was successfully downloaded (step 76), otherwise, the download status flag is set to a “failed” value. For example, a failed download may occur due to a problem in writing a record change to the regional database. If all the transactions as identified by their transaction records in the master cardholder transaction table have been downloaded, the download of cardholder information to the region is complete, otherwise, the branch to step 64 is taken to download the next transaction record in the master cardholder transaction table.

[0051] If at step 66, the transaction record has an Action Type set to add, the branch is taken to step 67. At step 67, the master server looks up the record referenced by Object Type and either EMPID, or Badge Number, of the transaction record in the master database and adds the record to the regional database. When the record added to the regional database is an Access Level Link table, identifier(s) may be stored in that record to default access level(s) which may be assigned by the regional server in that record to the Access Level table for the region. After the record is added to the regional database, a branch to step 74 is taken in which if the change in the record of the cardholder information affects access control decisions in the region, then security information reflecting this change in the regional database is distributed automatically to the access control equipment of the region (step 74), as described in cited patent application Ser. No. 09/135,822. Thereafter, the master server sets the download status flag of the transaction record in the master cardholder transaction table to a “done” value if the transaction record was successfully downloaded, otherwise, the download status flag is set to a “failed” value (step 76). If all the transactions as identified by their transaction records in the master cardholder transaction table have been downloaded, the download of cardholder information to the region is complete, otherwise, the branch to step 64 is taken to download the next transaction record in the master cardholder transaction table.

[0052] If at step 66, the transaction record has an Action Type set to delete, the branch is taken to step 68. At step 68, the master server looks up the record referenced by Object Type and either EMPID, or Badge Number, of the transaction record in the regional database and deletes the record from the regional database. After the record is deleted from the regional database, a branch to step 74 is taken in which if the change in the record of the cardholder information affects access control decisions in the region, then security information reflecting this change in the regional database is distributed automatically to the access control equipment of the region (step 74), as described in cited patent application Ser. No. 09/135,822. The master server then sets the download status flag of the transaction record in the master cardholder transaction table to a “done” value if the transaction record was successfully downloaded, otherwise, the download status flag is set to a “failed” value (step 76). If all the transactions as identified by their transaction records in the master cardholder transaction table have been downloaded, the download of cardholder information to the region is complete, otherwise, the branch to step 64 is taken to download the next transaction record in the master cardholder transaction table.

[0053] Referring back to FIG. 3, after step 42 is complete for a region, the cardholder information stored in the regional database will be identical to the cardholder information stored in the master database, unless a failed upload or download of a transaction record occurred. For each region, steps 38-42 may occur during the same communication session established between the regional server 18 of the region and the master server 16 or in different communication sessions. Further, steps 38-42 may take place in different order. But, regardless of the order of these steps, it is important that they occur periodically for each region, as indicated by loop 43, to enable distribution of cardholder information to databases of the system, uploading access control information to the master database from each region, and downloading of system information to regional databases. For example, the periodic interval may be daily or hourly. This interval may also be variable for one or all regions in which either step 38, 39, 40 or 42 occurs in real-time whenever a change (add/modify/delete) is made to either the regional or master database. In this manner, changes which have occurred in the cardholder information and access control information of each regional database are periodically uploaded from each regional database to the master database since such information was last identical between the regional database and the master database. Further, for each region, changes in cardholder information uploaded to the master database from other regions (or due to changes in cardholder information made to the master database via master workstations) are periodically downloaded to the regional database of the region. Thus, the master database maintains a repository of information, i.e., system, cardholder, and access control information, used by each of the regions of the system, and as described later, information used by a portable badging system 20 (FIG. 1).

[0054] At step 40, it is possible during the upload of changes in cardholder information from a regional database to the master database that one or more changes cannot be uploaded. This is due to the record of cardholder information being effected by an earlier upload from another regional database, or by a change to the record made in the master database by a user via master computer workstations 17. For example, if at a first region, a record was removed from the Badge table in its regional database, and at a second region, the same record was modified in its regional database, then the regional server of the first region when uploading changes in cardholder information will remove this record of the Badge table in the master database, and then the regional server of the second region will be unable to locate that record in the master database during its upload at step 52 (FIG. 4). Whenever a regional server is unable to upload one of its transaction records, it sets the upload status flag of the transaction record to a “failed” value. In the above example, when cardholder information is downloaded to the second regional database later at step 42 (FIG. 5) having changes made by other regions, that record of the Badge table will be removed from the second regional database. A similar condition can occur at step 42 when the master server is unable to download a change in cardholder information to a region. Whenever the master server is unable to download one of its transaction records, it sets the download status flag of the transaction record to a “failed” value.

[0055] When the regional server sets the upload status flag of a transaction record of its regional cardholder transaction table to a “failed” value, the details of the failed upload may be entered in an error log by the regional server in the regional database. For example, these details may include the time of the attempted upload in accordance with the transaction record, a copy of the data sent to the master server, a copy of the record associated with the transaction record in the regional database, or, if applicable, a copy of the record in the master database to which upload was attempted. An administrator at the regional server can investigate the failed upload using this entry in the log, and decide either to delete the transaction record, or fix the problem causing the failed upload and retry upload of the transaction record the next time step 40 occurs for that region by resetting the upload status flag of the transaction record to a “not done” value. Similarly, when the master server sets the download status flag of a transaction record of its master cardholder transaction table to a “failed” value, the detail of the failed download may be entered in an error log by the master server in the master database. An administrator at the master server can investigate the failed download using this entry in the log, and decide either to delete the transaction record, or fix the problem causing the failed download and retry download of the transaction record the next time step 42 occurs to that region by resetting the download status flag of the transaction record to a “not done” value.

[0056] Each region is capable of deleting, modifying, or generating badges for use in accessing areas throughout all the regions of the system 10, called badging. As stated earlier, a computer workstation 19 coupled to the regional database 14, via regional server 18, can provide for such badging. The modifying of badges is provided by updating records in the tables of the cardholder information, while deleting of badges is provided by removing records in such tables. For example, to update a person's badge to access areas for a particular region, a user via the regional server can access the cardholder information for a person in the regional database of the region, and set the badge for this person to an Access Level of the region, i.e., add an Access Level Link table for Badge Number having an identifier to the Access Level table of the region. The generating of new badges requires new identifiers, such as EMPID or Badge Number, for building new records for the tables in the cardholder information in the regional database. Each region obtains such new identifiers from the ranges of unused identifiers allocated to the region via the downloaded system information (step 34 of FIG. 3). Similarly, each region provides for deleting, modifying, or generating records for access control information. To generate new records for access control information, each region obtains new identifiers from the ranges of unused identifiers allocated to the region for such information. Thus, when the master database is uploaded with new records from each region generated using new identifiers, such records will not interfere with existing records.

[0057] In addition to the master database 12 storing transaction records in response to changes in cardholder information uploaded from each region, the cardholder information stored at the master database could also be changed by a user at a master computer workstation 17, or at a regional computer workstation 19 having permission to access the master database. For each change (i.e., add, modify, or delete) so made in a record to a table of the cardholder transaction information, a transaction record is entered into the master cardholder transaction table for each region. The data structure for each transaction record in the master cardholder transaction table is identical to the data structure of the transaction record stored in the region cardholder transaction table. Each transaction record added has the Destination Database ID data field set to the Database ID of the regional database to be updated in accordance with the transaction record. In other words, at step 56, multiple transaction records equal to the number of regions are added to the master cardholder transaction table in which each transaction record is identical, except for the Destination Database ID. The download status flag is included in each transaction record added to the master cardholder transaction table which is initially set to a “not done” value.

[0058] As stated earlier, each regional database may further include regional configuration information needed only by the region. Regional configuration information is not replicated to the master database or provided to other regions, but located only on the regional database of the region. For example, such regional configuration information may include access groups, where various access levels may be defined as part of an access group, or zones of areas monitored by the region.

[0059] Referring back to FIG. 1, system 10 may also include a portable badging system 20 having a portable database 15. This database 15 may represent another regional database in the system, except that no access control information is stored in the database and the database is not coupled to access control equipment. Portable badging system 20 may represent a laptop computer, while database 15 may represent the hard drive or other memory storage unit coupled to the computer. A network connection may be established between the badging system 20 and the master database 12, via the master server 16, as denoted by arrows 13. The portable badging system 20 has a Database ID in system 10 and a cardholder transaction table, such that it can participate in the periodic uploading and downloading of changes in cardholder information as described earlier. In operation, the portable badging system 20 performs the same as the regional database and regional server as described in connection with FIGS. 3-5, except that steps 36 and 38 are not required. Although only one portable badging system in shown in FIG. 1, system 10 may have any number of such portable badging systems.

[0060] For purposes of database and network management, one or more of the regional databases 14 may be logically segmented into two or more segments, where each segment has a unique Segment ID. A segmented regional database is the same as described earlier, except that each record of access control information is assigned a Segment ID. The Segment ID is included in the access control information uploaded to the master database at steps 36 and 38 (FIG. 3). Each segment is composed of records relating to a different set of access control equipment, i.e., access controllers, card readers, and alarm panels. A segment may relate to a group of areas in the region where access is controlled, such as a department, company division, or other section where logical partitioning of access control is desired. Although segmenting a regional database is optional, it can facilitate administration in the region by enabling administration segment by segment. For example, a user may be given permission to view or edit from a workstation only the access control information related to specific segment(s). Segmentation also enables a segment to have access control configuration different from another segment in terms of the programmable features such as timezones or access levels. Further, the access controllers in a segment need only store records pertinent to their segment, thereby increasing the total number of records which can be stored in access controllers within the entire region. FIG. 6 shows an example of segmentation of a region 82 where the regional database of each region has three segments 83(a), 83(b), and 83(c). The segments are illustrated as separate parts of the database for purpose of illustration.

[0061] Optionally in system 10, a regional database 14 may serve as a master database to one or more subregional databases in subregions of a region. This is shown, for example, in FIG. 6 in which region 80 has subregions 84 and 86. A subregional database 14(a) and 14(b) is provided for subregion 84 and 86, respectively, through a subregional server 18(a) and 18(b), respectively. Each subregional database represents a regional database to the regional database serving as a master database, and stores access control information for the subregion, and system information and cardholder information similar to a regional database. The subregional database operates like the regional database and the regional database operates like the master database as described in connection with FIGS. 3-5. Each subregion has access control equipment having a number of access controllers and reader coupled each access controller, and an Access Level table having, for each access level, the readers and time zones defining where and when entry/exit will be granted for that subregion. The subregion may have access control equipment and computer workstations coupled to the subregional database. Further, each subregional database can then serve as a master database to further databases in that subregion, and so forth, thus providing multiple levels of subregional databases. For example, the sites of a company in Tokyo, Los Angeles, and the Eastern United States may each represent a region in system 10, the Eastern United States region may have sites in subregions of New York State, Boston and Atlanta, and New York State may have further have sites in subregions of New York City and Rochester.

[0062] Each subregional database has a Database ID. This enables each subregional database to upload and download changed cardholder information with the regional database acting as a master database. The upload and download of cardholder information is the same as described earlier between a regional database 14 and master database 12, except that when a record is changed at the regional database in response to an upload from a subregional database, in addition to transaction records being created for each other subregional database, a transaction record is created for updating the master database 12 by setting the Destination Database ID of the record to that of the master database. Accordingly, when the regional database participates in uploading changes in cardholder information to the master database 12, changes in cardholder information made at subregional databases are uploaded to the master database. Further, when a record in the regional database is changed responsive to a download from the master database, a transaction record is created in the regional cardholder transaction for each subregional database associated with the regional database. Thus, when the regional database participates in the downloading changes in cardholder information to the subregional database 12, changes in cardholder information originally made at master database are downloaded to the subregional database. Also, changes in access control information made at each subregional database are replicated to the regional database acting as a master database to the subregions, as described earlier between a regional database 14 and the master database 12. Such changes made in the access control information at the regional database in accordance with the subregional databases are then replicated to the master database. The master server 16 may store in the master database the access control information separately for each subregion. System information downloaded to the regional database acting as a master database is downloaded from the regional database to each subregional database, where each subregional database is allocated a different subset of unused identifiers assigned to the region. Therefore, the master database 14 contains all access control information and events for generating reports on system 10, and all cardholder changes made anywhere in the system are distributed throughout the databases of the system. Further, like regional databases, subregional databases operate independently of the master database and the regional databases, in accordance with their respective subregional database.

[0063] For the purpose of tracking access control information in the regional database, each different subregion may be assigned a Segment ID, as defined above, and records of access control information for each subregion include the Segment ID of the subregion. The subregional database, like a regional database, may be segmented into two or more segments, such as described earlier.

[0064] Referring back to FIG. 2, a mobile badging unit 30 may also be coupled to the region database 14, through regional server 13. The mobile badging unit 30 has a database, which represents another subregional database to the regional database, except that no access control information is stored in the database and the database is not coupled to access control equipment. Mobile badging unit 30 may represent a laptop computer and its database a hard drive or other memory storage unit. A network connection may be established between the badging unit 30 and a regional database 14, via the regional server 18. The mobile badging unit 30 has a Database ID and a cardholder transaction table, such that it can participate in the periodic uploading and downloading of changes in cardholder information with the regional database to which it is associated. In operation, the mobile badging units 30 performs the same as the subregional database and subregional server, except that steps 36 and 38 are not required. Thus, the mobile badging unit operates similar to the portable badging unit 20, but with respect to the regional database, rather than the master database.

[0065] As stated earlier, regional computer workstations 19 coupled to a regional database 14, via a regional server 18, can in addition to logging into the regional server, can login to other regional servers 18 in the system or the master server, depending on user permission. This can provide badging, monitoring, or administration functions outside of a region. A single computer workstation 17 or 19 can monitor the operation of the access control equipment in one region or simultaneously in multiple regions by logging onto the regional server of such regions. Such monitoring of the operation of the access control equipment of a region, such as alarm panels or access controllers, may be performed, for example, by query as to status, events, or alarms.

[0066] System 10 can be separated into two systems, a first system for providing security access control in multiple regions in accordance with access control information at each regional database, and a second system for managing badging for security access control in multiple regions in accordance with cardholder information at each regional database. The first and second systems could be operated independent of each other in which the master database in the first system would provide a repository of all access control information in each region, while the master database in the second system would provide a repository of all cardholder information in the system and facilitate the distribution of changes in cardholder information from each of the regions to other regions. The operation of the first system for providing security access control in multiple regions would be identical to that of described in connection with FIG. 3, except step 34 would download only system information, and steps 40 and 42 would not be required. The operation of the second system for managing badging for security access control in multiple regions would be identical to that described in connection with FIGS. 3-5, except steps 36 and 38 would not be required.

[0067] The data structures described above are exemplary. Other data structures with different information may be used with different tables for storing the information described herein. For example, the Personnel table of the cardholder information may be two or more related tables for purposes of data storage management.

[0068] From the foregoing description, it will be apparent that an improved access control system operating in multiple regions has been provided. Variations and modifications of the herein described system and other applications for the invention will undoubtedly suggest themselves to those skilled in the art. Accordingly, the foregoing description should be taken as illustrative and not in a limiting sense.