BACKGROUND

[0001] Access control systems typically involve the use of credentials to manage the operation of an access control device (e.g., a lock device). Such credentials may be assigned to a particular user or device and are often physical in nature, forming at least a portion of, for example, a smartcard, proximity card, key fob, or token device. Thus, credential systems generally require an interaction between the credential and a reader device (e.g., on or secured to the access control device) such that the reader device may read the credential and determine whether access should be granted. In particular, a user may be required to swipe, tap, or otherwise present the credential to the reader device. As such, access control systems often require an active physical action on behalf of the user in order to grant the user access via the access control device.

SUMMARY

[0002] One embodiment is directed to a unique system, components, and methods for UWB-based intent detection for seamless access. Other embodiments are directed to apparatuses, systems, devices, hardware, methods, and combinations thereof for UWB-based intent detection for seamless access.

[0003] According to an embodiment, a method may include receiving, from an ultra wideband (UWB) subsystem of an access control device, UWB data indicative of a distance of a mobile device from the access control device and an angle of arrival of a UWB signal from the mobile device, performing, by the access control device, predictive analysis on the UWB data to generate expected location data associated with a location of the mobile device, determining, by the access control device, a velocity of the mobile device and a heading of the mobile device based on the UWB data, determining, by the access control device, whether the mobile device is on course to a passageway associated with the access control device based on the velocity and the heading of the mobile device, performing, by the access control device, state estimation to determine whether the mobile device is within a secure distance threshold from the passageway, wherein the secure distance threshold dynamically changes based on the velocity of the mobile device, and inferring, by the access control device, ingress intent of a user of the mobile device in response to determining that the mobile device is within the secure distance threshold and on course to the passageway.

[0004] In some embodiments, the method may further include calibrating the UWB data with a distance offset and an angle calibration.

[0005] In some embodiments, the method may further include filtering the UWB data to remove burst noise.

[0006] In some embodiments, performing the predictive analysis may include removing outlier data from the UWB data based on the expected location data.

[0007] In some embodiments, performing the predictive analysis may include applying a Kalman filter to generate the expected location data.

[0008] In some embodiments, determining the velocity of the mobile device may include determining an average velocity of the mobile device.

[0009] In some embodiments, determining the velocity of the mobile device may include determining the velocity of the mobile device based on historical location data calculated for the mobile device.

[0010] In some embodiments, the method may further include unlocking, by the access control device, a lock mechanism associated with the access control device in response to inferring ingress intent of the user.

[0011] In some embodiments, the access control device may be embodied as or include a reader device.

[0012] According to another embodiment, an access control device may include an ultra wideband (UWB) subsystem configured to perform a ranging session with a mobile device and generate UWB data indicative of a distance of the mobile device from the access control device and an angle of arrival of a UWB signal from the mobile device, a processor, and a memory comprising a plurality of instructions stored thereon that, in response to execution by the processor, causes the processor to receive the UWB data from the UWB subsystem, perform predictive analysis on the UWB data to generate expected location data associated with a location of the mobile device, determine a velocity of the mobile device and a heading of the mobile device based on the UWB data, determine whether the mobile device is on course to a passageway associated with the access control device based on the velocity and the heading of the mobile device, perform state estimation to determine whether the mobile device is within a secure distance threshold from the passageway, wherein the secure distance threshold dynamically changes based on the velocity of the mobile device, and infer ingress intent of a user of the mobile device in response to determining that the mobile device is within the secure distance threshold and on course to the passageway.

[0013] In some embodiments, the plurality of instructions may further cause the processor to calibrate the UWB data with a distance offset and an angle calibration.

[0014] In some embodiments, the plurality of instructions may further cause the processor to filter the UWB data to remove burst noise.

[0015] In some embodiments, to perform the predictive analysis may include to remove outlier data from the UWB data based on the expected location data.

[0016] In some embodiments, to perform the predictive analysis may include to apply a Kalman filter to generate the expected location data.

[0017] In some embodiments, to determine the velocity of the mobile device may include to determine an average velocity of the mobile device.

[0018] In some embodiments, to determine the velocity of the mobile device may include to determine the velocity of the mobile device based on historical location data calculated for the mobile device.

[0019] In some embodiments, the access control device may further include a lock mechanism configured to unlock in response to inferred ingress intent of the user.

[0020] In some embodiments, the access control device may further include a credential reader.

[0021] According to yet another embodiment, a method may include receiving, from an ultra wideband (UWB) subsystem of a mobile device, UWB data indicative of a distance of the mobile device to an access control device and an angle of arrival of a UWB signal from the access control device, performing, by the mobile device, predictive analysis on the UWB data to generate expected location data associated with a location of the mobile device relative to the access control device, determining, by the mobile device, a velocity of the mobile device and a heading of the mobile device based on the UWB data, determining, by the mobile device, whether the mobile device is on course to a passageway associated with the access control device based on the velocity and the heading of the mobile device, performing, by the mobile device, state estimation to determine whether the mobile device is within a secure distance threshold from the passageway, wherein the secure distance threshold dynamically changes based on the velocity of the mobile device, and inferring, by the mobile device, ingress intent of a user of the mobile device in response to determining that the mobile device is within the secure distance threshold and on course to the passageway.

[0022] In some embodiments, determining the velocity of the mobile device and the heading of the mobile device may be further based on sensor data from an inertial measurement unit of the mobile device.

[0023] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter. Further embodiments, forms, features, and aspects of the present application shall become apparent from the description and figures provided herewith.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The concepts described herein are illustrative by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, references labels have been repeated among the figures to indicate corresponding or analogous elements.

[0025] FIG. l is a simplified block diagram of at least one embodiment of an access control system for ultra wideband-based intent detection for seamless access;

[0026] FIG. 2 is a simplified block diagram of at least one embodiment of a computing device;

[0027] FIG. 3 is a simplified flow diagram of at least one embodiment of a method for ultra wideband-based intent detection for seamless access;

[0028] FIG. 4 is a simplified illustration of spatial relationships of a mobile device relative to a passageway; and

[0029] FIGS. 5-7 are simplified illustrations of a graphical user interface depicting a light ring that conveys various information to an approaching user. DETAILED DESCRIPTION

[0030] Although the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.

[0031] References in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. It should further be appreciated that although reference to a “preferred” component or feature may indicate the desirability of a particular component or feature with respect to an embodiment, the disclosure is not so limiting with respect to other embodiments, which may omit such a component or feature. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

Additionally, it should be appreciated that items included in a list in the form of “at least one of A, B, and C” can mean (A); (B); (C); (A and B); (B and C); (A and C); or (A, B, and C).

Similarly, items listed in the form of “at least one of A, B, or C” can mean (A); (B); (C); (A and B); (B and C); (A and C); or (A, B, and C). Further, with respect to the claims, the use of words and phrases such as “a,” “an,” “at least one,” and/or “at least one portion” should not be interpreted so as to be limiting to only one such element unless specifically stated to the contrary, and the use of phrases such as “at least a portion” and/or “a portion” should be interpreted as encompassing both embodiments including only a portion of such element and embodiments including the entirety of such element unless specifically stated to the contrary.

[0032] The disclosed embodiments may, in some cases, be implemented in hardware, firmware, software, or a combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

[0033] In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures unless indicated to the contrary. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.

[0034] The terms longitudinal, lateral, and transverse may be used to denote motion or spacing along three mutually perpendicular axes, wherein each of the axes defines two opposite directions. The directions defined by each axis may also be referred to as positive and negative directions. Additionally, the descriptions that follow may refer to the directions defined by the axes with specific reference to the orientations illustrated in the figures. For example, the directions may be referred to as distal/proximal, left/right, and/or up/down. It should be appreciated that such terms may be used simply for ease and convenience of description and, therefore, used without limiting the orientation of the system with respect to the environment unless stated expressly to the contrary. For example, descriptions that reference a longitudinal direction may be equally applicable to a vertical direction, a horizontal direction, or an off-axis orientation with respect to the environment. Furthermore, motion or spacing along a direction defined by one of the axes need not preclude motion or spacing along a direction defined by another of the axes. For example, elements described as being “laterally offset” from one another may also be offset in the longitudinal and/or transverse directions, or may be aligned in the longitudinal and/or transverse directions. The terms are therefore not to be construed as further limiting the scope of the subject matter described herein.

[0035] Referring now to FIG. 1, in the illustrative embodiment, an access control system 100 for ultra wideband (UWB)-based intent detection for seamless access is shown. The illustrative access control system 100 includes an access control device 102, a management system 104, and a mobile device 106. Further, the management system 104 may include a management server 110, a gateway device 112, an access control panel 114, and/or a mobile device 116. Further, as shown, the illustrative access control device 102 includes a lock mechanism 120 and a UWB subsystem 122. However, in other embodiments, it should be appreciated that the access control device 102 may be embodied as a UWB accessory device configured to perform or facilitate the UWB-based intent detection described herein, which may be communicatively coupled to an electronic lock including a lock mechanism (e.g., such as the lock mechanism 120).

[0036] As described in detail below, the access control device 102 may control and/or facilitate access to a passageway (e.g., through a doorway) via a lock mechanism 120 based on an intent of the user of a mobile device 106 (e.g., a UWB-capable smartphone) inferred based on UWB communication signals received from the mobile device 106. In particular, the access control device may receive UWB data from the UWB subsystem 122 related to a UWB ranging session with the mobile device 106 and indicative of a distance of the mobile device 106 from the access control device 102 and an angle of arrival (AoA) of UWB signals received from the mobile device 106. As described below, the access control device 102 may perform various analyses on the UWB data and infer ingress intent of a user of the mobile device 106 if the mobile device 106 is on course to the passageway and within a dynamically changing secure distance threshold. If ingress intent is inferred, in some embodiments, the access control device 102 may automatically control the lock mechanism 120 without requiring user input or a physical action by the user (e.g., to unlock the lock mechanism 120).

[0037] It should be appreciated that the access control device 102, the management system 104, the mobile device 106, the management server 110, the gateway device 112, the access control panel 114, and/or the mobile device 116 may be embodied as any type of device or collection of devices suitable for performing the functions described herein.

[0038] More specifically, in the illustrative embodiment, the access control device 102 may be embodied as any type of device capable of controlling and/or facilitating access through a passageway (e.g., at least in part). For example, in various embodiments, the access control device 102 may be embodied as an electronic lock (e.g., a mortise lock, a cylindrical lock, or a tubular lock), an exit device (e.g., a pushbar or pushpad exit device), a door operator, an autooperator, a motorized latch/bolt (e.g., for a sliding door), a barrier control device (e.g., battery- powered), or a peripheral controller of a barrier to a passageway. Accordingly, in some embodiments, the access control device 102 may include a lock mechanism 120 configured to be positioned in a locked state in which access to the passageway is denied, or positioned in an unlocked state in which access to the passageway is permitted. In some embodiments, the lock mechanism 120 includes a deadbolt, latch bolt, lever, and/or other mechanism adapted to move between the locked and unlocked state and otherwise perform the functions described herein. However, it should be appreciated that the lock mechanism 120 may be embodied as any another mechanism suitable for controlling access through a passageway in other embodiments.

[0039] Depending on the particular embodiment, the access control device 102 may include a credential reader or be electrically/communicatively coupled to a credential reader configured to communicate with the mobile device 106 and/or other credential devices. In some embodiments, the access control device 102 may have an access control database stored thereon for locally performing access control decisions associated with user access. Accordingly, in such embodiments, the access control database may store credential data, biometric data, historical information, PINs, passcodes, and/or other relevant authentication data associated with users. In other embodiments, such data or a portion thereof may be stored in a centralized access control database (e.g., hosted by and/or accessible to the management server 110).

[0040] As described herein, the access control device includes a UWB subsystem 122 for performing UWB ranging with other UWB-capable devices (e.g., the mobile device 106). In the illustrative embodiment, the UWB subsystem 122 includes a plurality of UWB antennas for wireless communication using UWB technology (e.g., using the IEEE 802.15.4 (wireless) standard). It should be appreciated that a UWB signal may be received by multiple UWB antennas, and the UWB subsystem 122 of the access control device 102 may calculate or estimate the distance and angle of arrival of the mobile device 106 based on the received UWB signal. It should be further appreciated that the number, size, and/or arrangement of UWB antennas of the UWB subsystem 122 may vary depending on the particular embodiment.

Further, it should be appreciated that the access control device 102 may also include other wireless communication circuitry for communicating with the mobile device 106 and/or other devices via corresponding protocols (e.g., Wi-Fi, Bluetooth (e.g., including BLE), Zigbee, Z- Wave, Near Field Communication (NFC), Thread, etc.).

[0041] In the illustrative embodiment, the mobile device 106 may be embodied as any mobile device capable of communicating with the access control device 102 via UWB signals (e.g., for UWB ranging), exchanging credential information with the access control device 102, and/or otherwise performing the functions described herein. Accordingly, in some embodiments, in addition to having UWB communication circuitry, it should be appreciated that the mobile device 106 may also include other wireless communication circuitry for communicating with the access control device 102 and/or other devices via corresponding protocols (e.g., Wi-Fi, Bluetooth (e.g., including BLE), Zigbee, Z-Wave, Near Field Communication (NFC), Thread, etc.). It should be appreciated that, in some embodiments, the mobile device 106 may be embodied as a smartphone, UWB fob, or UWB tag device.

[0042] As described herein, in some embodiments, the mobile device 106 may be configured to perform the various functions described herein (see, for example, the method 300 of FIG. 3) in addition to or in the alternative to the access control device 102. Further, in some embodiments, the mobile device 106 may leverage sensor data to validate various data and/or otherwise improve the accuracy of the functions described herein. In particular, in some embodiments, the mobile device 106 may include an inertial measurement unit (IMU) including, for example, an accelerometer, gyroscope, and/or magnetometer that generates inertial data associated with the mobile device 106, which may be used to verify the velocity/heading of the mobile device 106. In other embodiments, the mobile device 106 may include environmental sensors (e.g., temperature sensors, air pressure sensors, humidity sensors, light sensors, etc.), inertial sensors (e.g., accelerometers, gyroscopes, etc.), magnetometers, proximity sensors, optical sensors, electromagnetic sensors, audio sensors (e.g., microphones), motion sensors, cameras, piezoelectric sensors, pressure sensors, switches (e.g., reed switches), and/or other types of sensors.

[0043] As described herein, the management system 104 may be configured to manage credentials of the access control system 100. For example, the management system 104 may be responsible for ensuring that the access control devices 102 have updated authorized credentials, whitelists, blacklists, device parameters, and/or other suitable data. Additionally, in some embodiments, the management system 104 may receive security data, audit data, raw sensor data, and/or other suitable data from the access control devices 102 for management of the access control system 100. In some embodiments, one or more of the devices of the management system 104 may be embodied as an online server or a cloud-based server. Further, in some embodiments, the management system 104 may communicate with multiple access control devices 102 at a single site (e.g., a particular building) and/or across multiple sites. That is, in such embodiments, the management system 104 may be configured to receive data from access control devices 102 distributed across a single building, multiple buildings on a single campus, or across multiple locations.

[0044] It should be appreciated that the management system 104 may include one or more devices depending on the particular embodiment of the access control system 100. For example, as shown in FIG. 1, the management system 104 may include a management server 110, a gateway device 112, an access control panel 114, and/or a mobile device 116 depending on the particular embodiment. The functions of the management system 104 described herein may be performed by one or more of those devices in various embodiments. For example, in some embodiments, the management server 110 may perform all of the functions of the management system 104 described herein. Further, in some embodiments, the gateway device 112 may be communicatively coupled to the access control device 102 such that the other devices of the management system 104 (e.g., the management server 110, the access control panel 114, and/or the mobile device 116) may communicate with the access control device 102 via the gateway device 112.

[0045] In some embodiments, the access control device 102 may communicate with the management server 110 over a Wi-Fi connection and/or with the mobile device 116 over a Bluetooth connection. Additionally, the access control device 102 may communicate with the management server 110 and/or the access control panel 114 via the gateway device 112. As such, in the illustrative embodiment, the access control device 102 may communicate with the gateway device 112 over a Wi-Fi connection and/or a Bluetooth connection, and the gateway device 112 may, in turn, forward the communicated data to the relevant management server 110 and/or access control panel 114. In particular, in some embodiments, the gateway device 112 may communicate with the access control panel 114 over a serial communication link (e.g., using RS-485 standard communication), and the gateway device 112 may communicate with the management server 110 over a Wi-Fi connection, an Ethernet connection, or another wired/wireless communication connection. As such, it should be appreciated that the access control device 102 may communicate with the management server 110 via an online mode with a persistent real-time communication connection or via an offline mode (e.g., periodically or in response to an appropriate condition) depending on the particular embodiment (e.g., depending on whether the access control device 102 is offline). As indicated above, in other embodiments, it should be appreciated that the access control device 102 may communicate with the devices of the management system 104 via one or more other suitable communication protocols.

[0046] It should be appreciated that each of the access control device 102, the management system 104, the mobile device 106, the management server 110, the gateway device 112, the access control panel 114, and/or the mobile device 116 may be embodied as one or more computing devices similar to the computing device 200 described below in reference to FIG. 2. For example, in the illustrative embodiment, each of the access control device 102, the management system 104, the mobile device 106, the management server 110, the gateway device 112, the access control panel 114, and the mobile device 116 includes a processing device 202 and a memory 206 having stored thereon operating logic 208 for execution by the processing device 202 for operation of the corresponding device.

[0047] It should be further appreciated that, although the management system 104 and the management server 110 are described herein as one or more computing devices outside of a cloud computing environment, in other embodiments, the system 104 and/or server 110 may be embodied as a cloud-based device or collection of devices. Further, in cloud-based embodiments, the system 104 and/or server 110 may be embodied as a “serverless” or server- ambiguous computing solution, for example, that executes a plurality of instructions on-demand, contains logic to execute instructions only when prompted by a particular activity/trigger, and does not consume computing resources when not in use. That is, the system 104 and/or server 110 may be embodied as a virtual computing environment residing “on” a computing system (e.g., a distributed network of devices) in which various virtual functions (e.g., Lambda functions, Azure functions, Google cloud functions, and/or other suitable virtual functions) may be executed corresponding with the functions of the system 104 and/or server 110 described herein. For example, when an event occurs (e.g., data is transferred to the system 104 and/or server 110 for handling), the virtual computing environment may be communicated with (e.g., via a request to an API of the virtual computing environment), whereby the API may route the request to the correct virtual function (e.g., a particular server-ambiguous computing resource) based on a set of rules. As such, when a request for the transmission of updated access control data is made by a user (e.g., via an appropriate user interface to the system 104 or server 110), the appropriate virtual function(s) may be executed to perform the actions before eliminating the instance of the virtual function(s).

[0048] Although only one access control device 102, one management system 104, one mobile device 106, one management server 110, one gateway device 112, one access control panel 114, and one mobile device 116 are shown in the illustrative embodiment of FIG. 1, the system 100 may include multiple access control devices 102, management systems 104, mobile devices 106, management servers 110, gateway devices 112, access control panels 114, and/or mobile devices 116 in other embodiments. For example, as indicated above, the server 110 may be embodied as multiple servers in a cloud computing environment in some embodiments. Further, each user may be associated with one or more separate mobile devices 106 in some embodiments.

[0049] Referring now to FIG. 2, a simplified block diagram of at least one embodiment of a computing device 200 is shown. The illustrative computing device 200 depicts at least one embodiment of an access control device, mobile device, management server, gateway device, and/or access control panel that may be utilized in connection with the access control device 102, the management system 104, the mobile device 106, the management server 110, the gateway device 112, the access control panel 114, and/or the mobile device 116 illustrated in FIG. 1. Depending on the particular embodiment, computing device 200 may be embodied as a reader device, credential device, access control device, UWB-capable device, server, desktop computer, laptop computer, tablet computer, notebook, netbook, Ultrabook™, mobile computing device, cellular phone, smartphone, wearable computing device, personal digital assistant, Internet of Things (loT) device, control panel, processing system, router, gateway, and/or any other computing, processing, and/or communication device capable of performing the functions described herein.

[0050] The computing device 200 includes a processing device 202 that executes algorithms and/or processes data in accordance with operating logic 208, an input/output device 204 that enables communication between the computing device 200 and one or more external devices 210, and memory 206 which stores, for example, data received from the external device 210 via the input/output device 204.

[0051] The input/output device 204 allows the computing device 200 to communicate with the external device 210. For example, the input/output device 204 may include a transceiver, a network adapter, a network card, an interface, one or more communication ports (e.g., a USB port, serial port, parallel port, an analog port, a digital port, VGA, DVI, HDMI, FireWire, CAT 5, or any other type of communication port or interface), and/or other communication circuitry. Communication circuitry may be configured to use any one or more communication technologies (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, etc.) to effect such communication depending on the particular computing device 200. The input/output device 204 may include hardware, software, and/or firmware suitable for performing the techniques described herein.

[0052] The external device 210 may be any type of device that allows data to be inputted or outputted from the computing device 200. For example, in various embodiments, the external device 210 may be embodied as the access control device 102, the management system 104, the mobile device 106, the management server 110, the gateway device 112, the access control panel 114, and/or the mobile device 116. Further, in some embodiments, the external device 210 may be embodied as another computing device, switch, diagnostic tool, controller, printer, display, alarm, peripheral device (e.g., keyboard, mouse, touch screen display, etc.), and/or any other computing, processing, and/or communication device capable of performing the functions described herein. Furthermore, in some embodiments, it should be appreciated that the external device 210 may be integrated into the computing device 200.

[0053] The processing device 202 may be embodied as any type of processor(s) capable of performing the functions described herein. In particular, the processing device 202 may be embodied as one or more single or multi-core processors, microcontrollers, or other processor or processing/controlling circuits. For example, in some embodiments, the processing device 202 may include or be embodied as an arithmetic logic unit (ALU), central processing unit (CPU), digital signal processor (DSP), and/or another suitable processor(s). The processing device 202 may be a programmable type, a dedicated hardwired state machine, or a combination thereof. Processing devices 202 with multiple processing units may utilize distributed, pipelined, and/or parallel processing in various embodiments. Further, the processing device 202 may be dedicated to performance of just the operations described herein, or may be utilized in one or more additional applications. In the illustrative embodiment, the processing device 202 is of a programmable variety that executes algorithms and/or processes data in accordance with operating logic 208 as defined by programming instructions (such as software or firmware) stored in memory 206. Additionally or alternatively, the operating logic 208 for processing device 202 may be at least partially defined by hardwired logic or other hardware. Further, the processing device 202 may include one or more components of any type suitable to process the signals received from input/output device 204 or from other components or devices and to provide desired output signals. Such components may include digital circuitry, analog circuitry, or a combination thereof.

[0054] The memory 206 may be of one or more types of non-transitory computer- readable media, such as a solid-state memory, electromagnetic memory, optical memory, or a combination thereof. Furthermore, the memory 206 may be volatile and/or nonvolatile and, in some embodiments, some or all of the memory 206 may be of a portable variety, such as a disk, tape, memory stick, cartridge, and/or other suitable portable memory. In operation, the memory 206 may store various data and software used during operation of the computing device 200 such as operating systems, applications, programs, libraries, and drivers. It should be appreciated that the memory 206 may store data that is manipulated by the operating logic 208 of processing device 202, such as, for example, data representative of signals received from and/or sent to the input/output device 204 in addition to or in lieu of storing programming instructions defining operating logic 208. As shown in FIG. 2, the memory 206 may be included with the processing device 202 and/or coupled to the processing device 202 depending on the particular embodiment. For example, in some embodiments, the processing device 202, the memory 206, and/or other components of the computing device 200 may form a portion of a system-on-a-chip (SoC) and be incorporated on a single integrated circuit chip.

[0055] In some embodiments, various components of the computing device 200 (e.g., the processing device 202 and the memory 206) may be communicatively coupled via an input/output subsystem, which may be embodied as circuitry and/or components to facilitate input/output operations with the processing device 202, the memory 206, and other components of the computing device 200. For example, the input/output subsystem may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations. [0056] The computing device 200 may include other or additional components, such as those commonly found in a typical computing device (e.g., various input/output devices and/or other components), in other embodiments. It should be further appreciated that one or more of the components of the computing device 200 described herein may be distributed across multiple computing devices. In other words, the techniques described herein may be employed by a computing system that includes one or more computing devices. Additionally, although only a single processing device 202, I/O device 204, and memory 206 are illustratively shown in FIG.

2, it should be appreciated that a particular computing device 200 may include multiple processing devices 202, I/O devices 204, and/or memories 206 in other embodiments. Further, in some embodiments, more than one external device 210 may be in communication with the computing device 200.

[0057] It should be appreciated that, in inferring intent, the system 100 may determine a user’s intention to walk/pass through a doorway or other passageway as the user approaches so that the system 100 can proactively unlock or open a corresponding barrier. Although a user walking directly toward a passageway at a steady pace may be a straightforward use case to determine user intent, other use cases are more complex (e.g., a user walking down a hallway parallel to the passageway, a user changing speeds and/or directions relative to the passageway, etc.). The technologies described herein may be leveraged to infer user intent in many use cases and provide for a secure and robust access control solution (e.g., rejecting false positives that may be prevalent using various other techniques).

[0058] Referring now to FIG. 3, in use, the access control device 102 may execute (e.g., in firmware) a method 300 for UWB-based intent detection for seamless access. It should be appreciated that the particular blocks of the method 300 are illustrated by way of example, and such blocks may be combined or divided, added or removed, and/or reordered in whole or in part depending on the particular embodiment, unless stated to the contrary. As described herein, it should be appreciated that the method 300 (or portions thereof) may be alternatively executed by the mobile device 106 in some embodiments.

[0059] The illustrative method 300 begins with block 302 in which the access control device 102 receives UWB data from the UWB subsystem 122 of the access control device 102 (e.g., associated with a UWB ranging session between the access control device 102 and the mobile device 106). In particular, in the illustrative embodiment, the UWB data is indicative of a distance of the mobile device 106 from the access control device 102 and an angle of arrival of the mobile device 106 (e.g., based on an angle of arrival of a UWB signal received from the mobile device 106). In other words, the UWB data from the UWB subsystem 122 includes distance and angle/ AoA data. Although described in the singular for convenience and brevity of the description, it should be appreciated that the UWB data may include multiples of the UWB data in various embodiments (e.g., multiple angle/ AoA measurements). It should be further appreciated that, in some embodiments, the UWB data from the UWB subsystem 122 may include non-line-of-sight (NLOS) data, signal noise ratio (SNR) data, received signal strength indicator (RSSI) data, and/or other data.

[0060] In block 304, the access control device 102 calibrates the UWB data (e.g., the distance and angle data) to address potentially poor data (e.g., due to the particular materials the RF signals are transmitting through, etc.). That is, the access control device 102 may process the raw data from the UWB subsystem 122 and apply a calibration to the data to correct for errors in the data, for example, such that the data can be reliably processed in later phases of the techniques described herein. In some embodiments, the calibration includes applying a distance offset to the distance data and/or applying an angle calibration (e.g., based on look-up table data). The resultant data of block 304 may include calibrated distance data and/or calibrated angle data.

[0061] In block 306, the access control device 102 filters the UWB data (e.g., the distance and angle data received from the UWB subsystem 122) or calibrated/processed versions thereof (e.g., the calibrated distance data and/or the calibrated angle data). In the illustrative embodiment, in filtering the data, the access control device 102 applies median filtering to the data to remove burst noise, which results data that are more reliable. However, it should be appreciated that the access control device 102 may otherwise filter other types of noise and/or characteristics and/or filter burst noise using different filters in other embodiments. Further, the filter window size may vary depending on the particular embodiment. The resultant data of block 306 may include filtered distance data and/or filtered angle data (which may also have been calibrated).

[0062] In block 308, the access control device 102 performs predictive analysis on the UWB data (e.g., the distance and angle data received from the UWB subsystem 122) or processed versions thereof (e.g., the calibrated distance/angle data and/or the filtered distance/angle data) to determine/generate expected location data associated with a location of the mobile device 106. For example, in some embodiments, the access control device 102 calculates two-dimensional coordinates (e.g., x and y coordinates) for the predicted location of the mobile device 106 based on the distance and angle data. In doing so, in some embodiments, the access control device 102 may apply a Kalman filter for the detection of outlier or invalid data that can be ignored or replaced with predicted data. In some embodiments, the access control device 102 further receives signal noise ratio (SNR) data and/or non-line-of-sight (NLOS) data (e.g., from the UWB subsystem 122), which may be used to adapt the filter response. In other embodiments, it should be appreciated that the access control device 102 may receive other adaptation parameters that may be used to adapt the filter, determine data validity, and/or otherwise modify the analyses described herein. For example, in some embodiments, the adaptation parameters may include further UWB subsystem parameters received from the UWB subsystem 122. In particular, in an embodiment, an example UWB subsystem parameter may indicate the likelihood that a particular value (e.g., distance, angle, etc.) generated by the UWB subsystem 122 is valid (e.g., with a value from 0 to 100), which may be used to improve data validity analyses. The resultant data of block 308 may include the sample rate (e.g., 100ms), angle (e.g., in the same and/or converted units), distance (e.g., in the same and/or converted units), raw coordinates from direct calculation using the raw UWB distance/angle data (e.g., raw- x and raw-y coordinates), filtered coordinates from calculation using the filtered distance/angle data (e.g., filtered-x and filtered-y coordinates), coordinate outputs from the Kalman filter (e.g., x and y coordinates), and/or a data validity flag (e.g., set to false if there is a significant amount outliers or poor data). Although described in reference to a Kalman filter, it should be appreciated that the access control device 102 may use an alternative dead reckoning or path prediction filter or algorithm in other embodiments.

[0063] In block 310, the access control device 102 performs pose estimation based on the UWB data (e.g., using processed versions thereof) to determine a velocity, course/heading, and/or heading slope of the mobile device 106. In particular, in some embodiments, access control device 102 determines the velocity, course/heading, and/or heading slope of the mobile device 106 based on the sample rate (or time since the last UWB data sample) and the coordinate outputs from the Kalman filter. It should be appreciated that the velocity may be calculated as the average velocity of the mobile device 106 based on the coordinates and the sample rate, and the heading slope may be calculated as the change in y coordinates over the absolute value of the change in x coordinates (e.g., which may give a general indication of whether the user is heading toward the passageway). It should be further appreciated that the access control device 102 maintains historical data for location data and/or values calculated in the method 300. The resultant data of block 310 may include the velocity (e.g., average velocity), heading slope, and/or course of the mobile device 106.

[0064] In block 312, the access control device 102 performs state estimation to calculate and/or evaluate various thresholds and/or scalars associated with the location, velocity, and/or heading of the mobile device 106 relative to the passageway. In some embodiments, the access control device 102 calculates various parameters that describe the state of the mobile device 106 (and, therefore, the corresponding user) including a target associated with the passageway and distance thresholds based on the coordinates, velocity, heading, and/or other data associated with the mobile device 106. In particular, in some embodiments, the access control device 102 calculates a target width scalar based on an angle of the mobile device 106 from the target center, a velocity distance scalar based on the velocity (e.g., average velocity) of the mobile device 106, and/or other data. Further, the access control device 102 may determine whether the mobile device 106 has a heading that is on course toward the target (e.g., based on a dynamic target) and/or whether the mobile device 106 is within a predefined intent distance from the secure passageway and/or a secure distance threshold from the passageway that dynamically changes based on the velocity of the mobile device 106. The resultant data of block 312 may include a target width scalar, a velocity distance scalar, an indication of whether the mobile device 106 is within a predefined intent distance threshold, an indication of whether the mobile device 106 is within a dynamic secure distance threshold, and/or an indication of whether the mobile device 106 is on course to the passageway.

[0065] FIG. 4 depicts a passageway 402 defined in a wall 404 and secured by a door 406. The illustrative access control device 102 of FIG. 4 is secured to the wall 404 nearby the passageway 402. Accordingly, in some embodiments, it should be appreciated that the access control device 102 may be embodied as a wall-mounted reader, UWB accessory device, electric strike, and/or other wall-mounted access control device. It should be further appreciated that coordinates of the center point 408 of the passageway may be predefined and/or otherwise known or calculable to the access control device 102. Accordingly, as described above, the access control device 102 computes a target width scalar based on the approach angle of the mobile device 106 that is multiplied by a base target size to determine a width of a target 410. For example, in an embodiment, if a user’s course is zero degrees toward the center point 408 of the target 410, the scaler may be 1.0, and as the user’s course deviates from zero degrees (e.g., increases in either direction), the scalar increases. Accordingly, the target 410 is dynamic in the sense that the size of the target 410 is dependent on the approach angle of the mobile device 106 and, therefore, may vary over time. The mobile device 106 is located at a current distance 412 away from the passageway (e.g., from the center point 408 or the access control device 102 depending on the particular embodiment) and has the determined heading 414. The access control device 102 may determine whether the mobile device 106 is “on course” by determining whether the heading 414 would be projected onto the target 410, as would be the case in the embodiment of FIG. 4.

[0066] As indicated above, the access control device 102 also determines whether the mobile device 106 is within a predefined intent distance 416 and/or a dynamic secure distance 418 from the passageway (e.g., from the center point 408 or the access control device 102 depending on the particular embodiment). It should be appreciated that the predefined intent distance 416 may be predefined in the access control device 102 (e.g., as a static or configurable parameter). In the illustrative embodiment, if the mobile device 106 is outside of the predefined intent distance 416, further intent analyses are ignored to save on processing, etc. In other words, the user intent may be ignored or never determined if the mobile device 106 is outside of the predefined intent distance 416. As described above, the access control device 102 also calculates a velocity distance scalar based on the velocity of the mobile device 106 that is multiplied by a base distance to determine a dynamic secure distance 418. Accordingly, the secure distance 418 is dynamic in the sense that the secure distance 418 is dependent on the velocity (e.g., average velocity) of the mobile device 106 and, therefore, may vary over time. In particular, as the velocity of the mobile device 106 increases, the secure distance 418 increases. In some embodiments, ingress intent is generally not inferred unless the mobile device 106 is within the dynamic secure distance 418.

[0067] Referring back to FIG. 3, in block 314, the access control device 102 determines whether the dynamics of the mobile device 106 are indicative of ingress intent. In particular, in some embodiments, the access control device 102 may rely on various param eters/values calculated from other phases of the method 300 described above to infer whether the user of the mobile device 106 has ingress intent. For example, the access control device 102 may determine whether the mobile device 106 has been moving consistently with a heading toward the passageway or the center point 408 of the target 410 (e.g., for at least a threshold distance traversed and/or threshold period of time elapsed), and whether the mobile device 106 has passed (and is now within) the secure distance threshold. If so, the access control device 102 may infer ingress intent. More specifically, in some embodiments, the access control device 102 makes the determination of ingress intent based on the intent distance threshold, the secure distance threshold, the determination regarding whether the mobile device 106 is “on course,” the change is distance from the last-calculated distance point, and/or the data validity flag. Further, in some embodiments, it should be appreciated that the access control device 102 may determine an ingress progress value indicative of a likelihood that the user is walking toward the passageway (e.g., expressed as a percentage, value between 0 and 1, or otherwise), which may be used by a graphical user interface or display interface of the access control device 102 to provide feedback to the user as the user is walking nearby the access control device 102 (see, for example, FIG. 5). Accordingly, in the various embodiments, the resultant data of block 314 may include an ingress intent determination and/or an ingress progress value. It should further appreciated that, in some embodiments, the access control device 102 may utilize a “distance only” fallback mode. In such an embodiment, if the access control device 102 has “lost track” of the mobile device 106 as the mobile device 106 approached the passageway but the mobile device 106 is now detected within the secure distance threshold and has been stationary for at least a threshold period of time, the access control device 102 may infer ingress intent.

[0068] If the access control device 102 determines, in block 316, that ingress intent has not been inferred, the method 300 returns to block 302 in which the access control device 102 again receives UWB data from the UWB subsystem 122 (e.g., after expiration of a corresponding sample period) to re-execute blocks 304-314 with the new UWB data. However, if the access control device 102 determines, in block 316, that ingress intent has been inferred, the method 300 advances to block 318 in which the access control device 102 may automatically unlock the lock mechanism 120 or transmit instructions to the lock mechanism 120 (or a device including the lock mechanism 120) to unlock depending on the particular embodiment.

Although not described herein for simplicity and brevity of the description, it should be appreciated that the access control device 102 may also receive a wireless access credential from the mobile device 106 (e.g., via a suitable wireless communication protocol) and evaluate the wireless access credential to ensure that the user of the mobile device 106 is authorized to gain access to the passageway.

[0069] Although the blocks 302-318 are described in a relatively serial manner, it should be appreciated that various blocks of the method 300 may be performed in parallel in some embodiments. Additionally, although the method 300 is described primarily in reference to inferring a user’s intent to gain access to a passageway as the user approaches the passageway, it should be appreciated that similar techniques may be employed to automatically lock a lock mechanism 120 and/or otherwise secure a passageway as the user departs the passageway.

[0070] Although the techniques described herein are primarily in reference to two- dimensional calculations, it should be appreciated that the three-dimensional data may be used in some embodiments. For example, in some circumstances, the elevation of the mobile device 106 may skew the data as used herein. Accordingly, in some embodiments, the access control device 102 may project a three-dimensional data point to two-dimensional space (e.g., the plane of the access control device 102 extending outward horizontally) or otherwise convert three- dimensional data points to two-dimensional data points in order to provide further robustness (e.g., during and/or after the calibration phase described herein).

[0071] Additionally, although described in reference to the access control device 102, it should be appreciated that the mobile device 106 may perform one or more of the functions (e.g., all of the functions) described in reference to the method 300 of FIG. 3 in some embodiments. In such embodiments, it should be appreciated that the access control device 102 may further leverage sensor data as indicated above and/or artificial intelligence technologies (e.g., machine learning). Further, in some embodiments, the system 100 may include multiple access control devices 102 and/or other devices that function in concert to provide more robust UWB-based locational triangulation of the mobile device 106.

[0072] In some embodiments, the access control device 102 may leverage an adaptive intent algorithm that utilizes parameters such as historical average velocities to tune the algorithms described herein for specific users based on the particular mobile device 106 (e.g., by MAC address or credential identifier). For example, the access control device 102 may utilize data such as that a child typically moves faster than an octogenarian for dynamically assessing ingress intent. Further, in some embodiments, machine learning techniques may be used to learn of “hot spots” frequently traversed by users by tracking each user’s movements and associating the path taken with an unlocking/opening of a door. For example, in some embodiments, such features may be used to ignore users who do not travel on learned paths or hot spots. Further, in some embodiments, the system 100 may allow for augmented reality to be used (e.g., by a camera of a mobile device) in order to set up hot spots and/or calibration data (e.g., allowing the drawing of a box around desired “dead zones”).

[0073] It should be further appreciated that the access control device 102 may provide audible or visual feedback to the user as the user moves nearby and/or interacts with the system 100. In particular, the access control device 102 may include a display device that displays a graphical user interface with feedback to the user of the mobile device 106 (e.g., indicating that the user is being tracked by the access control device 102 and/or to otherwise convey information to the user). For example, the display device may be embodied as or include LEDs, a display screen, a light ring (or other shape), and/or another indicator device.

[0074] As indicated above, the access control device 102 may determine an ingress progress value indicative of a likelihood that the user is walking toward the passageway. In some embodiments, the access control device 102 may display a light ring with various lighted segments illuminated to convey the ingress progress value as shown in the sequence 500 of FIG. 5. As the likelihood that the user is walking toward the passageway increases, the ingress progress value likewise increases, which may result in a greater number of light segments being illuminated (or changing color) as shown in the iterations 502-516 of the sequence 500 of FIG. 5. [0075] Further, in some embodiments, a light ring may be illuminated to convey the approach angle of the user relative to the passageway as shown in the sequence 600 of FIG. 6 or the sequence 700 of FIG. 7. As shown, the sequence 600 of FIG. 6 involves illuminating three adjacent light segments to indicate the approach angle, whereby the iterations 602-610 indicate by way of example that the user is moving from left to right. The sequence 700 of FIG. 7 involves illuminating one light segment to indicate the approach angle, whereby the iterations 702-706 indicate that the user is moving from left to right. It should be further appreciated that the color of the illuminated light segment may change (e.g., from blue to red) if the user is approaching the passageway from an undesirable angle. Further, in some embodiments, the light ring may be configured to convey both the ingress progress value and the approach angle simultaneously. For example, in an embodiment, the number of lighted segments may indicate the ingress progress value, and a different colored lighted segment may indicate the approach angle.

[0076] In some embodiments, feedback to the user may guide the user to an optimal position for tracking purposes and/or indicate to the user that the RF performance is poor (e.g., recommending that the user remove the mobile device 106 from potential RF interference, such as from the user’s purse or pocket).