Context-related AUTHORIZATION FOR PHYSICAL ACCESS CONTROL

Abstract

In one example, a procedure for context-related credential access for a physical access control involves receiving an access request, which includes one or more credentials and context information indicating one or more activities to be performed by a user of the computing device, by an access control device associated with a locking device for a controlled area, and determining whether the context information satisfies one or more context conditions, by the access control device.The procedure may further include determining whether one or more access credentials are valid, by the access control device, and in response to determining that one or more access credentials are valid, and in response to determining that the context information satisfies one or more context conditions, changing a state of the locking device by the access control device.

Description

BACKGROUND

[0001] Access control readers can control access to physical areas by granting or denying entry. They can grant access by unlocking doors or other openings upon receiving valid access credentials from digital key devices, such as mobile and wearable devices. If the access credentials are invalid, access control readers can deny access by not unlocking a locked door or other opening. Digital key devices and access control readers can communicate access credentials using various wireless communication protocols. SUMMARY

[0002] In general, the techniques described in this disclosure are geared toward the use of contextual access credentials for physical access control. In some examples, digital key devices (such as mobile or wearable devices) can provide contextualized access credentials to an access control device (such as an access control reader). For example, a digital key device can transmit access credentials along with contextual information to the access control device. The access control device can use the contextual information to refine a determination of whether to grant or deny physical access to an area.

[0003] Some access control readers determine whether to grant or deny physical access based on credentials. In such systems, an access control reader can grant or deny physical access (e.g., lock or unlock) based solely on the validation of credentials. In some systems, a digital key device can determine the relevant credentials to be presented to an access control reader based on an identifier of the access control reader, such as the group identification (group ID) or subgroup identification (subgroup ID).

[0004] According to the techniques disclosed herein, an access control device can determine whether physical access is granted or denied based on access credentials and contextual information indicating one or more activities performed by a user. In this way, the access control device can, for example, deny access if the contextual information indicates that access should not be granted, even if the access credentials are valid. For example, an access control device for an automobile or bicycle garage can refrain from granting access if contextual information indicates that the user of the digital key device is not in an automobile or on a bicycle.

[0005] In some examples, the digital key device can assess the contextual information and send the access credentials without including or transmitting the contextual information to the access control device. Continuing the example above, the digital key device might locally determine that the user must perform certain activities (e.g., be in a car or on a bicycle) to gain access from the access control device. In such a case, provided the user performs these activities, the digital key device can send the access credentials to the access control device without the contextual conditions. This way, the contextual information can be retained by the digital key device and not shared with the access control device.

[0006] As can be seen, contextual information can be advantageous for hands-free access control, where an access control device can be automatically unlocked without any additional action from the user. According to the techniques disclosed herein, for example, an access control device for a pedestrian door may not unlock if the contextual information indicates that the user is passing by in or on a vehicle (e.g., a car or bicycle), or an access control device for an exterior door of a house may only unlock if the contextual information indicates that the user is outside the house as opposed to inside the house.With regard to non-hands-free operation, the techniques disclosed herein may cause the digital key device, based on contextual information, to refrain from requesting user authorization or confirmation to unlock the access control device. For example, the digital key device may refrain from requesting user confirmation to unlock an access control device for a garage door if the contextual information indicates that the user is not in a vehicle or is on foot (e.g., walking or running).

[0007] In one example, various aspects of the techniques are directed toward a procedure, including: receiving an access request, which includes one or more credentials and context information specifying one or more activities to be performed by a user of the computing device, by an access control device associated with an interlocking device for a controlled area, and by a computing device; determining, by the access control device, whether the context information satisfies one or more context conditions; and determining, by the access control device, whether the one or more credentials are valid.and in response to the determination that one or more access credentials are valid, and in response to the determination that the context information satisfies one or more context conditions, the access control device changes the state of the locking device.

[0008] In another example, various aspects of the techniques are directed at a computing device that includes an interlocking device for a controlled area, a memory that stores instructions, and a processing circuit that executes the instructions to: receive an access request that includes one or more credentials and context information that specifies one or more activities to be performed by a user of the computing device; determine whether the context information satisfies one or more context conditions; determine whether the one or more credentials are valid; and, in response to determining that the one or more credentials are valid and in response to determining that the context information satisfies the one or more context conditions, change a state of the interlocking device.

[0009] In another example, various aspects of the techniques are directed at non-transitory, computer-readable storage media that store instructions which, when executed by a processing circuit, cause the processing circuit to: receive an access request from a computing device that includes one or more credentials and context information specifying one or more activities to be performed by a user of the computing device; determine whether the context information satisfies one or more context conditions; determine whether the one or more credentials are valid; and, in response to determining that the one or more credentials are valid and in response to determining that the context information satisfies the one or more context conditions, change a state of the interlocking device.

[0010] The details of one or more examples of the disclosure are set forth in the accompanying drawings and the description below. Other features, functions, and advantages of the disclosure will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE FIGURES Fig. Figure 1 is a conceptual diagram illustrating an example of an environment for using contextual credentials for physical access control according to one or more aspects of this disclosure. Fig. Figure 2 is a block diagram illustrating an exemplary computing system according to one or more aspects of the present disclosure. Fig.Figure 3 is a conceptual diagram illustrating an example of an environment including examples of access control devices and controlled areas according to one or more aspects of the present disclosure. Fig. Figure 4A is a block diagram illustrating initial examples of computing devices and access control systems according to one or more aspects of the present disclosure. Fig. Figure 4B is a block diagram illustrating second examples of computing devices and access control systems according to one or more aspects of the present disclosure. Fig. Figure 5 is a conceptual diagram illustrating an example process for using context-identifying credentials for physical access control according to one or more aspects of the present disclosure. Fig.Figure 6 is a flowchart of a first example process for context-related access credentials for physical access control according to one or more aspects of the present disclosure. Fig. Figure 7 is a flowchart of a second example process for context-related access credentials for physical access control according to one or more aspects of the present disclosure. DETAILED DESCRIPTION

[0011] Fig.Figure 1 is a conceptual diagram illustrating an example of a context-aware access credential environment for physical access control according to one or more aspects of this disclosure. As can be seen, the environment 100 may include one or more computing devices 102, one or more computing systems 120, and one or more access control devices 132. As described herein, the computing system 120 may be an administration system for managing access credentials (e.g., generating, distributing, and invalidating access credentials), which computing devices 102 may submit to access control devices 132 for access to controlled areas 130 (e.g., buildings, rooms, safes, lockers, or other physical areas). The computing devices 102 may also be referred to here as digital key devices 102.

[0012] The computing device 102 could be, for example, a mobile phone, a tablet computer, a laptop computer, a portable device, a gaming system, a media player, an e-book reader, or any other type of computing device that can act as a digital key. Fig. Figure 1 illustrates a specific example of a computing device 102, and many other examples of the computing device 102 can be used in other cases and may include a subset of the components included in the exemplary computing device 102, or may include additional components that are in Fig. 1 are not shown.

[0013] The computing device 102 can include or communicate with one or more processors 104, one or more input devices 106, one or more output devices 108, one or more storage devices 110, one or more sensors 112, and one or more communication units 114, or various subsets thereof. The communication channels 116 can connect any of the components 104, 106, 108, 110, 112, 114 for communication between the components (physical, communicative, and / or operational). In some examples, the communication channels 116 can include a system bus, a network connection, a data structure for communication between processes, or any other method for data communication.

[0014] The processor 104 can implement functionality and / or execute instructions for the computing device 102. Examples of processors 104 include, but are not limited to, one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term "processor," as used here, can refer to any of the structures mentioned above or any other structure suitable for implementing the techniques described in this document.

[0015] The processor 104 can implement functionality and / or execute instructions for the computing device 102. For example, one or more processors 104 can receive and execute instructions for the computing device 102 that are stored by one or more memory devices 110, which execute the functionality of the context module 122 and the credential module 124. The instructions executed by one or more processors 104 can cause the computing device 102 to store information in one or more memory devices 110 during program execution. One or more processors 104 can execute instructions from the context module 122 and the credential module 124 to perform actions or functions.This means that the context module 122 and the authorization module 124 can be operated by one or more processors 104 to perform various actions or functions of the computing device 102.

[0016] One or more input devices 106 for the computing device 102 can receive inputs. Examples of inputs are tactile, acoustic, and optical. The input devices 106 of the computing device 102 include, in one example, a presence-sensitive display, a touch-sensitive screen, a mouse, a keyboard, a voice-controlled system, a video camera, a microphone, or any other type of device for detecting inputs from a human or a machine.

[0017] One or more output devices 108 for the computing device 102 can produce an output. Examples of outputs are tactile, acoustic, and visual outputs. Output devices 108 for the computing device 102 can include, for example, a presence-sensitive display, a sound card, a video graphics card, a loudspeaker, an organic light-emitting diode (OLED), or any other type of device for producing an output for a person or a machine.

[0018] One or more communication units 114 for the computing device 102 can communicate with external devices via one or more wired and / or wireless communication links, such as by transmitting and / or receiving wired and / or wireless signals over one or more networks or directly with the external devices. Examples of communication units 114 include a network interface card (e.g., such as an Ethernet card), an optical transceiver, a radio frequency transceiver (e.g., Wi-Fi® transceiver, cellular transceiver, ultra-wideband transceiver, near-field NFC transceiver, Bluetooth® transceiver), a global navigation satellite system (GNSS) receiver, or any other type of device capable of sending and / or receiving information.Other examples of communication units 114 can include shortwave radios, as well as Universal Serial Bus (USB) controllers.

[0019] One or more storage devices 110 within the computing device 102 can store information for processing during the operation of the computing device 102. That is, the computing device 102 can store data that the context module 122 and / or the credential module 124 have accessed during execution on the computing device 102, including credentials, context information, or other data. In some examples, the storage device 110 can be temporary storage, meaning that a primary purpose of the storage device 110 is not long-term storage. One or more storage devices 110 on the computing device 102 can be configured as volatile storage for the short-term storage of information, and therefore, stored content is not retained when the computing device is powered off.Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in engineering.

[0020] In some examples, one or more storage devices 110 also include one or more computer-readable storage media. One or more storage devices 110 may be configured to store larger amounts of data compared to volatile storage. One or more storage devices 110 may also be configured for long-term storage of information as non-volatile storage, where information is retained after power cycles. Examples of non-volatile storage include magnetic hard disks, optical media, floppy disks, flash memory, or forms of electrically programmable memory (EPROM) or electrically erasable and programmable memory (EEPROM). One or more storage devices 110 may store programming instructions and / or information (e.g.,data) that are associated with the context module 122 and the credential module 124. In some examples, one or more storage devices 110 can store an operating system that is run by the processor 104 to provide an execution environment for the context module 122, the credential module 124, and / or any applications or processes that are installed on the computing device 102.

[0021] The context module 122 and the credential module 124 can run on one or more processors 104 to perform functions related to context-based access credentials for physical access control. In some examples, the context module 122 can generate context information, including information corresponding to one or more activities performed by a user of the computing device 102. For example, the user of the computing device 102 may be in a means of transport (e.g., in a car, on a bicycle) or on foot (e.g., walking, standing, running). It should be noted that the context module 122 can determine that the user of the computing device 102 is only on foot if the user is not in or on a vehicle.Therefore, the context module 122 cannot generate context information indicating that the user is on foot when the user is standing, walking, or running in or on a vehicle. The user of the computing device 102 can be inside or outside the controlled area 130 (e.g., building, room, house). The context information can indicate an intention in some examples. For instance, the user of the computing device 102 can arrive at or leave a controlled area 130 (e.g., building, room, house).

[0022] In some examples, the context module 122 can determine the user's intent based on historical information, such as historical location data (e.g., GNSS positions), historical network connection data (e.g., Wi-Fi or cellular connection history), historical activity data (e.g., on foot, in a transport vehicle, outside a controlled or other area, inside a controlled or other area), provided the user has previously given permission to use the historical information.

[0023] Context Module 122 can include one or more machine learning (ML) models to determine the user's context (e.g., contextual information). For example, Context Module 122 can apply an ML model trained using a training dataset that includes sensor or other information with corresponding activities using various types of models (e.g., K-nearest neighbors, support vector machine (SVM), random forest, decision trees, logical regression, naive Bayes) and various training techniques (e.g., supervised, unsupervised, semi-supervised, reinforcement). In some examples, Computing Device 102 can train the ML model using the training dataset and then provide the trained ML model to Computing Device 102.The Computing Device 102 can validate the ML model, for example, by applying one or more validation datasets that include examples of sensor or other information and corresponding activity indicators. The Computing Device 102 can determine and refine the accuracy of the ML model by comparing the activity indicators generated by the ML model with the sensor or other information in the validation dataset against the corresponding activity indicators provided by the validation dataset. The ML model can output activity indicators that identify the user's current activity, intent, or both.

[0024] As can be seen, the context module 122 can generate context information indicating that the user of the computing device is in a transport vehicle, on foot, within the controlled area 130 (or another defined area), outside the controlled area 130 (or another defined area), arriving at the controlled area (or another defined area), leaving the controlled area 130 (or another defined area), or in various subsets thereof. For data protection reasons, the context information can be very broad or general (e.g., on foot, in a transport vehicle, within a controlled (or other) area, outside a controlled (or other) area).

[0025] Other examples of contextual information that the context module 122 can generate include contextual information that, in addition to the information mentioned above, specifies the geographic location of the computing device 102 (e.g., GNSS coordinates), the location of the computing device 102 relative to another device or object (e.g., inside a vehicle, inside a room, outside a vehicle, outside a room), whether and / or at what speed and / or in which direction the computing device 102 is moving, rotating, tilting, or otherwise moving, or various subsets thereof. The context module 122 can include information about the user of the computing device 102 in the contextual information, provided the user's permission has been obtained beforehand.

[0026] The context module 122 can generate context information in various ways. For example, the context module 122 can generate context information by acquiring one or more readout values ​​or measurements, such as those obtained by one or more sensors 112. The sensor 112 can collect or obtain sensor information relating to the circumstances of the computing device 102. In some examples, a sensor 112 can be a sampling or input component that obtains physical position, motion, and / or location information of the computing device 102. For example, sensors 112 can be one or more location sensors (GNSS components, Wi-Fi® components, cellular components, ultra-wideband components, near-field communication (NFC) components), one or more temperature sensors, one or more activity or motion sensors (e.g., multi-axis accelerometers, gyroscopes), one or more pressure sensors (e.g., pressure gauges, pressure sensors).barometer), one or more ambient light sensors, and one or more other sensors (e.g., microphone, camera, infrared proximity sensor, hygrometer, and the like). In some examples, one or more sensors may include one or more components such as keyboards, mice, a presence-sensitive enclosure, and / or a display or other input devices.

[0027] The sensor 112 can output sensor information, including metrics, measurements, or other data corresponding to the sensor components representing the sensor 112. For example, an activity sensor can output sensor information indicating an activity performed by a user of the computing device 102 (e.g., walking, running, sitting, standing); a motion sensor can output sensor information indicating the acceleration, velocity, rotation, etc., of the computing device 102; an ultra-wideband or proximity sensor can output sensor information indicating the distance or position of the computing device 102 relative to another object (e.g., another computing device / computer system); a GNSS or other positioning sensor can output sensor information indicating the location (e.g., coordinates) of the computing device 102, and so on.

[0028] The context module 122 can use sensor information from the sensors 112 to generate context information and, in some cases, can analyze and / or combine the sensor information from the sensors 112 to generate this context information. For example, the context module 122 can analyze sensor information from a motion sensor 112 to determine whether the user is on foot (e.g., walking, running, standing) and generate context information indicating that the user is on foot. As another example, the context module 122 can use sensor information from a proximity sensor 112 (e.g., ultra-wideband, Bluetooth, or NFC sensor) indicating that the user is in a transportation vehicle to generate context information indicating this. As yet another example, the context module 122 can use sensor information from a location sensor 112 and / or a motion sensor 112 (e.g.,GNSS sensor, accelerometer) that indicate whether the user is inside or outside the controlled area 130 (or any other defined area) or whether the user is entering or leaving the controlled area 130 (or any other defined area) to generate contextual information indicating this.

[0029] In some examples, the context module 122 can receive context information from a user, for example, through user-provided input. For instance, the context module 122 can prompt a user to enter context information, and the user can respond by entering that information, such as selecting or specifying an activity indicator that indicates an action the user is performing. The context module 122 can determine context information from user input, such as one or more settings the user has selected for the computing device 102. For example, an airplane mode setting for the computing device 102 can represent an activity indicator that the user is in a transportation vehicle.

[0030] The context module 122 can send the context information, along with one or more access credentials, to the access control device 132, for example, via the communication unit 114. In some examples, the context module 122 can send the context information and the access credential to the access control device 132 in the form of an access request. As described below, the access control device 132 can use the context information to determine whether to grant or deny access to the controlled area 130. For example, the access control device 132 can determine whether to grant access (e.g.,The access control device 132 may refuse to lock or refrain from unlocking a pedestrian door of controlled area 130, even if valid access credentials are received along with context information, if the context information indicates that the user is in a means of transport (e.g., in a car or on a bicycle). As another example, the access control device 132 may determine to grant access (e.g., unlocking) to a garage door of controlled area 130, provided that valid access credentials have been received along with the context information, if the context information indicates that the user is in a means of transport.

[0031] As can be seen, contextual information can be advantageous relative to hands-free access, such as in the context of an ultra-wideband access control system, where the user does not provide any additional input (e.g., user confirmation or authorization) before the access control device 132 permits access, at least on the grounds that the access control device 132 can deny access under undesirable circumstances and thereby prevent unauthorized persons from gaining physical access to the controlled area 130. For example, the access control device 132 can deny access through a pedestrian door (e.g., the front door) if the user is in a transport vehicle, as indicated by the contextual information received from the computing device 102.As such, the access control device 132 does not unlock the pedestrian door when the user passes by on the vehicle, thus preventing unauthorized persons from entering through the pedestrian door while the user passes the pedestrian door on the transport vehicle.

[0032] The context information can be used by the access control device 132, the computing device 102, or both. For example, in a non-hands-free operation scenario (e.g., Bluetooth-enabled access control), the computing device 102 can use the context information to determine whether to notify the user or prompt them for input (e.g., authorization or confirmation) before an access request is sent to the access control device 132. For example, the computing device 102 cannot prompt a user for confirmation to unlock a pedestrian door if the context information indicates that the user is inside a transportation vehicle.As another example of a non-hands-free case, the computing device 102 can use the context information to determine which access credential from a variety of access credentials to present to the access control device 132. For example, the computing device 102 can be located in close proximity to several access control devices 132 for different doors or other openings and retrieve and present different access credentials based on the context information. To illustrate, the computing device 102 can present the access credential for a first access control device 132 (e.g., garage door opener) if the context information indicates that the user is in a transport vehicle, and the access credential for a second access control device 132 (e.g., a car) if the context information indicates that the user is in a vehicle.Pedestrian door access control reader) if the context information indicates that the user is on foot (e.g., walking). In this example, the first and second access control devices 132 can be located close enough to each other to cause at least some ambiguity as to which access control device 132 the user intends to use.

[0033] The credential module 124 can store access credentials, such as in a database or other structured data format, in the storage device 110. Some examples of access credentials include digital tokens, keys, usernames, passwords, or other authentication information. In some examples, access credentials may include cryptographic tokens or keys, or other encrypted authentication information, including tokens, passcodes, usernames, and passwords. During operation, the context module 122 can present (e.g., send) the context information, along with one or more access credentials, to the access control device 132, for example, in the form of an access request to request physical access to the controlled area 130.

[0034] Context module 122 can manage access credentials in credential module 124 (e.g., save, update, delete, retrieve). For example, context module 122 can save access credentials for credential module 124 and update and delete access credentials within credential module 124, renewing or invalidating them (e.g., revoking, removing, or expiring). In some examples, context module 122 can receive management instructions from computer system 120 and perform certain management functions (e.g., saving, updating, or deleting access credentials) on locally stored access credentials (e.g., access credentials stored by storage device 110) in response to those instructions.

[0035] The computer system 120 can be a management system for one or more access control devices 132 at one or more controlled areas 130 and one or more computing devices 102. For example, the computer system 120 can register one or more computing devices 102, one or more access control devices 132, and one or more controlled areas 130, such as during a provisioning process. Each controlled device 132 can be provisioned to the computer system 120 using an administrator device. The administrator device can be any computing device, including the computing device 102, configured to provision one or more controlled devices 132. During the provisioning process, the administrator device can provide contextual information about the one or more controlled devices 132 to the computer system 120.Such context information may include the type of controlled device 132 (e.g., a type of door, which may be represented by a variable "Door_Type"). Door types may include, as non-restrictive examples, a pedestrian door, a garage door, a security door, a vault door, a turnstile, an automatic door, a revolving door, a sliding door, a gate, a roller door, etc. The context information may also include a list of types of user interactions that are likely and / or unlikely to occur when a user attempts to unlock or otherwise make accessible a controlled area managed by the particular access control device 132. In some examples, the list of user interaction types may be provided using a variable called "User_Activity".The types of user interactions can include, among other things, types of user activities such as walking, running, cycling, driving, skating (e.g., on inline skates, ice skates, etc.), dancing, jumping, etc. The context information can also include a side of the access control device 132 from which the user must approach to gain access to the controlled area 130. For example, the context information can indicate that the access control device 132 can grant access if the user approaches from either side of the access control device 132 (e.g., from within the controlled area 130 or from outside the controlled area 130). Alternatively, the context information can indicate that the access control device 132 can only provide access if the user approaches the access control device 132 from outside the controlled area 130.Similarly, the context information can indicate that the access control device 132 can only provide access if the user approaches the access control device 132 from within the controlled area 130.

[0036] Each access control device 132 can be equipped with multiple and / or secondary markers. For example, a garage door can be marked with "Door_Type = Rolling Garage Door". The garage door can be marked with "User_Activity = Drive" and "User_Activity = Walk". In some examples, the garage door can further be configured to allow access when the user approaches the access control device 132 from either side while driving, but only from the inside while walking.

[0037] The computer system 120 can register such contextual information by, for example, storing administrative information in a storage device of the computer system 120. This information includes a specification of one or more computer devices 102, one or more access control devices 132 (including a type of access control device 132), and one or more controlled areas 130 for the management of which the computer system 120 is responsible, as well as one or more types of user interactions that a user is likely and / or unlikely to perform when attempting to gain access to one or more access-controlled areas 130. The computer system 120 can store the administrative information in a database or other structured data format on the storage device.

[0038] In some examples, instead of providing the context information to computer system 120 during the initial provisioning process, access control device 132 can provide the context information to computer system 120 during an authentication transaction. This means that computer system 120 can authenticate a user based on the information provided by computer device 102, as well as the context information provided by access control device 132. For example, computer device 102 can provide information about user activity and authentication credentials to computer system 120, while access control device 132 can provide information about a door type and one or more user interaction types associated with access control device 132.In some cases, instead of directly providing the user activity information and authentication credentials to the computer system 120, the computer device 102 can provide the user activity information and authentication credentials to the access control device 132, and the access control device 132 (e.g., by including the information in extended BLUETOOTH Low Energy announcements issued by the computer device 102) can provide the user activity information and authentication credentials to the computer system 120 in addition to the door type and one or more user interaction types.Using the information on user activity and authentication credentials received from the computing device 102, and the door type and one or more user interaction types received from the access control device 132, the computing system 120 can determine whether the access credentials are valid and can determine whether the context information (e.g., the user activity from the computing device 102) satisfies one or more context conditions (e.g., the one or more user interaction types from the access control device 132).

[0039] The management information can specify which access control devices 132 correspond to which controlled areas 130. For example, the computer system 120 can store in the management information an indication of the respective controlled area 130 in which the respective access control device 132 is located or installed. The computer system 120 can store in the management information an indication of the respective computing devices 102 that are assigned to (e.g., paired with) each access control device 132. The computer system 120 can send an indication of access control devices 132 to which computing devices 102 are assigned to the computing devices 102, an indication of computing devices 102 to which access control devices 132 are assigned to the access control devices 132, or both.In this way, computing devices 102 and / or access control devices 132 can refrain from communicating with unknown (e.g., unregistered, unpaired) devices (e.g., refrain from communicating access requests).

[0040] In some examples, the computer system 120 can group access control devices 132 into one or more groups, such as by assigning access control devices 132 to one or more groups (e.g., Group 1, Group 2, ... Group n). The computer system 120 can assign access control devices 132 within a group to one or more subgroups (e.g., Subgroup 1, Subgroup 2, ... Subgroup n). The computer system 120 can store an indication of the group and / or subgroup to which each access control device 132 is assigned in the management information.

[0041] The computer system 120 can use such groupings and / or subgroupings to apply configuration settings across a number of access control devices 132. For example, the computer system 120 can apply the same configuration settings to each access control device 132 in a group (e.g., Group 1). The computer system 120 can also specify context conditions (e.g., criteria) that context information must meet for each access control device 132 within a group or subgroup. For example, the computer system 120 can store an indication of the context information assigned to a group or subgroup in its administrative information. The computer system 120 can send different sets of context conditions to groups and / or subgroups of access control devices 132.Access control devices 132 can receive and store respective context conditions, such as in the storage device 140. The access control device 132 can grant or deny access to the controlled area 130 based on the context conditions, as described below.

[0042] In some examples, the computer system 120 can specify the context conditions for access control devices 132 during the provisioning or registration of access control devices 132. The computer system 120 can assign context conditions to the respective access control devices 132 in the management information, such as by storing the context conditions for each access control device 132 in a "CONTEXT" field within the management information for each access control device. In some examples, such a "CONTEXT" field can be a column of a database, another field in a database, or another structured data format.

[0043] In some examples, the computer system 120 can send a first set of context conditions to a group of access control devices 132, which includes each access control device 132 on the outer perimeter of the controlled area 130 (e.g., exterior doors of a building). Continuing this example, the computer system 120 can send a second set of context conditions to a subgroup of the group of access control devices 132 (e.g., garage doors of the controlled area 130). Therefore, the first set of context conditions might, for example, require that the user be outside, and the second set of context conditions might, for example, require that the user be inside a transport vehicle.

[0044] The computing device 102 can operate according to the context conditions in some examples. As described above, during non-hands-free operation, the computing device 102 can prompt a user for additional input (e.g., authorization or confirmation) before requesting physical access from the access control device 132. In such a case, the computing device 102 can determine, based on the context conditions of the access control device 132, whether to prompt a user for additional input.Continuing the example above, the computing device 102 may, for instance, require that the user be outside before prompting him to enter additional data when the computing device 102 is used with the access control device 132 with the first set of context conditions, and may require that the user be inside a transport vehicle when the computing device 102 is used with the access control device 132 with the second set of context conditions.

[0045] In some examples, the computer system 120 can generate and distribute (e.g., send) access credentials to computing devices 120 and validation information for validating access credentials to access control devices 132. For example, the computer system 120 can generate an access credential, such as a cryptographic key or token, for computing device 102, which is assigned to access control device 132, and transmit the access credential to computing device 102. The computer system 120 can reference the management information to identify computing device 102 and access control device 132. The credential module 124 of computing device 102 can receive the access credential and store it, for example, in storage device 110.The context module 122 can then present (e.g., send) the access credential to the access control device 132, which is assigned to the controlled area 130, to grant the user access to the controlled area 130. The access control device 132 can store the validation information and use it to validate the presented access credential. In some examples, the computing system 120 can use a public key infrastructure (PKI) to generate cryptographic keys or tokens that represent access credentials and validation information. In such examples, computing devices 102 and access control devices 132 can use corresponding public and private keys to encrypt, decrypt, sign, and / or validate access credentials.

[0046] In some examples, computer system 120 can invalidate access credentials (e.g., revoke, delete). For instance, computer system 120 can transmit one or more administrative instructions to access control device 132 and / or computer device 102, causing access control device 132 and / or computer device 102 to invalidate one or more access credentials identified in the administrative instructions. Upon presentation of an invalid access credential, access control device 132 can deny access to the controlled area 130.

[0047] The computer system 120 can communicate with one or more computing devices 102 and one or more access control devices 132, for example via the network 126. The network 126 can be any public or private communication network, such as a cellular network, Wi-Fi, and / or another type of network for transmitting data between computer systems, servers, and computing devices. The network 126 can include one or more network hubs, network switches, network routers, or other network equipment that are interconnected and thereby enable the exchange of information between the computer system 120, the computing device 102, the access control device 132, or various subsets thereof.The computing device 102, the access control device 132, and the computing system 120 can transmit and receive data over the network 126 using any suitable communication techniques. For example, access credentials and other data can be transmitted and received between the computing system 120, the computing device 102, and the access control device 132, or different subsets thereof, over the network 126. Each of the computing devices 102, access control devices 132, and computing systems 120 can be operationally connected to the network 126 using respective network connections such as Ethernet, Wi-Fi, or any other type of wired and / or wireless network connection. Wired and / or wireless connections between devices / systems can be established by appropriate communication units (e.g.,Communication unit 114 of the computing device 102 and communication unit 144 of the access control device 132) are manufactured.

[0048] The access control device 132 can control access to a controlled area 130, such as a building, room, safe, locker, or other physical area. The access control device 132 can grant or deny access to the controlled area 130 by controlling the operation of one or more locking devices 138 (e.g., locks), such as a door opening or other opening of the controlled area 130. Examples of access control devices 132 include access control readers (e.g., ID card readers, card readers), smart locks, digital locks, biometric locks, and the like. As shown in the example in Fig.As can be seen from Figure 1, the access control device 132 can comprise one or more processors 134, one or more communication units 144, and one or more locking devices 138. In some examples, the access control device 132 can include one or more input devices 136 and one or more storage devices 140. The communication channels 146 can connect any of the components 134, 136, 138, 140, 144 for communication between components (physical, communicative, and / or operational). In some examples, the communication channels 146 can include a system bus, a network connection, a data structure for communication between processes, or any other method for data communication.

[0049] The processors 134, input devices 136, storage devices 140, and communication units 144 of the access control device 132 can be structured similarly to the processors 104, input devices 136, storage devices 110, and communication units 114 described above in connection with the computing device 102. For example, the processor 134 can implement functions and / or execute instructions within the access control device 132 to implement the functions of the access control device 132 and may include integrated or discrete logic circuits (e.g., DSP, ASIC, CPU, FPGA) or any other hardware configured to function as a processing unit. The processor 134 of the access control device 132 can receive and execute instructions stored by one or more storage devices 140, which perform the functionality of the control module 142.The instructions executed by one or more processors 134 can cause the access control device 132 to store information in one or more memory devices 140 during program execution. One or more processors 134 can execute instructions from the control module 142 to perform actions or functions. That is, the control module 142 can be operated by one or more processors 134 to perform various actions or functions of the access control device 132.

[0050] One or more input devices 136 of the access control device 132 can receive inputs, such as tactile, acoustic, and visual inputs. The input devices 136 of the access control device 132 include, for example, a presence-sensitive display, a touch-sensitive screen, a mouse, a keyboard, a voice-controlled system, a video camera, a microphone, or any other type of device for detecting inputs from a human or a machine. Such input can be a code (e.g., a personal identification number (PIN)), biometric information, or the like, which the access control device 132 can validate to grant access.

[0051] One or more storage devices 140 for the access control device 132 can store information for processing during the operation of the access control device 132. That is, the storage device 140 can store data that the control module 142 accesses, including validation information for validating access credentials (e.g., public / private keys of a PKI), credentials, context information, or other data. In some examples, one or more storage devices 140 can store an operating system that is executed by the processor 134 to provide an execution environment for the control module 142 and / or any applications or processes installed on the access control device 132.

[0052] One or more locking devices 138 of the access control device 132 can unlock to grant access to the controlled area 130 and lock or remain locked (e.g., not unlock) to deny access to the controlled area 130. Locking devices 138 can comprise one or more actuators, motors, servos, electromagnets, magnets, or the like to lock and unlock a bolt or detent mechanism of the locking device 138. Examples of locking devices 138 include electronic locks such as electric door locks, electronic deadbolt locks, magnetic or electromagnetic locks, electronic lever locks, or the like.

[0053] One or more communication units 144 of the access control device 132 can communicate with external devices via one or more wired and / or wireless communication links, such as by transmitting and / or receiving wired and / or wireless signals over one or more networks 126 or directly with the external devices. For example, in Fig. As shown in Figure 1, the access control device 132 can communicate with the computer system 120 via the communication unit 144 and the network 126. The computer 102 and the access control device 132 can communicate directly via their respective communication units (e.g., communication unit 114 and communication unit 144), as for example through the direct communication link 128 between the computer 102 and the access control device 132 in the example shown in Figure 1. Fig.Figure 1 shows that in some examples, the direct communication link 128 can be a wireless communication link, such as a BLUETOOTH, WI-FI, NFC, ultra-wideband, or other wireless communication link. The computing device 102 can use a direct communication link 128, a network 126, or both to send context information and access credentials, such as in one or more access requests, to the access control device 132.

[0054] The control module 142 can be executed on one or more processors 134 to grant or deny access to the controlled area 130 by changing the state of one or more locking devices 138 (e.g., locks), such as opening a door or otherwise opening the controlled area 130. For example, to grant access, the control module 142 can change the state of the locking device 138 to an unlocked state, and to deny access, the control module 142 can either refrain from changing the state of the locking device 138 to an unlocked state or change the state of the locking device 138 to a locked state. In some examples, the control module 142 can operate a mechanical, electrical, magnetic, or other mechanism of the locking device 138 to change its state.For example, to change the state of the locking device 138 to an unlocked state, the control module 142 can release an electric striker, retract a bolt, release a magnetic or other detent, or the like. To change the state of the locking device 138 to a locked state, the control module 142 can, for example, lock an electric door opener, extend a bolt, activate / engage a magnetic or other detent, or the like.

[0055] The control module 142 can receive one or more context conditions for the access control device 132 from the computer system 120, for example, via the network 126 and the communication units 144. Similarly, the control module 142 can receive the validation information from the computer system 120. The storage devices 140 can store the context conditions, the validation information, or both. During operation, the control module 142 can receive an access request from the computer system 102. The access request can include the context information and one or more access credentials of the computer system 102. The control module 142 can compare the context information with one or more context conditions and validate the access credentials against the validation information. Assuming that the control module validates the access credentials, the control module 142 can grant access (e.g., by retrieving the user's password).B. Grant access (e.g., by unlocking the locking device 138) to the controlled area 130 if the context information meets the context conditions, and deny access (e.g., by withholding the unlocking or locking of the locking device 138) to the controlled area 130 if the context information does not meet the context conditions. The control module 142 can deny access to the controlled area 130 if it cannot validate the access credentials. The control module 142 can validate the access credentials by comparing them with the validation information using PKI encryption, such as by using one or more public / private keys in the validation information to validate the access credentials, or similar methods.

[0056] Examples of the operation of Control Module 142 with respect to some examples of the current user context and context conditions are shown in Table 1 below. The example in Table 1 assumes that the access credentials are valid. Control Module 142 can deny access if the access credentials are invalid, regardless of the contents of the context information. The context conditions in Table 1 can represent the User_Activity context information provided during a provisioning process. The current context can represent a currently determined user interaction, such as walking, driving, on foot, in a transport vehicle, etc. In some cases, the list of potential user interactions corresponds to the list of potential user activities. Table 1 Contextual condition(s) Current context Grant or deny access? in a transport vehicle On foot Refuse in a transport vehicle in a transport vehicle Grant in a transport vehicle and outside the controlled area in a transport vehicle Refuse in a transport vehicle or outside the controlled area in a transport vehicle Grant On foot On foot Grant On foot and outside a controlled area On foot Refuse On foot and outside a controlled area On foot and outside a controlled area Grant Arrival in the controlled area Within the controlled area Refuse Arrival in the controlled area Arrival in the controlled area Grant

[0057] As can be seen, the context conditions and context information can each contain one or more activity indicators (e.g., on foot, in a transport vehicle, within the controlled area, outside the controlled area). Control Module 142 can grant access if at least one of the activity indicators in the context information matches each of the activity indicators in the context conditions (e.g., it is identical). In some cases, Control Module 142 can treat some activity indicators as optional (e.g., for transport vehicle, "or" outside the controlled area) using a logical "OR" operator. Therefore, Control Module 142 may not require a corresponding activity indicator in the context information for activity indicators of optional context conditions.Thus, by receiving an access request that includes both credentials and contextual information, the access control device can make more informed decisions about whether to grant or deny access. This dual-verification mechanism enhances security by ensuring that access is granted not only based on valid credentials but also on the context in which the request is made, such as the user's current activity.

[0058] The access control device 132 can therefore determine, based on the context information, whether physical access is granted or denied. In this way, the access control device 132 can, for example, refrain from granting access if the context information indicates that access should not be granted, even if the access credentials are valid. For example, the access control device 132 can refrain from granting access to the controlled area 130, which includes a car or bicycle garage, if the context information indicates to the computing device 102 that the user is not in a transportation vehicle. That is, if the Door_Type is provided as Garage Door and the User_Activity is provided as Driving, if the computing device 102 determines that the user is in a transportation vehicle (e.g.,If the user is driving or riding in a vehicle (as determined by the system) and receives valid credentials from the computing device 102, the access control device 132 can determine that the specified user activity matches the provided user activity and can grant access to the controlled area 130. However, if the specified user activity is "Walking", the access control device 132 can determine that the specified user activity does not match the provided user activity and deny access to the controlled area 130.

[0059] As another example, an access control device 132 for a controlled area 130 that includes a pedestrian door may not grant access if the context information indicates that the user is passing by in a transport vehicle, or an access control device 132 for an exterior door (e.g., a front door) of a controlled area 130 that includes a house may only grant access if the context information indicates that the user is outside the house and not inside the house.

[0060] Fig.Figure 2 is a block diagram illustrating an exemplary computing system according to one or more aspects of the present disclosure. Computing system 220 can be an example of one or more computing devices, such as servers, desktop computing devices, in-service devices (e.g., server equipment), integrated computing devices, and other types of computing devices. As can be seen from the example in Figure 220, the system can be described as follows: Fig.As can be seen from Figure 2, the computing system 220 can include one or more processors 252, one or more communication units 254, and one or more storage devices 260. In some examples, the computing system 220 can include one or more input devices 256 and one or more output devices 258. The computing system 220 can include communication channels 216. The communication channels 216 can connect any of the components 252, 254, 256, 258, 260 for communication between the components (physical, communicative, and / or effective). In some examples, the communication channels 216 can include a system bus, a network connection, a data structure for communication between processes, or any other method for data communication. The computing system 220 in Fig. 2 can be an example of the 120 computer system in Fig. Be 1.

[0061] One or more communication units 254 of the computing system 220 can communicate with external devices by transmitting and / or receiving network signals on one or more networks over one or more wired and / or wireless networks. Examples of communication units 254 include a network interface card (such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GNSS receiver, or any other type of device capable of sending and / or receiving information. Other examples of communication units 254 may include shortwave radios, cellular data radios, wireless network radios, and universal serial bus (USB) controllers.

[0062] One or more input devices 256 may include one or more components such as keyboards, mice, a presence-sensitive enclosure, and / or a display or other input components. One or more output devices 258 may produce an output. Examples of outputs are tactile, acoustic, and visual outputs. The output devices 258 of the computing system 220 include, in one example, a presence-sensitive display, a sound card, a video graphics card, a loudspeaker, an OLED, or any other type of device for producing an output for a person or a machine.

[0063] The computer system 220 can provide a user interface to allow a user (e.g., an administrator) to configure and operate the computer system 220. For example, the computer system 220 can provide a local graphical user interface (GUI) through one or more input devices 256 and / or one or more output devices 258. The computer system 220 can provide a remote user interface, such as a dashboard or other web user interface (Web UI), through one or more communication units 254.The computing system 220 can, for example, receive user input via the user interface and via the input device 256 and / or the communication unit 254 in order to register, set up, assign and / or manage computing devices, access control devices and controlled areas, as well as receive configuration settings, such as context conditions for one or more computing devices and / or access control devices, and pair computing devices and access control devices.

[0064] One or more processors 252 can implement functionality and / or execute instructions within the computing system 220. Examples of processors 252 include, but are not limited to, one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term "processor," as used here, can refer to any of the structures mentioned above or to any other structure suitable for implementing the techniques described in this document.The management module 264 and the management directory 266 can be run on one or more processors 252 to manage computing devices 102, access control devices 132, access credentials and context conditions, as described above in relation to . Fig. 1 are described.

[0065] One or more storage devices 260 within the computing system 220 can store information for processing during the operation of the computing system 220. In some examples, the storage device 260 is temporary storage; that is, long-term storage is not its primary purpose. The storage devices 260 on the computing system 220 can be configured as volatile memory for short-term storage of information and therefore do not retain stored contents when the system is powered off. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in engineering.

[0066] The storage devices 260 also include, in some examples, one or more computer-readable storage media. The storage devices 260 can be configured to store larger amounts of information than volatile memory. The storage devices 260 can also be configured for long-term storage of information as non-volatile memory, where information is retained after power cycles. Examples of non-volatile memory include magnetic hard disks, optical media, floppy disks, flash memory, or forms of electrically programmable memory (EPROM) or electrically erasable and programmable memory (EEPROM). Storage devices 260 can include an operating system 262, a management module 264, and a management directory 266. As in Fig.As shown in Figure 2, the storage device 260 can contain an operating system 262 that provides an execution environment for one or more applications, such as an administrative module 264 and an administrative directory 266.

[0067] The administrative directory 266 can store administrative information, contextual conditions, and other data used to provide context-related access credentials for physical access control. The administrative directory 266 can store the administrative information and other data in a database or other structured data format. The administrative module 264 can manage the administrative information in the administrative directory 266 (e.g., save, update, delete). The administrative module 264 can perform the above-mentioned functions with respect to the computer system 120. Fig.1. Provide the described management functionality. For example, the management module 264 can register devices / units (e.g., computing devices 102, access control devices 132, controlled areas 130), assign access control devices 132 to one or more groups and / or subgroups, assign computing devices 102 to access control devices 132 (e.g., in pairs), and store context conditions for access control devices 132. The management module 264 can provide (e.g., send) and invalidate access credentials to computing devices 102 and provide and invalidate validation information to access control devices 132.

[0068] Fig.Figure 3 is a conceptual diagram illustrating an example of an environment, including examples of access control devices and controlled areas, according to one or more aspects of this disclosure. As can be seen, the environment 301 may include one or more controlled areas 330A-330N (collectively, "controlled areas 330") and one or more access control devices 332A-332N (collectively, "access control devices 332") installed at one or more access points 362A-362N (collectively, "access points 362"). In some examples, access points 362 may be openings, such as doors, that provide physical access to the controlled areas 330. As shown, the controlled areas 330 may be defined areas, such as physical areas, delimited by walls, fences, railings, or other barriers. Fig. 3 will be discussed below in the context of Fig.1 described. For example, the controlled areas 330 and the access control devices 332 can be described by Fig. 3 examples each for the controlled areas 130 and the access control devices 132 of Fig. Be 1.

[0069] As described above, the computer system 120 can assign access control devices 332 to one or more groups 360A-360N (collectively, "groups 360") based on user input. If these groups are at least partially nested within a parent group, they can be referred to as subgroups 360A-360N (collectively, "subgroups 360"). For example, in Fig.As shown in Figure 3, subgroups 360A and 360B can be within group 360C, and group 360N can be an independent group of access control devices 332. The computer system 120 can assign a group identifier (group ID) (e.g., group 1, group 2, ... group n) to each group (e.g., group 360C, 360N) and a subgroup identifier (e.g., group 360C, 360N) to each subgroup (e.g., subgroup 1, subgroup 2, ... subgroups). In the example of Fig. 3. Access control devices 332A, 332B are assigned to subgroup 360A, access control devices 332C, 332D are assigned to subgroup 360B and access control devices 332A-332D are assigned to group 360C.

[0070] The computer system 120 can use groups and subgroups to organize access control devices 332. For example, the computer system 120 can assign the access control devices 332 to group 360C, which represents a first campus, and assign the control device 332 to subgroups 360A and 360B, which represent controlled areas 330A and 330B (e.g., buildings) within the first campus. In this example, the computer system 120 can assign the access control device 332N to group 360N, which represents a separate controlled area 330N, or a second campus. In this way, the computing system can uniformly apply 120 configuration settings (e.g., context conditions and / or validation information) to multiple access control devices 332 by applying the configuration settings to a group (e.g., group 360C, 360N) or subgroup (e.g., subgroup 360A, 360B).

[0071] For example, controlled area 330A could be an office, and controlled area 330B could be a garage. In this example, computer system 120 can send initial context conditions requiring a user to be on foot to access access control devices 332A and 332B within subgroup 360A, and secondary configuration settings, including context conditions requiring the user to be in a transport vehicle to access access control devices 332C and 332D within subgroup 360B. Computer system 120 can send validation information to the entire group of access control devices by sending the validation information to access control devices 332A-332D within subgroup 360C.Therefore, the validation information applies to access control devices within group 360C, the first context conditions apply to access control devices within subgroup 360A, and the second context conditions apply to access control devices within subgroup 360B. Continuing this example, the controlled area 360C (e.g., a warehouse) may have restricted access for different users. Therefore, the computer system can send 120 different validation information to access control device 332N of group 360N, which may differ from that of group 360C.

[0072] Access control devices 332 can store and reference configuration settings (e.g., context conditions and validation information) from the computer system 120 and operate according to such configuration settings. Continuing the example above, access control devices 332A and 332B within subgroup 360A may require context information indicating that the user is on foot before granting access to controlled area 330A, and access control devices 332C and 332D within subgroup 360B may require receiving context information indicating that the user is in a transport vehicle before granting access to controlled area 330B.

[0073] Access control devices 332 can receive a group ID and / or subgroup ID from the computer system 120 for each group and / or subgroup in which the access control devices 332 are located. Access control devices 332 can announce (e.g., transmit) their respective group IDs and / or subgroup IDs in some examples to allow computer devices 102 to identify the access credential for each access control device 332. For example, subgroup 360A and subgroup 360B may each be accessible to different sets of users. Therefore, computer device 102 can present different access credentials to access control devices 332A and 332B compared to access control devices 332C and 332D, based on the subgroup ID announced by the access control devices (e.g.,Subgroup ID 1 for access control devices 332A, 332B and subgroup ID 2 for access control devices 332C, 332D). Since access control devices 332A-332D are within group 360C, each of the access control devices 332A-332D can have the same group ID (e.g., group ID 1).

[0074] Fig. Figure 4A is a block diagram illustrating initial examples of computing devices and access control systems according to one or more aspects of the present disclosure. Fig. 4A illustrates examples of access requests 480A-480C (collectively “Access Requests 480”) that are sent from Computing Devices 402A-402C (collectively “Computing Devices 402”) to respective Access Control Devices 432A-432C (collectively “Access Control Devices 432”). Fig. 4A will be discussed below in the context of Fig.1 described. For example, the computing devices 402 and the access control devices 432 can be described by Fig. 4 examples each for the computing devices 102 and the access control devices 132 of Fig. Be 1. In the example of Fig. 4A The solid lines between the computing devices 402 and the access control devices 432 represent successful access requests 480, and the dashed lines between the computing devices 402 and the access control device 432 represent invalid access requests 480. The access control device 432 can respond to successful access requests 480 by granting access to the controlled area 130 and respond to invalid access requests 480 by denying access to the controlled area 130.

[0075] As can be seen, Access Requests 480 can each include one or more Access Credentials 472A-472B (collectively, "Access Credentials 472") and Context Information 474A-474C (collectively, "Context Information 474"). The Access Credentials 472 and the Context Information 474 can each be examples of the Access Credentials and Context Information that may be used in conjunction with Fig.The access requirements 480 can correspond to a requirement structure in some examples. For instance, the access requirement 480 can include various fields in which data for the access requirement 480 can be stored. For example, the access requirement 480 can include a "CONTEXT" field that stores context information 474, a "AUTH CREDITS" field that stores access credentials 472, a "GROUP ID" field that contains a group ID for the access control device 432, a "SUBGROUP ID" field that contains a subgroup ID for the access control device 432, or various subsets thereof. An example of such an access requirement 480 is shown below in Table 2.In some examples, the group ID and / or subgroup ID can be included in the access request 480 to, for example, allow the access control device 432 to confirm that the access request 480 is intended for access control device 432 and not for another access control device 432 with a different group ID and / or subgroup ID. The "CONTEXT" field can be added to standards-based protocols, including open access standards such as Aliro (https: / / csa-iot.org / allsolutions / aliro / ). Table 2 Area Data GROUP ID 1 SUB GROUP ID 2 ACCESS AUTHORIZATION PROOFS a7816bf8f01cfea414140de5dae2223b0036 CONTEXT On foot

[0076] Access control devices 432 can each contain validation information 476A-476B (collectively, "validation information 476"), context conditions 478A-478C (collectively, "context conditions 478"), or both. Validation information 476 and context conditions 478 can each be examples of validation information and context conditions 478 that are used in conjunction with Fig. 1 are described.

[0077] As described above, the access control device 432 can only grant access to the controlled area 130 if the access authorization credentials 472 are valid, such as with regard to corresponding validation information 476. For example, in the example of Fig.4A The access credential 472A is only valid if it is validated by the access control device 432 using the validation information 476A, and the access credential 472B is only valid if it is validated by the access control device 432 using the validation information 476B. With respect to the context information 474, the access control device 432 can only grant access to the controlled area 130 if the context information 474 satisfies one or more context conditions 478. In example of Fig. For example, context information 474A can satisfy context conditions 478A, context information 474B can satisfy context conditions 478B, and context information 474C can satisfy context conditions 478C.

[0078] Accordingly, access request 480A is successful if the computing device 402A sends access request 480A to the access control device 432A, and access request 480A is invalid if the computing device 402A sends access request 480A to the access control devices 432B and 432C. If computing device 402B sends access request 480B to access control device 432B, access request 480B is successful, and if computing device 402B sends access request 480B to the access control devices 432A and 432C, access request 480B is invalid. Likewise, access request 480C is successful if the computing device 402C sends access request 480C to the access control device 432C, and access request 480C is invalid if the computing device 402C sends access request 480C to the access control devices 432A, 432B.

[0079] The computing device 402 may choose not to send the access request 480 based on the context conditions 478 associated with the access control devices 432. For example, context conditions 478A may require the user to be on foot, while context conditions 478B may require the user to be in a transport vehicle. Therefore, supposing that computing device 402A determines that the user is on foot, computing device 402 may send the access request 480A to access control device 432A and choose not to send an access request 480 to access control devices 432B and 432C, even if computing device 402 is within sufficient proximity to communicate with access control device 432A and one or more of access control devices 432B and 432C.

[0080] In some examples, the computing device 402 can determine whether context information 474 satisfies conditional conditions 478 and send only access credentials 472 (e.g., an access request 480 without context conditions 478) to the access control device 432. For example, context conditions 478A may require the user to be on foot, and the computing device 402A can determine locally whether the context information 474A satisfies the context conditions 478A. If the context information 474A satisfies the context conditions 478A, the computing device 402A can send only access credentials 472 (e.g., an access request 480 without context conditions 478) to the access control device 432A. In this way, context information 474 can be retained by computing devices 402 and not shared with access control devices 432.

[0081] Fig.4A can be considered an example of hands-free operation, in which computing devices 402 can automatically send access requests 480 to the access control device 432 without any additional input from the user (e.g., without user confirmation or authorization). For example, the computing device 402 can automatically send an access request 480 when it moves within a threshold distance of the access control device 432, as determined by ultra-wideband or other proximity detection technologies. Accordingly, if the access request 480 is successful, the access control device 432 can grant access without any additional input from the user.

[0082] Fig. Figure 4B is a block diagram illustrating second examples of computing devices and access control systems according to one or more aspects of the present disclosure. Fig. 4B can be considered an example of non-hands-free operation, as additional inputs (e.g., user confirmation or authorization) may be required before the computing device 402 sends the access request 480. In comparison to Fig. 4A includes Fig. 4B the users 482A-482C (collectively “Users 482”) at respective access control devices 432A-432C, which must provide the additional input before the computing devices 402 can send the access requests 480. Fig. 4B will be discussed below in the context of Fig. 1 described. As can be seen, the computing devices 402 can obtain the additional input by means of a prompt 484 (e.g., a notification or message) presented to the user, for example, via an output device 108. The computing device 402 can receive the additional input from the user 482 via an input device 106.

[0083] The computing device 402 can determine whether to present the request 484 and receive the additional input based on context information 474 related to context conditions 478. For example, the computing device 402 can present the request 484 if the context information 474 satisfies the context conditions 478, and refrain from presenting the request 484 if the context information 474 does not satisfy the context conditions 478.

[0084] In the example of Fig.Context information 474A can satisfy context conditions 478A, context information 474B can satisfy context conditions 478B, and context information 474C can satisfy context conditions 478C. Therefore, the solid line between the computing device 402B and the user 482B represents the presentation of the request 484 to the user 482A, while the dashed lines between the computing devices 402 and the access control devices 432 represent cases where no request is presented because the respective context conditions 478 are not met. For example, the computing device 402A cannot present the request 484 to the user 482A because the context information 474A of the computing device 402A does not satisfy the condition information 478A corresponding to the access control device 432A.Similarly, the computing device 402C does not present the prompt 484 to the user 482C because the context information 474C of the computing device 402C does not satisfy the context conditions 478C corresponding to the access control device 432C.

[0085] As in connection with the example in Fig.As described in 4A, the access credential 472B can only be valid if it is validated by the access control device 432 using the validation information 476B. Accordingly, if the user 482B provides confirmatory additional input (e.g., an acknowledgment or authorization) to the computing device 402B, the access request 480B can be sent to the access control device 432B. The access control device 432B can then grant access to the controlled area 130 because, in this example, the access credential 472A is valid with respect to the validation information 476A, and the context information 474B satisfies the context conditions 478B.

[0086] In some examples, the 402 computing device can validate the authentication information provided by the user as additional input. For example, the 402 computing device can receive and validate a passcode, password, biometric information (such as a fingerprint), or similar information as additional input. The 402 computing device can refrain from terminating the 480 access request if the authentication information is invalid and send the 480 access request if the authentication information is valid.

[0087] The computing device 402 may choose not to present the prompt 484 based on the context conditions 478 associated with the access control devices 432. For example, context conditions 478A may require the user to be on foot, while context conditions 478B may require the user to be in a transportation vehicle. Therefore, assuming the computing device 402B determines that the user is in a transportation vehicle, it may present the prompt 484 to the user 432B and choose not to present the prompt 484, even if the computing device 402B is within sufficient proximity to communicate with the access control device 432B and one or more access control devices 432A, 432C.

[0088] Fig.Figure 5 is a conceptual diagram illustrating an example of a process for context-related access credentials for physical access control according to one or more aspects of the present disclosure. In the example of Fig. 5 executes a calculating device (such as the calculating device 102). Fig. 1) in conjunction with an access control device (such as the access control device 132 from Fig. 1) Context-related access credentials for physical access control. Fig. 5 will be discussed below in the context of Fig. 1 described.

[0089] The computing device 102 detects the access control device 132 in the vicinity of the computing device 102 (502). The computing device 102 can detect that the access control device 132 is nearby (e.g., within a distance threshold) by scanning for an access control device 132 using communication units 114 (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy radios), sensors 112 (e.g., ultra-wideband sensors), or both, and by attempting to establish a communication session with any access control device 132 within the communication range of the computing device 102.

[0090] The computing device 102 can be connected to the access control device (504) via a direct connection 128 or a network 126, for example, using one or more communication protocols such as Wi-Fi, Bluetooth, Bluetooth Low Energy, ultra-wideband, or another communication protocol. The access control device 132 can respond to initial communication (e.g., a handshake) from the computing device 102 by completing the establishment of the communication session with the computing device 102 (506). For example, the access control device 132 can complete the handshake process and thereby establish the connection to the computing device 102.

[0091] In non-hands-free situations, the computing device 102 can perform the prompt steps 508, and in hands-free situations, the computing device 102 cannot perform steps 508. The computing device 102 can distinguish between hands-free and non-hands-free situations based on configuration settings. In some examples, the computing device 102 can detect a hands-free situation if the computing device 102 and / or the access control device 132 use ultra-wideband for proximity detection and / or communication.

[0092] Assuming a non-hands-free situation exists, the computing device 102 can compare the context information of the computing device 102 with the context conditions of the access control device 132 (510). If the context information satisfies the context conditions, the computing device 102 can receive an affirmative additional input from the user (512), such as in response to the computing device 102 presenting the user with a prompt for the additional input.

[0093] The computing device 102 can send an access request to the access control device 132 (514), which the access control device 132 can receive (516). As described above, the access request can include context information and one or more credentials. Although not shown, in a non-hands-free situation, if the context information does not meet the context conditions or if no additional confirming input is received from the user, the computing device 102 may refrain from sending an access request.

[0094] The access control device 132 can compare the context information of the computing device 102 with the context conditions of the access control device 132 (518). The access control device 132 can validate the access credentials (520). The access control device 132 can grant or deny access to the controlled area 130 (522) based on the comparison of the context information with the context conditions and the validation of the access credentials. For example, the access control device 132 can provide access to the controlled area 130 if the context information meets the context conditions and the access credentials are valid. The access control device 132 can deny access to the controlled area 130 if the context information does not meet the context conditions or the access credentials are invalid.The access control device 132 can optionally send an indication of whether it grants or denies access. The computing device 102 can receive such an indication (524), for example, for presentation to the user via the output device 108.

[0095] Fig. Figure 6 is a flowchart of a first example process for context-related access credentials for physical access control according to one or more aspects of the present disclosure. Fig. 6 will be discussed below in the context of Fig. 1 described.

[0096] The access control device 132 can receive an access request from the computing device 102 (602). As described above, the access request can include one or more credentials and contextual information indicating one or more activities being performed by a user of the computing device 102. The contextual information can include one or more activity indicators. For example, the activity indicators can identify whether the user of the computing device 102 is on foot or in a transport vehicle and / or whether the user of the computing device 102 is inside or outside the controlled area. The access control device 132 can receive the contextual conditions, for example, from the computing system 120.

[0097] The access control device 132 can determine whether the context information satisfies one or more context conditions (604). The access control device 132 can compare the context information with the one or more context conditions to determine whether the context information satisfies one or more context conditions. For example, the context conditions and the context information can each include one or more activity indicators (e.g., on foot, in a transport vehicle, inside a controlled area, outside a controlled area). The access control device 132 can grant access if at least one of the activity indicators in the context information matches (e.g., is identical to) each of the activity indicators in the context conditions. The access control device 132 can grant access to the controlled area 130 only if the context information satisfies the context conditions.

[0098] The access control device 132 can determine whether the access credentials are valid (606). For example, the access control device 132 can use validation information that can be received from the computing system 120 to determine whether the access credentials are valid. The access control device 132 can perform various reconciliation or cryptographic processes (e.g., PKI) to validate the access credentials, as described above. In response to determining that one or more access credentials are valid, and in response to determining that the context information satisfies one or more context conditions, the access control device 132 can change a state of the locking device (608). For example, the access control device 132 can unlock the locking device to change its state.Access control devices 132 can change the state of the locking device to an unlocked state, for example, if the context information satisfies one or more of the context conditions. The access control device 132 may refrain from changing the state of the locking device if the context information does not satisfy one or more of the context conditions. As described above, the access control device 132 can only grant access to the controlled area 130 if the access credentials are valid.

[0099] Fig. Figure 7 is a flowchart of a second example process for context-related access credentials for physical access control according to one or more aspects of the present disclosure. Fig. 7 will be discussed below in the context of Fig. 1 described.

[0100] The computing device 102 can detect the access control device 132 (702). For example, the computing device 102 can detect an access control device 132 in the vicinity of the computing device 102. The computing device 102 can detect that the access control device 132 is nearby (e.g., within a distance threshold) by scanning for an access control device 132 using communication units 114 (e.g., Wi-Fi, Bluetooth radios), sensors 112 (e.g., ultra-wideband sensors), or both, and by attempting to establish a communication session with any access control device 132 within the communication range of the computing device 102.

[0101] The computing device 102 can determine the context information that specifies one or more activities being performed by the user of the computing device 102 (704). The computing device 102 can determine the context information in various ways. In some examples, the computing device 102 can obtain sensor information from one or more sensors 112 and generate the context information based on the sensor information. The computing device 102 can determine the context conditions for the access control device 132 (706). For example, the computing device 102 can request and receive the context conditions for the access control device 132 from the access control device 132, the computing system 120, or both, such as through a direct connection 128, a network 126, or both.In some examples, the computing device 102 can request the context conditions for the access control device 132 by sending a request that includes an identifier for the access control device 132 (e.g., an access control device identifier). In response, the access control device 132 and / or the computing system 120 can send the context conditions to the computing device 102. In some examples, the computing system 120 can send the context conditions to the computing device 102 without a request (e.g., as part of the provisioning, coupling, or registration process for the computing device 102).

[0102] The computing device 102 can determine whether the context information satisfies the context conditions (708), for example, by comparing the context information with the context conditions, as described above. In response to determining that the context information satisfies the context conditions, the computing device 102 can prompt the user for confirmatory additional input (e.g., confirmation or authorization) (710). In some examples, the computing device 102 can issue a prompt via an output device 108 and receive the confirmatory additional input via an input device 106.

[0103] In response to receiving the confirmatory additional input, the computing device 102 can send an access request, including one or more access credentials and the context information (712), to the access control device 132. The computing device 102 may refrain from sending the access credential if the confirmatory additional input is not received from the user (for example, the user provides non-confirmatory additional input or ignores the prompt). The access control device 132 can receive the access request and grant or deny access to the controlled area 130, as described in conjunction with Fig. 6 described.

[0104] This revelation includes the following examples.

[0105] Example 1: A procedure involves receiving an access request, which includes one or more credentials and context information indicating one or more activities to be performed by a user of the computing device, by an access control device associated with an interlocking device for a controlled area, and by a computing device; determining whether the context information satisfies one or more context conditions, by the access control device; and determining whether the one or more credentials are valid, by the access control device.and in response to the determination that one or more access credentials are valid, and in response to the determination that the context information satisfies one or more context conditions, the access control device changes the state of the locking device.

[0106] Example 2: The procedure according to Example 1, where the context information includes one or more activity indicators.

[0107] Example 3: The method according to Example 2, wherein one or more activity indicators identify whether the user of the computing device is on foot or in a transport vehicle.

[0108] Example 4: The method according to Example 2, wherein the one or more activity indicators identify whether the user of the computing device is inside or outside the controlled area.

[0109] Example 5: The method according to any one of Examples 1-4, further comprising: receiving the one or more context conditions by the access control device during a provisioning process; and storing the one or more context conditions in a storage device of the access control device, wherein determining whether the context information satisfies the one or more context conditions includes: retrieving the one or more context conditions from the storage device; comparing at least one value from the context information with at least one value from the one or more context conditions by the access control device; and determining by the access control device that the context information satisfies the one or more context conditions if the at least one value from the context information matches the at least one value from the one or more context conditions.

[0110] Example 6: The method from any of Examples 1-5, wherein changing the state of the locking device includes changing the state of the locking device by the access control device to an unlocked state in response to validating one or more access credentials and determining that the context information satisfies one or more context conditions.

[0111] Example 7: The procedure according to any of Examples 1-6, further comprising: in response to a determination that one or more credentials are not valid, or in response to a determination that the context information does not satisfy one or more context conditions, without the access control device changing the state of the locking device.

[0112] Example 8: The procedure according to one of Examples 1-7, wherein: the context information includes a variable Door_Type and a variable User_Activity; the variable Door_Type includes a type of door associated with the locking device; and the variable User_Activity includes at least one type of user interaction.

[0113] Example 9: The procedure according to Example 8, wherein the variable Door_Type includes one or more of a pedestrian door, a garage door, a security door, a vault door, a turnstile, an automatic door, a revolving door, a sliding door, a gate and a roller door, and wherein the variable User_Activity includes one or more of walking, running, cycling, driving, riding, skating, dancing, jumping, on foot or in a transport vehicle.

[0114] Example 10: The procedure according to any of Examples 1-9, wherein determining whether the context information satisfies one or more context conditions comprises: sending a statement of the context information by the access control device to a remote computing system; and receiving a statement of whether the context information satisfies one or more context conditions by the access control device and from the remote computing system.

[0115] Example 11: The procedure from Example 10, wherein determining whether the context information satisfies the one or more context conditions further includes: sending a statement of the one or more context conditions by the access control device to the remote computing system.

[0116] Example 12: A method comprising: Receiving provisioning information for an access control device by a computing system, wherein the provisioning information includes a door type and one or more user activity types; storing the provisioning information by the computing system; and provisioning the access control device using the provisioning information by the computing system.

[0117] Example 13: A computing device includes a locking device for a controlled area; a memory that stores instructions; and a processing circuit that executes the instructions to: receive an access request from a computing device that includes one or more credentials and context information specifying one or more activities to be performed by a user of the computing device; determine whether the context information satisfies one or more context conditions; determine whether the one or more credentials are valid; and, in response to determining that the one or more credentials are valid and in response to determining that the context information satisfies the one or more context conditions, change a state of the locking device.

[0118] Example 14: The computing device according to Example 13, wherein the context information includes one or more activity indicators.

[0119] Example 15: The computing device from Example 14, wherein one or more activity indicators identify whether the user of the computing device is on foot or in a transport vehicle.

[0120] Example 16: The computing device from Example 14, wherein one or more activity indicators identify whether the user of the computing device is inside or outside the controlled area.

[0121] Example 17: The computing device according to any of Examples 13-16, wherein the processing circuit further executes the instructions to: receive the one or more context conditions during a provisioning process; and store the one or more context conditions in the memory, wherein the processing circuit determines whether the context information satisfies the one or more context conditions by at least executing the instructions to retrieve the one or more context conditions from the memory; compare at least one value from the context information with at least one value from the one or more context conditions; and determine that the context information satisfies the one or more context conditions if the at least one value from the context information matches the at least one value from the one or more context conditions.

[0122] Example 18: The computing device according to one of Examples 13-17, wherein, to change the state of the locking device, the processing circuit executes the instructions to change the state of the locking device to an unlocked state in response to validating the one or more credentials and determining that the context information satisfies the one or more context conditions.

[0123] Example 19: The computing device according to any of Examples 13-18, wherein the processing circuit executes the instructions to refrain from changing the state of the locking device in response to a determination that one or more credentials are invalid, or in response to a determination that the context information does not satisfy one or more context conditions.

[0124] Example 20: The computing device according to one of Examples 13-19, wherein: the context information includes a variable Door_Type and a variable User_Activity; the variable Door_Type includes a type of door associated with the locking device; and the variable User_Activity includes at least one type of user interaction.

[0125] Example 21: The computing device according to Example 20, wherein the variable Door_Type includes one or more of a pedestrian door, a garage door, a security door, a vault door, a turnstile, an automatic door, a revolving door, a sliding door, a gate and a roller door, and wherein the variable User_Activity includes one or more of walking, running, cycling, driving, riding, skating, dancing, jumping, on foot or in a transport vehicle.

[0126] Example 22: Computing device according to any of Examples 13-21, wherein the processing circuit determines whether the context information satisfies one or more context conditions by at least executing the instructions to send an indication of the context information to a remote computing system; and to receive an indication from the remote computing system as to whether the context information satisfies one or more context conditions.

[0127] Example 23: Computing device according to Example 22, wherein the processing circuit determines whether the context information satisfies the one or more context conditions by at least executing the instructions to send a specification of the one or more context conditions to a remote computing system.

[0128] Example 24: A non-transitory, computer-readable storage medium that stores instructions which, when executed by a processing circuit, cause the processing circuit to: receive an access request from a computing device that includes one or more credentials and context information specifying one or more activities to be performed by a user of the computing device; determine whether the context information satisfies one or more context conditions; determine whether the one or more credentials are valid; and, in response to determining that the one or more credentials are valid and in response to determining that the context information satisfies the one or more context conditions, change a state of the interlocking device.

[0129] Example 25: The non-transitory computer-readable storage medium from Example 24, wherein the context information includes one or more activity indicators.

[0130] Example 26: The non-transitory computer-readable storage medium of Example 25, wherein one or more activity indicators identify whether the user of the computing device is on foot or in a transport vehicle.

[0131] Example 27: The non-transitory computer-readable storage medium from Example 25, wherein one or more activity indicators identify whether the user of the computing device is inside or outside a controlled area.

[0132] Example 28: The non-transitory computer-readable storage medium according to any of Examples 24-27, wherein the processing circuit further executes the instructions to: receive the one or more context conditions during a provisioning process; and store the one or more context conditions in the memory, wherein the processing circuit determines whether the context information satisfies the one or more context conditions by at least executing the instructions to retrieve the one or more context conditions from the memory; compare at least one value from the context information with at least one value from the one or more context conditions; and determine that the context information satisfies the one or more context conditions if the at least one value from the context information matches the at least one value from the one or more context conditions.

[0133] Example 29: The non-transitory computer-readable storage medium according to any of Examples 24-28, wherein, to change the state of the locking device, the processing circuit executes the instructions to change the state of the locking device to an unlocked state in response to validating the one or more credentials and determining that the context information satisfies the one or more context conditions.

[0134] Example 30: The non-transitory computer-readable storage medium according to any of Examples 24-29, wherein the processing circuit executes the instructions to refrain from changing the state of the locking device in response to a determination that one or more credentials are invalid or in response to a determination that the context information does not satisfy one or more context conditions.

[0135] Example 31: The non-transitory computer-readable storage medium according to any of Examples 24-30, wherein: the context information includes a variable Door_Type and a variable User_Activity; the variable Door_Type includes a type of door associated with the locking device; and the variable User_Activity includes at least one type of user interaction.

[0136] Example 32: The non-transitory computer-readable storage medium according to Example 31, wherein the variable Door_Type includes one or more of a pedestrian door, garage door, security door, vault door, turnstile, automatic door, revolving door, sliding door, gate and roller door, and wherein the variable User_Activity includes one or more of walking, running, cycling, driving, riding, skating, dancing, jumping, on foot or in a transport vehicle.

[0137] Example 34: The non-transitory computer-readable storage medium according to any of Examples 24-33, wherein the processing circuit determines whether the context information satisfies one or more context conditions by at least executing the instructions to send an indication of the context information to a remote computing system; and to receive an indication from the remote computing system as to whether the context information satisfies one or more context conditions.

[0138] Example 35: The non-transitory computer-readable storage medium of Example 34, wherein the processing circuit determines whether the context information satisfies the one or more context conditions by executing at least the instructions to send a statement of the one or more context conditions to a remote computing system.

[0139] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted on a computer-readable medium as one or more instructions or as code and executed by a hardware-based processing unit. Computer-readable media may include a computer-readable storage medium corresponding to a tangible medium, such as a data storage medium, or a communication medium, which includes any medium that facilitates the transmission of a computer program from one location to another, for example, according to a communication protocol. In this way, computer-readable media can generally correspond to (1) a tangible, computer-readable storage medium that is non-transitory, or (2) a communication medium, such as a signal or carrier wave.Data storage media can be any available media that one or more computers or one or more processors can access to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product can include a computer-readable medium.

[0140] As an example, and not a limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other storage media that can be used to store the desired program code in the form of instructions or data structures and that a computer can access. Furthermore, any such connection is correctly referred to as a computer-readable medium.For example, if instructions from a website, server, or other remote source are transmitted using coaxial cable, fiber optic cable, twisted-pair cable, digital subscriber line (DSL), or wireless technology such as infrared, radio, and microwaves, then the coaxial cable, fiber optic cable, twisted-pair cable, DSL, or wireless technology such as infrared, radio, and microwaves are included in the definition of the medium. However, it is understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other volatile media, but instead refer to non-volatile, tangible storage media.In the sense used here, "disk" and "disc" include Compact Disc (CD), Laser Disc, Optical Disc, Digital Versatile Disc (DVD), floppy disk, and Blu-ray Disc, whereby "discs" typically reproduce data magnetically, while "discs" reproduce data optically using lasers. Combinations of the above are also included in the scope of computer-readable media.

[0141] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term "processor," as used here, can refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described in this document. Furthermore, some aspects of the functionality described in this document can be provided in dedicated hardware and / or software modules. Additionally, the techniques could be implemented entirely in one or more circuits or logic elements.

[0142] The techniques of this disclosure can be implemented in a wide variety of devices or equipment, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). This disclosure describes various components, modules, or units to highlight functional aspects of devices configured to perform the disclosed techniques, but does not necessarily require implementation by different hardware units. Rather, as described above, different units can be combined in a single hardware unit or provided by a collection of intraoperative hardware units, including one or more processors, as described above in conjunction with suitable software and / or firmware.

[0143] It should be noted that, depending on the embodiment, certain actions or events of one of the methods described herein may be performed in a different sequence, added, combined, or omitted entirely (i.e., not all described actions or events are necessary for the practical application of the method). Furthermore, in certain embodiments, actions or events may be performed concurrently, e.g., through multithreaded processing, interrupt handling, or multiple processors, rather than sequentially.

[0144] In some examples, a computer-readable storage medium includes a non-transitory medium. The term "non-transitory" means that the storage medium is not contained within a carrier wave or transmitted signal. In certain examples, a non-transitory storage medium can store data that may change over time (e.g., in RAM or cache).

[0145] Several examples have been described. These and other examples are within the scope of the following patent claims. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited non-patent literature

[0000] https: / / csa-iot.org / allsolutions / aliro /

[0075]

Claims

[1] Procedure, encompassing: Receiving an access request, which includes one or more credentials and contextual information indicating one or more activities performed by a user of the computing device, by an access control device associated with a locking device for a controlled area, and from a computing device; Determine whether the context information satisfies one or more context conditions, by the access control device; Determine whether one or more access credentials are valid, using the access control device; and In response to determining that one or more credentials are valid, and in response to determining that the context information satisfies one or more context conditions, the access control device changes the state of the locking device. [2] Method according to claim 1, wherein the context information includes one or more activity indicators. [3] Method according to claim 2, wherein one or more activity indicators identify whether the user of the computing device is on foot or in a vehicle. [4] Method according to claim 2, wherein one or more activity indicators identify whether the user of the computing device is inside or outside the controlled area. [5] Method according to any of the preceding claims, in particular claim 1, further comprising: Receipt of one or more context conditions by the access control device during a provisioning process; and Storing one or more context conditions in a storage device of the access control device, Determining whether the context information satisfies one or more context conditions involves the following: Retrieving one or more context conditions from the storage device; Comparing at least one value from the context information with at least one value from the one or more context conditions by the access control device; and Determine that the context information satisfies one or more context conditions, by the access control device, if at least one value from the context information matches at least one value from the one or more context conditions. [6] Method according to any of the preceding claims, in particular claim 1, wherein changing the state of the locking device comprises changing the state of the locking device by the access control device to an unlocked state in response to validating one or more access credentials and determining that the context information satisfies one or more context conditions. [7] Method according to any of the preceding claims, in particular claim 1, further comprising: In response to a determination that one or more credentials are invalid, or in response to a determination that the context information does not satisfy one or more context conditions, prevent the access control device from changing the state of the locking device. [8] Method according to any of the preceding claims, in particular claim 1, wherein: The context information includes a variable Door_Type and a variable User_Activity; The variable Door_Type contains a type of door that is associated with the locking device; and The variable User_Activity must include at least one type of user interaction. [9] Method according to claim 8, where the variable “Door_Type” includes one or more of a pedestrian door, a garage door, a security door, a vault door, a turnstile, an automatic door, a revolving door, a sliding door, a gate and a roller door and where the variable User_Activity includes one or more of walking, running, cycling, driving, riding, skating, dancing, jumping, on foot or in a transport vehicle. [10] A method according to any of the preceding claims, in particular claim 1, wherein determining whether the context information satisfies one or more context conditions comprises: Sending a statement of context information to a remote computing system via the access control device; and Receiving an indication of whether the context information satisfies one or more context conditions, by the access control device and from the remote computing system. [11] The method of claim 10, wherein determining whether the context information satisfies one or more context conditions further comprises: Sending a specification of one or more context conditions to the remote computing system by the access control device. [12] Procedures, including: Receiving provisioning information for an access control device by a computing system, wherein the provisioning information includes a door type and one or more user activity types; The computing system stores the deployment information; and Providing the access control information from the computer system to the access control device using the provisioning information. [13] Computing device comprising: a locking device for a controlled area; a memory that stores instructions; and a processing circuit that executes the instructions to: Receiving an access request from a computing device that includes one or more credentials and contextual information indicating one or more activities performed by a user of the computing device; Determine whether the context information satisfies one or more context conditions; whether the one or more credentials are valid; and In response to determining that one or more credentials are valid, and in response to determining that the context information satisfies one or more context conditions, a change in the state of the locking device. [14] Computing device according to claim 13, wherein the context information includes one or more activity indicators. [15] Computing device according to claim 13 or 14, wherein the processing circuit further executes the instructions to: Receiving one or more context conditions during a provisioning process; and Storing one or more context conditions in memory, wherein the processing circuit determines whether the context information satisfies one or more context conditions by executing at least the following instructions: Retrieving one or more context conditions from memory; Compare at least one value from the context information with at least one value from one or more context conditions; and Determine that the context information satisfies one or more context conditions if at least one value from the context information matches at least one value from the one or more context conditions. [16] Computing device according to claim 13, 14 or 15, wherein, to change the state of the locking device, the processing circuit executes the instructions to change the state of the locking device to an unlocked state in response to validating the one or more access credentials and determining that the context information satisfies the one or more context conditions. [17] Computing device according to claims 13 to 16, in particular claim 13, wherein: The context information includes a variable Door_Type and a variable User_Activity; The variable Door_Type contains a type of door that is associated with the locking device; and The variable User_Activity must include at least one type of user interaction. [18] Computing device according to claim 17, wherein the variable Door_Type includes one or more of a pedestrian door, a garage door, a security door, a vault door, a turnstile, an automatic door, a revolving door, a sliding door, a gate and a roller door, and wherein the variable User_Activity includes one or more of walking, running, cycling, driving, riding, skating, dancing, jumping, on foot or in a transport vehicle. [19] Computing device according to claims 13 to 18, in particular claim 13, wherein the processing circuit determines whether the context information satisfies one or more context conditions by executing at least the instructions to: Sending a statement of context information to a remote computing system; and Receiving information from the remote computing system indicating whether the context information meets one or more context conditions. [20] Non-transitory computer-readable storage medium which stores instructions which, when executed by a processing circuit of an access control device associated with an interlocking device for a controlled area, cause the processing circuit to: Receiving an access request from a computing device that includes one or more credentials and contextual information indicating one or more activities performed by a user of the computing device; Determine whether the context information satisfies one or more context conditions; whether the one or more credentials are valid; and In response to determining that one or more credentials are valid, and in response to determining that the context information satisfies one or more context conditions, a change in the state of the locking device.

Images