Access control system

Abstract

The invention name of the present disclosure is "Access control system". An access control system for controlling access to at least one secure area is provided. The access control system comprises: a credential (8) associated with a user and used to identify the user to the access control system; an administrator-level permission (12) that has been set by an administrator and used to determine whether the user is an authorized person in order to control access to the at least one secure area; and a user-level permission (10) that has been set by the user and used to determine whether access to the at least one secure area is in line with the user's preferences. The access control system is arranged to grant access to the at least one secure area when it is presented with a credential (8) that both identifies the user as an authorized person for that secure area and also confirms that the user's access is in line with the user's preferences.

Description

Technical Field

[0001] This invention relates to access control systems and related methods for controlling access to secure areas. For example, the access control system can be used as part of a building's security system. Background Technology

[0002] It is known that access to or within a building is controlled in various situations, such as to ensure that only authorized persons can access the building or parts thereof. Access routes, such as doors, can be controlled by access control systems and can be opened by presenting credentials (such as badges, QR (Quick Response) codes, mobile devices, etc.). Such credentials typically include tokens embodied in a physical object (e.g., an access card) and / or may include tokens in electronic form associated with a physical object (e.g., a mobile device with suitable software). Credentials may also, or alternatively, include biometric identification of the user. It may be required to combine multiple identification methods (such as two or more of physical tokens, PIN input, and / or biometric identification) to confirm that the user is authorized. This enhances security, for example, by avoiding the risk of unauthorized users gaining access via lost or stolen physical tokens.

[0003] Various examples of access control systems can be found in existing technologies (such as within WO 2018 / 160560), which is an example of a physical access control system that uses physical tokens to control access to areas of a building. Another known access control system is BlueDiamond. TM Sales. Another known access control system is described in US 2020 / 312070, which includes details of the specific handling of access protocols. In a typical access control system, a user presents their credentials to an access control point (such as a card reader or other sensor), and the access control system determines whether the user is authorized to pass through that access control point based on permissions set by an administrator. For example, in the case of a door, if permissions set by the administrator indicate that the user is authorized to enter the area through the door, then the access control system can enable door opening.

[0004] For existing technology systems, access rights can be defined on a static or dynamic basis. For example, static policies can act to allow fixed user groups or categories of users access to each secure area, where these users are granted access whenever they request it, which can be done by presenting their credentials to the access control system (e.g., via a card reader). Dynamic policies are those that react to changing characteristics of a building or its occupants. For example, an existing technology system might block access to an area once it has reached its set maximum capacity. In this case, while a user might be authorized to enter an area, they might still be denied entry if that area has reached its maximum capacity. Like static policies, these dynamic policies rely on permissions set by administrators, ensuring that users can only access secure areas if they have satisfied one or more policies set by the administrator. Administrator-level permissions and policies can be determined, for example, by the building owner or the user's employer. Summary of the Invention

[0005] From a first aspect, the present invention provides an access control system for controlling access to at least one secure area, the access control system comprising: credentials associated with a user and used to identify the user to the access control system; administrator-level permissions set by an administrator and used to determine whether the user is an authorized person in order to control access to the at least one secure area; and user-level permissions set by the user and used to determine whether access to the at least one secure area conforms to the user's preferences; wherein the access control system is configured to grant access to the at least one secure area when credentials are presented to it, the credentials both identifying the user as an authorized person of the secure area and confirming that the user's access conforms to the user's preferences.

[0006] Therefore, with this arrangement, access is denied only when the user is authorized, and even then, access must conform to the user's preferences. In practice, the invention may require a set of "must have" and "must satisfy" criteria, whereby the user must have the access permissions granted by the administrator to the secure area, and where the secure area must meet the user's expectations. This allows the administrator to set permissions to control access to and optionally exit from secure areas, which can be one of multiple secure areas; however, if the user's access does not conform to their preferences, these preferences can override and prevent access (even when authorized by administrator-level permissions). As discussed further below, user preferences may include characteristics of secure areas that the user deems acceptable (e.g., secure or insecure), such as the maximum number or density of other occupants. In known access systems, access control is based solely on administrator-level permissions, and there are no additional permission levels that consider user preferences beyond administrator-level permissions. By extending access control decisions to include both user preferences and administrator-level permissions, this access control system offers advantages over those known systems.

[0007] Advantageously, users can define the circumstances under which they would prefer to be prevented from accessing a secure area. Optionally, users can also define the circumstances under which they wish to be notified of the characteristics of a secure area before entering it, via means such as audible alarms or visual messages. Thus, the access control system can include: user-level permissions (based on user preferences) and user-level notification criteria (also based on user preferences), which, if not satisfied, will prevent access, and if not satisfied, will trigger a notification. For example, if the temperature is outside a certain range, a user might not want to enter a secure area, while if the temperature is within that range but outside a narrower threshold range in which the user wants to be notified before entering the secure area, the user might consider entering the secure area acceptable.

[0008] A secure area may include a region of a building, such as the interior of the building or a portion thereof (e.g., a room or a group of rooms). An access control system can control access to multiple secure areas, wherein different administrator-level permissions and user-level preferences may be optionally applied to each of the multiple secure areas. The access control system may control doors or other access routes to control access to the secure area.

[0009] The access control system proposed in this paper includes additional levels of control over access to one or more security zones (or areas thereof) with direct user input. Therefore, users can set user-level permissions without the need for administrator-level intervention. The ability of users to directly set their own permissions based on their preferences is not a feature of previous systems, where only administrator permissions were used within access control. This access control system may have an administrator input module accessible only to a set of operators with administrator-level access rights to the system, and a user input module accessible only to users.

[0010] The input module can be implemented via suitable software and / or hardware. The administrator input module may be intended for administrator control in a manner similar to existing access control systems. For example, the administrator input module may be part of a security system operated by a building owner or employer and may be configured for overall control of access to one or more security zones. Specifically, a user may not be permitted any access to one or more security zones unless identified as an authorized user through administrator-level permissions set via the administrator input module. The user may not have access to the administrator input module and / or may not be authorized to change administrator-level permissions. The access control system may include hardware, such as hardware including a computer system, to enable authorized persons acting at the administrator level to use the administrator input module to set administrator-level permissions, whereby authorized persons access the input module via a computer terminal or mobile device.

[0011] In the example embodiment, the administrator input module may have the ability to define parameters that a user can adjust using the user input module; however, advantageously, the administrator input module does not have the ability to change user-level permissions. Instead, in the example embodiment, user-level permissions can only be changed by the user through actions performed via the user input module. Therefore, the proposed access control system has two separate sets of permissions, each requiring the fulfillment of one set of permissions in order to enter the secure area. One set of permissions is set by the administrator (e.g., via an authorized person as described above), and the other set is set by the user.

[0012] In some cases, administrators and users may have the authority to change user-level permissions via a user input module. This allows for greater flexibility. Alternatively, to ensure the separation of changes made to users from changes made to administrators, the user input module, as mentioned above, may only be accessible to users. In such cases, administrators may alternatively have the ability to set permissions for each user based on similar dynamic policies via an administrator input module.

[0013] Advantageously, each user is only authorized to modify their own user-level permissions, preventing them from altering these permissions for other users. Advantageously, the user input module does not allow users to change administrator-level permissions, but allows users to adjust user-level permissions according to their preferences. Therefore, the user (and in the example embodiment, not the administrator) has control over certain preferences (such as those discussed below). The access control system may include hardware for enabling users to set user-level permissions via the user input module, such as hardware comprising a computer system, wherein the user accesses the input module via a computer terminal or mobile device. In some examples, the user input module may be accessible via a reader or terminal of the access control system, and / or via a user device, which may be a device known and trusted by the user. For example, the user input module may be accessible and / or may include the user's mobile device (e.g., a smartphone). In some cases, as described below, the user's mobile device may also be used to present the user's credentials to the access control system.

[0014] User preferences may consider the characteristics of the secure area and / or the characteristics of the system / environment within the secure area. User preferences may also consider the time of day and / or external factors such as weather. Historical information may also be considered, such as time spent in secure areas or other areas during previous time periods and / or the number of visits during previous time periods. In the example implementation, user preferences may define characteristics that a user considers acceptable or unacceptable in terms of being granted access to one or more secure areas(s). Assessing what is acceptable may consider security, health, performance goals, etc. Based on user preferences, the user input module enables the user to determine user-level permissions, which are then combined with administrator-level permissions to assess user-level permissions to determine whether access is permitted, such as whether a door should be opened. Similar to administrator-level permissions discussed below, user-level permissions may also include static and / or dynamic policies.

[0015] It will be recognized that access control for secure areas taking the form of spaces within a building can be used for passageways along one or the other (e.g., entry or exit) or along both directions. For this reason, it will be appreciated that the discussion herein applies to transits from one location to another via controlled access, where the access control system considers both relevant administrator-level permissions and relevant user-level permissions regarding the area the user will move into. Therefore, it may be necessary to determine whether, after entering a first location, the user should be granted permission to exit from the first location and move to a second location. In this context, the first and / or second location can be secure areas, as discussed elsewhere herein, but it is not necessary for both locations to be secure areas. Using an access control system to determine whether permission to exit a location is granted may be applicable even if the user intends to return to the location from which they originated, as changes to the characteristics of that location may affect permissions. For example, if user preferences specify temperature or occupancy requirements, returning to the previous area after such changes may not conform to the user's preferences.

[0016] Access control systems may consider user-level permissions (in accordance with user preferences) for exiting and entering secure areas, and optionally consider user-level notification criteria (if applicable). This may be done even if areas outside the secure area are not otherwise restricted or controlled by administrator-level permissions, such as if they are public areas freely accessible to all, or if they are entirely outside the control system's scope (such as outdoor spaces). In some examples, user preferences include characteristics of such areas that are considered unsafe or unsuitable for users or that require notification (e.g., to remind them to change clothing or other precautions). In the case of outdoor locations, this might include temperature, UV index, air pollution levels, data from early warning systems for weather anomalies and hazards (or natural disasters, such as earthquakes or tsunamis), etc.

[0017] Information about user preferences and / or user-level permissions can be stored on any device, such as on a smart card, a mobile device (e.g., a user's smartphone), or a system database.

[0018] The characteristics of the security zone considered for user preferences may include one or more of the following: - For threshold environmental parameters that must be met to enter a safe area, such as temperature, cleanliness (e.g., time since self-cleaning or meeting specific quality requirements of a disinfection process), door or window status (e.g., requiring complete closure or requiring at least one opening to allow outside air in), air circulation level, or noise level, one or more of these parameters. - Evaluation of device operation within a safe area, for example, to prevent malfunctions of devices that users deem dangerous.

[0019] - The security status of the secure area, such as whether potential security vulnerabilities (e.g., intrusion) have been detected, to allow users to ensure they avoid accidental contact with thieves.

[0020] - Air quality detection by a smoke detector or any other suitable sensor, for example to avoid values ​​that are unacceptable and / or considered unsafe based on user preferences (e.g., allergies, suspected fire, sensitivities to odors, etc.).

[0021] - The number or density of other people in the safe area, such as to avoid the area from having too many occupants or occupants exceeding the threshold of a given floor area.

[0022] - The presence or absence of specific other users or other categories of users, such as entering certain areas only when other people are present, or avoiding direct contact with other people or specific individuals (such as those who may exhibit risks related to infectious diseases).

[0023] - Access the control system for known current and historical alarms / events, such as events caused by device operation and / or human activity.

[0024] - Data from external systems (such as cloud services, fire protection systems, intelligent building systems, etc.).

[0025] In each case, the above may vary depending on the day and / or time of day, and potentially on external input regarding the safe zone. For example, in cases such as the COVID-19 pandemic, user-level permissions could include dynamic policies that change based on government risk assessments.

[0026] Administrator-level permissions can be set based on considerations similar to those of known access control systems. Administrator-level permissions can be based on administrator policies that determine whether user access to a secure area is permitted. These administrator policies can include static administrator policies that instruct which of several users are authorized to access the secure area, where unauthorized users are not permitted access. Administrator policies can also, or alternatively, include dynamic administrator policies, through which administrators can set permissions based on dynamic events. For example, if a security vulnerability exists, certain users may be blocked from accessing the secure area; and / or if the area has reached its maximum capacity, users may be blocked from accessing the secure area. Another possible dynamic policy is to make administrator-level permissions allow user access only when predetermined personnel are present or absent. For example, administrator-level permissions might restrict access to subordinates unless a supervisor is present.

[0027] Administrator-level permissions can be based on dynamic administrator policies equivalent to those set via user-level permissions, such as those relating to characteristics of the security area discussed below (e.g., environmental parameters, device operation, security, air quality, people, specific other users, etc.). Therefore, it is possible for administrators to control access for any given user based on considerations similar to user preferences, and in parallel, users cannot change / set administrator-level permissions, and administrators cannot change / set user-level permissions. In this way, three levels of access control can exist, including: "must-have" requirements as defined by static policies at the administrator level regarding basic authorization to enter an area; "must-meet" requirements set by the administrator regarding variable characteristics of the security area (e.g., temperature, occupancy, etc.); and "must-meet" requirements set by users, also relating to variable characteristics of the security area.

[0028] The access control system uses credentials associated with a user to identify the user, and then determines access to one or more secure areas based on administrator-level permissions and user-level permissions. Access to one or more secure areas can be granted by opening and / or unlocking access routes such as doors. Credentials can be in physical and / or electronic form and can be presentable by one or more hardware or software elements. Credentials may include tokens embodied in the form of physical objects (e.g., access cards), and / or may include tokens in electronic form associated with physical objects (e.g., mobile devices with suitable software). Credentials may also, or alternatively, include the user's biometric identification. It may be required to combine multiple identification methods (such as two or more of physical tokens, PIN input, and / or biometric identification) to confirm that the user is an authorized person. This improves security, for example, by avoiding the risk of unauthorized users gaining access via lost or stolen physical tokens. In example embodiments, credentials may take the form of one or more of cards (including smart cards), badges, QR (Quick Response) codes, mobile devices, electronic tags (such as RFID tags), etc.

[0029] Access control systems may include terminals for detecting credentials and for interacting with the computer network of the access control system. For example, an access control system may include a card reader, a wireless terminal for interacting with a mobile device, and / or other sensors for detecting credentials.

[0030] The access control system may differ from existing access control systems only in the software used, and therefore may not require any hardware modifications. Advantageously, this enables the retrofitting / upgrading of existing systems without installing new hardware. Access control systems (such as those that allow users to set user-level permissions via their mobile devices) can be easily integrated with mobile solutions. It can also be easily integrated with systems such as BlueDiamond. TM Integration with pre-existing access control systems.

[0031] Dynamic policies for setting user-level permissions can be set based on individual contract terms, which define a set of relationships between the characteristics of a security zone (such as system or environment parameters / state) and the individual user's personal expectations.

[0032] User-level permissions (e.g., those set based on individual contract terms) may have a lower priority than administrator-level permissions, but advantageously, if enabled, they are required to be included. As mentioned above, an access control system may make access decisions based on permissions granted by the administrator as "must-have" requirements, and then include user-level permissions as "must-fulfill" requirements (e.g., those set based on individual contract terms). Optionally, as discussed above, additional "must-fulfill" requirements may exist at the administrator level.

[0033] Optionally, administrators may enable / disable user-level permissions, for example, for specific users or in specific situations (such as in an emergency). User-level permissions that a user can access to change (e.g., via a user-level input module) may include all relevant characteristics of the security area (e.g., as set based on all possible individual contractual terms), or may include a subset of those characteristics, wherein the subset may be determined by the administrator.

[0034] From a second aspect, the present invention provides a method for controlling access to a secure area, the method comprising using an access control system of the first aspect. The method may include any of the other features discussed above. The method may include: the access control system detecting credentials associated with a user and using the credentials to identify the user; determining whether the user is an authorized person based on administrator-level permissions already set by an administrator; and determining whether access to the at least one secure area conforms to user preferences based on user-level permissions already set by the user; wherein, when the credentials both identify the user as an authorized person for the secure area and confirm that the user's access conforms to user preferences, the access control system permits the user to access the secure area.

[0035] The method may include, prior to the steps of the first aspect, receiving administrator-level permissions via an administrator input module and receiving user-level permissions via a user input module, for example as discussed above.

[0036] This method may include administrators setting permissions to control access to a secure area (which may be one of multiple secure areas), and may include users setting user-level permissions that override administrator-level permissions and block access if a user's access does not conform to their preferences (even when authorized by administrator-level permissions). The method may include preventing administrator access from changing user-level permissions, and preventing user access from changing administrator-level permissions.

[0037] As further discussed above, user preferences may include any of the various characteristics of a secure area. This approach may include: users defining situations in which they would prefer to be prevented from accessing a secure area; and / or the access control system receiving appropriate input from the user via an input module to define such situations. Optionally, the access control system may also receive input from the user to define user-level notification criteria, as discussed elsewhere in this document.

[0038] A secure area may include an area of ​​a building, such as the interior of the building or a portion thereof (e.g., a room or a group of rooms). The method may include controlling access to multiple secure areas, wherein different administrator-level permissions and / or user-level preferences may be optionally applied to each of the multiple secure areas. The method may include controlling doors or other access routes to control access to the secure areas. The method may further include controlling exit from (or from) the secure area(s), which may be accomplished based on administrator-level permissions, user-level permissions, and / or user-level notification criteria as discussed above.

[0039] This method may include allowing users to set user-level permissions without administrator-level involvement. The method may use an access control system having an administrator input module accessible only to a set of operators with administrator-level access rights to the system, and a user input module accessible only to users. The method may include using the administrator input module to receive input for administrator control of administrator-level permissions. This can be accomplished in a manner similar to prior art access control methods. Advantageously, the administrator input module does not have the ability to change user-level permissions. Instead, in an example embodiment, the method includes allowing user-level permissions to be changed only by the user through actions performed via the user input module. Therefore, the proposed access control method uses two separate sets of permissions, requiring the satisfaction of each set of permissions to enter a secure area, one set set by an administrator (e.g., via an authorized person as described above), and the other set set by the user.

[0040] In some examples, the method includes the user accessing a user input module via a reader or terminal of the access control system and / or via a user device, which can be a device known and trusted by the user, such as the user's mobile device, as discussed above. To account for the separate technical features of changes made to users and changes made by administrators, the administrator may alternatively have the ability to set permissions for each user based on similar dynamic policies via an administrator input module.

[0041] User preferences may take into account the characteristics of the secure zone and / or the characteristics of the system / environment within the secure zone, such as those discussed above. User preferences may also take into account the time of day and / or external factors, such as the weather. Historical information may also be considered, such as the time spent in the secure zone or other zones in previous time periods and / or the number of visits in previous time periods.

[0042] This method may include storing information about user preferences and / or user-level permissions. Such information can be stored on any device, such as a smart card, a mobile device (e.g., a user's smartphone), a system database, etc.

[0043] This method may include administrator-level permissions based on static policies indicating which of a plurality of users are authorized to access a secure area, where unauthorized access is denied. These policies may also, or alternatively, include dynamic policies, allowing administrators to set permissions based on dynamic events. The method may also include user-level permissions set based on dynamic policies and, optionally, user-level notification criteria also set based on dynamic policies. Therefore, this method may have multiple levels of control: assessment of administrator-level permissions related to access authorization (in any case, i.e., static policies); administrator-level permissions related to access status (context-dependent, i.e., dynamic policies as discussed above); user-level permissions related to user preferences (context-dependent, i.e., dynamic policies or individual contractual terms as discussed above); and, optionally, user-level notification criteria that allow access but issue a warning notification (context-dependent, as discussed above). The method may further include additional controls for exiting a secure area, as discussed above, even when the destination location itself is not a secure area or otherwise not controlled by an access control system, such as a public space or a generally accessible outdoor location.

[0044] This access control method uses user-associated credentials to identify the user, and then determines access to one or more secure zones based on administrator-level permissions and user-level permissions. As discussed above, access to one or more secure zones can be granted by opening and / or unlocking access routes (such as doors). Credentials can be in physical and / or electronic form and can be represented by one or more hardware or software components. Credentials can be as discussed above. Administrator-level permissions can be based on dynamic administrator policies, such as those relating to the characteristics of the secure zones discussed above, which are equivalent to dynamic policies set via user-level permissions.

[0045] In this manner, the method may include the use of three levels of access control, including: a "must-have" requirement, as defined by a static policy at the administrator level, for requiring basic authorization to enter a zone; a "must-meet" requirement related to administrator settings concerning variable characteristics of the security zone (e.g., temperature, occupancy, etc.); and a "must-meet" requirement related to user settings, also concerning variable characteristics of the security zone.

[0046] The access control method may include using a terminal to detect credentials and to interact with the computer network of the access control system. For example, the access control method may include using a card reader, a wireless terminal for interacting with a mobile device, and / or other sensors for detecting credentials.

[0047] From a third perspective, the present invention provides a computer program product including instructions that, when executed, configure an access control system to operate according to the method of the second aspect. Attached Figure Description

[0048] Some exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings, which are shown by way of example only. Figure 1 An access control system incorporating additional user-level permissions is shown. Detailed Implementation

[0049] In a typical access control system (such as the access control system according to WO 2018 / 160560), the administrator sets permissions, which determine whether a user can access a secure area (such as a room in a building). Users present credentials to the access control system, for example, by presenting a card, badge, or mobile device to a reader or other terminal, and the credentials are used to identify the user. Access decisions are made based on the permissions controlled by the administrator of the access control system. If the user is authorized to access the secure area, access is granted (e.g., by opening or unlocking a door or other access route).

[0050] Using the proposed access control system, such as Figure 1 As shown, there are multiple levels of permissions. Specifically, the access control system includes user-level permissions 10 and administrator-level permissions 12. These permissions 10 and 12 may include dynamic or static policies as outlined above, and they may include overlapping areas as shown. The access control system makes an access decision 14 based on both user-level permissions 10 and administrator-level permissions 12. If both user-level permissions 10 and administrator-level permissions 12 are satisfied, access is granted 18 (such as by opening or unlocking a door to a secure area or other access routes). If neither user-level permission 10 nor administrator-level permission 12 is satisfied, access is denied 16.

[0051] The access control system detects credentials 8 associated with the user and uses credentials 8 to identify the user (such as via a terminal (not shown) or any other suitable hardware and / or software as discussed above). The access control system is configured to: determine whether the user is an authorized person based on administrator-level permissions 12 already set by the administrator; and also determine whether access to the at least one secure area conforms to the user's preferences based on user-level permissions 10 already set by the user.

[0052] The access control system considers setting and / or updating administrator-level permissions 12 (e.g., as discussed above) via administrator input module 22 and considers setting and / or updating user-level permissions 10 via user input module 20.

[0053] The administrator input module 22 has the ability to define parameters that users can adjust using the user input module 20, but the administrator input module 22 does not have the ability to change user-level permissions 10. In this embodiment, user-level permissions 10 can only be changed by the user through actions performed via the user input module 20. Therefore, the proposed access control system has two separate sets of permissions. To enter the secure area, each set of permissions must be satisfied, with one set controlled only by an administrator (e.g., via an authorized person as described above) and the other set controlled only by the user.

[0054] Users adjust user-level permissions 10 according to their preferences via user input module 20. User preferences take into account the characteristics of the security zone and / or the characteristics of the system / environment within the security zone. User preferences may also take into account the time of day and / or external factors, such as weather or other environmental parameters. Historical information may also be considered, such as time spent in the security zone or other zones in previous time periods and / or the number of visits in previous time periods.

[0055] User preferences can also be used to determine user-level notification criteria, which can be considered concurrently with user-level permissions. The user preferences used for user-level notification criteria can be from the same set of user preferences used for user-level permissions, or they can be from a different set. User-level notification criteria can specify situations / features in which a user considers being permitted entry into a secure area (or other location, such as exiting a secure area) acceptable but desires to be notified before entry.

[0056] User input module 20 can receive data in the form of internal data 30 (such as data from security systems) and / or external data 31 (such as data from other systems inside and / or outside the security area, such as inside and / or outside the building or building rooms). Thus, for example, there may be input data from one or more of fire protection systems, intrusion systems, intelligent building systems, and / or cloud services, such as data from early warning systems for weather anomalies and hazards. This data can provide parameters that enable the input module to construct a suitable set of user-level permissions and user-level notification criteria. Therefore, input module 20 can use internal and / or external data to determine which preferences (such as those via individual contractual terms) can be considered and thus determine what parameters to provide to the user when setting user-level permissions and user-level notification criteria. Therefore, the access control system should have the authority to read the values ​​of the relevant parameters, which can be done by the access control system (e.g., via its controller or processor) or more specifically by the user input module.

[0057] The user input module can be separate from other parts of the access control system. For example, it could be a standalone application on the user's mobile device, which may not be accessible to administrators but can be configured to communicate with the access control system via a secure and authorized connection. Therefore, in this case, user-level permissions (and optional user-level notification criteria) can be evaluated via the user input module on user device 20. In this scenario, the access system will "ask" user device 20 about user-level permissions (i.e., whether they have been satisfied), and may include a response from user device 20 during the access decision 14. User device 20 can also be used for audible and / or visual notifications related to situations where a user has requested notification before entering an area, as discussed elsewhere herein.

[0058] The hardware and software implementation of the access control system can incorporate features similar to those of existing systems, such as secure handling of unlocking access gates and / or credentials. For example, known systems in WO 2018 / 160560 and / or US 2020 / 312070 can be modified to incorporate the new features described herein.

[0059] The characteristics of the security zone considered for user preferences may include one or more of the following: - For threshold environmental parameters that must be met to enter a safe area, such as temperature, cleanliness (e.g., time since self-cleaning or meeting specific quality requirements of a disinfection process), door or window status (e.g., requiring complete closure or requiring at least one opening to allow outside air in), air circulation level, or noise level, one or more of these parameters. - Evaluation of device operation within a safe area, for example, to prevent malfunctions of devices that users deem dangerous.

[0060] - The security status of the secure area, such as whether potential security vulnerabilities (e.g., intrusion) have been detected, to allow users to ensure they avoid accidental contact with thieves.

[0061] - Air quality detection by a smoke detector or any other suitable sensor, for example to avoid values ​​that are unacceptable and / or considered unsafe based on user preferences (e.g., allergies, suspected fire, sensitivities to odors, etc.).

[0062] - The number or density of other people in the safe area, such as to avoid the area from having too many occupants or occupants exceeding the threshold of a given floor area.

[0063] - The presence or absence of specific other users or other categories of users, such as entering certain areas only when other people are present, or avoiding direct contact with other people or specific individuals (such as those who may exhibit risks related to infectious diseases).

[0064] - Access the control system for known current and historical alarms / events, such as events caused by device operation and / or human activity.

[0065] - Data from external systems (such as cloud services, fire protection systems, intelligent building systems, etc.).

[0066] In each case, the above may vary depending on the day and / or time of day, and potentially on external input regarding the safe zone. For example, in situations such as the COVID-19 pandemic, user preferences and associated user-level permissions may vary due to regulations imposed locally by national or local governments. Therefore, if a “lockdown” is declared or other levels of restrictions on citizens are increased, a more stringent set of user preferences may be activated. Similarly, administrator-controlled dynamic policies may be adjusted, such as limiting maximum room occupancy for all users.

[0067] Based on known access control systems (such as WO 2018 / 160560 and / or such as BlueDiamond) TMSimilar considerations to those used in access control systems within the system are applied to setting administrator-level permissions. Administrator-level permissions can be based on policies that determine whether a user is permitted access to a secure area. These policies can include static policies that indicate which of several users are authorized to access the secure area, while disallowing unauthorized users. These policies can also, or alternatively, include dynamic policies, allowing administrators to set permissions based on dynamic events. Administrator policies may overlap with user preferences, but as mentioned above, their control is separate.

[0068] As a specific example: Users U1 and U2 have access to area A1 (through administrator-level permissions granted by the administrator).

[0069] User U1 has their own user-level permissions (e.g., personal contract terms), which they have set for themselves (and advantageously, the administrator cannot change these user-level permissions). In this example, user U1 expects the temperature in area A1 to be <30 degrees Celsius and does not wish to enter areas with temperatures exceeding that.

[0070] User U2 has their own user-level permissions (e.g., personal contract terms), which they have set for themselves (and advantageously, the administrator cannot change these user-level permissions). In this example, user U1 expects the temperature in area A1 to be >20 degrees Celsius and wants to be warned if this condition is not met; that is, allowed entry, but a "warning" sound will notify the user.

[0071] In the first example case, the current temperature in region A1 is 18 degrees.

[0072] When user U1 presents their credentials (e.g., swipes their badge / card) to enter area A1, access will be granted (e.g., the door will open / unlock) because user U1 has administrator-level permissions and meets user-level permissions (e.g., personal contract terms).

[0073] When user U2 presents their credentials (e.g., swiping their badge / card) to enter area A1, they present their credentials (e.g., swiping their badge / card), but the card reader will play a "warning" sound notification.

[0074] In the second example case, the current temperature in region A1 is 32 degrees.

[0075] When user U1 presents their credentials to enter area A1, access is denied because although user U1 has permissions granted by the administrator, the user-level permissions are not met.

[0076] When user U2 presents their credentials to enter area A1, access is granted without any warning sound, because user A2 has the permissions granted by the administrator and meets the requirements of user-level permissions.

[0077] If an administrator removes user U1 or U2's permissions for area A1, they will not be able to enter the area even if the temperature meets their expectations. The action might differ if users change their expectations and therefore modify user-level permissions via the user-level input module. User-level permissions may include alternative or additional criteria, such as those discussed above regarding possible dynamic policies and the characteristics of security zones.

Claims

1. An access control system for controlling access to at least one secure area, the access control system comprising: Credentials, which are associated with a user and used to identify the user to the access control system; Administrator-level permissions, which have been set by an administrator and are used to determine whether the user is an authorized person in order to control access to the at least one security zone; as well as User-level permissions, which have been set by the user and are used to determine whether accessing the at least one secure area is in line with the user's preferences; The access control system is configured to grant access to the at least one security zone when presented with credentials that both identify the user as an authorized person of the security zone and confirm that the user's access conforms to the user's preferences.

2. The access control system as described in claim 1, wherein, The secure area includes a section of a building; and wherein the access control system controls doors or other access routes to control access to or exit from the secure area.

3. The access control system as described in claim 1 or 2, comprising an administrator input module accessible only to a group of operators with administrator-level access rights to the system, and a user input module accessible only to the user.

4. The access control system as described in claim 3, wherein, The administrator input module is part of a security system configured for overall control of access to the security zone; and wherein, unless the user is identified as an authorized user through the administrator-level permissions set via the administrator input module, the user is not permitted any access to the security zone.

5. The access control system as described in claim 3, wherein, The user does not have permission to access the administrator input module, and / or the user is not authorized to change the administrator-level permissions.

6. The access control system as described in claim 3, wherein, The administrator input module is configured to define parameters that the user can adjust using the user input module; and wherein the administrator input module does not have the ability to change the user's level permissions.

7. The access control system as described in claim 3, wherein, The user-level permissions can only be changed by the user through actions performed via the user input module.

8. The access control system as described in claim 3, wherein, The user input module does not allow the user to change the administrator-level permissions. Furthermore, the user input module enables the user to adjust the user-level permissions according to user preferences.

9. The access control system as described in claim 1 or 2, wherein, The user preference takes into account the characteristics of the security zone and / or the characteristics of the system / environment within the security zone; and / or wherein the user preference defines the characteristics that the user considers acceptable or unacceptable in terms of granting access to the security zone based on the security.

10. The access control system of claim 1 or 2, further comprising user-level notification criteria, said user-level notification criteria having been set by the user and used to determine whether the user should receive notification of details relating to the user's preferences before accessing the secure area.

11. The access control system as claimed in claim 1 or 2, wherein, The access control system also controls exit from the at least one secure zone, wherein the access control system is configured to allow exit from the at least one secure zone when presented with credentials that both identify the user as an authorized person for leaving the secure zone and confirm that the user's exit is in accordance with the user's preferences.

12. The access control system as claimed in claim 1 or 2, wherein, The user preferences relating to user-level permissions and / or user-level notification guidelines involve one or more of the following: - Threshold environmental parameters that must be met for entry into the safe area include one or more of the following: temperature, cleanliness, door or window status, air circulation level, noise level, or any other measured environmental parameter or signal; - Evaluation of device operation within the safety zone to prevent malfunctions of devices deemed dangerous by the user; - The security status of the security zone; - Air quality detection by a smoke detector or any other suitable sensor; - The number or density of other people within the security area; and / or - The presence or absence of specific other users or users of other categories; - Current and historical alarms / events known to the access control system, such as events caused by the operation of the device and / or events caused by human activity; - Access the historical, current, or predicted status of the control system or area; - Signals or data from external systems or cloud services.

13. The access control system as described in claim 1 or 2, wherein, The administrator-level permissions are based on a policy for determining whether to allow the user to access the security zone; Furthermore, these strategies include both static and dynamic strategies.

14. A method for controlling access to a secure area, the method comprising using an access control system as described in any of the preceding claims, and optionally comprising: The access control system detects credentials associated with a user and uses those credentials to identify the user; Determine whether the user is an authorized person based on the administrator-level permissions already set by the administrator; And based on the user-level permissions already set by the user, determine whether access to at least one security area conforms to the user's preferences; wherein, when the credentials both identify the user as an authorized person of the security area and confirm that the user's access conforms to the user's preferences, the access control system grants the user access to the security area.

15. A computer program product comprising instructions that, when executed, configure an access control system to operate according to the method of claim 14.

Images