Patent Publication Number: US-10769872-B2

Title: Multi-factor authentication with geolocation and short-range communication with indoor-outdoor detection

Description:
BACKGROUND 
     A technological revolution in the home is driving development for new “smart” services, including consolidation by service providers in the fields of data, voice, video, security, energy management, etc., as well as with expanding home networks. Buildings are getting smarter and more convenient as a means to reduce operational costs for enterprise facilities. 
     In the area of home and building automation, smart homes and buildings may provide control over virtually any device or system in the home or office, from appliances to plug-in electric vehicle (PEV) security systems. As such, in the near future, increasing development will lead to numerous ‘smart’ devices surrounding a user at home, in vehicles, at work, and in many other locations. These smart devices are increasingly popular for sensing environmental conditions, controlling equipment, and securely providing information, control, and alerts to users via applications of the network-connected devices that are connected to the cloud-based services. Various approaches are used in these systems to authenticate the identity of users of the network-connected devices and systems, to provide privacy and security for the users and user-related information. However, conventional authentication methods for identifying a user by a smart device typically require significant user participation. For example, a smart lock may be deployed in a building or other structure to provide controlled access to a protected area, such as a room, office, storage, area, etc. Conventional smart locks typically provide the user with the ability to unlock/lock the smart lock by way of their network-connected devices. Often, however, these conventional smart locks require that a dedicated application be installed on their network-connected device, where the application requires the user to provide some input for authentication (e.g., password). Furthermore, these conventional applications often communicate directly with the smart lock in order to activate the lock, which may present a security vulnerability should an un-authorized user attempt to spoof the user&#39;s device or otherwise hack into the smart lock itself. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The detailed description is described with reference to the accompanying figures, in which the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items. 
         FIG. 1  illustrates an example architecture of a wireless communication network. 
         FIG. 2  illustrates examples of user equipments (UEs). 
         FIG. 3  illustrates an example location server. 
         FIG. 4  illustrates an example access control device (ACD). 
         FIG. 5  is a call flow diagram of an example process for multi-factor authentication with indoor-outdoor detection. 
         FIG. 6  is a diagram illustrating UEs at various locations with respect to an ACD. 
         FIG. 7  is a flow diagram illustrating an example process for multi-factor authentication performed by an ACD. 
         FIG. 8  is a diagram illustrating an example of an ACD controlling access by way of a door lock. 
         FIG. 9  is a diagram illustrating an example of an ACD controlling access by way of an automatic door opener. 
     
    
    
     DETAILED DESCRIPTION 
     Aspects of the present disclosure are directed to computing platforms (i.e., user equipment, server, etc.), computer-readable media, and processes for use with an access control device (ACD). 
     A user device, or user equipment (UE), may be mobile or stationary, and may communicate with a radio access network (RAN). As used herein, the term “UE” may be referred to interchangeably as an “access terminal” or “AT”, a “wireless device”, a “subscriber device”, a “subscriber terminal”, a “subscriber station”, a “user terminal” or UT, a “mobile terminal”, a “mobile station” and variations thereof. Generally, UEs can communicate with a core network via the RAN, and through the core network the UEs can be connected with external networks such as the Internet. Of course, other mechanisms of connecting to the core network and/or the Internet are also possible for the UEs, such as over wired access networks, Wi-Fi networks (e.g., based on IEEE 802.11, etc.) and so on. UEs can be embodied by any of a number of types of devices including but not limited to PC cards, compact flash devices, external or internal modems, wireless or wireline phones, and so on. A communication link through which UEs can send signals to the RAN is called an uplink channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). A communication link through which the RAN can send signals to UEs is called a downlink or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.). As used herein the term traffic channel (TCH) can refer to either an uplink/reverse or downlink/forward traffic channel. 
       FIG. 1  illustrates a high-level system architecture of a wireless communication network  100  in accordance with various aspects. The wireless communication network  100  contains UE 1 . UE 1  may include a mobile phone, a personal computer (e.g., a laptop computer, desktop computer, etc.), and so on. For example, in  FIG. 1 , UE 1  is illustrated as a cellular touchscreen mobile phone or smart phone. 
     Referring to  FIG. 1 , UE 1  is configured to communicate with an access network (e.g., the RAN  120 , an access point  125 , etc.) over a physical communications interface or layer, shown in  FIG. 1  as air interfaces  104  and  108  and/or a direct wired connection  130 . The air interface  104  can comply with a given cellular communications protocol (e.g., CDMA, EVDO, eHRPD, GSM, EDGE, W-CDMA, LTE, etc.), while the air interface  108  can comply with a wireless IP protocol (e.g., Wi-Fi, IEEE 802.11). The RAN  120  includes a plurality of access points that serve UEs over air interfaces, such as the air interface  104 . The access points in the RAN  120  can be referred to as access nodes or ANs, access points or APs, base stations or BSs, Node Bs, eNode Bs, and so on. These access points can be terrestrial access points (or ground stations), or satellite access points. The RAN  120  is configured to connect to a core network  140  that can perform a variety of functions, including bridging circuit switched (CS) calls between UEs served by the RAN  120  and other UEs served by the RAN  120  or a different RAN altogether, and can also mediate an exchange of packet-switched (PS) data with external networks such as Internet  175 . The Internet  175  includes a number of routing agents and processing agents (not shown in  FIG. 1  for the sake of convenience). In  FIG. 1 , UE N is shown as connecting to the Internet  175  directly (i.e., separate from the core network  140 , such as over an Ethernet connection of Wi-Fi or 802.11-based network). The Internet  175  can thereby function to bridge packet-switched data communications between UE N and UE  1  via the core network  140 . Also shown in  FIG. 1  is the access point  125  that is separate from the RAN  120 . The access point  125  may be connected to the Internet  175  independent of the core network  140  (e.g., via an optical communication system such as FiOS, a cable modem, etc.). The air interface  108  may serve UE 1  over a local wireless connection, such as IEEE 802.11 in an example. UE N is shown as a desktop computer with a direct wired connection  130  to the Internet  175 , such as a direct connection to a modem or router, which can correspond to the access point  125  itself in an example (e.g., for a Wi-Fi router with both wired and wireless connectivity). 
     The core network  140  is configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, Push-to-Talk (PTT) sessions, group communication sessions, social networking services, etc.) for UEs that can connect to the core network  140  via the RAN  120  and/or via the Internet  175 , and/or to provide content (e.g., web page downloads) to the UEs. 
     Further illustrated in  FIG. 1  is an access control device (ACD)  127 . In some aspects, the ACD  127  is deployed to provide authentication (and authorization) for User1 to access a protected area  131 . For example, protected area  131  may be a building, room, storage, etc., where ACD  127  authenticates the User1 and then generates an access signal  129  to trigger access to the protected area  131  (e.g., by unlocking and/or automatically opening a door). These and other examples of granting access to a protected area  131  will be described in further detail below with regards to  FIGS. 8 and 9 . 
     As will be described in further detail below, UE 1  may include a transceiver that periodically generates a beacon signal  133  in accordance with a short-range radio access technology (RAT), such as Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Wi-fi, etc., by way of air interface  106 . The UE 1  may also include a communications device for transmitting its current location (e.g., positioning data) over one or more of the air interfaces  104  and  108  according to one or more RATs. For example, UE 1  may be configured to transmit its current location to location server  170  via a first RAT, such as long term evolution (LTE) by way of air interface  104 . In another example, UE 1  may be configured to transmit its current location to location server  170  via a second RAT, such as Wi-Fi, by way of air interface  108 . 
     Referring to  FIG. 1 , location server  170  is shown as connected to the Internet  175 , the core network  140 , or both. The location server  170  can be implemented as a plurality of structurally separate servers, or alternately may correspond to a single server. As will be described below, location server  170  may include a UE location module for collecting positioning data from one or more UEs and for reporting the positioning data to one or more ACDs (e.g., ACD  127 ). 
     The features described herein are directed to apparatus and methods for ACD  127  to control user access to protected area  131  utilizing indoor-outdoor detection and a multi-factor authentication procedure. Access control to a protected area, such as protected area  131  of  FIG. 1 , may be summarized as follows: (1) ACD  127  detects a beacon signal (e.g., Bluetooth (BLE) beacon signal, such as beacon signal  133 , transmitted by UE 1  via air interface  106 ); (2) the ACD  127  determines whether UE 1  is located within the protected area  131  or in an exterior area that is outside the protected area  131  based on the detected beacon signal  133 ; (3) in response to determining that UE 1  is within the protected area, the ACD  127  may deny access to the protected area  131  (e.g., keep door locked and/or closed); (4) however, if ACD  127  determines that the UE 1  is in the exterior area, outside of the protected area  131 , then ACD  127  may perform a multi-factor authentication procedure that includes: (a) communicating with a location server  170  (e.g., via air interfaces  104  or  108 ) to obtain a current geo-location of the UE 1 , where UE 1  is a trusted UE that has been previously associated with the ACD  127 ; (b) location server  170  then queries UE 1  based, in part, on a unique device identifier (e.g., IMSI number) to obtain a current geo-location of UE 1  (e.g., via air interfaces  104  or  108 ); (c) Upon receiving the current geo-location of UE 1 , the location server  170  may forward an indication of the current geo-location of UE 1  to the ACD  127 ; (d) ACD  127  determines whether UE 1  is within a threshold distance of ACD  127  based on the indication of the current location received from the location server  170 ; and (e) if the information received from the location server  170  indicates that UE 1  is within a threshold distance (e.g., within a “safe zone”), ACD  127  then generates an access signal  129 , where access signal  129  indicates that the User1 associated with UE 1  is authorized to access the protected area  131 . 
     Accordingly, aspects of the present disclosure include an access control device that controls access to a protected area by way of a multi-factor authentication procedure, but where performance of the multi-factor authentication procedure is controlled based on a determination of whether the UE is already within the protected area or in an exterior area outside of the protected area. For example, if User1 (and their corresponding UE 1 ) are already within a protected area  131 , then the access control device  127  may deny further access to the protected area  131  by keeping a door locked and/or closed. If, however, the access control device  127  determines that UE 1  is outside of the protected area  131 , then the access control device  127  may proceed with the authentication procedure to determine whether access to the protected area  131  should indeed be granted. Of particular note, is that aspects of the present disclosure eliminate the need for a dedicated application to be installed on the UE and eliminate the need for any user interaction. Furthermore, the examples provided herein may increase security as no communication session is established between the UE 1  and the ACD  127 , nor does the location server  170  provide any unlock command to the ACD  127  (i.e., the ACD  127  may make the determination to grant access to the protected area  131  on its own accord). Even still, authentication is further enhanced by utilizing existing device identifiers (e.g., IMSI number included in a subscriber identity module (SIM) card of the UE 1 ) to verify a trusted UE. 
       FIG. 2  illustrates examples of UEs (i.e., user devices) in accordance with embodiments of the present disclosure. UEs  200 A and  200  B are possible implementations of the UE 1  of  FIG. 1 . The various device types illustrated in  FIG. 2  include a mobile phone (e.g., UE  200 A) and smart phone (e.g., UE  200 B). 
     UEs  200 A and  200 B, may also be referred to as cellular phones and includes portable telephones that can make and receive calls over a radio frequency link while the user is moving within a telephone service area. 
     While internal components of UEs such as the UEs  200 A and  200 B can be embodied with different hardware configurations, a basic high-level UE configuration for internal hardware components is shown as platform  202  in  FIG. 2 . The platform  202  can receive and execute software applications, data and/or commands transmitted from the RAN  120  that may ultimately come from the core network  140 , the Internet  175  and/or other remote servers and networks (e.g., application servers, web URLs, etc.). The platform  202  can also independently execute locally stored applications without RAN interaction. The platform  202  can include a transceiver  206  operably coupled to a processor  208  (e.g., an application specific integrated circuit (ASIC) or other microprocessor, logic circuit, data processing device, etc.). The processor  208  executes the application programming interface (API)  209  layer that interfaces with any resident programs in the memory  212  of the wireless device. The memory  212  can be comprised of read-only or random-access memory (RAM and ROM), EEPROM, flash cards, or any memory common to computer platforms. The platform  202  also can include a local database  214  that can store applications not actively used in memory  212 , as well as other data. The local database  214  is typically a flash memory cell, but can be any secondary storage device as known in the art, such as magnetic media, EEPROM, optical media, tape, soft or hard disk, or the like. 
     Platform  202  may also include a position module  218  that provides one or more motion and/or position determination functionalities. Such motion and/or position determination capabilities may be provided using digital cellular positioning techniques and/or Satellite Positioning Systems (SPS). Additionally, the position module  218  may include one or more motion sensors (e.g., simple switches, accelerometers, angle sensors, etc.), or other on-board devices to provide relative position, velocity, acceleration, and/or orientation information of the UE, itself. 
     Accordingly, an embodiment of the invention can include a UE (e.g., UE  200 A-B, etc.) including the ability to perform the functions described herein. As will be appreciated by those skilled in the art, the various logic elements can be embodied in discrete elements, software modules executed on a processor or any combination of software and hardware to achieve the functionality disclosed herein. For example, the position module  218  may also be configured to respond to queries received from a location server (e.g., location server  170 ) and in response thereto, report a current location of the platform  202  back to location server  170 . 
     The processor  208  may execute instructions and perform tasks under the direction of software components that are stored in memory  212 . For example, the memory  212  may store various software components that are executable or accessible by the one or more processors  208 . 
     The position module  218  may include routines, program instructions, objects, and/or data structures that perform particular tasks or implement particular abstract data types. For example, the position module  218  may include one or more instructions, which when executed by the one or more processors  208  direct the UE to perform operations related to receiving, processing, reporting, and presenting positioning data indicating a current geo-location of the UE. 
     Thus, in some aspects, the processor  208 , memory  212 , API  209 , local database  214 , and position module  218  may all be used cooperatively to load, store and execute the various functions disclosed herein and thus the logic to perform these functions may be distributed over various elements. Alternatively, the functionality could be incorporated into one discrete component. Therefore, the features of the UEs  200 A and  200 B in  FIG. 2  are to be considered merely illustrative and the invention is not limited to the illustrated features or arrangement. 
     The wireless communication between the UEs  200 A and/or  200 B and the RAN  120  can be based on different technologies, such as CDMA, W-CDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), Orthogonal Frequency Division Multiplexing (OFDM), GSM, or other protocols that may be used in a wireless communications network or a data communications network. Voice transmission and/or data can be transmitted to the UEs from the RAN using a variety of networks and configurations. 
     Accordingly, the illustrations provided herein are not intended to limit the embodiments of the invention and are merely to aid in the description of aspects of embodiments of the invention. 
     Furthermore, the transceiver  206 , may be configured to periodically broadcast a beacon signal  133  by way of antenna  207  in accordance with a short-range radio access technology (RAT), such as Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Wi-Fi, etc. In some examples, the beacon signal  133  generated by the transceiver  206  may include a unique identifier. In some examples, the identifier is unique to the UE such as an Integrated Circuit Card Identifier (ICCID) of a subscriber identity module (SIM) card of the UE, an International Mobile Equipment Identity (IMEI) of the UE, or an International Mobile Subscriber Identity (IMSI) of the UE. In other examples, the identifier may be unique to the beacon signal generated by the transceiver  206  (e.g., iBeacon ID, universally unique identifier (UUID), globally unique identifier (GUID), etc.). 
       FIG. 3  illustrates an example server  302 . Server  302  is one possible implementation of location server  170  of  FIG. 1 . The components illustrated in  FIG. 3  may be implemented in different types of apparatuses in different implementations (e.g., in an ASIC, in an SoC, etc.). The illustrated components may also be incorporated into other apparatuses in a communication system. For example, other apparatuses in a system may include components similar to those described to provide similar functionality. Also, a given apparatus may contain one or more of the components. For example, an apparatus may include multiple transceiver components that enable the apparatus to operate on multiple carriers and/or communicate via different technologies. 
     The location server  302  may include at least one communication device (represented by the communication device  304 ) for communicating with other nodes. For example, the communication device  304  may comprise a network interface that is configured to communicate with one or more network entities via a wire-based or wireless links. In some aspects, the communication device  304  may be implemented as a transceiver configured to support wire-based or wireless signal communication. This communication may involve, for example, sending and receiving: messages, parameters, or other types of information. Accordingly, in the example of  FIG. 3 , the communication device  304  is shown as comprising a transmitter  306  and a receiver  308 . 
     The location server  302  may also include other components that may be used in conjunction with the operations as taught herein. For example, the location server  302  may include hardware  310 , one or more processors  312 , memory  314 , and a user interface  326 . 
     The hardware  310  may include additional hardware interfaces, data communications, and/or data storage hardware. For example, the hardware interfaces may include a data output device (e.g., visual display, audio speakers), and one or more data input devices. The data input devices may include, but are not limited to, combinations of one or more of keypads, keyboards, mouse devices, touch screens that accept gestures, microphones, voice or speech recognition devices, and any other suitable devices. 
     In addition, the location server  302  may include a user interface  326  for providing indications (e.g., audible and/or visual indications) to a user and/or for receiving user input (e.g., upon user actuation of a sensing device such a keypad, a touch screen, a microphone, and so on). 
     The memory  314  may be implemented using computer-readable media, such as computer storage media. Computer-readable media includes, at least, two types of computer-readable media, namely computer storage media and communications media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), high-definition multimedia/data storage disks, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. 
     The processor  312  of location server  302  may execute instructions and perform tasks under the direction of software components that are stored in memory  314 . For example, the memory  314  may store various software components that are executable or accessible by the one or more processors  312  of the location server  302 . The various components may include software  316  and a UE location module  318 . 
     The software  316  and UE location module  318  may include routines, program instructions, objects, and/or data structures that perform particular tasks or implement particular abstract data types. For example, the UE location module  318  may include one or more instructions, which when executed by the one or more processors  312  direct the location server  302  to perform operations related to: receiving and responding to queries for a UE location generated by ACD  127  and initiating and receiving UE location queries to and from UE 1 . 
     In operation, the UE location module  318  may receive a query from ACD  127  for the current location of a particular UE (e.g., UE 1 ). In some aspects, a received query includes a unique identifier of the UE for which location information is requested (e.g., ICCID, IMEI, IMSI, iBeacon ID UUID, GUID, etc.). Based on the unique identifier, the UE location module  318  may send a query to the UE itself (e.g., via core network  140  and/or internet  175 ). In response to receiving the current location of the UE, the location server  302  may generate and send a response to the ACD  127  that provides an indication of the current location of the UE. 
     In some aspects, the location server  302  may communicate the current location of the UE in a variety of ways. For example, in one embodiment, the UE location module  318  may forward the current geo-location information (e.g., location coordinates) to the ACD  127 , such that the ACD  127  may determine if UE 1  is within a threshold distance of the ACD  127 . In another example, the UE location module  318  may determine the distance between UE 1  and the ACD  127  based on a known location of the ACD  127  (stored in memory  314 ) and forward the distance information to the ACD  127 . In yet another example, the UE location module  318  may determine whether UE 1  is within the threshold distance of the ACD  127  and send a notification to the ACD  127  indicating as such. 
       FIG. 4  illustrates an example access control device (ACD)  402 . ACD  402  is one possible implementation of ACD  127  of  FIG. 1 . In the example of  FIG. 4 , the communication device  404  of the ACD  402  includes a RAT A transceiver  406  that is configured to operate in accordance with a short-range RAT (e.g., Bluetooth and/or BLE). The communication device  404  may also include a RAT B transceiver  408  that is configured to operate in accordance with another RAT (e.g., LTE). Further shown as included in the example communication device  404  is a RAT C transceiver  410  that may be configured to operate in accordance with yet another RAT (e.g., Wi-Fi). As used herein, a “transceiver” may include a transmitter circuit, a receiver circuit, or a combination thereof, but need not provide both transmit and receive functionalities in all designs. For example, a low functionality receiver circuit may be employed in some designs to reduce costs when providing full communication is not necessary (e.g., a receiver chip or similar circuitry simply providing low-level sniffing) Further, as used herein, the term “co-located” (e.g., radios, access points, transceivers, etc.) may refer to one of various arrangements. For example, components that are in the same housing; components that are hosted by the same processor; components that are within a defined distance of one another; and/or components that are connected via an interface (e.g., an Ethernet switch) where the interface meets the latency requirements of any required inter-component communication (e.g., messaging). 
     The RAT transceivers  406 - 410  may provide different functionalities and may be used for different purposes. As an example, the RAT A transceiver  406  may operate in accordance with Bluetooth technology to detect beacon signals broadcast by UE 1 , while the RAT B transceiver  408  may operate in accordance with LTE technology to communicate with location server  170 . 
     The components illustrated in  FIG. 4  may be implemented in different types of apparatuses in different implementations (e.g., in an ASIC, in an SoC, etc.). The illustrated components may also be incorporated into other apparatuses in a communication system. For example, other apparatuses in a system may include components similar to those described to provide similar functionality. Also, a given apparatus may contain one or more of the components. For example, an apparatus may include multiple transceiver components that enable the apparatus to operate on multiple carriers and/or communicate via different technologies. 
     The ACD  402  may also include other components that may be used in conjunction with the operations as taught herein. For example, the ACD  402  may include, memory  412 , one or more processors  414 , a beacon detection module  416 , a location server interface module  418 , a signal strength monitoring module  420 , and access determination module  422 , and a trusted UE data store  424 . 
     The beacon detection module  416  of ACD  402  may include hardware and optionally software to detect the presence of beacon signals broadcast by one or more UEs (e.g., UE 1 ). For example, the beacon detection module  416  may interface with RAT A transceiver  406  for detecting the presence of a Bluetooth or BLE beacon signal. In addition, the beacon detection module  416  may be configured to extract and/or determine a unique identifier that is included in the detected beacon signal. As mentioned above, in some aspects, no communication session need be established between the ACD  402  and the UE 1 . Thus, beacon detection module  416  may be configured to detect the presence of beacon signals generated by UEs, but need not send a response, or otherwise establish a communication session with the UE via the short-range communication RAT. 
     The indoor-outdoor detection module  417  of ACD  402  may include hardware and optionally software for determining whether the UE that generated the detected beacon signal in within a protected area or in an exterior area that is outside the protected area. For example, as shown in  FIG. 4 , ACD  402  may include a first antenna  403  as well as a second antenna  405 , where both antennas are configured to receive and detect beacon signals transmitted by a UE via the short-range RAT. In some aspects, ACD  402  is configured to control access to a protected area (e.g., protected area  131 ) where the protected area and the exterior area are separated by a barrier, such as a door or gate. Thus, in this example, antenna  403  may be disposed in the exterior area on a first side of the barrier and the antenna  405  may be disposed within the protected area on a second side of the barrier. Continuing with this example, the same beacon signal (e.g., beacon signal  133 ) may be received at both antenna  403  and antenna  405 . In one implementation, indoor-outdoor detection module  417  may determine a first signal strength (e.g., received signal strength indication (RSSI)) of the beacon signal received at the antenna  403  as well as a second signal strength of the same beacon signal received at antenna  405 . The indoor-outdoor detection module  417  may then compare the first signal strength to the second signal strength to determine whether the UE that transmitted the beacon signal is within the protected area or in the exterior area. For example, as mentioned above, if the antenna  403  is disposed in the exterior area on one side of the barrier and antenna  405  is disposed within the protected area on another side of the barrier, then a first signal strength that is greater than the second signal strength would indicate that the UE is located in the exterior area. Similarly, a second signal strength that is greater than the first signal strength would indicate that the UE is located within the protected area. 
     In another example, indoor-outdoor detection module  417  may be configured to determine whether the UE is located within the protected area or in the exterior area based on a time-of-arrival of the beacon signals received at antennas  403  and  405 . That is, indoor-outdoor detection module  417  may be configured to determine a first time-of-arrival of the beacon signal received at antenna  403  as well as a second time-of-arrival of the beacon signal received at the antenna  405 . The indoor-outdoor detection module  417  may then compare the first time-of-arrival with the second time-of-arrival to determine whether the UE is within the protected area or in the exterior area. For example, a first time-of-arrival that is less than (e.g., earlier than) the second time-of-arrival indicates that the UE is in the exterior area, whereas a second time-of-arrival that is less than the first time of arrival indicates that the UE is within the protected area. In some aspects, the indoor-outdoor detection module  417  may determine the time-of-arrival of the beacon signals utilizing one or more clocks and/or counters (not explicitly illustrated in  FIG. 4 ). 
     The location server interface module  418  of ACD  402  may include hardware and optionally software to communicate with a location server (e.g., location server  170 ). For example, location server interface module  418  may be configured to send a query to the location server  170  for a current location of the UE 1 . As mentioned above, the location server interface module  418  may incorporate a unique identifier associated with UE 1  into the query, itself, such that the location server  170  may obtain the location of the UE 1  based on the unique identifier. The location server interface module  418  may also be configured to receive the indication of the current location of the UE 1  from the location server  170 . 
     The signal strength monitoring module  420  of ACD  402  may include hardware and optionally software to monitor the signal strength of one or more beacon signals broadcast by one or more UEs (e.g., UE 1 ). In some examples, the signal strength monitoring module  420  may begin monitoring the signal strength (e.g., RSSI) of the beacon signals broadcast by the UE 1  in response to determining that the UE is within a threshold distance of the ACD  402 . In some examples, the location server  170  may provide the current location coordinates of the UE 1 . Thus, in this example, the signal strength monitoring module  420  may calculate a distance between the UE 1  and the ACD  402  based on the location coordinates of the UE 1  and known location coordinates of the ACD  402  (e.g., stored in memory  412 ). In other examples, the location server  170  may calculate a distance between the UE 1  and the ACD  402  and communicate the distance information to the ACD  402 . In either case, the ACD  402  may then compare the calculated distance with the threshold distance, and if the UE is within the threshold distance, the signal strength monitoring module  420  may initiate the monitoring of the signal strength of the beacon signals. If the distance information indicates that the UE 1  is not within the threshold distance, then the ACD  402  may disregard the beacon signal transmitted by the UE. 
     In some examples, if a beacon signal is detected, but it is determined that the UE 1  is not within the threshold distance, then the ACD  402  may implement a delay period, where the location server interface module  418  may generate another query to obtain an updated location of the UE 1  to determine whether the UE 1  is now within the threshold distance. 
     In some aspects, the ACD  402  may detect the presence of several beacon signals and generate a query for the current location of each of the UEs associated with the beacon signals. Thus, the received responses from the location server  170  may include both an indication of the current location of the UE and the associated unique identifier, such that the ACD  402  may correlate the detected beacon signal with the determined location. 
     The access determination module  422  of ACD  402  may include hardware and optionally software to generate an access signal (e.g., access signal  129  of  FIG. 1 ). For example, in some implementations, the access determination module  422  may generate the access signal  129  indicating that the user (e.g., User  1 ) associated with the UE 1  is authorized to access a protected area (e.g., protected area  131 ) in response to the current location as provided by the location server  170  indicating that UE 1  is within the threshold distance of ACD  402 . In another example, access determination module  422  may generate the access signal  129  in response to both: (1) the current location of UE 1  being within the threshold distance, and (2) the signal strength monitoring module  420  detecting that the signal strength of the beacon signal generated by UE 1  exceeds a signal strength threshold (e.g., indicating that the UE 1  is in close proximity to the ACD  402 ). 
     In some examples, access determination module  422  is configured to send the access signal to a locking mechanism of a door lock to actuate the locking mechanism between a locked position and an unlocked position (e.g., transition to unlocked position in the case of granting authorization). In another example, the access determination module  422  is configured to send the access signal  129  to an automatic door opener to actuate a door between an open position and a closed position (e.g., transition to open position in the case of granting authorization). 
     In some examples, the access determination module  422  may also implement one or more rule-based authentication techniques. For example, the access determination module  422  may be configured with one or more time-based rules to grant access to a protected area only during specified times. 
     The trusted UE data store  424  of ACD  402  may include hardware and optionally software to maintain a list of trusted UEs and associated unique identifiers. For example, the trusted UE data store  424  may store a list of trusted UEs and their associated unique identifiers (e.g., ICCID, IMEI, IMSI, iBeacon ID UUID, GUID, etc.) for which the access determination module  422  may grant access to the protected area. In one example, the list of trusted UEs are obtained by the ACD  402  during an initial setup of the device. In other examples, the ACD  402  may be configured to receive an updated list of trusted UEs via one or more of the RAT transceivers  406 - 410 . 
     In some examples, when beacon detection module  416  detects the presence of a beacon signal transmitted by a UE, the beacon detection module  416  may determine whether the unique identifier included in the beacon signal corresponds to at least one of the trusted UEs included in the list of trusted UEs (e.g., stored in trusted UE data store  424 ). If so, ACD  402  may proceed with determining whether the UE is in the exterior area (i.e., outside the protected area) and if so, send a query to the location server  170  to obtain a current location of the UE. However, if the unique identifier does not correspond to any of the trusted UEs included in the list of trusted UEs, the ACD  402  may deny access to the protected area (e.g., do not query location server  170  for current location, do not monitor signal strength of beacon signal, and do not generate the access signal  129 ). 
       FIG. 5  is a call flow diagram of an example process for multi-factor authentication.  FIG. 5  illustrates a UE  500 , an ACD  502 , and a location server  504 . UE  500  may correspond to UE 1  of  FIG. 1 , ACD  502  may correspond to ACD  127  of  FIG. 1 , and location server  504  may correspond to location server  170  of  FIG. 1 . 
     In block  506 , the UE  500  generates one or more beacon signals  507 . As mentioned above, aspects of the present disclosure may require little, if any, user interaction in order for ACD  502  to perform its authentication. For example, existing short-range communication technologies may provide for UE  500  to automatically generate the one or more beacon signals on a periodic basis, provided that the particular RAT has been enabled by the user (e.g., Bluetooth turned on by User1). 
     In block  508 , the ACD  502  detects the beacon signal  507 . As mentioned above, the ACD  502  need not respond to the UE  500  via the short-range RAT so as to further improve security. Thus, in response to detecting the beacon signal  507 , block  510  illustrates the ACD  502  first determining whether UE  500  is within the protected area or in the exterior area (outside of the protected area). If the ACD  502  determines that UE  500  is within the protected area then ACD  502  may deny access to the protected area, such as by keeping a door locked and/or closed. If, however, ACD  502  determines that UE  500  is in the exterior area, then ACD  502  may proceed with performing a multi-factor authentication procedure in order to determine whether to grant the user associated with UE  500  access to the protected area. 
     In some examples, the multi-factor authentication procedure performed by the ACD  502  includes first determining whether a unique identifier included in the beacon signal  507  corresponds to any of the UEs included in the list of trusted UEs (e.g., see trusted UE data store  424  of  FIG. 4 ). If so, block  512  illustrates the ACD  502  generating and sending a query  509  to the location server  504  for a current location of the UE  500 . 
     Next, in block  514 , the location server  504  generates and sends a query  511  to UE  500  to obtain the current location of the UE  500 . As mentioned above, the location server  504  may generate the query  511  based on the unique identifier included in the initial query  509 . In some examples, the location server  504  is configured to not store the unique identifier in persistent storage, so as to prevent unauthorized access. That is, location server  504  may only temporarily store the unique identifier long enough for the location server  504  to send the query  511 , receive the response  513  from the UE  500 , and then send the indication  515  to the ACD  502 . After which, the unique identifier may be purged from the memory of location server  504 . 
     Returning back to block  516 , the location server  504  then receives a response  513  from the UE  500  which indicates the current location of the UE  500 . In some examples, the response  513  may include the location coordinates (e.g., LAT/LONG) of the UE  500 . Next, in block  518  the location server  504  forwards an indication  515  of the current location to the ACD  502 . 
     In block  520 , the ACD  502  receives the indication  515  and then determines whether the UE  500  is within a threshold distance of the ACD  502  based on the current location provided in indication  515 . For example, as will be described below with reference to  FIG. 6 , a ‘safe zone’ may be established around the ACD  502 , which may act as a geo-fence for determining when to grant access to the protected area. If ACD  502  determines that UE  500  is indeed within the threshold distance, then ACD  502  may generate the access signal  517  to grant the user associated with UE  500  access to the protected area. 
     As mentioned above, in some implementations, ACD  502  may be configured to generate the access signal  517  not only based on whether the indication  515  indicates that the UE  500  is within the threshold distance, but also based on the signal strength of the beacon signal  507 . Thus, in this example, if the indication  515  indicates that UE  500  is indeed within the threshold distance, then ACD  502  may then begin monitoring the signal strength of one or more beacon signals (e.g., beacon signal  507  as well as subsequent beacon signals periodically transmitted by UE  500 ). The ACD  502  may then generate the access signal  517  to grant access to a protected area only if the signal strength of the monitored beacon signals exceeds a signal strength threshold indicating that the UE  500  is within an even closer proximity to ACD  502 . 
       FIG. 6  is a diagram illustrating UE 1 , UE 2 , and UE 3  at various locations with respect to an ACD  620 . As mentioned above, an ACD, such as ACD  620 , may be configured with a safe zone, which defines a threshold distance within which UEs have to be located in order for the ACD  620  to grant access to a protected area. Thus,  FIG. 6  illustrates an example threshold distance  616  from the ACD  620 , which provides a ‘safe zone’  618 . Accordingly, the ACD  620  may grant access to a protected area for UEs that are determined to be within the safe-zone  618  and may disregard beacon signals detected for UEs that are outside of the safe-zone  618 . 
     Further illustrated in  FIG. 6 , is a protected area  604  that is separated from an exterior area  606  by way of a barrier  608 . In some examples, barrier  608  is an interior or exterior door of a building or other structure. In other examples, barrier  608  may be implemented as a fence gate, a roadblock, a turnstile, a collapsible or retractable bollard, a retractable tire spike, a parking lot/garage control beam, and the like. 
       FIG. 6  further illustrates ACD  620  disposed on or near the barrier  608  such that antenna  622  is disposed within the exterior area  606  on a first side  626  of the barrier  608  and antenna  624  is disposed within the protected area  604  on a second side  628  of the barrier  608 . In some examples, first side  626  and second side  628  are opposite sides of the same barrier  608 . 
       FIG. 6  also illustrates UE 1 , UE 2 , and UE 3  at respective locations  610 ,  612 , and  614 . That is, UE 1  is shown as being at location  610  that is in the exterior area  606 . UE 2  is shown at location  612  that is also in the exterior area  606 . UE 3  is shown as being at location  614  that is within the protected area  604 . 
     When the UE 1  is at location  610 , the ACD  620  may detect the presence of a beacon signal  630  transmitted by the UE 1 . As shown, the beacon signal  630  may be received at both antennas  622  and  624 . The ACD  620  may then determine, based on the beacon signal  630 , that the UE 1  is indeed in the exterior area  606  (e.g., a signal strength of the beacon signal  630  received at antenna  622  is greater than the signal strength of the beacon signal  630  received at antenna  624 , and/or the time-of-arrival of the beacon signal  630  received at antenna  622  may be less than (i.e., earlier) than the time-of-arrival of the beacon signal  630  received at antenna  624 ). In response to determining that UE 1  is indeed in the exterior area  606 , then ACD  620  may perform an authentication procedure that includes querying the location server for a current location of UE 1 . However, the indication of the current location provided by the location server indicates that the UE 1  is not within the safe-zone  618  (e.g., not within the threshold distance  616 ). Accordingly, ACD  620  may determine to not grant UE 1  access to the protected area  604 . 
     With regards to UE 2 , ACD  620  may also determine that UE 2  is in the exterior area  606  based on the beacon signal  632  received at antennas  622  and  624 . However, the indication for the current location of UE 2 , provided by the location server, indicates that UE 2  is within the threshold distance  616  (i.e., within the safe-zone  618 ). Accordingly, the ACD  620  may then generate the access signal to grant the user associated with UE 2  access to the protected area  604 . 
     With regards to UE 3  at location  614 , ACD  620  may receive the beacon signal  634  at both antennas  622  and  624 . Based on the beacon signal  634  received at antennas  622  and  624 , the ACD  620  may determine that the UE 3  is already within the protected area  604  (e.g., signal strength of beacon signal  634  received at antenna  624  is greater than signal strength of beacon signal  634  received at antenna  622  and/or the time-of-arrival of the beacon signal  634  received at antenna  624  is less than the time-of-arrival of the beacon signal  634  received at antenna  622 ). Accordingly, the ACD  602  may then deny access to the protected area  604 . In some examples, denying access to the protected area  604  may include maintaining the barrier  608  in a locked and/or closed state so as to prevent one or more users from gaining access to protected area  604  by way of exterior area  606 . 
       FIG. 7  is a flow diagram illustrating an example process  700  for multi-factor authentication performed by an ACD. Process  700  is one example process performed by the ACD  402  of  FIG. 4 . 
     In a process block  702 , the beacon detection module  416  of  FIG. 4  detects at least one beacon signal transmitted by a UE (e.g., UE 1  of  FIG. 1 ) via a short-range RAT (e.g., Bluetooth, BLE, Zigbee, Wi-Fi, etc.). The ACD  402  may then determine whether a unique identifier included in the beacon signal correlates to any of the trusted UEs included in the trusted UE data store  424 . If so, process  700  may proceed to decision block  704 , where the indoor-outdoor detection module  417  determines whether the UE that generated the detected beacon signal is within the protected area or in an exterior area that is outside the protected area. If the indoor-outdoor detection module  417  determines that the UE is within the protected area, then process  700  proceeds to process block  706  where the ACD  402  denies access to the protected area (e.g., keep door locked and/or closed). If, however, the indoor-outdoor detection module  417  determines that the UE is in the exterior area, then process  700  proceeds to process block  708 , where ACD  402  performs a multi-factor authentication procedure to determine whether to grant access to the protected area. 
     By way of example, the multi-factor authentication procedure may include process block  710  where the location server interface module  418  sends a query to the location server (e.g., location server  170 ) for a current location of the UE. Next, in process block  712 , the location server interface module  418  receives an indication (e.g., position coordinates, distance, etc.) of the current location of the UE. In process block  714 , the ACD  402  determines whether the UE is within a threshold distance (e.g., distance  616  of  FIG. 6 ) of the ACD  402  based on the indication received from the location server. 
     If the ACD  402  determines that the UE is indeed within the threshold distance of the ACD  402 , then process  700  proceeds to process block  716 , where the access determination module  422  generates the access signal  129  to indicate that the user associated with the UE is granted access to a protected area (e.g., protected area  604  of  FIG. 6 ). 
       FIG. 8  is a diagram illustrating an example of ACD  127  controlling access by way of a door lock  800 . As shown in  FIG. 8 , door lock  800  is mounted to a door  802  for controlling access to a protected area  804 , which may be the interior of a dwelling, a storage area, an office, etc. Door lock  800  is shown as including a locking mechanism  808 , a bolt  810 , a strike plate  812 , a housing  814 , a thumb turn  816 , a keypad  818 , security ring  820 , one or more keys  822 , and ACD  127 . In some embodiments, one or more of the thumb turn  816 , keypad  818 , security ring  820 , and keys  822  are optional and may be omitted. Thumb turn  816  is configured to provide a user with manual control over a position of the bolt  810 , between a locked position (e.g., extended) and an unlocked position (e.g., retracted) while the user is within the protected area  804 . Similarly, security ring  820  and keys  822  are configured to provide a user with manual control over the position of the bolt  810  while the user is in the exterior area  806 . Keypad  818  may be provided to allow a user to enter a code (e.g., alphanumeric characters) in order to trigger the locking mechanism  808  to actuate the bolt  810  between the locked and unlocked positions. 
       FIG. 8  also illustrates the door lock  800  as including an ACD  127 . ACD  127  may be implemented as any of the example ACDs described herein, including ACD  402  of  FIG. 4 . ACD  127  may be incorporated within the housing  814  or ACD  127  may be fixedly attached to an exterior of the housing  814  (e.g., connected to thumb turn  816 ). ACD  127  may also include several antennas for detecting beacon signals transmitted by a UE. For example, ACD  127  may include a first antenna disposed on a first side  828  of the door  802  in the exterior area  806 . In one example, the antenna on first side  828  may be incorporated into the keypad  818 . ACD  127  may also include a second antenna disposed on a second side  826  of the door  802  within the protected area  804 . In some examples, the second antenna on second side  826  may be incorporated within housing  814 . 
     As shown, once a user is authenticated (e.g., via process  700  of  FIG. 7 ), the ACD  127  may generate and send the access signal  129  to the locking mechanism  808 . In some examples, locking mechanism  808  includes a motor or other actuator to alter a position of the bolt  810  between the locked and unlock positions. 
       FIG. 9  is a diagram illustrating an example of ACD  127  controlling access by way of an automatic door opener  900 . As shown in  FIG. 9 , automatic door opener  900  is mounted between a door  902  and a door frame/wall  904  for controlling access to an area such as a dwelling, a storage area, an office, etc. Automatic door opener  900  is shown as including a housing  906 , a lever arm  908 , a motor  910 , and ACD  127 . 
     ACD  127  of  FIG. 9  may be implemented as any of the example ACDs described herein, including ACD  402  of  FIG. 4 . ACD  127  may be incorporated within the housing  906  or ACD  127  may be fixedly attached to an exterior of the housing  906 . As shown, once a user is authenticated (e.g., via process  700  of  FIG. 7 ), the ACD  127  may generate and send the access signal  129  to the motor  910 . In some examples, the motor  910  or other actuator is configured to alter a position of the door  902  between an open position and a closed position by way of lever arm  908 . 
     CONCLUSION 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.