Intelligent configuration of unlock notifications

Abstract

A method for operating an access control system includes detecting one or more physical access portals using an application on a mobile device; displaying a notification for the one or more physical access portals on a display screen of the mobile device; receiving a selection of the physical access portal using a user interface of the mobile device; establishing a secure communication channel with a secure relay device associated with the selected physical access portal; transmitting an encrypted access token stored on the mobile device to the secure relay device; and the secure relay device granting access to the selected physical access portal in accordance with the encrypted access token.

Description

[Technical Field]

[0001] Embodiments illustrated and described herein generally relate to automatic identity authentication systems for authenticating users to access secure resources, and to secure messaging techniques for identity authentication systems. [Background Art]

[0002] Physical access control (PAC) systems grant physical access to authorized users via controlled portals. Access authorization typically involves cumbersome actions for the user, such as inserting or swiping an access card at a card reader, or entering a personal identification number (PIN) or password. PAC systems authenticate and authorize the passage of persons through physical access points such as secured doors. Improvements to PAC systems are described herein that feature innovative interactions between wireless technology, smartphones, secure access points, and cloud infrastructure. [Brief Description of the Drawings]

[0003] [Figure 1] FIG. 1 is a diagram illustrating an example of a portion of a secure access control system. [Figure 2] FIG. 2 is a flow diagram of an example method for operating an access control system. [Figure 3] FIG. 3 is a diagram illustrating an example of a display screen of a mobile device in a secure access control system. [Figure 4] FIG. 4 is a block diagram illustrating an example of a portion of a secure relay device. [Figure 5] FIG. 5 is a schematic block diagram of a portion of an example mobile device. [Mode for Carrying Out the Invention]

[0004] Figure 1 shows an access control system. The system includes a mobile device 105, a secure relay device 110, and a management server 115. Some examples of the mobile device 105 are a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch), a tablet computer, or any other portable computing device. The mobile device 105 stores access credential information that controls user access to the physical access portal 120 (e.g., a door). The secure relay device 110 grants access based on the access credential information provided by the mobile device 105. The secure relay device 110 controls actual physical access to the physical access portal 120 but is a relatively simple device that does not require access to a system backend server or system access control server. The secure relay device 110 is only required to receive information from the mobile device 105 using out-of-band (OOB) signaling 135 (e.g., Bluetooth Low Energy (BLE) signaling) that is different from the cellular network, and to initiate opening the physical access portal 120. The secure relay device 110 may transmit signals or other instructions to an auto-lock 125 that secures the physical access portal 120, or the auto-lock 125 may be integrated with the secure relay device 110.

[0005] As will be described in more detail herein, in order to gain access to the physical portal 120, the mobile device 105 identifies the physical portal using a beacon signal transmitted by the secure relay device 110. The mobile device 105 initiates secure communication with the secure relay device 110 and pushes an access token for the portal to the secure relay device 110. The secure relay device 110 checks the information in the access token to decide whether to grant access.

[0006] Figure 2 is a flowchart of an example of a method 200 for operating an access control system, such as the access control system shown in Figure 1. In block 205, one or more physical access portals 120 are detected using a verification application on a mobile device 105. The physical access portals 120 may be detected from low-energy beacon signals transmitted at the physical access portal, such as BLE beacon signals or other OOB signaling broadcast by a secure relay device 110. Each beacon signal may include the identification of the corresponding physical access portal 120 or secure relay device 110.

[0007] In block 210, a notification for one or more detected or identified physical access portals 120 is presented on the display screen of the mobile device 105, and in block 215, the selection of a physical access portal is received by the mobile device 105 via a user interface (e.g., a touch-sensitive display screen). Figure 3 shows an example of a displayed notification for a physical access portal (e.g., a door). On display screen 305, the notification is displayed while the mobile device 105 is locked for use. The user unlocks the device and enters a selection. In some examples, the mobile device 105 may accept the selection of a physical access portal while it is locked. On display screen 310, the notification is displayed after the user has unlocked the mobile device 105 for use.

[0008] Returning to Figure 2, the process then proceeds to user credential verification and device authentication. In block 220, a mutually authenticated secure channel is established between the mobile device 105 and the secure relay device 110 before the access credential information is sent to the secure relay device. Device authentication information is sent from the mobile device 105 to the secure relay device 110. The authentication information may include a certificate and a mobile device identifier (mobile device ID). The mobile device 105 may also authenticate the secure relay device. The secure relay device 110 may send authentication information (e.g., a certificate and relay ID) to the mobile device 105 that the mobile device 105 uses to authenticate the secure relay device 110.

[0009] In block 225, once device authentication is complete, the mobile device 105 transmits encrypted or otherwise encrypted access credentials to the secure relay device 110. Encryption in the access control system may be based on a public key infrastructure (PKI) and may use public key cryptography. In block 230, the secure relay device 110 decrypts the access credentials, checks the validity of the access credentials, and grants access to the physical access portal based on the access credentials. The secure relay device 110 may send signals or other instructions to the auto-lock 125 that secures the physical access portal 120. The mobile device 105 may indicate that the physical access portal 120 is open.

[0010] The functional blocks in Figure 2 do not need to be executed in the order shown. For example, the mobile device 105 may authenticate and establish a secure communication channel with the detected physical access portal (block 220) before the user enters their selection of a physical access portal (block 215). Then, secure communication with the secure relay device 110 of the physical access portal that was not selected is terminated.

[0011] As previously described herein, notifications of physical access portals detected by a mobile device are presented on the mobile device's display screen. When the user turns on the mobile device's display screen, a set of notifications is presented to the user on the lock screen (e.g., lock screen 305 in Figure 3). The user touches the displayed notification corresponding to the desired portal. In some examples, the operating system (OS) then presents an authentication screen (e.g., for providing biometric authentication or for entering a Personal Identification Number (PIN) code). The verification application is launched after the user has authenticated.

[0012] The verification application may use beacon ranging (e.g., iBeacon®) to detect nearby portals. Beacon ranging may be linked to the mobile device's "screen on" and "screen off" events. The "screen on" event may turn on beacon ranging for a predetermined period (e.g., 10 seconds). Beacon ranging may end when the screen is turned off. As a result of this beacon ranging, all portals within the signaling range will be displayed as notifications on the screen. Notifications may be presented for a limited period (e.g., 10 seconds). Each notification displays the portal's secure relay device ID. One potential problem when displaying notifications is that there may be many physical portals (e.g., doors) located close to each other near the mobile device. In this case, the user may be presented with an overwhelming number of notifications about portals.

[0013] One approach to address this problem is for the application to maintain a list of physical portals that are displayed as notifications. This list can be maintained by either the system administrator or the user. The application determines which physical access portals the user is allowed to access (e.g., a "whitelist") from the detected portals and displays only the whitelisted portals on the screen. The whitelist can be created and maintained by either the system administrator or the user. For example, in a scenario where a user enters a warehouse with numerous storage lockers, the user is only presented with notifications for the whitelisted storage lockers that the user is permitted to open. Storage lockers not on the whitelist are not presented to the user. Alternatively, a "blacklist" of portals that the user is not permitted to open is maintained, and these blacklisted portals are not included in notifications. In some examples, the user may define the whitelist or blacklist using the user interface for the verification application. In some examples, the whitelist or blacklist is provided as a policy by the management server.

[0014] Alternatively, the verification application determines the distance of the identified physical access portal 120 from the mobile device 105 (and therefore from the user) and presents notifications for detected physical access portals sorted by proximity to the user (e.g., closest first). Distance can be determined using the received beacon signal strength (e.g., Bluetooth Low Energy Relative Signal Strength Indicator (BLE RSSI)) or other radio signals indicating the user's distance, position, or movement relative to a reference point associated with the physical access portal (e.g., ultra-wideband (UWB) radio signals). In some examples, a recent history of signal strength readings (e.g., recent BLE RSSI patterns) is used to determine the order in which notifications are presented. When a physical access portal is detected, the most recently visited portals, based on the beacon signal, are presented first in the notifications displayed on the screen.

[0015] UWB is a wireless communication method that uses a wide signal bandwidth. Wide bandwidth is typically defined as either a -10 dB bandwidth greater than 20% of the signal's center frequency, or a bandwidth greater than 500 megahertz (500 MHz) in absolute terms. Commercial UWB systems are intended for use in complex environments such as residential, office, or industrial indoor areas. In these environments, signal reflection and diffraction play a significant role. The signal received by an antenna is the sum of attenuated, delayed, and potentially overlapping versions of the transmitted signal, and can change over time (due to the movement of the receiver / transmitter or changes in the environment). These different versions of the transmitted signal are typically called multipath components. The wide bandwidth of UWB systems provides a high level of immunity to frequency-selective fading, an effect that can limit the performance of narrowband technologies. The presence of UWB signaling transmitted by a UWB-enabled secure relay device 110, detected by a UWB-enabled mobile device 105, can be used to detect the presence of a user in the vicinity of a physical access portal 120.

[0016] The precise ranging capabilities of UWB signaling enable the determination of user intent (e.g., movement toward a physical access portal). This location-based user intent can be inferred from changes in distance between the UWB-enabled mobile device 105 and the UWB-enabled secure relay device 110, and from changes in angle between the mobile device 105 and the secure relay device 110. In some examples, the mobile device 105 may perform ranging using Time-of-Flight (TOF) Two-Way Ranging (TWR). In TWR, radio packets are exchanged between the mobile device 105 and the secure relay device 110. The timing difference for sending and receiving packets between the mobile device 105 and the secure relay device 110 can be used to calculate ranging information, such as changes in distance and / or angle, to determine the user's intent to gain access to the physical access portal 120. In some examples, the presence of a user at the physical access portal 120 is detected by the mobile device first detecting a BLE beacon transmitted by the secure relay device 110. After detection, the mobile device 105 engages the secure relay device 110 using UWB signaling, and the secure relay device 110 switches to UWB signaling so that the user's intent is determined using UWB signaling. This switch from BLE to UWB may be useful when it is not desired to constantly transmit UWB beacon signals, which can use more power than BLE signaling.

[0017] The detected physical access portals 120 may be sorted and displayed according to one or more of the following: the distance of the mobile device from the physical access portal, the position of the mobile device relative to the physical access portal, and the movement of the mobile device relative to the physical access portal. In a particular example, notifications for all detected physical access portals are displayed, and then the user's intent is determined to select some notifications. Examples of location-based intent techniques can be found in concurrently pending U.S. Patent Application No. 16 / 828,001, and concurrently pending Patent Cooperation Treaty (PCT) applications PCT / EP2020 / 058197, PCT / EP2020 / 076428, and PCT / EP2020 / 058199, PCT / EP2020 / 058216, each of which is incorporated herein by reference in its entirety.

[0018] In another example, one or more sensors (e.g., accelerometer, gyroscope) included in the mobile device 105 are used to determine one or more of the following: the distance of the mobile device 105 from the physical access portal 120, the position of the mobile device 105 relative to the physical access portal 120, and the movement of the mobile device 105 relative to the physical access portal 120. Notifications are then sorted and presented on the display screen according to one or more of the determined distance, position, and movement between the mobile device 105 and the user. Administrators or users can configure notification policies so that notifications for different portals are displayed based on the user's different detected distances from the portals.

[0019] In another example, the user defines a list of preferred physical access portals 120 that are listed first in the notifications presented on the display screen. The user's preferred list may be defined using a user interface for the verification application. In a further example, the verification application tracks the user's portal access history (e.g., by location and / or time) to order the most visited portals first in the presented notifications.

[0020] In any of these examples, notifications can be presented without sound or vibration, and the highest priority notification appears first. For mobile devices, different Android® models may incorporate different launchers, themes, and other user interface (UI) tweaks. In some examples, the lock screen may not be presented at all. Verification applications for Android devices may use "foreground services" to track nearby access portals.

[0021] Returning to Figure 1, the access credentials stored by the mobile device 105 can be one or more access tokens that indicate authorization for access to the physical portal 120. The access token is presented by the mobile device 105 to the secure relay device 110 to grant access to the portal when the user's authorization is confirmed by the mobile device 105. The access token proves that the mobile device has access rights. The access token may include one or more of the following: access token ID, mobile device ID, relay ID, optional additional access control information, start time for access, expiration time for access, and cryptographic signature. The access token ID is the unique identifier of the token. The mobile device ID and relay ID establish that this mobile device 105 can open the physical portal 120, which is secured by the secure relay device 110. Additional access control information may include additional access control rules (e.g., the time at which access is permitted). The start time and expiration time determine the validity period (e.g., one week) during which the access token is valid. The cryptographic signature is attached (taken over) to all fields of the access token and generated using the private key for the access token.

[0022] Access tokens are generated by the management server 115 and periodically pushed to mobile devices 105 that have the corresponding mobile device ID. The management server 115 also maintains an access revocation list for each secure relay device 110. Each list contains access token IDs that are currently invalid for the secure relay device 110. When a new revocation list becomes available, the management server pushes the new revocation list to all mobile devices 105 that currently have access to the secure relay device 110.

[0023] To verify a mobile device holder's access to a specific secure relay device 110, the secure relay device 110 may check additional access information such as the signature, mobile device ID, start time and expiration time, and access token, to determine whether the physical portal 120 should be opened. The secure relay device 110 may also check an access revocation list it maintains for access tokens and deny access if the access token is included in the list.

[0024] The mobile device 105 may be online to perform the described verification and authentication functions, but is not required to be online, and may perform the functions offline. The mobile device 105 may occasionally connect to a network (e.g., the Internet or a cellular telephone network) to receive updated access credentials pushed from the management server 115. In addition, the verification application may periodically initiate transmission of a status request (e.g., an Online Certificate Status Protocol (OCSP) request) to the management server 115 or another verification device regarding the user's access credentials, and receive and store a response to the request (e.g., an OCSP response). As part of the authentication process, the mobile device 105 may push the response to the secure relay device 110 as part of the access credentials. The secure relay device 110 checks the response, and closes the connection if the response is not valid.

[0025] When the mobile device 105 is introduced into the access control system, the mobile device 105 is personalized by the verification application and the management server 115. The mobile device 105 establishes a secure connection with the management server 115, and authenticates the user by providing a password, an invitation code, and the like. The verification application generates a key pair that is transmitted to the management server 115. The management server 115 issues a certificate for the public key of the key pair, and issues a mobile device ID rooted in the certificate. This personalization information is then transmitted to the mobile device 105. The personalization information includes CA certificates for the mobile device 105 and the secure relay device 110. The mobile device also receives the latest access tokens and revocation list, and stores them in long-term memory. A status request (e.g., an OCSP request) may be transmitted as part of the personalization.

[0026] Personalization information such as cryptographic key material may be stored in a secure element (SE: secure element) or a secure enclave of the mobile device 105. The SE may include a secure processor or a coprocessor including a key manager. Communication between the SE and an application processor is strictly controlled, for example, by separating communication into an interrupt-driven mailbox. In some examples, the information is included in a trusted execution environment (TEE: trusted execution environment) of the mobile device 105. The information may be periodically updated by being pushed to the mobile device 105 by the management server 115. Also, the information stored in the SE may include a current response to a request transmitted to the management server 115, and a certificate from a certificate authority (CA certificate).

[0027] The access control provided to the mobile device 105 normally operates within the boundaries of an application executed on the mobile device 105. The access permission technique of FIG. 2 may be made more efficient by including access control logic in the notification itself. A mobile device running iOS (registered trademark) may have program code included in the notification itself that can be executed without opening the application. This program code may be activated like the "widget" function of an iOS mobile device.

[0028] Instead of clicking on a notification on the display screen, the user "long-presses" the notification on the display screen while the mobile device 105 is locked. The display screen 315 in Figure 3 shows an example of this type of notification. The mobile device 105 detects contact with the notification or icon displayed on the locked display screen corresponding to the physical access portal and detects that the contact with the icon is held for longer than a specified duration (i.e., a long press). The program code accompanying the notification is activated in response to the long press, and the verification and authentication process immediately begins. The notification presents a small user interface that allows tracking of the access status. This technique is more efficient because it does not require unlocking the mobile device 105 or opening the main application on the mobile device 105. The "long-press" method is effective when biometric authentication or PIN code authentication is not required to open the physical portal. In some examples, the portal notification is presented on the display screen after the mobile device 105 is unlocked. In certain examples, the operating system presents an authentication screen when the notification is long-pressed, and in certain examples, authentication is performed without presenting an authentication screen. Multiple long-press notifications may be displayed for multiple detected secure relay devices 110 or physical access portals 120.

[0029] Figure 4 is a block diagram of an example of a secure relay device 410 in an access control system, such as the access control system in Figure 1. The device includes a physical layer circuit 440 and a processing circuit. The processing circuit may include a microprocessor or microcontroller 445 and may include a separate processing circuit 442 for transmitting beacon signals. The secure relay device may include a memory separate from or integrated with the microcontroller 445, which contains executable instructions for performing any of the functions or operations of the secure relay device described herein, such as the method described in Figure 2. The processing circuit is responsible for OOB signaling (e.g., BLE communication), personalization of the secure relay device 410, processing of commands received from the mobile device 105, storage of revocation lists and personalization parameters, and implementation of transport layer security (TLS) functions.

[0030] The physical layer circuit 440 transmits and receives information wirelessly. The physical layer circuit 440 may broadcast a beacon signal readable by the mobile device 105 to identify the secure relay device 410, or the physical layer circuit 440 may include a separate circuit (beacon module 442) to provide beacon functionality. The beacon signal may be a BLE signal, and the secure relay device may function as a BLE central device for communicating with the mobile device 105 as a peripheral device. The beacon module 442 may function as an iBeacon device. The beacon module 442 may include a separate processor used for beacon functionality. The beacon module 442 may be connected to the main microcontroller 445 using the I2C (inter-integrated circuit) protocol. At startup, the main microcontroller 445 sends the relay ID that the beacon should advertise to the beacon module 442. The beacon module 442 stores the relay ID in the major version field and minor version field of the advertised data and starts advertising the relay ID using OOB signaling.

[0031] As previously described herein, the secure relay device 410 authenticates the mobile device 105 and provides authentication information to the mobile device 105. The processing circuit may implement transport layer security or TLS (e.g., TLS 1.2). As described herein, key material may be stored in the secure element of the secure relay device. If out-of-band signaling is BLE, first all incoming BLE data is transferred using the TLS handshake procedure and responses are sent back using BLE. During the TLS handshake, the mobile ID is extracted (e.g., from the serial number of the peer certificate) and used throughout the session. Once the handshake is complete, all BLE traffic is first TLS unwrapped. When a complete TLS frame is received, the commands stored in the frame are processed by the processing circuit, the responses to the commands are wrapped, and sent to the mobile device. In case of BLE disconnection or general error, the TLS handshake is reset and the handshake must be completed again. The processing circuit of the secure relay device 410 decrypts the authentication information received from the mobile device 105 and encodes that authentication information for transmission to the mobile device 105. Once the device is authenticated, the secure relay device 410 receives encrypted access information from the mobile device 105, and the processing circuit decrypts the access information to grant or deny access to the user. The relay circuit 455 is activated when access is granted, and the relay circuit can cause the physical access portal 120 to be automatically unlocked.

[0032] The secure relay device 410 can open the physical access portal 120 in response to an "open" command received from the mobile device 105 along with a valid access token. In response to the open command, the secure relay device 410 may perform the following sequence: It checks that the "Push OCSP data" command was successfully executed within the current TLS session, parses the access token supplied in the open command, checks the signature and validity of the access token, verifies that the access token is not included in the revocation list, and if the access token is valid and not in the revocation list, it opens the physical portal. "Push OCSP data" is a response to a valid OCSP response received from the mobile device 105 and includes the following sequence: The secure relay device 410 parses the OCSP response, checks the OCSP response signature and validity of the OCSP response, and if the OCSP response is valid, sends the revocation list information back to the mobile device 105.

[0033] The secure relay device 410 may receive a revocation list when the verification application on the mobile device executes the "Push revocation list" command. The secure relay device 410 checks whether the "Push OCSP data" command has been executed within the current TLS session. If the command has been executed, the secure relay device 410 parses the revocation list and checks its signature and validity. If the revocation list currently stored by the secure relay device 410 is an older version, the secure relay device 410 stores the later pushed version of the revocation list.

[0034] The secure relay device 410 may include a secure element 450 for storing one or more cryptographic keys used for the operation of the secure relay device. The secure element 450 may store one or more of the following: the relay secret key, the relay certificate, the relay ID, the mobile device's CA certificate, and the public key of the mobile device's certificate response. Access information may include an access token, and the secure element 450 may store the secret key of the access token for decrypting the access token. The secure relay device 410 may also store an access revocation list. As previously described herein, the secure element may include a secure processor or coprocessor, including a key manager. In some examples, the secure element performs cryptographic processing. The secure element may communicate with the main microcontroller 445 using I2C.

[0035] Returning to Figure 1, the management server 115 can be implemented as a set of command-line scripts (e.g., Python scripts) and may include a graphical user interface (GUI). The set of command-line scripts may include a server initialization script, an access token generation script, an expiration list generation script, a secure relay device personalization script, an NFC tag personalization script, and a mobile device provisioning script.

[0036] Server initialization generates keys, certificates, and file system settings and may include the following sequence: a CA key pair and certificate are generated for the mobile device 105, a CA key pair and certificate are generated for the secure relay device 110, a tag CA key pair and certificate are generated, an access token signing key pair is generated, and a revocation list signing key pair is generated. These key pairs and certificates are generated for each physical access portal 120. Furthermore, OCSP responses are signed by the mobile device's CA key pair.

[0037] The management server 115 may generate an access token by providing the mobile device ID, relay ID, start time, and end time to the access token generation script. The script uses the provided information to create an access token, signs the access token using the access token signing secret key, and writes the new access token to the server database. The script may maintain the current access token ID in the database and increment the access token ID for each access token generated.

[0038] The management server 115 may generate a revocation list by providing the relay ID and access token ID to the revocation list generation script. The script uses this information to create the revocation list, signs the revocation list using the revocation list public key, and writes the new revocation list to the server database. The revocation list generation script maintains a revocation list for each secure relay device 110 and may increment the version of the revocation list each time a new revocation list is generated for a secure relay device 110.

[0039] The personalization script for the secure relay device receives the relay ID as input and executes the following sequence: The current time and relay ID are sent to the secure relay device. The mobile device certificate, access token public key, OCSP key, and revoked public key are sent to the secure relay device. The script triggers key pair generation on the secure relay device. The management server 115 receives the public key of the key pair, sends the CA certificate to the secure relay device, and stores the certificate in the server database. The secure relay device 110 can be personalized using the NFC interface of the secure relay device 110.

[0040] The NFC tag personalization script receives the NFC tag ID as input and executes the following sequence: The script sends the tag ID to the NFC tag and triggers key pair generation. The management server 115 receives the public key of the key pair, sends the CA certificate to the NFC tag, and stores the certificate in the server database.

[0041] Conventional physical access control systems include a credential device that holds user access credentials, a reader device that checks the credentials, and a controller device that grants physical access. The credential device stores the access credentials presented to the reader device, which receives and authenticates the access credentials. If the reader device grants access, it may send a notification (e.g., a signal or message) to the access controller to open the physical access portal. The reader device and the access controller can be integrated into a single device. The reader device and the access controller can communicate with a backend system (e.g., a backend server) of the access control system. Access credentials are authenticated by the authentication engine of the backend system. The systems, devices, and methods described herein provide a secure access control system in which the roles of the reader device, access controller device, and backend server are performed by a mobile device 105 and a secure relay device 110. A securely authenticated connection is established between the secure relay device 1101 and the mobile device 105, and access credentials are securely transferred between the mobile device 105 and the secure relay device 110 using one of several methods described herein. This transfer may occur while the secure relay device 110 and the mobile device 105 are offline from the access control system backend. The mobile device 105 then re-provides updated information (e.g., revocation list) to the secure relay device 110 while the device is offline from the backend system. In this way, each of the mobile device 105 and the secure relay device 110 performs part of the role of the backend system of a conventional access control system. This reduces the complexity of verifying and granting access to physical portals, thereby reducing the complexity of one or more devices required for each physical access portal (e.g., each door).

[0042] Figure 5 is a schematic block diagram of various exemplary components of device 500 to support the device architecture described and illustrated herein. Device 500 in Figure 5 may be, for example, a mobile device (e.g., mobile device 105 in Figure 1) that authenticates credentials for the authority, status, rights, and / or privileges of the device owner. Device 500 holds the user's access credentials and runs a verification application that authenticates the access credentials.

[0043] Referring particularly to Figure 5, additional examples of devices 500 to support the device architecture described and illustrated herein may generally include one or more of the following: memory 502, processing circuits such as a processor 504, one or more antennas 506, a communication port or communication module 508, a network interface device 510, a user interface 512, and a power supply 514 or power supply unit.

[0044] Memory 502 may be used for the temporary or long-term storage of program instructions or instruction sets 516 and / or authorization data 518, such as credential data, credential authorization data, or access control data or instructions, in connection with application programming or instruction execution by the processing circuit, as well as any data, data structures, and / or computer executable instructions required or desired to support the device architecture described above. For example, memory 502 may include executable instructions 516 used by the processor 504 of the processing circuit to compute an encryption key for communicating credential or authorization data 518, and / or to perform any of the functions or operations described herein, such as a function as an operation of a mobile device as described with respect to the method in Figure 2. Memory 502 may include a computer-readable medium, which may be any medium that can contain, store, communicate, or carry instructions for use by or in connection with device 500, such as data, program code, or instructions for verification applications. Memory may include memory contained within the secure element of a mobile device. Computer-readable media may, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices. More specific examples of suitable computer-readable media include, but are not limited to, electrical connections having one or more wires, or tangible storage media such as portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), dynamic RAM (DRAM), any solid-state storage device, generally compact disc read-only memory (CD-ROM), or other optical or magnetic storage devices.Computer-readable media includes computer-readable storage media, but should not be confused with computer-readable storage media, and computer-readable storage media is intended to cover all physical, non-temporary, or similar embodiments of computer-readable media.

[0045] The processing circuit of device 500 is configured (for example, by firmware) to perform the functions of the mobile device described herein. These functions include, for example, the functions of the exemplary method shown in Figure 2. The processing circuit can correspond to one or more computer processing devices or resources. For example, the processor 504 may be provided as silicon, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), any other type of integrated circuit (IC) chip, a collection of IC chips, etc. More specifically, the processor 504 may be provided as a microprocessor, a central processing unit (CPU), or multiple microprocessors or CPUs configured to execute instruction sets stored in internal memory 520 and / or memory 502. The processing circuit may include a processor within the secure element of the mobile device.

[0046] Antenna 506 may be compatible with one or more antennas and may be configured to provide wireless communication between device 500 and another device. Antenna 506 may be operably coupled to a physical layer circuit having one or more physical (PHY) layers 524 to operate using one or more wireless communication protocols and operating frequencies, including but not limited to IEEE 802.15.1, Bluetooth®, Bluetooth Low Energy (BLE), Near Field Communications (NFC), ZigBee®, GSM®, CDMA, Wi-Fi, RF, UWB, etc. For example, antenna 506 may include one or more antennas coupled to one or more physical layers 524 to operate using ultra-wideband (UWB) for in-band activity / communication and Bluetooth® (e.g., BLE) for out-of-band (OOB) activity / communication. However, any RFID or personal area network (PAN) technology, such as IEEE 502.15.1, Near Field Communication (NFC), ZigBee, GSM, CDMA, or Wi-Fi, may be used alternatively or additionally for the OOB activities / communications described herein.

[0047] Device 500 may further include a communication module 508 and / or a network interface device 510. The communication module 508 can be configured to communicate with one or more different systems or devices, remote or local to Device 500, according to any suitable communication protocol. The network interface device 510 includes hardware to enable communication with other devices on a communication network using one of several transport protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Exemplary communication networks may include, among others, local area networks (LANs), wide area networks (WANs), packet data networks (e.g., the Internet), mobile phone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, wireless data networks (e.g., the IEEE 802.11 standard family known as Wi-Fi, the IEEE 802.16 standard family known as WiMAX), the IEEE 802.15.4 standard family, and peer-to-peer (P2P) networks. In some examples, the network interface device 510 may include Ethernet® ports or other physical jacks, Wi-Fi cards, network interface cards (NICs), cellular interfaces (e.g., antennas, filters, and associated circuitry), etc.In some examples, the network interface device 510 may include multiple antennas for wireless communication using at least one of the following techniques: single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO). In some exemplary embodiments, one or more of the antennas 506, the communication module 508, and / or the network interface device 510 or its subcomponents may be integrated as a single module or device, and may function or operate as if they were a single module or device, or may have elements shared among them.

[0048] The user interface 512 may include one or more input devices and / or display devices. Suitable user input devices that may be included in the user interface 512 include, but are not limited to, one or more buttons, a keyboard, a mouse, a touch-sensitive surface, a stylus, a camera, a microphone, etc. Suitable user output devices that may be included in the user interface 512 include, but are not limited to, one or more LEDs, an LCD panel, a display screen, a touch screen, one or more lights, a speaker, etc. It should also be understood that the user interface 512 may include a combination of user input and user output devices, such as a touch-sensitive display.

[0049] The power supply 514 can be any suitable internal power supply, such as a battery, a capacitive power supply, or a similar type of charge storage device, and / or may include one or more power conversion circuits suitable for converting external power into power suitable for the components of device 500 (e.g., converting externally supplied AC power to DC power). Device 500 may also include one or more interlinks or buses 522 capable of transmitting communication between the various hardware components of the device. The system bus 522 may be one of several commercially available types of bus structures or bus architectures.

[0050] Further disclosures and examples Example 1 includes a subject (such as how to operate an access control system) that involves using a mobile device application to discover one or more physical access portals, receiving a selection of a physical access portal using the mobile device's user interface, establishing a secure communication channel with a secure relay device associated with the selected physical access portal, sending an encrypted access token stored on the mobile device to the secure relay device, and the secure relay device granting access to the selected physical access portal according to the encrypted access token.

[0051] In Example 2, the subject of Example 1 optionally includes displaying a notification on the screen after the user has unlocked the mobile device for use. In Example 3, the subject of Example 1 optionally includes displaying a notification on the display screen while the mobile device is locked, and accepting the selection of a physical access portal while the mobile device is locked.

[0052] In Example 4, the subject of Example 3 optionally includes detecting contact with an icon displayed on a locked display screen corresponding to a physical access portal, and detecting that contact with the icon is held for longer than a specified duration.

[0053] In Example 5, the subject of one or any combination of Examples 1-4 optionally includes determining which of the one or more discovered physical access portals a user can access based on access credentials, and displaying notifications only for the one or more discovered physical access portals that the user can access according to the access credentials.

[0054] In Example 6, the subject of Example 5 optionally includes comparing the identifiers of one or more detected physical access portals with a stored list of physical access portals that the mobile device user is permitted to access, and displaying notifications for one or more detected physical access portals included in the list.

[0055] In Example 7, the subject of Example 6 optionally includes storing a list of physical access portals that the user is permitted to access, and the list is user-defined. In Example 8, the subject of Example 6 optionally includes storing a list of physical access portals that users are permitted to access, and the list is administrator-defined.

[0056] In Example 9, the subject of one or any combination of Examples 1-8 optionally includes the application determining the distance to a user for multiple detected physical access portals, and displaying notifications for multiple detected physical access portals sorted in an order determined by their proximity to the user.

[0057] In Example 10, the subject of Example 9 optionally includes determining the distance using the received beacon signal strength. In Example 11, the subject of Example 10 optionally includes determining the distance using a Bluetooth® Low Energy Relative Signal Strength Indicator (BLE RSSI).

[0058] In Example 12, the subject matter of one or any combination of Examples 1-11 optionally includes the application determining one or more of the distance, location, and movement of a mobile device to a plurality of detected physical access portals, and sorting and displaying notifications for the plurality of detected physical access portals according to one or more of the determined distance, location, and movement of the mobile device.

[0059] In Example 13, the subject of Example 12 optionally includes using ultra-wideband (UWB) signaling to determine one or more of the distance, location, and movement of a mobile device to multiple detected physical access portals.

[0060] In Example 14, the subject of Example 12 optionally includes using one or more sensors included in the mobile device to determine one or more of the distance, position, and movement of the mobile device to a plurality of detected physical access portals.

[0061] In Example 15, the subject of one or any combination of Examples 1-14 optionally includes comparing one or more detected physical access portals to a list of unauthorized physical access portals stored in the mobile device's memory, and not displaying notifications for detected physical access portals included in the list.

[0062] In Example 16, the subject of one or any combination of Examples 1-14 optionally includes comparing one or more detected physical access portals with a user-defined list of unauthorized physical access portals and an administrator-defined list of unauthorized physical access portals stored in the mobile device's memory, and not displaying notifications for detected physical access portals included in the user-defined list and the administrator-defined list.

[0063] In Example 17, the subject of one or any combination of Examples 1-16 optionally includes using a mobile device application to detect beacons from a secure relay device of at least one of one or more physical access portals.

[0064] In Example 18, the subject of Example 17 optionally includes detecting Bluetooth® low-energy beacon signals or ultra-wideband beacon signals transmitted by a secure relay device.

[0065] In Example 19, the subject matter of one or any combination of Examples 1-18 optionally includes the secure relay device comparing an access token to an invalid access token revocation list and granting access to the physical access portal according to the comparison.

[0066] In Example 20, the subject of one or any combination of Examples 1-19 optionally includes a mobile device verification application initiating a status request to a verification device regarding the mobile device user's access credentials, receiving a response to the request, and including the response to the request in the access credentials.

[0067] In Example 21, the subject of one or any combination of Examples 1-20 optionally includes tracking the history of user access to physical access portals and displaying notifications for one or more detected physical access portals in the order determined by the user access history.

[0068] Example 22 includes a subject (such as a secure relay device in an access control system) comprising a physical layer circuit and a processing circuit operably coupled to the physical layer circuit, or can be optionally combined with one or any combination of Examples 1 to 21 to include such a subject. The physical layer circuit is configured to transmit a beacon signal containing information identifying a physical access portal and to receive the information wirelessly. The processing circuit is configured to decrypt a first set of credentials received wirelessly from a mobile device, encode a second set of credentials for transmission to the mobile device, decrypt the access credentials received from the mobile device in response to the transmission of the second set of credentials, and grant access to the physical access portal according to the decrypted access credentials.

[0069] In Example 23, the subject of Example 22 optionally includes a first processing circuit configured to encode information identifying a physical access portal and initiate transmission of a beacon signal, and a second processing circuit configured to decode the first authentication information.

[0070] Example 24 includes a subject comprising a machine-readable storage medium containing instructions that cause a mobile device to perform actions including, when executed by the mobile device's processing circuitry, detecting one or more physical access portals for which access is controlled; displaying a notification for one or more physical access portals on the mobile device's display screen; receiving a selection of a physical access portal using the mobile device's user interface; establishing a secure communication channel with a secure relay device associated with the physical access portals; and transmitting an encrypted access token stored on the mobile device to the secure relay device (or may be optionally combined with one or any combination of Examples 1-23 to include such a subject).

[0071] In Example 25, the subject of Example 24 optionally includes a machine-readable storage medium containing instructions that cause the mobile device to perform an action, which includes displaying a notification on the display screen after the user has unlocked the mobile device for use.

[0072] In Example 26, the subject of Example 24 optionally includes a machine-readable storage medium containing instructions that cause the mobile device to perform actions including displaying a notification on the display screen while the mobile device is locked, and accepting a selection of a physical access portal while the mobile device is locked.

[0073] In Example 27, the subject of Example 26 optionally includes a machine-readable storage medium containing instructions causing a mobile device to perform an action which includes detecting contact with an icon on a locked display screen, where the icon is a notification of one of one or more physical access portals, and detecting that contact with the icon is held for longer than a specified duration as a selection of the physical access portal.

[0074] In Example 28, the subject of one or any combination of Examples 24-27 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform actions including determining which of one or more discovered physical access portals a user can access based on information contained in an access token, and displaying notifications only for the one or more discovered physical access portals that the user can access, according to the information.

[0075] In Example 29, the subject of Example 28 optionally includes a machine-readable storage medium containing instructions that cause the mobile device to perform actions including comparing the identifier of a detected physical access portal with a stored list of physical access portals that the user of the mobile device is permitted to access, and displaying a notification for one or more detected physical access portals included in the list.

[0076] In Example 30, the subject of Example 29 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform an action that includes storing a list of physical access portals to which the user is permitted access, and the list is user-defined.

[0077] In Example 31, the subject of Example 29 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform an action that includes storing a list of physical access portals to which the user is permitted access, and the list is administrator-defined.

[0078] In Example 32, the subject of one or any combination of Examples 24-31 optionally includes a machine-readable storage medium containing instructions that cause the mobile device to perform actions including determining the distance to one or more detected physical access portals from the mobile device, and displaying notifications for one or more detected physical access portals in an order determined by their proximity to the mobile device.

[0079] In Example 33, the subject of Example 32 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform an action that includes determining distance using the received beacon signal strength.

[0080] In Example 34, the subject of Example 32 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform an action including determining distance using a Bluetooth® Low Energy Relative Signal Strength Indicator (BLE RSSI).

[0081] In Example 35, the subject of one or any combination of Examples 24-34 optionally includes a machine-readable storage medium containing instructions that cause the mobile device to perform actions including determining one or more of the distance, location, and movement of the mobile device to a plurality of detected physical access portals, and sorting and displaying notifications for the plurality of detected physical access portals according to one or more of the determined distance, location, and movement of the mobile device.

[0082] In Example 36, the subject of Example 35 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform an action which includes determining one or more of the distance, location, and movement of the mobile device to a plurality of detected physical access portals using ultra-wideband (UWB) signaling.

[0083] In Example 37, the subject of Example 35 optionally includes a machine-readable storage medium containing instructions causing the mobile device to perform an action that includes determining one or more of the distance, position, and movement of the mobile device to a plurality of detected physical access portals using one or more sensors contained in the mobile device.

[0084] In Example 38, the subject of one or any combination of Examples 24-37 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform an action that includes decoding information identifying a physical access portal received in a beacon signal.

[0085] In Example 39, the subject of one or any combination of Examples 24-38 optionally includes a machine-readable storage medium containing instructions that cause a mobile device to perform actions including tracking the history of user access to physical access portals and displaying notifications for one or more detected physical access portals in an order determined by the user access history.

[0086] Example 40 includes, or may be optionally combined with, one or any combination of Examples 1-39 to include, a subject (such as how to operate an access control system) that includes using a mobile device application to discover one or more physical access portals, establishing a secure communication channel with a secure relay device associated with one or more discovered physical access portals, displaying a notification for one or more physical access portals on the mobile device's display screen, receiving a selection of a physical access portal using the mobile device's user interface, sending an encrypted access token stored on the mobile device to the secure relay device, and the secure relay device granting access to the selected physical access portal according to the encrypted access token.

[0087] In Example 41, the subject of Example 40 optionally includes the application determining one or more of the distance, location, and movement of a mobile device to a plurality of detected physical access portals, and sorting and displaying notifications for the plurality of detected physical access portals according to one or more of the determined distance, location, and movement of the mobile device.

[0088] In Example 42, the subject matter of either or both of Examples 40 and 41 optionally includes comparing the identifier of one or more discovered physical access portals with a stored list of physical access portals, and displaying a notification for one or more discovered physical access portals that the user of the mobile device is permitted to access based on the stored list.

[0089] These non-limiting examples can be combined in any permutation or combination. The above detailed description includes references to accompanying drawings that form part of the detailed description. The drawings illustrate specific embodiments in which the invention can be carried out. The above description is intended to be illustrative and not limiting. For example, the above examples (or one or more of them) can be used in combination with each other. Other embodiments can be used, for example, by a person skilled in the art who has considered the above description. The abstract is provided for the purpose of enabling the reader to quickly review the contents of the technical disclosure. The abstract is submitted with the understanding that it is not to be used to interpret or limit the claims or their meaning. In the above detailed description, various features can be grouped together for the sake of simplification of the disclosure. This should not be interpreted as meaning that any disclosed features not claimed are essential to any claim. Rather, subject matter may reside in fewer features than all of the features of a particular disclosed embodiment. Accordingly, the following claims are incorporated into the detailed description herein, with each claim standing independently as a separate embodiment, and such embodiments are intended to be combined with each other in various combinations or substitutions. The scope should be determined with reference to the attached claims, along with the entire scope of equivalents to which such claims are granted. The technical concepts that can be understood from the above embodiments are described below as an addendum. [Note 1] A method for operating an access control system, The steps include: discovering one or more physical access portals using a mobile device application; The steps include displaying a notification for one or more physical access portals on the display screen of the mobile device, The steps include receiving a selection of a physical access portal using the user interface of the mobile device, The steps include establishing a secure communication channel with a secure relay device associated with the selected physical access portal, The steps include: transmitting the encrypted access token stored on the mobile device to the secure relay device; A method comprising the step of the secure relay device granting access to the selected physical access portal in accordance with the encrypted access token. [Note 2] The method according to Appendix 1, wherein the step of displaying the notification includes displaying the notification on the display screen after the user has unlocked the mobile device for use. [Note 3] The step of displaying the aforementioned notice is: Displaying the notification on the display screen while the mobile device is locked. The method according to Appendix 1 or 2, which includes accepting the selection of the physical access portal while the use of the mobile device is locked. [Note 4] The method according to Appendix 3, wherein the step of receiving the selection of the physical access portal includes detecting contact with an icon displayed on the locked display screen corresponding to the physical access portal, and detecting that the contact with the icon is held for a longer duration than specified. [Note 5] The step of displaying the aforementioned notice is: Based on the stored access token, determine which of the one or more detected physical access portals the user can access. The method according to any one of the appendices 1 to 4, comprising displaying only notifications for one or more detected physical access portals that the user can access in accordance with the stored access token. [Note 6] The method according to Appendix 5, comprising comparing the identifier of one or more detected physical access portals with a stored list of physical access portals to which the user of the mobile device is permitted to access, and displaying a notification for one or more detected physical access portals included in the list. [Note 7] The method according to Appendix 6, comprising storing the list of physical access portals to which a user is permitted access, wherein the list is user-defined. [Note 8] The method according to Appendix 6 or 7, comprising storing the aforementioned list of physical access portals to which users are permitted access, wherein the aforementioned list is administrator-defined. [Note 9] The step of displaying the aforementioned notice is: The application determines the distance to the users of multiple detected physical access portals. The method according to any one of the appendices 1 to 8, comprising sorting and displaying notifications for the plurality of detected physical access portals in an order determined by their proximity to the user. [Note 10] The method according to Appendix 9, wherein determining the distance includes determining the distance using the received beacon signal strength. [Note 11] The method according to Appendix 10, wherein determining the distance using the received beacon signal strength includes determining the distance using a Bluetooth® Low Energy Relative Signal Strength Indicator (BLE RSSI). [Note 12] The step of displaying the aforementioned notice is: The application determines one or more of the distance, location, and movement of the mobile device relative to a plurality of detected physical access portals. The method according to any one of Annexes 1 to 11, comprising sorting and displaying notifications for the plurality of detected physical access portals according to one or more of the determined distance, location, and movement of the mobile device. [Note 13] The method according to Appendix 12, wherein determining one or more of the distance, location, and movement of the mobile device includes using ultra-wideband (UWB) signaling to determine one or more of the distance, location, and movement of the mobile device relative to the plurality of detected physical access portals. [Note 14] The method according to Appendix 12 or 13, wherein one or more of the distance, position, and movement of the mobile device to the plurality of detected physical access portals is determined using one or more sensors included in the mobile device that determine one or more of the distance, position, and movement of the mobile device to the plurality of detected physical access portals. [Note 15] The step of displaying the aforementioned notice is: Comparing one or more detected physical access portals with a list of unauthorized physical access portals stored in the mobile device's memory, The method described in any one of the appendices 1 to 14, including not displaying notifications for detected physical access portals included in the aforementioned list. [Note 16] The step of displaying the aforementioned notice is: The one or more detected physical access portals are compared with a user-defined list of unauthorized physical access portals and an administrator-defined list of unauthorized physical access portals stored in the mobile device's memory. The method according to any one of the appendices 1 to 15, including not displaying notifications for detected physical access portals included in the user-defined list and the administrator-defined list. [Note 17] The method according to any one of the appendices 1 to 16, wherein the step of detecting one or more physical access portals includes using the application on the mobile device to detect a beacon signal from a secure relay device associated with at least one of the one or more physical access portals. [Note 18] The method according to Appendix 17, wherein detecting the beacon signal includes detecting a Bluetooth® low-energy beacon signal or an ultra-wideband beacon signal transmitted by the secure relay device. [Note 19] The method according to any one of the appendices 1 to 18, wherein the secure relay device compares the access token with an invalid access token revocation list and grants access to the physical access portal in accordance with the comparison. [Note 20] The steps include: the verification application of the mobile device initiates a status request to the verification device regarding the access credentials of the user of the mobile device; The steps include receiving a response to the aforementioned request, The method according to any one of the appendices 1 to 19, further comprising the step of including the response to the request in the access credentials. [Note 21] The steps include tracking the user access history of the aforementioned physical access portal, The method according to any one of the appendices 1 to 20, further comprising the step of displaying notifications for one or more detected physical access portals in the order determined by the user access history. [Note 22] A secure relay device for an access control system, A physical layer circuit, It transmits a beacon signal containing information that identifies the physical access portal, The physical layer circuit configured to receive information wirelessly, A processing circuit operably coupled to the physical layer circuit, The first authentication information received wirelessly from the mobile device is decrypted. Encode a second authentication information for transmission to the aforementioned mobile device, In response to the transmission of the second authentication information, the access credentials received from the mobile device are decrypted. A secure relay device comprising: a processing circuit configured to grant access to a physical access portal in accordance with the decrypted access credentials. [Note 23] The aforementioned processing circuit is A first processing circuit configured to encode the information identifying the physical access portal and to initiate the transmission of the beacon signal, The secure relay device according to Appendix 22, further comprising a second processing circuit for decrypting the first authentication information. [Note 24] A machine-readable storage medium containing instructions, wherein, when the instructions are executed by the processing circuit of the mobile device, the mobile device... To detect one or more physical access portals with controlled access, Displaying notifications for one or more physical access portals on the display screen of the mobile device, The selection of a physical access portal is received using the user interface of the aforementioned mobile device. To establish a secure communication channel with a secure relay device associated with the physical access portal, A machine-readable storage medium that causes the mobile device to perform an operation including transmitting an encrypted access token stored on the mobile device to the secure relay device. [Note 25] A machine-readable storage medium according to Appendix 24, which includes an instruction causing the mobile device to perform an action including displaying the notification on the display screen after the user has unlocked the mobile device for use. [Note 26] Displaying the notification on the display screen while the mobile device is locked. A machine-readable storage medium according to Appendix 24 or 25, which includes an instruction causing the mobile device to perform an action including accepting the selection of the physical access portal while the use of the mobile device is locked. [Note 27] Detecting contact with an icon on a locked display screen, where the icon is a notification for one of the one or more physical access portals. A machine-readable storage medium according to Appendix 26, comprising an instruction causing the mobile device to perform an action including detecting that contact with the icon is held for a longer duration than specified as a selection of the physical access portal. [Note 28] Based on the information contained in the access token, determine which of the one or more detected physical access portals the user can access. A machine-readable storage medium according to any one of the appendices 24 to 27, comprising an instruction causing the mobile device to perform an action that includes displaying only notifications for one or more detected physical access portals that the user can access in accordance with the aforementioned information. [Note 29] Comparing the identifiers of the one or more detected physical access portals with a stored list of physical access portals that the user of the mobile device is permitted to access, A machine-readable storage medium as described in Appendix 28, comprising instructions causing the mobile device to perform an action including displaying a notification for one or more detected physical access portals included in the aforementioned list. [Note 30] A machine-readable storage medium as described in Appendix 29, comprising instructions causing the mobile device to perform an action including storing the list of physical access portals to which the user is permitted access, wherein the list is user-defined. [Note 31] A machine-readable storage medium as described in Appendix 29 or 30, which includes an instruction causing the mobile device to perform an action that includes storing the list of physical access portals to which the user is permitted access, wherein the list is administrator-defined. [Note 32] To determine the distance from the one or more detected physical access portals to the mobile device. A machine-readable storage medium according to any one of the appendices 24 to 31, comprising an instruction causing the mobile device to perform an action including displaying notifications for one or more detected physical access portals in an order determined by proximity to the mobile device. [Note 33] A machine-readable storage medium according to Appendix 32, comprising an instruction causing the mobile device to perform an operation including determining the distance using the received beacon signal strength. [Note 34] A machine-readable storage medium according to Appendix 32 or 33, comprising instructions causing the mobile device to perform an operation including determining the distance using a Bluetooth® Low Energy Relative Signal Strength Indicator (BLE RSSI). [Note 35] The application determines one or more of the distance, location, and movement of the mobile device relative to multiple detected physical access portals. A machine-readable storage medium according to any one of the clauses 24 to 34, comprising instructions causing the mobile device to perform an action including sorting and displaying notifications for a plurality of detected physical access portals according to one or more of the determined distance, location, and movement of the mobile device. [Note 36] A machine-readable storage medium according to Appendix 35, comprising instructions causing the mobile device to perform an action that includes determining one or more of the distance, position, and movement of the mobile device to the plurality of detected physical access portals using ultra-wideband (UWB) signaling. [Note 37] A machine-readable storage medium according to Appendix 35 or 36, comprising instructions causing the mobile device to perform an action that includes determining one or more of the distance, position, and movement of the mobile device to the plurality of detected physical access portals using one or more sensors included in the mobile device that determine one or more of the distance, position, and movement of the mobile device to the plurality of detected physical access portals. [Note 38] A machine-readable storage medium according to any one of the appendices 24 to 37, comprising an instruction causing the mobile device to perform an operation including decoding information that identifies a physical access portal received in a beacon signal. [Note 39] Tracking the history of user access to the physical access portal. A machine-readable storage medium according to any one of the appendices 24 to 38, comprising an instruction causing the mobile device to perform an action including displaying notifications for one or more detected physical access portals in an order determined by the user access history. [Note 40] A method for operating an access control system, The steps include: discovering one or more physical access portals using a mobile device application; The steps include establishing a secure communication channel with a secure relay device associated with one or more detected physical access portals, The steps include displaying a notification for one or more physical access portals on the display screen of the mobile device, The steps include receiving a selection of a physical access portal using the user interface of the mobile device, The steps include: transmitting the encrypted access token stored on the mobile device to the secure relay device; A method comprising the step of the secure relay device granting access to the selected physical access portal in accordance with the encrypted access token. [Note 41] The step of displaying the aforementioned notice is: The application determines one or more of the distance, location, and movement of the mobile device relative to a plurality of detected physical access portals. The method according to Appendix 40, comprising sorting and displaying notifications for the plurality of detected physical access portals according to one or more of the determined distance, location, and movement of the mobile device. [Note 42] The steps include comparing the identifiers of one or more detected physical access portals with a stored list of physical access portals, The method according to Appendix 40 or 41, further comprising the step of displaying a notification for one or more detected physical access portals that the user of the mobile device is permitted to access, based on the saved list.

Claims

1. A method for operating an access control system, The steps include: discovering one or more physical access portals using a mobile device application; The steps include determining which of the one or more detected physical access portals the user can access, based on the access token stored on the mobile device and the list of physical access portals stored on the mobile device that the user of the mobile device is permitted to access, The steps include: displaying a notification on the mobile device's display screen for only one or more physical access portals that the application has determined the user can access; The steps include receiving a selection of a physical access portal using the user interface of the mobile device, The steps include establishing a secure communication channel with a secure relay device associated with the selected physical access portal, The steps include: transmitting the encrypted access token stored on the mobile device to the secure relay device; A method comprising the steps of: the secure relay device granting access to the selected physical access portal in accordance with the encrypted access token.

2. The method according to claim 1, wherein the step of displaying the notification comprises displaying the notification on the display screen after the user has unlocked the mobile device for use.

3. The step of displaying the aforementioned notice is: Displaying the notification on the display screen while the mobile device is locked. The method according to claim 1, further comprising accepting the selection of the physical access portal while the use of the mobile device is locked.

4. The method according to claim 3, wherein the step of receiving the selection of the physical access portal comprises detecting contact with an icon displayed on the locked display screen corresponding to the physical access portal, and detecting that the contact with the icon is held for a longer duration than specified.

5. The step of displaying the aforementioned notice is: The method according to any one of claims 1 to 4, comprising comparing the identifier of one or more detected physical access portals with the stored list of physical access portals to which the user of the mobile device is permitted to access, and displaying a notification for one or more detected physical access portals included in the list.

6. The method according to claim 5, further comprising storing the list of physical access portals to which a user is permitted to access, wherein the list is user-defined.

7. The method according to claim 5, further comprising storing the list of physical access portals to which users are permitted to access, wherein the list is administrator-defined.

8. The step of displaying the aforementioned notice is: The application determines the distance to the mobile device from multiple detected physical access portals. The method according to any one of claims 1 to 4, further comprising sorting and displaying notifications for the plurality of detected physical access portals in an order determined by the proximity to the mobile device.

9. The method according to claim 8, wherein determining the distance is performed using the received beacon signal strength.

10. The method according to claim 9, wherein determining the distance using the received beacon signal strength comprises determining the distance using a Bluetooth® Low Energy Relative Signal Strength Indicator (BLE RSSI).

11. The step of displaying the aforementioned notice is: The application determines one or more of the distance, location, or movement of the mobile device relative to a plurality of detected physical access portals. The method according to any one of claims 1 to 4, comprising sorting and displaying notifications for a plurality of detected physical access portals according to one or more of the determined distance, location, or movement of the mobile device.

12. The method according to claim 11, wherein determining one or more of the distance, location, or movement of the mobile device comprises using ultra-wideband (UWB) signaling to determine one or more of the distance, location, or movement of the mobile device to the plurality of detected physical access portals.

13. The method according to claim 11, wherein one or more of the distance, position, or movement of the mobile device to the plurality of detected physical access portals is determined by using one or more sensors included in the mobile device that determine one or more of the distance, position, or movement of the mobile device to the plurality of detected physical access portals.

14. The step of displaying the aforementioned notice is: Comparing one or more detected physical access portals with a list of unauthorized physical access portals stored in the mobile device's memory, The method according to any one of claims 1 to 4, further comprising not displaying notifications for detected physical access portals included in the aforementioned list.

15. The step of displaying the aforementioned notice is: The one or more detected physical access portals are compared with at least one of the user-defined list of physical access portals or the administrator-defined list of physical access portals stored in the memory of the mobile device. The method according to any one of claims 1 to 4, further comprising displaying or not displaying a notification for a specific physical access portal detected based on at least one of the user-defined list and the administrator-defined list.

16. The method according to any one of claims 1 to 4, wherein the step of detecting one or more physical access portals comprises using the application on the mobile device to detect a beacon signal from a secure relay device associated with at least one of the one or more physical access portals.

17. The method according to claim 16, wherein detecting the beacon signal comprises detecting a Bluetooth® low-energy beacon signal or an ultra-wideband beacon signal transmitted by the secure relay device.

18. The method according to any one of claims 1 to 4, wherein the secure relay device compares the access token with an invalid access token revocation list and grants access to the physical access portal in accordance with the comparison.

19. The steps include: the verification application of the mobile device initiates a status request to the verification device regarding the access credentials of the user of the mobile device; The steps include receiving a response to the aforementioned request, The method according to any one of claims 1 to 4, further comprising the step of including the response to the request in the access credentials.

20. The steps include tracking the user access history of the aforementioned physical access portal, The method according to any one of claims 1 to 4, further comprising the step of displaying notifications for one or more detected physical access portals in an order determined by the user access history.

Images