Abstract:
As access control system and method is provided. The access control system in one aspect may comprise a client application operable to provide a user interface for allowing a user to dynamically configure rules and associated parameters for controlling access to an entity; a rules engine proxy operable to receive said rules and associated parameters from the client application, the rules engine proxy further operable to dynamically compile and execute said rules; and a controller coupled to the rules engine proxy operable to receive input and further operable to trigger the rules engine proxy to execute one or more of said rules in response to the received input

Description:
BACKGROUND OF THE INVENTION  
       [0001]    1. Field of Invention 
         [0002]    The present disclosure generally relates to security systems, and particularly to access control system with rules engine architecture. 
         [0003]    2. Description of Related Art 
         [0004]    Access control systems ensure that only authorized persons or entities access elements such as physical entries to buildings or areas, access to computer system or data, etc. Access control systems can provide different levels of access to different persons or entities based on different authorization levels, for example configured in the systems. Many systems exist that implement authentication mechanism for controlling or verifying authorized access to physical areas, locked doors, computer systems, data, etc. Most common approach is authentication by user id and password. These systems may use a physical device, such as a bank card, a smart card, or a computer chip to identify a person. Additionally or alternatively, the systems may use biometrics to identify physical characteristics of a person. Biometrics may include technologies that verify voice, perform a retinal scan, palm identification, and fingerprints. 
         [0005]    Access control systems can provide different levels of access to different persons or entities based on different authorization levels, for example configured in the systems. Typically, the existing systems hard code or implement in a similar manner the access control authorization configuration the meet specific needs of an individual entity or user. For instance, bank A may have one logic and authorization configuration required to meet its security needs, while bank B may have a different logic and authorization configurations. 
         [0006]    What is desired, therefore, is an access control system that can be used to configure and execute different rules and configurations without having to excessively re-implement the access control system in order to meet the different requirements of different users or customers. It would be also desirable to have a flexible access control system-n in which the users or customers may dynamically update or modify the rule logic and associated parameters and be able to execute the rules, for example, without having to request a customer service to re-implement the access control system. 
       BRIEF SUMMARY OF THE INVENTION  
       [0007]    An access control system and method is provided. The access control system in one aspect may comprise a client application operable to provide a user interface for allowing a user to dynamically configure rules and associated parameters for controlling access to an entity; a rules engine proxy operable to receive said rules and associated parameters from the client application, the rules engine proxy further operable to dynamically compile and execute said rules; and a controller coupled to the rules engine proxy operable to receive input and further operable to trigger the rules engine proxy to execute one or more of said rules in response to the received input. 
         [0008]    Further features as well as the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0009]      FIG. 1  is an architectural diagram illustrating a system of the present disclosure in one embodiment. 
           [0010]      FIG. 2  illustrates an example of a ladder icon diagram representing access control logic in one embodiment of the present disclosure. 
           [0011]      FIG. 3  is a diagram showing a rules engine system of the present disclosure in one embodiment. 
           [0012]      FIGS. 4A-4G  illustrate an example of a logic implemented with a ladder diagram for vault-door restraint operation according to one embodiment of the present disclosure. 
           [0013]      FIG. 5  illustrates examples of the icons that may be used to implement rules logic in the ladder diagram of the present application. 
           [0014]      FIG. 6  is a flow diagram illustrating an operation in one embodiment of a rules engine proxy. 
           [0015]      FIG. 7  illustrates examples of components used in the rules engine in its operation. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0016]    System and method for implementing rules engine in security access control system are provided. An application such as a user interface application allows a user to configure or define rules specific to the user&#39;s requirements. The system and method in one embodiment intelligently parses particular rule configurations that are specific to a user and also implements user-changed requirements. Based on the defined rules, a compiler or rules engine automatically parses each statement of configuration program and assigns it to the access controllers for pre-defined execution. 
         [0017]      FIG. 1  is an architectural diagram illustrating a system of the present disclosure in one embodiment. Client application tools  202 ,  204 ,  206  may be distributed and installed on various client systems, workstations, etc. Client application tools  202 ,  204 ,  206  allow a user to enter and edit rules, change parameters, etc. The client application  202 ,  204 ,  206  may provide various levels of access to different types of users. For example, a user with an administrator status may be allowed to add and edit rule logic, a user with an operator status may be allowed to change parameters such as adding and deleting users, and a user with a guest status may be allowed to view the rules, but not change them, etc. Other user access levels or permissions are possible. 
         [0018]    In one embodiment, an application tool may comprise functional components or functionalities for processing user login and authentication, graphical user interface and editor for presenting the rule logic and other information in a presentable form, a translator that translates stored data such as the rule logic and other information into a graphical form for presentation, a downloader or a communication functionality that communicates data such as the rule logic and other information to a server. A client application  202 ,  204 ,  206  may locally store rule logic and other data in a local database to be retrieved for presentation and editing. 
         [0019]    A server component  208  collects data from the client, for example, new rules, modifications to the existing rules, or other parameter changes, and uploads the data to one or more rules engine proxies  210 ,  212 . During execution, rules engine proxies  210 ,  212  dynamically generate and execute code for enforcing the rules, for example, based on the rules configured by a user and downloaded to the proxies. In this way, users may dynamically configure and modify rules based each user&#39;s specifications. 
         [0020]      FIG. 2  illustrates an example of a ladder icon diagram representing access control logic in one embodiment of the present disclosure. In the ladder diagram, if the variables represented by the icons appearing on the same level of the ladder evaluate to true then the variable represented by the rightmost icon on that same level in the ladder evaluates to true. The ladder diagram shown in  FIG. 2  implements the following logic for a card swiped at a card reader device. At level  1  shown at  202 , if a reader device is “Reader1”, access card belongs to or has access level of “president”, the time at which the card is swiped is within a specified time zone, then “EN1” flag is enabled or set. At level  2  shown at  204 , if flag “EN1” is enabled, another card belonging to user “A” is swiped at reader device “Reader1”, then a parameter “FL1” is enabled or set. At level  3  shown at  206 , if “EN1” flag is enabled and card belonging to user “B” is swiped at “Reader1” device, then “FL2” parameter is enabled or set. At level  4  shown at  208 , if “FL1” and “FL2” parameters are set and “DR2” evaluates to true, that is, for example, the door identified as “DR2” is shut ten the door identified as “DR1” is opened. At level  5  shown at  210 , if “FL1” and “FL2” parameters are set and “DR2” is true, then set “Reset1” to true, which triggers resetting various data and parameters to default values. 
         [0021]    The logic shown at level  206  in combination with the logic at levels  1  and  2  ( 202  and  204 ) is an example of the logic for implementing multi-card check at a device for opening a door or other enabling access to secured area. That is, the logic at those levels checks that both user “A” and “B” have swiped the card at a reader device, before enabling parameters “FL1” and “FL2” for allowing access to “DR1”. The logic shown at  208  is an example that implements interlock requirement for providing access to “DR1”. For example, the logic checks that another door or access entry “DR2” is closed before allowing access to “DR1”. 
         [0022]    In one embodiment, the values for the icons need not be a single value, rather they may comprise multiple of range of values. For example, user “A” icon shown at  212  may include a number of users. Thus, when a rules engine proxy checks for user “A” criterion, it may compare the swiped user with a number of qualified users. 
         [0023]    A user of the client application may create or edit rules in the ladder icon diagram, for instance, by dragging and dropping the appropriate icons on the user interface. A user may further enter the desired values for the icons in the diagram. For example, clicking on that icon may present a pop-up screen  214  via which a user may add, delete, and modify the values associated with that icon. 
         [0024]      FIG. 3  is a diagram showing a rules engine system of the present disclosure in one embodiment. A client system  302  may include an application tool, which may be used to configure various logic rules that dictate security access to security systems. The application tool as described above may include a graphical user interface such as shown at  304  for adding and editing rules defined for example by a user to meet the user&#39;s specific needs. In one embodiment the rules may be edited using graphical components such as a ladder diagram  314 . Icons from a panel  316  may be dragged and dropped in the ladder diagram to create logic rules. A mouse pass over an icon may trigger a popup of information associated with that icon. Double clicking on the icon may enable editing of the information associated with that icon. Icons values may also be added, modified using the interface  304 . A graphical user interface of the present disclosure such as the ladder diagram schema shown may use various icon symbols to denote different elements or components of the logic rules. 
         [0025]    The application tool in one embodiment translates the entered and/or edited rules into an expression and uploads the expression to a rules engine proxy  308 . The application tool may also store the rules in the client system  302  locally. The client system  302  may be connected to a rules engine proxy  308  via any know or will be known communication system or network  306 , wired or wireless or combination of both, etc., such as the LAN, WAN, Internet. The data from the client system  302  may be uploaded using protocols such as FTP or any other data transferring protocols or mechanisms. 
         [0026]    One or more controllers  3   10  receiving card swipes or other input entries connect to a rules engine proxy. An example of a controller  310  is a card reader device that reads data on a card and sends the data to a rules engine proxy  308 . Any known or will be known communication mechanism may be used to connect the controllers to rules engine proxies. In one embodiment, a rules engine proxy may be integrated with a controller. In  FIG. 3 , RS-485 connects a controller and a rules engine proxy, for example, which may reside in computer systems such as workstations, mid size systems, legacy systems. 
         [0027]    In operation, a user may swipe a card at a reader device associated with a controller  310 . The controller  310  then sends the data on the card to a rules engine proxy  308 . When a card is swiped or information otherwise entered, the data is sent to the rules engine proxy  308 , which triggers evaluation of rules associated with the received information. Upon evaluation of the rules logic associated with the received information, rules engine proxy  308  outputs status as to whether access should be allowed or denied. Output status that allows access may result in automatically opening or unlocking an entry such as a door. 
         [0028]      FIGS. 4A-4G  illustrate an example of a logic implemented with a ladder diagram for vault-door restraint operation according to one embodiment of the present disclosure.  FIG. 4A  particularly shows a segment of ladder diagram implementing an operation that grants an authority, for example, by a manager of the security system such as a bank manager. At step  1  ( 402 ) shown, a bank manager group CH 10  swiping on a card reader LV 10  within time zone TZ 10  results in inversion of register FLP 10 . At step  2  ( 402 ), if the icons specified on this rung evaluates to true, CH 22  is assigned to the card holder information. If FLP 10  is true, signifying that the Reader LV 10  has been enabled, and card from CH 21  group is swiped on LV 10  Reader within TZ 10 , CH 22  is assigned to the card holder information, meanwhile, Boolean variable LV 22  is set to TRUE. In this implementation, LV 22  is used to save the state of this line. Simultaneously, DRS 22 , APB 23  states are set to TRUE, to enable DURESS and ANTI-PASSBACK. 
         [0029]      FIG. 4B  illustrates a step of comparing the second card group. At step  3  ( 406 ), if FLP 10  is true, and a card from CH 23  group is swiped at reader LV 10  within the time zone specified in TZ 21 , CH 24  is assigned the card holder information. PLS 23  and LV 24  are used to store the state of the line temporarily. 
         [0030]      FIG. 4C  illustrates steps for opening the first door. At step  4  ( 408 ), if LV 22  or LV  24  is true, TW 20  is started to limit the card swipe time within two drawing group windows. At step  5  ( 410 ), if both LV 22  and LV 24  are true and TW 20  is started, DR 20  is opened. Further, TW 20  is reset, PLS 23  is triggered to release the card reader outside the first door, a counter CNT 10  is started to prepare tracking, TW 21  and TW 30  start. TW 21  represents a time within which an entry should occur. If TW 21  expires without entry, timeout occurs and the process returns back to step  2  ( 404 ) in  FIG. 4A . TW 30  represents a time limit for opening the second door. 
         [0031]      FIG. 4D  illustrates steps for comparing the cardholder at the second door. At step  6  ( 412 ), if TW 21  timed out on DR 20 , reset TW 21  and return to step  2  ( 404 ) in  FIG. 2 . At step  7  ( 414 ), if a card is swiped at LV 30  reader and belongs to user CH 22  and door DR 201  is closed, set LV 31  flag. At step  8  ( 416 ), if a card is swiped at LV 30  reader and belongs to user CH 24  and door DR 201  is closed, set LV 33  flag. 
         [0032]      FIG. 4E  illustrates steps for opening the second door. At step  9  ( 418 ), if LV 31  and LV 33  are true and TW 30  is valid, stop TW 30  and open the second door DR 30 , start timer TW 40 . TW 30  is reset. At step  10  ( 420 ), if a card belonging to CH 21  is swiped on LV 40 , DR 301  door is closed and TW 40  has not timed out, set LV 41  flag. At step  11  ( 422 ), if a card belonging to CH 23  is swiped on LV 40 , DR 301  door is closed and TW 40  has not time out, set LV 43  flag. 
         [0033]      FIG. 4F  illustrates steps for exiting with a door open, for example, in emergency handling. At step  12  ( 424 ), DR 20  door is opened when within TW 40  time, close LV 41  and LV 43  are true. Step  13  ( 426 ) may represent granting a user in CH 50  when swiped on LV 10  reader the ability to open DR 20  door, for example, in emergency situations. Step  14  ( 428 ) triggers a timeout warning when any of the times expire. 
         [0034]      FIG. 4G  illustrates steps that implement timeout, door status, duress, tracking and passback warning. Step  15  ( 430 ) illustrates that when any of the duress parameters (DRS 1 , DRS 20 , DRS 22 ) are set, a duress report represented by icon LV 53  may be triggered. Step  16  ( 432 ) illustrates that if DRS 22  counter is logically true, LV 54  warning or report is triggered. Step  17  ( 434 ) illustrates that if any item of the passback list is logically true, passback report is generated. Step  18  ( 436 ) illustrate that if there are two doors opening simultaneously (for example, DR 201  and DR 301 ), a warning represented by LV 51  parameter, for example, two-door abnormally opened warning, may be generated. 
         [0035]      FIG. 5  illustrates examples of the icons that may be used to implement rules logic in the ladder diagram of the present application. The icon  502  represents a logical variable associated with a card holder group. The values may be one or many. The icon  504  represents a logical variable with respect to a cardholder. For instance, if an input card is consistent with the stored identification is otherwise valid, this icon is assigned a valued of that cardholder. This passback icon  506  may hold passback list which contains information as to whether a card is swiped again in the same reader, different reader, within what period of time, etc. Logical variable icon  510  represents Alarm, and logical variable icon  512  represents Alarm Reset ( 512  is a logical of  510 ). DRn Logical variable icon shown at  518  represents general logic for opened door. Icon at  519  represents general logic for closed door. Logical variable icon  520  represents a general logical flag when set (1) and the icon  521  represents a general logical flag when reset (0). TRUEn icon shown at  522  represents logical constant “1” and FALSFn icon shown at  524  represents logical constant “0”. TZn icon  528  represents time zone. A parameter associated with this icon is set to true if a card is swiped during the time specified in the TZ icon. RDn icon shown at  526  represents a card reader. A parameter associated with this icon is set to true if there occurs a card swipe in a specified card reader. The swiped card number may be stored temporarily for further comparison. TWn icon  530  represents window timer. If the time, once triggered, does not stop until the time expires, it provides logical true. CNTn icon shown at  508  represents a counter. A counter value associated with this icon is decremented at the occurrence of specified events and when the value reaches zero, a logical value associated with this icon is set to true. DRS icon  514  represents duress. If under duress, logical value associated with this icon is set to true. This icon may also store or be associated with information related to the cardholder that is under duress. FLPn icon  516  represents reverting or flipping a register. PR icon  532  represents single-pulse logical variable. RST icon  534  represents reset logic. When triggered, one or more variables associated with this icon are reset. FLP is a logic variable, which can reserve its former state. It is often used to implement enabling one or more readers. A person of ordinary skill in the art will appreciate that additional or different set of icons may be used to implement the method and system of the present disclosure. 
         [0036]      FIG. 6  is a flow diagram illustrating an operation in one embodiment of a rules engine proxy. At  602 , the rules engine proxy initializes the data tables, for example, “expression table”, “parameter table”, “function table”, etc, and performs self-checking. At  604 , after initialization, the rules engine proxy goes into a loop and waits for events to occur. Examples of event may be a card swipe, door opening, timeout, etc. At  606 , if the engine detects that any events has happened, it fetches the event and parses it at  608 . At  610 , the rules engine searches for one or more functions and parameters associated with the event. The rules engine compiles one or more functions and parameters and compiles them. The rules engine then executes the compiled expression line by line and takes one or more actions accordingly. The processing returns to wait state at  604 , when this processing completes. 
         [0037]      FIG. 7  illustrates examples of components used in the rules engine in its operation. Template Operation  702  illustrates execution procedures or functionalities of the rules engine in one embodiment of the present disclosure. The rules engine, for example, initializes data tables and performs “template scanning” which may comprise sub-procedures such as “template self-checking”, “input fresh”, and “output fresh”. “Template self-checking” may check the data store in rule engine. “Input fresh” gets input data such as card swipe information, timer expired information, etc. “Output fresh” outputs data to send commands such as open door, send alarm, etc. Rules engine may store “expression language” data table  704 , which includes expression forms of graphic diagrams on the user interface. It describes the relationships of graphic diagram. Data table  706  is a variable table, which includes all information (variable type, index of function library, etc.) associated with each variable in the list. Data table  708  is a parameter link table. It stores different data for different variables, for example, card number, reader number, etc. 
         [0038]    In one embodiment, the expression language table  704  is parsed line by line. Variable table  706  is searched by vector index (V 01 , V 02 , etc.) of each node in the line expression. From the variable table  706 , the index of the function associated with the variable being considered is identified from the function. One or more parameter associated with the variable being considered is also identified using the parameter link table  708 . The identified function and parameters are then passed to the function library, which executes the identified function with the parameters. 
         [0039]    While the above description provided an example use of the access control system of the present disclosure in relation to vault door operation for example of a bank and using identification cards swiped at a reader device, the access control system may be used in any other applications, for example, to secure building, areas, data, etc. Further, the identifying devices need not be limited to cardkeys, rather may include any known or will be known methodologies including but not limited to smart cards, computer chips, biometrics, etc. 
         [0040]    The system and method of the present disclosure may be implemented and run on a general-purpose computer, a processor, and/or hardware circuitry. The computer system may be any type of known or will be known systems and may typically include a processor, memory device, a storage device, input/output devices, internal buses, and/or a communications interface for communicating with other computer systems in conjunction with communication hardware and software, etc. 
         [0041]    The embodiments described above are illustrative examples and it should not be construed that the present invention is limited to these particular embodiments. Thus, various changes and modifications may be effected by one skilled in the art without departing from the spirit or scope of the invention as defined in the appended claims.