Capturing behavioral user intent when interacting with multiple access control devices

Abstract

A method of advertisement filtering includes receiving advertisements from a plurality of access control devices, filtering the received advertisements based on credentials on a mobile device, comparing the filtered received advertisements, and determining a user intent to access a particular access control device in response to the comparison and a destination intent.

Description

Background Technology

[0001] This disclosure relates generally to access control systems, and more particularly to a system and method for capturing user intent when interacting with multiple access control devices.

[0002] Access control systems typically operate by encoding data indicating access permissions onto physical key cards. Some access control systems are online, where readers can communicate with the system using various means. In online systems, access permissions are typically reference identifiers. Other access control systems are offline, and access permissions are encoded as data that can be decoded and interpreted by an offline lock to retrieve those permissions. One example is a hotel lock system where the front desk encodes guest cards, and an offline battery-powered lock on the guest room door has a mechanism for decoding the key card and granting or denying access based on the encoded access permissions. Some methods of encoding access permissions include sequencing, where subsequent access permissions have a sequence number greater than the previous access permission.

[0003] Various mobile devices have been used to wake the lock by pointing a directional infrared 'beam' at it or by 'pressing a button' on the box to unlock it for subsequent communication via Bluetooth. With the ability to communicate at very low power inherent in Bluetooth Low Energy (BTLE), the new system architecture requires the lock to be 'always open' and send periodic BTLE notifications, such as once per second. The very low power requirement results in many years of battery life. With this setup, the user will not need to 'press a button' to wake the lock – the lock is already awake. However, in environments with multiple locks within range of a mobile device, such as in a hotel, each user can receive notifications from a large number of locks, thus complicating the capture of user intent. Summary of the Invention

[0004] A notification filtering method according to a disclosed non-limiting embodiment of the present disclosure may include: receiving notifications on a mobile device from each of a plurality of access control devices; filtering the received notifications based on credentials on the mobile device; comparing the filtered received notifications; and determining a user intent to access a particular access control device in response to the comparison and behavioral intent.

[0005] Another embodiment of this disclosure may include an access control device that is a lock.

[0006] Another embodiment of this disclosure may include a mobile device that is a smartphone.

[0007] Another embodiment of this disclosure may include sorting filtered received announcements based on RSSI (Received Signal Strength Indicator).

[0008] Another embodiment of this disclosure may include a prior act where the intent of the action is the prior act.

[0009] Another embodiment of this disclosure may include the date on which the prior behavior includes the time on which the user previously accessed the access control device.

[0010] Another embodiment of this disclosure may include where prior behavior includes routes previously taken by the user.

[0011] Another embodiment of this disclosure may include prior actions including a user's previous access to the location of the access control device.

[0012] Another embodiment of this disclosure may include a behavioral intent based on proximity to other users.

[0013] Another embodiment of this disclosure may include a behavioral intent associated with the access control device that is accessed most frequently.

[0014] An access control system according to a disclosed non-limiting embodiment of the present disclosure may include: a plurality of access control devices; and a mobile device that communicates with the plurality of access control devices, the mobile device being operable to determine, at least in part, a user intent to access a particular access control device among the plurality of access control devices based on behavioral intent.

[0015] Another embodiment of this disclosure may include a behavioral intent that is at least partially based on an accelerometer in the mobile device.

[0016] Another embodiment of this disclosure may include a behavior intent that is at least partially based on GPS in a mobile device.

[0017] Another embodiment of this disclosure may include a behavior intent that is at least in part based on the time of the day on which the user previously accessed the access control device.

[0018] Another embodiment of this disclosure may include a behavior intent that is based at least in part on the location of the mobile device when the user previously accessed the access control device.

[0019] Another embodiment of this disclosure may include a situation where the behavioral intent is based, at least in part, on communication between the mobile device and the passenger transport vehicle.

[0020] Another embodiment of this disclosure may include an elevator as the passenger transport vehicle.

[0021] Another embodiment of this disclosure may include a behavior intent that is at least partially based on the location of the mobile device relative to another user device.

[0022] Another embodiment of this disclosure may include a behavior intent associated with an identifier of a previously opened access control device.

[0023] Unless otherwise expressly stated, the foregoing features and elements may be combined in various combinations non-exclusively. These features and elements, and their operation, will become more apparent from the following description and accompanying drawings. However, it should be understood that the following description and accompanying drawings are intended to be exemplary in nature and not limiting. Attached Figure Description

[0024] Various features will become apparent to those skilled in the art from the following detailed description of non-limiting embodiments. The accompanying drawings accompanying the detailed embodiments can be briefly described as follows:

[0025] Figure 1 This is a general schematic diagram of a user authentication system;

[0026] Figure 2 This is a block diagram of a user authentication system;

[0027] Figure 3 This is a flowchart of the credential management method executed by the user authentication system;

[0028] Figure 4 It is a flowchart of a credential management method performed by a user authentication system according to a publicly disclosed, non-restrictive implementation.

[0029] Figure 5 It is a schematic diagram of a certificate based on another publicly disclosed non-restrictive embodiment;

[0030] Figure 6 It is a flowchart of a notification filtering method based on a publicly disclosed, non-restrictive implementation.

[0031] Figure 7 It is a schematic diagram of a filtering method according to another disclosed non-limiting embodiment; and

[0032] Figure 8 This is a schematic diagram of a filtering method according to another disclosed non-restrictive embodiment. Detailed Implementation

[0033] Figure 1 Access control system 10 is illustrated schematically. System 10 typically includes mobile device 12, server 14, and multiple access control devices 16, schematically shown as 16a, 16b, ..., 16n. It should be understood that although a particular system is defined separately in the schematic block diagram, each or any of the components in the system may be additionally combined or separated via hardware and / or software.

[0034] Mobile device 12 is a wirelessly capable handheld device, such as a smartphone, capable of operating to communicate with server 14 and access control device 16. Server 14 may provide credentials and other data to mobile device 12, such as firmware or hardware updates transmitted to one or more of access control devices 16. Although server 14 is shown herein as a single device, it should be understood that server 14 may optionally be embodied as multiple systems from which mobile device 12 receives credentials and other data.

[0035] Each access control device 16 is a wirelessly capable, restricted access, or restricted use device, such as a wireless lock, an access control reader for building entrances, an electronic banking control device, a data transfer device, a key distributor device, a tool distributor device, and other restricted use machines. The mobile device 12 submits credentials to the access control device 16, thereby selectively granting the user access or activating the functionality of the access control device 16. For example, a user may submit credentials to an electromechanical lock to unlock it and thus gain access to a restricted area. In another instance, a user may submit credentials to an electronic banking control device to withdraw funds. In yet another instance, a user may submit credentials to a unit that assigns data associated with or retrieves from the credentials to a key card. The mobile device 12 may store credentials for one or more of the above examples, and may also store multiple credentials for each type of application simultaneously. Some credentials may be used for multiple access control devices 16. For example, multiple electronic locks in a facility may respond to the same credential. Other credentials may be dedicated to a single access control device 16.

[0036] refer to Figure 2 The block diagram of the example electronic lock system 20 includes an access control device 16a, a mobile device 12, and a server 14. The access control device 16a typically includes a lock actuator 22, a lock controller 24, a lock antenna 26, a lock transceiver 28, a lock processor 30, a lock memory 32, a lock power supply 34, a lock card reader 90, and a credential module 36. The access control device 16a responds to credentials from the mobile device 12 and may be, for example, a lockbox lock, a door lock, or a lock cylinder. While this disclosure focuses primarily on credentials for access control devices, it should be understood that other systems will also benefit from transmitting credentials from a mobile device to an access control device to identify users for online systems or to verify user access rights or permissions for offline systems. Such systems include virtual or electronic banking systems, machine operating systems, distribution systems, personnel transport systems (e.g., elevators, revolving doors, subways, trains, etc.), and data access systems.

[0037] After receiving and authenticating an appropriate credential from the mobile device 12 using the credential module 36, or after receiving card data from the lock reader 90, the lock controller 24 commands the lock actuator 22 to lock or unlock the mechanical or electronic lock. The lock controller 24 and the lock actuator 22 may be components of a single electronic or electromechanical lock unit, or may be sold or installed separately as parts.

[0038] Lock transceiver 28 is capable of sending and receiving data to at least mobile device 12. Lock transceiver 28 can be, for example, a Near Field Communication (NFC), Bluetooth, or Wi-Fi transceiver, or another suitable wireless transceiver. Lock antenna 26 is any antenna suitable for lock transceiver 28. Lock processor 30 and lock memory 32 are data processing and storage devices, respectively. Lock processor 30 can be, for example, a microprocessor that can process instructions to verify card data and determine access permissions contained in the card data, or pass messages from the transceiver to credential module 36 and receive response indications with card data returned from credential module 36. Lock memory 32 can be RAM, EEPROM, or other storage media, where lock processor 30 can read and write data, including but not limited to: lock configuration options and lock review trails. Lock review trails can be uniform review trails that include events initiated by accessing the lock via lock reader 90 or mobile device 12. Lock power supply 34 is a power source, such as a line power connection, a power harvesting system, or a battery that powers lock controller 24. In other embodiments, the lock power supply 34 may only power the lock controller 24, where the lock actuator 22 is primarily or entirely powered by another source, such as user work (e.g., turning a bolt).

[0039] The credential module 36 communicates with the lock processor 30 and is operable to decrypt and verify the credential to extract virtual card data transmitted to the lock controller 24 as a "virtual card read". That is, the access control device 16a essentially has two readers: a reader 90 for reading the physical key card 92; and a credential module 36 for communicating with the mobile device 12 via the lock processor 30, transceiver 28, and antenna 26.

[0040] Although the figure shows a latching antenna 26 and transceiver 28 connected to processor 30, this does not limit other embodiments to having an additional antenna 26 and transceiver 28 directly connected to credential module 36. Credential module 36 may include transceiver 28 and antenna 26 as part of the credential module. Alternatively, credential module 36 may have transceiver 28 and antenna 26 separate from processor 30, which may also have separate transceiver 28 and antenna 26 of the same or different type. In some embodiments, processor 30 may transmit communications received via transceiver 28 to credential module 36. In other embodiments, credential module may communicate directly with mobile device 12 via transceiver 28. In other embodiments, credential module may be a software module that executes entirely within processor 30.

[0041] Mobile device 12 typically includes a key antenna 40, a key transceiver 42, a key processor 44, a key memory 46, a GPS receiver 48, an input device 50, an output device 52, and a key power supply 54. The key transceiver 42 is a transceiver of the type corresponding to lock transceiver 28, and the key antenna 40 is a corresponding antenna. In some embodiments, the key transceiver 42 and key antenna 40 may also be used to communicate with server 14. In other embodiments, one or more separate transceivers and antennas may be included for communication with server 14. Key memory 46 is of the type used to locally store multiple credentials on mobile device 12. In other embodiments, mobile device 12 communicates with server 14 while communicating with access control device 16a. This is an online configuration, and in this embodiment, mobile credentials are retrieved in real time and delivered to credential module 36, rather than being initially stored in key memory 46 on mobile device 12.

[0042] refer to Figure 3A method 100 facilitating credential communication includes: retrieving, in digital form, a credential representing data that would normally be physically encoded on a key card 92 (step 110); encapsulating the credential in an encrypted form (step 112); downloading the credential to a mobile device 12 (step 114); securely transmitting the credential to a credential module 36 (step 116), which decrypts and verifies the credential (step 118); extracting virtual card data (step 120); and then transmitting the virtual card data as a "virtual card read" to a lock controller 24 (step 122). As will be further described, this, for example, would allow a user to bypass the hotel front desk and directly enter their room. The encrypted credential can be generated by the server 14 using well-known techniques for creating and encrypting digital certificates using cryptographic algorithms such as AES, ECC, RSA, etc. For example, the credential may include, but is not limited to: a credential identifier, a unique access control device 16 identifier, a unique credential module 36 identifier, an identifier shared with multiple access control devices, and parameters indicating the type or format of the credential. The credential may contain encrypted data, such as virtual card data, and may contain a digital signature. The encrypted data can be encrypted using an AES-128 encryption key that the credential module 36 may know. Alternatively, the encrypted data can be encrypted using an encryption key derived from the information contained in the credential. Furthermore, the digital signature can be a CBC-MAC type signature based on, for example, an AES-128 encryption key that the credential module 36 may know. Alternatively, the digital signature can be a digital signature based on a private key known to the server 14 and verifiable using a public key known to the credential module 36.

[0043] refer to Figure 4 One instance of method 200, which bypasses the front desk, is initiated by a user who first books a hotel room through any hotel-supported procedure, such as mobile booking, a website, a travel agency, etc. (step 210). Afterwards, a check-in process confirms the stay (step 212). Again, this can be performed through any hotel-supported procedure.

[0044] Next, a room is assigned in the hotel property management system 60 based on guest preferences (or room selection) and room availability at check-in (step 214). The hotel property management system 60 can request card data in digital form using a software-to-software application programming interface (API) provided by the front desk application 62 (step 216). The scope of the front desk application 62 can range from a standalone encoder 64 to a complete software package running in the cloud, capable of encoding virtual cards for the selected rooms and returning the virtual card data to the hotel system (step 218).

[0045] Next, after the hotel system has authenticated the user and assigned a room reservation, the hotel property management system 60 will make another software-to-software API call to the credential service 70 (step 220). Relevant information, including, for example, what hotel property, what room, what guest (e.g., user ID), what date, and also the virtual card data for the check-in, will be transmitted to the credential service 70.

[0046] Simultaneously or sequentially, while sending the virtual card data to the credential service 70, the hotel property management service 60 (again via any conventional method) sends to the user an instruction confirming check-in and room assignment (step 222).

[0047] Next, the hotel loyalty mobile application 80 based on mobile device 12 will utilize the software-to-software API in mobile library 82 (step 224) to download credentials from credential service 70 (step 226). Mobile library 82 will securely authenticate credential service 70 with a previously established shared key that may change with each successful connection.

[0048] After authentication, credential service 70 generates credentials for the user while communicating with the mobility library 82, and encrypts the virtual card data received in step 220 into the credentials for the guest associated with this instance of the mobility library. A credential is generated for each door or access point, and the virtual card data will be identical in each of these individual credentials, but can be encrypted with a unique key for a specific door or access point. The encryption method can be AES, 3DES, or other such encryption methods. The method used and the type of credential can be a compressed digital certificate or a standards-based certificate similar to X.509, or other certificate formats known in the art. That is, for example, the virtual card data is encrypted into the credentials with a unique key known to credential module 36 and known or determinable by credential service 70.

[0049] Mobile library 82 will use local OS protection and additional encryption of data containing device-specific information such as UDID, IMEI, IMSI, MAC address, etc., to download the credential list and store it on mobile device 12. Since check-in is complete and the encrypted mobile credentials (with virtual card data) reside on mobile device 12... Figure 2 This allows the user to operate the access control device 16 in offline mode at any later time without needing to connect the mobile device 12 to the credential service 70. For example, other implementations might allow the mobile device 12 to download credentials while communicating with the access control device 16, so that the user can access their room at the same time.

[0050] When a user wishes to access their room (step 228), the user can indicate this intent via gestures, button taps, screen taps, fingerprint scanning, passwords, proximity locks, touch locks, etc. In response to this intent, the hotel loyalty mobile application 80 again invokes the software-to-software API in the mobile library 82 to initiate a secure transfer of encrypted mobile credentials to the access control device 16 (step 230). While the loyalty application 80 initiates the transfer, the mobile library separately implements the secure transfer in the next step.

[0051] The secure transfer of credentials (step 232) can begin with the mobile device 82 listening for signal announcements from the access control device 16 within range, such as Bluetooth Low Energy (BTLE) announcements. That is, the access control device 16 announces its presence periodically via announcement data indicating the identifier of the access control device 16, and the mobile device 12 can automatically listen and connect without a person pressing a button to wake the sleeping battery-powered lock 16 or leaving the vehicle to interact with a reader access point on the garage door or other device. A reader access point is another type of lock 16. Another implementation uses Near Field Communication (NFC), where a person “taps” their mobile device onto the lock 16, and a secure credential exchange transfers the mobile credentials to the access control device 16 (step 232). The secure credential exchange can be accomplished using standard techniques such as establishing session keys, encrypting communication messages, and verifying the authenticity of the message sender and receiver.

[0052] In a preferred embodiment where the access control device uses Bluetooth Low Energy (BTLE) for notification, the mobile library 82 filters the received notifications based on, for example, the identifier of the received access control device 16, by comparing it with an identifier contained in or associated with each credential in the mobile credential list, and based on the user's intent to access a specific room. The comparison can be based on the unique identifier of the access control device 16, or on a shared identifier, where a group of access control devices share a common identifier. In some cases, the access control device 16 may notify both a unique identifier and a shared identifier, and the mobile library 82 may filter based on both. Upon receiving a notification for the target access control device 16, the mobile library 82 initiates a wireless connection and performs a secure transfer of encrypted mobile credentials (step 232). The secure transfer may utilize a unique session encryption key as well as standard cryptographic algorithms and techniques. It should be understood that data can be securely transmitted via any wireless link, including but not limited to BTLE, Zigbee, Near Field Communication, etc.

[0053] The credential module 36 receives the encrypted mobile credential and then verifies and decrypts it to retrieve the virtual card data. Decryption and verification may include, but are not limited to: verifying the digital signature, verifying the credential type, verifying the credential identifier matching the identifier in the lock memory 32, verifying the start and expiration dates of the credential, and verifying the source of the credential, etc. (step 118); Figure 3 After verification and decryption, extract the virtual card data (step 120). Figure 3 ).

[0054] According to the implementation scheme, the virtual card data is then transmitted to the lock controller 24 via hardware and software interfaces. The lock controller 24 can further decrypt the virtual card data, process the data based on lock vendor rules, and then unlock the door if access is permitted (step 234). It is noteworthy that the virtual card data is transmitted to the lock controller 24 as a "virtual card read" in a data format equivalent to the physical key card data format. Therefore, this allows the continued use of the traditional guest key card 92, such as the traditional guest key card of a family member or a guest who only wants a copy of the physical key card 92, while using the mobile device 12.

[0055] The review track uploaded by mobile device 12 can be a review generated solely by mobile device 12 itself, or it can include a unified review of an opening performed by a guest using a physical key card. Furthermore, when lock 16 is opened, battery status or other maintenance information can be uploaded to the review track from mobile device 12 to credential service 70, allowing the hotel to be notified of a low battery status and to proactively replace the battery or perform other maintenance. Other information associated with the review track may include, for example, failed opening attempts or failed credential verification attempts.

[0056] The use of "virtual card reading" maintains continuous audit trails and also preserves all known use cases of access control devices encoded into traditional card data. Furthermore, the credential module 36 is vendor-agnostic, allowing data from any vendor to be passed to it, enabling each vendor to independently modify card data. Additionally, the credential module 36 can be supplied by a different company than the lock 16. Moreover, besides treating card data as a data object to be encoded, encrypted, transferred, retrieved, and delivered, the server 14, mobile device 12, and credential module 36 may not have methods for further decrypting or verifying card data. Furthermore, "virtual card reading" can be used offline without requiring the mobile device 12 to be connected online to the credential service via Wi-Fi or a real-time connection. That is, the data for "virtual card reading" is stored on the mobile device 12 and securely transferred to the credential module 36 in offline mode. This does not limit performance to sending "virtual card reading" in online mode. An additional benefit is that any access control device 16 can use any card type besides the credential module 36, including but not limited to magnetic stripe, RFID, proximity sensing, etc.

[0057] In another disclosed non-limiting embodiment, the credential module 36 can be used for a variety of purposes, including but not limited to: transmitting data to a self-service hard key distributor unit 98 that generates physical key cards 92. The hard key distributor unit 98 has the credential module 36, which receives virtual card data, decrypts and extracts the virtual card data, and sends it to a lock controller 24 configured to encode the data onto the physical key card 92. That is, virtual card data on the mobile device 12 is written to the physical key card 92 by the unit 98, and the key card 92 is distributed automatically. Apart from the distribution elements for the key card 92 and unit power supplies including but not limited to batteries, mains power, energy harvesting, etc., the unit 98 does not require any user interface. The user interface of the unit 98 is actually the interface of the mobile device 12. When the unit 98 is about to run out of blank key cards 92, the mobile device 12 can upload a status indication to the credential server 70, which can become a report to the hotel notifying them that the unit 98 needs to be refilled.

[0058] In other disclosed non-limiting embodiments, virtual card data may be standard access control card data (i.e., identification data) used for marking card access systems or integrated into vending machines, where virtual card data serves as credit card information, tokens, purchase reference identifiers, etc.

[0059] refer to Figure 5In addition to mobile credentials with virtual card data (explicit permission) 302 generated by credential service 70 for a specific access control device 16a, mobile library 82 may include a set of mobile credentials generated by credential service 70 based on access category 300 (implicit permission). Access category 300 operates to grant a user access to a specific group of access control devices 16b that have collective significance. For example, an access category could be “public rooms” for accessing a swimming pool, business center, elevator, and wall-mounted readers. In the context of hotel booking, when mobile device 12 communicates with credential service 70 to download encrypted mobile credentials, credential service 70 generates credentials for each lock in one or more access categories for which the guest has been granted access. Thus, the encrypted mobile credentials will have the same virtual card data specifically encoded for each designated access point, such as a swimming pool, business center, etc., and may optionally be in the credential or downloaded via the credential. However, each mobile credential will be individually encrypted using a unique key for each access control device 16b.

[0060] Providing and using access categories 300 through credential service 70 facilitates the effective management of multiple access control devices 16b in the system, where mobile device 12 can open multiple locks, with each mobile device 12 possessing a specific credential for each lock. This is simpler than conventionally required, for example, two access control systems—one for a hotel system—that generates virtual card data using all current technologies available for hotel system access business rules; and another for granting access to each access point, such as guest rooms, wall-mounted readers, swimming pools, business lounges, etc., via mobile credentials. In other words, it would be necessary to replicate the hotel system's business rules in the credential service.

[0061] Access category 300 allows for multi-vendor integration and can operate independently of the hotel system access business rules encoded into the virtual card data. Therefore, mobile credentials are an additional security 'layer' on top of the virtual card data. Access category 300 also allows for relatively simpler maintenance procedures; for example, when a lock in the 'public' access category is replaced, only the same access category needs to be assigned to the replacement lock. However, to download a new set of mobile credentials, mobile device 12 still needs to communicate with the credential service 70 again. Aside from including the replacement lock in the correct access category, no further management is required on the guest or system side, and all guest permissions will continue to work seamlessly without modification, even if the new lock has a unique encryption key from the previous lock.

[0062] refer to Figure 6In another disclosed non-limiting embodiment, when multiple access control devices 16 are present, an announcement filtering method 400 can be enabled to capture user intent. Initially, each access control device 16 makes an announcement using Bluetooth Low Energy (BTLE), which is received by the mobile device 12 (step 402). If announcements from multiple access control devices 16 are all close to the mobile device 12, or if the announcements are transmitted with sufficiently high power that the announcements are within a certain distance of the mobile device 12 to be received, then the announcements can be received.

[0063] Next, the mobile library 82 filters the received notifications based on the downloaded set of credentials (step 404). That is, notifications not associated with the set of credentials downloaded to the mobile device 12 are filtered out. In this way, any access control device 16 that does not grant the user permission will not even be offered in the selection list or the reduced set of possible locks to be opened. This filtering can be based on an identifier contained in the notification message of the access control device 16, and matching this identifier with an identifier contained in or associated with the credentials stored in the mobile device 12.

[0064] Then, the mobile library 82 on the mobile device 12 compares the identifier contained in or associated with each credential in the filtered list of mobile credentials to determine the user's intent to access a specific access control device (step 406). Typically, after filtering, only the user's room remains within range, allowing the user's intent to be determined (step 408).

[0065] Optionally or additionally, if the filtered credential set still has more than one lock within the range, the filtered credential set can be sorted by RSSI (Received Signal Strength Indicator) or by the average of RSSI (step 410). Sometimes, due to radio frequency propagation characteristics (e.g., multipath, interference, etc.), the RSSI of a single announcement may be inaccurate, so an averaging function of more than one announcement can be used to reduce the probability of error on a single reading, to help, for example, to average the RSSI in addition to a single RSSI reading. Thus, the access control device with the highest signal strength is thus assumed to be closest to the person and therefore the user's intention. Additionally, if the mobile device 12 is using a positioning system such as GPS in which the precise location of the mobile device relative to the access control device 16 is known, the location and distance to the access control device can be used to determine the nearest access control device 16.

[0066] Optionally or additionally, mobile device 12 may include orientation capabilities, such as a compass and / or triangulation of Bluetooth signals. For example, mobile device 12 may include multiple Bluetooth antennas and the ability to determine the direction of a BTLE announcement relative to the orientation of mobile device 12 using methods known in the fields of wireless communication and antennas, or a separate positioning system in which the precise position of the mobile device relative to access control device 16 is known, and a compass may be used to determine which of access control devices 16 the mobile device 12 is pointing to.

[0067] Therefore, if the filtered set of credentials still contains more than one lock within the range, the user will typically point the mobile device 12 toward the lock they intend to open, and thus the direction can be used to further sort the filtered set of credentials (step 412) and determine the access control device associated with the user's intent.

[0068] Optionally or additionally, the filtered set of credentials can be presented to the user as a list, such as room 1125, room 1127, concierge lounge, elevator, etc. (step 414). The user can then select the desired access control device from the list. The list can be sorted in various ways to include the last access control device opened, such that, for example, the user's room might be at the top of the list after the initial access (416). The user can select from the list by tapping the screen, or by responding to a voice prompt to read the room with 'yes' or 'no, or by a voice recognition algorithm that matches their voice request to the filtered list of available rooms. Optionally or additionally, the user can also use gestures to scroll through the list and select a desired room. Gestures will indicate to the mobile device 12 which direction to scroll the list, and then individual gestures can be used to indicate selection, such as rotating the phone left or right, quick acceleration, or other gestures. The advantage of voice prompts or gestural taps is that these operations can be performed with one hand; for example, tilting the device away will scroll the list down, and tilting the device towards will scroll the list up, or other such gestures. In cases where a user has, for example, multiple simultaneous hotel room bookings, confirmation numbers or other reference information can also be included in the credentials. These multiple simultaneous hotel room bookings provide access to the same access category and set of doors involving multiple bookings simultaneously, such as swimming pools, side doors, etc. Therefore, using multiple credentials with the same lock, a user's 'check-in' or 'confirmation number' can also be used for filtering lists.

[0069] Optionally or additionally, the list can be selectively sorted by 'category,' i.e., 'Open My Room'—and if the user has only one room, other locks that do not belong to this category will be filtered out, even if those other locks are within range and permitted to be opened (step 418). This can be done, for example, by selecting a category icon on mobile device 12 or by selecting a preset preference, such as 'Public Doors,' to avoid accidentally opening room doors and public access points, as both are within Bluetooth range.

[0070] refer to Figure 7 Optionally or additionally, the secondary interface 500 can be used to provide additional information to the mobile device 12 to aid in the identification of the access control device 16. In one example, an NFC (Near Field Communication) tag 502 can be associated with the access control device 16, such that reading the NFC tag helps indicate which access control device is being communicated via Bluetooth Low Energy (BTLE). Because Bluetooth Low Energy (BTLE) has a relatively long range and can move up and down in various ways, this secondary interface facilitates appropriate proximity selection. For example, an NFC tag can be added relative to the access control device 16, such that by 'tapping' its mobile device 12 onto a lock, the mobile device reads a credential identifier from the tag, thus associating the tag with a specific access control device 16. It should be understood that other information, such as image recognition of the room number using the camera on the mobile device, or information used to determine the floor level of the mobile device 12, can be optionally or additionally utilized. It should be understood that other secondary interfaces 500, such as iBeacon printed on the lock, barcodes, or QR codes, can be read by the camera of the mobile device 12 to determine the identifier associated with the access control device 16.

[0071] Notification filtering facilitates interaction between the user and the access control device 16 because it eliminates the need to 'unlock'. Additionally, there is the benefit of allowing the user to interact from a distance from the lock. One example is a parking garage lock point, where traditionally, a user must open a window or leave the vehicle to use a card on a reader terminal to open the entrance.

[0072] refer to Figure 8Optionally or additionally, destination intent 600 can be used to provide additional information to mobile device 12 to help identify the desired access control device 16 in order to anticipate user intent. In one instance, anticipation of user intent can be used such that an intermediate door can be opened en route due to proximity / route planning of mobile device 12. In this instance, mobile device 12 can guide the user to a specific elevator / door to plan a route around a high-congestion area. A high-congestion area can be determined by other mobile devices 12 carried by others using the same application or indicating the presence of a person and able to transmit this to the first mobile device 12 to indicate the congestion area. Optionally, the location of the person and the adjustment of the route can be done by credential service 70. The destination and / or congested route can also be adjusted based on, for example, the time of day and the user's schedule. The destination can be manually selected by the user of mobile device 12 by selecting a specific destination access control device 16 from the list of access control devices. Alternatively, the user can select the location associated with access control device 16. The association can be made using various means, such as direct association or association via proximity (i.e., they are in the same location). Alternatively, the destination can be automatically selected based on the user's schedule, the time of day, or similar information obtained from another application on the user's device, such as Outlook Calendar. The route can be determined using various known methods for optimizing route planning algorithms or indoor route planning algorithms, and by defining "waypoints" for the actual access points 16 along the route. As the person moves along the route, the mobile device 12 automatically activates the access point 16 when it enters the range of the mobile device 12 as part of the route.

[0073] In another instance, the destination can be created by system 10 or can be created outside of system 10. This can happen, for example, when a hotel property management system 60 sends a destination to the credential service 70. In this instance, the property management system 60 is outside of system 10. Another instance of this is a car-sharing project, where the vehicle system sends a destination to the credential service 70, where the destination is the location of the vehicle to be shared. The vehicle itself can be an access control device 16 that will be activated upon arrival at the destination. Alternatively, the vehicle's ignition device can be the access control device 16 that activates the vehicle when actuated. The vehicle itself is a destination. Another instance could be a vacation rental property or other asset protected by the access control device 16, where the user's destination results in the access control device 16 at the destination granting permission to the credential service 70.

[0074] In another instance, access to groceries, maid services, personal assistant services, real estate shows, etc., can be granted at a given time of day when the user is near a specific access control device 16, where their destination is a pre-arranged event to provide services at a certain location. In another instance, intent can be delegated from one person to another, where the first person expresses the intent to open a door for the second person. This delegation can be made, for example, by providing the destination to the second person or by arranging services at a certain location for the other person based on a given destination. In this case, access point 16 can be associated with a destination or a location associated with a destination. Optionally or additionally, a work order on mobile device 12 may be required to anticipate the user's intent in conjunction with the associated specific access control device 16. That is, a work order and proximity are required to anticipate the user's intent, and access point 16 can be associated with the work order or the location of the work order's destination. The work order can be sent via email or through other media that provide specific authorization. Additionally, mobile device 12 may need to select a work order to further express intent, such that if no work order is selected or activated on mobile device 12, the user's intent is not expressed.

[0075] In the above examples, a destination can be selected as a user's predetermined goal, where the goal is to do something, such as 'find the enemy' or 'obtain something', and the goal may not be static. The goal is not a place, but something to do. In summary, the goal will specify the destination by inference, which inference will specify a particular access control device 16 or a set of access control devices 16 along the route to the destination, and the destination or route can change dynamically as the focus of the goal moves.

[0076] In another example, when navigating to a intended destination 600, mobile device 12 can provide pathfinding, such as via its camera, to indicate directions to a specific access control device 16. That is, the camera can be used to display the surrounding environment, directions, or other indicators or visual cues, such as 'glowing' boxes, arrows, or lines overlaid on the surrounding environment to reach the specific access control device 16. While viewing the screen of mobile device 12, a person can express intent by tapping the screen and visually indicating the access control device 16 they wish to open. Virtual augmentation will rely on known technologies for indoor positioning, indoor mapping, outdoor positioning, outdoor mapping, and direction indicators such as GPS, magnetic compasses, and accelerometers. Similar applications exist in the fields of stargazing, pathfinding for mobile device 12, and personal navigation. Access control device 16 will be defined as a waypoint or interactive virtual device within the personal navigation system, and when selected, can trigger the action and intent to open a door.

[0077] In another instance, mobile device 12 can identify this location feature, which may be a GPS location, address, event, or place, and guide the user through various access control devices 16 to reach the location, and after reaching the specific GPS location, access nearby access control devices 16.

[0078] In another example, mobile device 12 can provide guidance to friends and family, and mobile device 12 will activate any specific access control devices 16 along this path. That is, specific access control devices 16 that the user must pass through to access friends and family, such as "Find My Friends," can be identified, and said specific access control devices can be selectively activated along the route to reach the location of said friends and family. The route can be determined in a similar manner to that described in the examples above. The user's intent is automatically determined for these access control devices 16 based on the location of friends and family. Friends and family may have similar mobile devices 12 or some other method for locating their current location.

[0079] Optionally or additionally, a friend list is provided on mobile device 12. The selection of a specific friend or individual is then used to guide the user through various access control devices 16 to automatically direct the user to the selected family or friend. Optionally, guidance to the selected family or friend may include determining the friend's current location. Optionally, the location of the friend to be met may be determined. Optionally, it may include knowing the friend's permanent residence. Additionally, "friends" may be identified via interaction with social media accounts, where mobile device 12 uses information from the social media account or system to determine which access control device 16 to open. Furthermore, "friends" may choose to disclose their location to other friends, thereby providing a destination that can be used to express intent.

[0080] Optionally or additionally, destination intent 600 can be based on the environmental pressure applied to the mobile device 12. This includes pressure from gravity, air pressure, and underwater pressure. For example, if the access control device 16 is located in deep water, the user will use their mobile device 12 to detect underwater pressure, and this can indicate the user's intent to enter when the user is near the access control device 12 and at a certain depth. If the pressure has not yet reached a certain level, the user's intent is not expressed at this time.

[0081] Optionally or additionally, the destination intent can be based on the ambient temperature detected on the mobile device 12. For example, if the access control device 16 is located inside a nuclear reactor near a coolant pool, the user would use their mobile device 12 to select the correct access control device 16 based on the RSSI and the nearby heat relative to the water in the reactor core. Another example is in a building where firefighters can select the access control device 16 based on the RSSI and the heat of the room indicating the location of the fire. In some embodiments, the mobile device 12 determines the ambient temperature itself; in another embodiment, the ambient temperature can be transmitted to the mobile device 12 as a communication intent 900 in conjunction with a destination intent 600 from some other sensors measuring a heat source in a room, in water, or elsewhere. Again, in the above fire examples, the destination can be determined by a fire alarm system that knows which room is the hottest and routes firefighters to the location of the fire via the access control device 16.

[0082] Optionally or additionally, the RSSI can be combined with an audible alarm received on the mobile device 12. For example, if several access control devices 16 are located in a room and a fire alarm is detected through one of the doors, the user will use their mobile device 12 to select the correct access control device 16 based on the RSSI and the audible alarm triggered by the fire. In this example, when the audio signal reaches a certain dB level, this can express the intention to open the access control device 16. Optionally, the audible alarm notification can notify a system, such as an intrusion alarm panel, that the system has been compromised, and the destination can be automatically determined based on the location of the compromise or the location of the audible alarm, which is then transmitted by the intrusion system to the mobile device 12 along with the communication intent 900. This will be useful in situations such as rapid response or alarms. Alternatively, in another example, if an audible alarm is present, only the user's intent can be expressed, and if no alarm is present, no user intent can be expressed. This can be useful for rapid response, where users do not need to access the access control device or even authorize the access control device unless an alarm sounds.

[0083] Optionally or additionally, destination intent 600 may be based on audio captured by mobile device 12. For example, if a user wants to listen to their favorite band, the captured intent may be provided by sounding closer to the band's audio located in the background of the access control device 16, based on the audible sound of the music.

[0084] Optionally or additionally, destination intent 600 will be based on the voice heard on mobile device 12. For example, a user may want to find someone, but the mobile application only knows the voice signature of the selected person. As the user moves closer to the voice of the selected person, the destination is derived based on proximity to that voice. In some embodiments, the voice signal is detected directly by mobile device 12; however, in other embodiments, the voice signal may be detected by a surveillance camera or other device and transmitted to mobile device 12, and the destination is determined by the proximity of the surveillance device relative to the person uttering the voice.

[0085] Optionally or additionally, destination intent 600 will be based on an image captured on mobile device 12. For example, a user parks in an access-controlled parking garage, and after parking, the user uses mobile device 12 to take a picture of their car in the parking space. When the user attempts to return to their parking space, destination intent 600 is based on the image captured on mobile device 12. For example, by selecting an image and indicating an intent to go to the location where the image was taken, the user's intent to activate access control device 16 en route to the location where the car is parked in this instance will be implicitly acknowledged. Optionally, the image can be used to communicate with a system that can identify objects from the image and determine the current location of the object in the real world, and then provide a route including the implicit user intent to activate access control device 16 along this route to reach the actual location of the object.

[0086] Optionally or additionally, destination intent 600 will be based on video captured on the mobile device. For example, a user records a video, and later, when selecting this video, the user implicitly selects the location where the video was taken, and by expressing a desire to go to the location where the video was taken, the user gives an implicit intent to open any access control device 16 along the route or at the location where the video was taken. Alternatively, similar to the above example, an object from the video can be used to identify the object's current location (if the object is movable) and express a desire to go to said current location, and access any access control device 16 along the route to the new location.

[0087] Optionally or additionally, destination intent can be expressed based on arrival at a location determined by cellular network signal strength, Wi-Fi signal strength, or simply a specific Wi-Fi access point. The mobile device 12 can use signal strength to determine whether it has arrived at a location or is associated with a destination. In this case, the destination will be mapped to a specific cellular network signal strength or based on triangulation of several cell towers. Furthermore, Wi-Fi access point identifiers can be used more generally, such that if the user is within range of this specific Wi-Fi device (i.e., a specific SSID or MAC address), the destination has been reached. Additionally, if the mobile device 12 is near a given Wi-Fi network, this can express user intent due to proximity to the specific Wi-Fi network. If it is outside range, no user intent is expressed because the mobile device is no longer near the access control device 16 with which it normally interacts. Alternatives to Wi-Fi and cellular signals are based on... iBeacon, wherein when mobile device 12 detects a specific Bluetooth announcer, the mobile device infers that it has arrived at a specific location and will automatically have the destination intention to open the access control device 16 at the location.

[0088] Optionally or additionally, direct personal intent 700 can be used to provide additional information to the mobile device 12 to capture user intent and thereby help identify a specific access control device 16. For example, a Received Signal Strength Indicator (RSSI) can be used to initiate an access process, such as when the user is within one foot of a specific access control device 16. The access process can begin at the first distance, where the mobile device 12 can hear notifications from the access control device 16 and filter the possible set of credentials (step 404). Figure 6 Then, when the mobile device 12 moves closer to the second distance, this will indicate the intention to open the access control device 16 (step 408). Figure 6For example, the first distance could be 30 feet, and the second distance could be 3 feet. Optionally, the access process could also include another intermediate distance between the first distance at which filtering begins and the second distance at which intent is expressed. At this intermediate distance, the mobile device 12 can begin to automatically communicate with the access control device 16 in anticipation of expressing intent soon. In this case, the process of opening the access control device 16 has already begun and can be completed quickly when intent is expressed, giving the impression that the 'opening time' is fast. In another instance, the duration for which the mobile device 12 remains within the second distance can indicate the intent to open, and therefore if the duration is less than a time threshold (e.g., 1 second), the access control device 16 will not be opened, but if the duration is longer than the threshold, intent will be expressed. RSSI can be combined with gestures such as shaking the mobile device 12 to further capture user intent. In this case, the gesture will not trigger the opening of the access control device 16 unless the RSSI is within a certain level (i.e., within the second distance). Optionally, RSSI can be combined with the amount of time the mobile device 12 remains close to or at a certain distance from the access control device 16. Alternatively, the accelerometer in the mobile device 12 can be used to determine the user's intention, for example, if the mobile device 12 is still moving, the door will not be opened, but if the mobile device stops or does not move within a certain distance of the desired access control device 16, the door will be opened.

[0089] In another example, access control device 16 is selected based on a visual map, which may be displayed on mobile device 12, or on a monitor or wall mount where the map is interactive. The representation of access control device 16 is on the map, and the user taps the representation when they intend to open access control device 16. The representation of access control device 16 may include text, images, icons, something associated with access control device 16 (e.g., a door or entrance), or the representation may be some other visual indicator typically displayed on a map. When making a selection on the map that would provide an immediate intent, the user may be nearby. Alternatively, the user may provide a delayed intent, and access control device 16 will open as soon as the user enters the range. Alternatively, the user may provide a delegated intent and express to another person the intention to open the selected access control device when another person's mobile device 12 is within range of the access control device. The delegated intent may be sent from one mobile device 12 to another, for example, via SMS, email, or via credential service 14. If the map is, for example, outside mobile device 12, the map may be able to communicate with the mobile device 12 by sending Bluetooth messages to mobile device 12. Alternatively, users can express their intentions by reading an NFC tag located at a visual indicator on a map using their mobile device 12. Or, users can express their intentions by reading a QR code adjacent to the visual indicator using their mobile device 12.

[0090] In another example, mobile device 12 can use biometric identification or tracking to infer the intent to operate access control device 16. In this example, eye tracking can be used to capture user intent; for example, looking at access control device 16 and blinking would express an intent to unlock. In this embodiment, mobile device 12 may include wearable components, such as smart glasses or similar devices capable of tracking eye movements. Similar to the embodiments described above, known algorithms can be used to track augmented reality and identify objects that will be mapped to access control device 16.

[0091] In another example, haptic feedback can be used to determine user intent. When mobile device 12 approaches an accessible access control device 16, the mobile device may emit a buzzing sound, vibration, or noise. The access control device can then be opened using a gesture, such as a tap in the case of mobile device 12. An accelerometer in mobile device 12 can distinguish the tap from other movements of the device. Alternatively, instead of mobile device 12, an intention can be expressed to mobile device 12 using a device connected to mobile device 12, such as smart glasses, a watch, or other such device, where the user performs actions on the connected device, such as moving, tapping with their finger, etc. Optionally or additionally, mobile device 12 can be used to display an augmented reality view, where items, such as access control devices 16 or doors accessed by the user, are illuminated or otherwise highlighted, and the user indicates in the view which door or resource they wish to access.

[0092] Optionally or additionally, a user can express personal intent 700 by actually expressing no intent. In the above example, if the mobile device 12 provides haptic feedback (e.g., vibration) when it approaches the access control device 16, the user is expressing no intent if they do not respond with a tap or other gesture within a certain timeframe. Alternatively, a specific gesture or tap sequence can be used to express no intent, such as left-right gestures to indicate 'no,' contrasting with up-down gestures to indicate 'yes.' Or, a tap sequence such as a rapid, continuous series of taps—e.g., two taps within a 1-second timeframe—will indicate no intent. A specific voice command or word can also be used to express no intent.

[0093] Optionally or additionally, behavioral intent 800 can be inferred to provide additional information to the mobile device 12 to help identify accessible access control devices 16 in order to anticipate user intent. In one instance, an employee's behavioral intent can be determined by identifying the time of day, route, GPS location, proximity to access control device 16, previous behavior, and / or other people queuing near the user. In this instance, by using previous behavior regarding which access control device 16 was previously accessed, the user's intent upon approach can be inferred as a desire to access the same access control device again. Also in this instance, the time of day in which the user is near the access control device can express intent, such that, for example, the user typically wants to enter the building in the morning or at noon and therefore, when approaching during these known time intervals, the user will automatically express intent. Additionally, if the time of day is associated with a scheduled arrival, the time of day plus the schedule plus proximity can be interpreted as a specific intent to open access control device 16. Additionally, if other people with other mobile devices 12 are nearby, and those devices express an intention to open a particular access control device 16, then when the user's mobile device 12 approaches the access control device 16, the user's intention can be inferred as it is now 'their turn' to open the door. In this example, multiple mobile devices 12 can, for example, send messages to each other via short-range BTLE notifications to notify a group of people in the vicinity of the same location as the user's mobile device 12 of their activity.

[0094] Optionally or additionally, communication intent 900 can be used to transmit additional information to mobile device 12 to help identify accessible access control devices 16 in order to anticipate user intent. For example, communication with a passenger transport system such as an elevator can be used to identify the destination floor to filter the list of accessible access control devices 16 that mobile device 12 can access. This is useful when access control devices 16 can transmit signals between floors with sufficiently strong signals, and filtering can remove any access control devices 16 not on the current floor from the list. Optionally, the user can indicate a desired destination (e.g., “my office” or “5th floor”, etc.), and mobile device 12 can transmit the destination to or from the passenger transport vehicle, such that the indicated destination of mobile device 12 can then be used to further exclude certain access control devices 16, since the destination will directly or indirectly specify a particular floor of the building.

[0095] In another example, a first access control device 16 can be accessed, which provides authorization for the use of a passenger transport system such as an elevator, and the access control system can automatically call the elevator using a default floor associated with the user. Automatic calling and destination floor information will provide a communication intent 900 and can be used to further filter the list of secondary access control devices 16. Furthermore, the communication intent 900 can be applied for a period of time after communication has occurred—for example, floor filtering can be performed for a period of time, or until such a time when further communication intent 900 is provided.

[0096] In another example, multiple mobile devices 12 that are very close together can send messages to each other, for example, via short-range BTLE announcements, to share communication intent 900 with a group of nearby mobile devices 12 that are very close to the same location as the user's mobile device 12. Additionally, messages sent between user mobile devices 12 may include indications of the user's current floor or building location, or generally some information to provide location awareness to the user's mobile device 12. Furthermore, communication between user mobile devices 12 can simply be a repetition of communications received from the passenger transport system.

[0097] Additionally, if the communication intent 900 includes the ability of the mobile device 12 to sense location (e.g., a substantially certain location, such as inside a building versus outside the building, or indoors or outdoors, or within a site), the user's intent can be inferred based on the resource where the access control device 16 is located. In one example, for a door intended to be opened and passed through, if the user on the inside of the door is already inside the building or room, the user will not need to open the door to enter. Exits are typically handled separately from the access control system.

[0098] Determining intent facilitates interaction with multiple access control devices, enabling automated access to specific devices for the user. Intent determination also minimizes otherwise more extensive interactions with mobile devices when operating access control devices. Furthermore, it reduces the time required to open access control devices by essentially anticipating user intent and at least partially automating the process.

[0099] The elements described and depicted herein, including the flowcharts and block diagrams throughout the accompanying drawings, suggest logical boundaries between elements. However, in accordance with software or hardware engineering practice, the depicted elements and their functionality may be implemented on a machine as a monolithic software architecture, as a standalone software module, or as a module employing external routines, code, services, etc., or any combination thereof, through a computer-executable medium having a processor capable of executing program instructions stored thereon, and all such implementations may fall within the scope of this disclosure.

[0100] Unless otherwise specified herein or obviously contradicted by the context, the use of the terms “a,” “an,” “the,” and similar references in the context of the specification (especially in the context of the following claims) shall be regarded as covering both the singular and plural forms. The modifier “about” used in conjunction with quantity includes the stated value and has the meaning specified in the context (e.g., it includes the degree of error associated with the measurement of a specific quantity). All scopes disclosed herein include endpoints, and endpoints may be independently combined with each other.

[0101] Although the different non-limiting embodiments have the components specifically shown, embodiments of the invention are not limited to those particular combinations. It is possible to use some of the components or features from any non-limiting embodiment in combination with features or components from any other non-limiting embodiment.

[0102] It should be understood that similar reference numerals denote corresponding or similar elements in several figures. It should also be understood that although a particular arrangement of components is disclosed in the illustrated embodiments, other arrangements will also benefit from this.

[0103] Although a particular order of steps is shown, described and claimed, it should be understood that, unless otherwise specified, the steps may be performed individually or in combination in any order and will still benefit from this disclosure.

[0104] The foregoing description is exemplary and not intended to limit it. Various non-limiting embodiments are disclosed herein; however, those skilled in the art will recognize that various modifications and variations based on the above teachings will fall within the scope of the appended claims. Therefore, it should be understood that this disclosure may be practiced in ways other than those specifically described within the scope of the appended claims. Consequently, the appended claims should be examined to determine their true scope and content.

Claims

1. A notification filtering method, comprising: Receive notifications from each of multiple access control devices on the mobile device; Received notifications are filtered based on the set of credentials downloaded to the mobile device so that received notifications not associated with the set of credentials downloaded to the mobile device are filtered out, wherein the filtering is based on an identifier contained in the notification message of the access control device and the identifier is matched with an identifier contained in or associated with the credentials stored in the mobile device. The filtered received notifications are compared on the mobile device; as well as On the mobile device, in response to the comparison and in response to behavioral intent, a user intent to access a specific access control device is determined, wherein the behavioral intent includes the user's previous behavior and the proximity between the mobile device and each of the plurality of access control devices.

2. The method according to claim 1, wherein the access control device is a lock.

3. The method according to claim 1, wherein the mobile device is a smartphone.

4. The method according to claim 1, further comprising sorting the filtered received announcements based on RSSI (Received Signal Strength Indicator).

5. The method of claim 1, wherein the prior behavior includes the date and time on which the user previously accessed the access control device.

6. The method of claim 1, wherein the prior behavior includes the route previously taken by the user.

7. The method of claim 1, wherein the prior behavior includes the user's previous access to the location of the access control device.

8. The method of claim 1, wherein the behavioral intent is based on proximity to other users.

9. The method of claim 1, wherein the behavioral intent is related to the access control device accessed most frequently.

10. An access control system, comprising: Multiple access control devices; and A mobile device that communicates with the plurality of access control devices, the mobile device being operable to determine, at least in part, a user intent to access a specific access control device among the plurality of access control devices based on behavioral intent, wherein the behavioral intent includes the user's previous behavior and proximity between the mobile device and each of the plurality of access control devices, the mobile device including instructions comprising: Receive notifications from each of the plurality of access control devices on the mobile device; Received notifications are filtered based on the set of credentials downloaded to the mobile device so that received notifications not associated with the set of credentials downloaded to the mobile device are filtered out, wherein the filtering is based on an identifier contained in the notification message of the access control device and the identifier is matched with an identifier contained in or associated with the credentials stored in the mobile device. The filtered received notifications are compared on the mobile device; and On the mobile device, a user's intent to access a specific access control device among the plurality of access control devices is determined based on the comparison and behavioral intent, wherein the behavioral intent includes the user's previous behavior and the proximity between the mobile device and each of the plurality of access control devices.

11. The system of claim 10, wherein the behavioral intent is based at least in part on the accelerometer in the mobile device.

12. The system of claim 10, wherein the behavioral intent is based at least in part on the time of the day in which the user previously accessed the access control device.

13. The system of claim 10, wherein the behavioral intent is based at least in part on the location of the mobile device when the user previously accessed the access control device.

Images