HK1242032B - First entry notification - Google Patents

Description

First entry notification

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 62/048,702, filed September 10, 2014, which is hereby incorporated by reference in its entirety.

Technical Field

The present disclosure generally relates to access control systems and methods of operating access control systems.

Background Art

A smart card, chip card, or integrated circuit card (ICC) is any pocket-sized card with an embedded integrated circuit. Smart cards are typically made of plastic. A common use of smart cards is for security in hotels, etc.

Hotels and other multi-room facilities often utilize property management systems that are separate from the access control systems used to physically secure the rooms within the facility. For example, hotels have traditionally used their property management systems to manage and assign guest rooms and track transactions such as guest spending at restaurants, waitstaff, mini-bars, and other in-room purchases. During guest check-in at the hotel front desk, a new guest account is typically created in the property management system for each room.

Summary of the Invention

In an environment where guests can check in without the front desk, hotels face new challenges. One of these challenges is completing a guest check-in in the property management system, even though the guest never came to the front desk to check in. There's a desire to allow guests to bypass the front desk to make the guest experience more administratively efficient and less burdensome. However, without requiring the guest to visit the front desk, a way is needed to communicate the guest's check-in from the access control system back to the property management system, even though these two systems are separate and independent.

Thus, one aspect of the present disclosure allows an access control system to detect, record, and automatically distribute information about the first time a given electronic key arrives at or enters a given 'offline lock.' Previously, automatic distribution of this information was possible for 'online locks,' but not for 'offline locks.'

An 'online lock' is a lock with built-in networking capabilities that enables it to automatically report events to the access control system. Typical events might be key usage, door opening, etc. Typical networks used might be wired or wireless Ethernet, RF networks, etc.

In contrast, an 'offline lock' is a lock that has no such network capabilities and, therefore, has no means of automatically reporting lock events to the access control system.

In some embodiments, the proposed access control system includes the following components:

a1) Generation of access codes/credentials: Generates an electronic key that can be stored on a phone (or other mobile device) and then used at the lock;

a2) Secure distribution of electronic keys to target phones/devices;

a3) Software on the phone/device that stores the electronic key and sends it to the lock, typically using radio frequency (RF) communications;

a4) Offline lock electronics and firmware that receives the electronic key from the phone/device, decrypts the electronic key, and decides whether to authorize access.

In some embodiments, an electronic key may be distributed to a mobile device via an electronic key delivery path. As a non-limiting example, an electronic key is generated in response to a request from an external system (e.g., a property management system). The key is securely distributed to a software application on the intended recipient's phone/mobile device. Depending on encryption requirements, customer preferences, etc., this distribution uses standard networks and protocols available to the device, such as Wi-Fi or cellular data. When the phone/mobile device is presented to a lock within an access control system, the key is sent to the electronic lock product via RF, Bluetooth, infrared, or some other contactless delivery mechanism. Within the electronic lock product, the access control logic on the lock (e.g., firmware) checks the key and determines whether access is authorized.

In some embodiments, the lock is offline, meaning the lock itself cannot report generated information to the access control system via a shared network. In the proposed system, a path reverse to the key delivery path is used to transmit information from the lock back to the access control system. Rather than using a dedicated network available to 'online locks,' the network available to phones/mobile devices is used. This allows more 'offline locks' to be used in access control systems, significantly reducing the overall cost associated with implementing a system (e.g., because no dedicated wiring or networking components are required to support the reporting mechanism).

Regarding the return path, when the phone/mobile device is presented to the lock, information from the lock is sent from the electronic lock product and firmware to the phone/mobile device's software application via RF, Bluetooth, infrared, or some other contactless delivery mechanism. Information included in this communication may include, but is not limited to: the current time (e.g., corresponding to the transaction time), the lock's identity, the result of the access control decision (whether access is granted), and whether this is the first time the key has been used on that lock or with any lock. The software application then sends this information back to the origination portion of the access control system using the phone/mobile device's available network and/or protocol. Upon receiving this information from the phone/mobile device, the origination portion of the access control system can register that the key has reached its destination and has been used. Additionally, arrival/first entry information can be sent from various points in the access control system back to other external systems (e.g., a property management system).

While examples of the present disclosure will primarily be discussed in conjunction with access control systems for hotels or similar types of multi-room facilities, it should be understood that embodiments of the present disclosure are not limited thereto. As some non-limiting examples, embodiments of the present disclosure may be used in the following types of access control systems: hotels (where guests arrive at their rooms); residences (where workers arrive at their homes); offices (where employees arrive to start work), and the like.

In a specific example of an embodiment of a hotel implementation of the present disclosure, the following steps may occur: (1) The hotel operator arranges for the property management system to request that a room access key be generated for a guest at the hotel; (2) An electronic key is generated and sent to the access control system application on the guest's phone/mobile device; (3) The guest arrives at the hotel and presents the phone to open the appropriate lock; (4) Information (e.g., room identifier/success/first use/etc.) is sent back to the phone application; (5) The phone application sends the above information back to the initiator of the access control system; and then, (6) the information is also distributed back to the hotel operator. Once the hotel operator receives the information, the information can potentially be stored in the property management system database along with other information (e.g., which network carried the electronic key and access information to and from the mobile device during step (5)). It should be understood that in some embodiments, some of the steps listed above may be performed in parallel/simultaneously rather than sequentially. As a non-limiting example, steps (4), (5) and/or (6) may occur in the same transaction as that used when the guest presents the phone to the appropriate lock in step (3), thereby eliminating the need for the guest to present the phone to the lock multiple times.

The present invention can be further understood from the accompanying drawings and the following detailed description. Although this description records specific details, it should be understood that certain embodiments of the present invention can be practiced without these specific details. It should also be understood that in some instances, well-known circuits, components, and techniques are not shown in detail to avoid obscuring the understanding of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is described with reference to the accompanying drawings:

FIG1 is a block diagram illustrating a communication system according to an embodiment of the present disclosure;

2 is a block diagram depicting components of a mobile device according to at least some embodiments of the present disclosure;

3 is a block diagram depicting components of a lock/reader according to at least some embodiments of the present disclosure;

4 is a flow chart depicting a method of generating and transmitting keys to a mobile device according to an embodiment of the present disclosure;

FIG5 is a flowchart depicting a method for reporting first interaction data according to an embodiment of the present disclosure;

FIG6 is a flowchart illustrating a method for distributing first interaction data according to an embodiment of the present disclosure;

7 is a flow chart depicting steps for using a key delivery path and a reverse path of the key delivery path according to an embodiment of the present disclosure;

8 is a flow chart depicting a method for performing a check-in process in response to receiving an indication of a first entry at a property management system according to an embodiment of the present disclosure; and

9 is a flow chart depicting a method of generating a direct-to-room check-in report according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

The following description provides only embodiments and is not intended to limit the scope, applicability, and configuration of the claims. Instead, the following description will provide those skilled in the art with an enabling description for implementing the described embodiments. It should be understood that various changes may be made to the function and arrangement of elements without departing from the spirit and scope of the appended claims.

The following description will provide various embodiments or features of a system that may include an access control system that facilitates interaction between multiple components. Although embodiments of the present disclosure are discussed in conjunction with an access control system that interacts with a property management system of a hotel or the like, it should be understood that embodiments of the present disclosure are not limited thereto.

With reference now to Figures 1-9, various details and features related to access control systems and methods of operating access control systems will be described in accordance with at least some embodiments of the present disclosure. Referring first to Figure 1, a communication system 100 will be described in accordance with at least some embodiments of the present disclosure. System 100 is shown as including one or more communication networks 104, an access control network 108, and an optional trust network 112. Although described as two separate and distinct networks, it should be understood that the communication network 104 can be implemented as a single network. Similarly, although the network 104 and the trust network 112 are described as separate networks, it should be understood that the networks can be combined or one network (e.g., the trust network 112) can be overlaid on top of the communication network 104 via a communication tunnel (e.g., a virtual private network (VPN), a wide area network (WAN), etc.). Thus, without departing from the scope of the present disclosure, the communication network 104 can include the trust network 112 overlaid thereon.

The access control network 108 can provide connectivity between one or more access control servers 140 and a plurality of readers 128, check-in devices 148, and other components of the access control system. Thus, the access control network 108 can support the management and implementation of physical access control systems (PACS), among others. The access control network 108 can use any type of known communication protocol to carry information between components connected to the access control network. Non-limiting examples of such protocols or networks that can be used within the access control network 108 include RS-232, RS-485, Wiegand, Ethernet, Power over Ethernet (PoE), ZigBee, Wi-Fi (e.g., IEEE 802.11, a variant of IEEE 802.11, or an extension of IEEE 802.11), an Internet Protocol (IP) network, or any other type of wired or wireless protocol.

The communication network 104 may correspond to a private, semi-private, or public communication network for carrying information between compatible communication devices. In some embodiments, the communication network 104 may correspond to an untrusted or unsecured communication network. Non-limiting examples of the communication network 104 include a telephone network, a cellular network, an IMS network, a wide area network (e.g., the Internet), a local area network, an IP network, an SNMP network, or any other known type of network architecture. One or more of email messages, SMS messages, MMS messages, SNMP messages, messages transmitted using HTTP or SHTTP or variants thereof, messages exchanged using FTP, messages exchanged using RTP or UDP, and the like may be used to carry information between the access control server 140 and the mobile device 116. In some embodiments, voice over IP (VoIP) and the like may also be used to carry information between the access control server 140 and the mobile device 116.

Reader 128 may correspond to any type of interactive device or a collection of interactive devices that restrict or control access to one or more protected assets. In some embodiments, reader 128 may be configured to exchange communications directly with mobile device 116 via communication channel 136. Communication channel 136 may be a contactless communication channel in some embodiments. Alternatively or additionally, communication channel 136 may be a contact-based communication channel. In some embodiments, electromagnetic radiation in the form of radio frequency (RF) waves may be used to carry information on communication channel 136. Alternatively or additionally, communication channel 136 may utilize light, magnetism, sound, or any other medium to carry information between reader 128 and mobile device 116. Communication channel 136 may also be characterized as a communication protocol used to exchange information. In some embodiments, signal modulation (e.g., amplitude modulation, frequency modulation, phase modulation, combinations thereof, and variations thereof, etc.) is used to transmit data between reader 128 and mobile device 116. Some non-limiting examples of the protocol(s) used on the communication channel 136 include protocols defined in ISO 14443, ISO 15693, ISO 18092, FeliCa, near field communication (NFC), Bluetooth, Wi-Fi (e.g., 802.11N, and its variants or extensions thereto), ZigBee, GSM, combinations thereof, and the like. It should be further understood that, depending on the capabilities of the mobile device 116 and the reader 128, multiple communication channels 136 can be established between the devices. For example, the reader 128 and the mobile device 116 can establish a first communication channel using a first protocol (e.g., Bluetooth or Bluetooth Low Energy (BLE)) and a second communication channel using a second protocol (e.g., NFC, infrared, etc.). It should be understood that the communication channel 136 can correspond to a proximity-based communication channel that can only be established when the mobile device 116 and the reader 128 are within a predetermined distance of each other (e.g., less than 0.5 meters for NFC, less than 50 meters for BLE, or less than 200 meters for Wi-Fi). The communication channel 136 can be further characterized as an authentication protocol used by devices (eg, reader 128 and mobile device 116) to authenticate each other. Examples of authentication protocols that can be used over the communication channel 136 include SEOS and FIDO.

Although the term "reader" is used herein to refer to a device or collection of devices used to control access to a protected asset (e.g., a physical asset such as a room door, a safe, etc.), it should be understood that the terms "reader," "lock," and the like may be used interchangeably. For example, the networked reader 128 shown in FIG. 1 may also be referred to as an 'online lock.' Similarly, as discussed further herein, the non-networked reader 132 may be synonymously referred to as an 'offline lock.' In other words, the use of the terms "lock," "reader," and other similar terms may be used to describe an electromechanical device or collection of devices used to protect and secure an asset, such as a physical asset. Additionally, the readers or locks discussed herein may be used to protect and secure logical assets, such as bank accounts, computer network resources, and the like.

In addition to the conventional readers 128 described as being connected to the access control network 108, the communication system 100 also includes one or more non-networked readers 132 or 'offline locks'. The non-networked readers 132 may differ from the readers 128 in that the non-networked readers 132 may not be natively or permanently connected to the access control network 108, which limits the ability of the non-networked readers 132 to communicate with the access control server 140 or other devices on an ad hoc basis. Thus, embodiments of the present disclosure contemplate the use of a communication channel 136 to facilitate the communication of information from the non-networked readers 132 to the mobile devices 116, and ultimately return the information to the access control server 140 and other devices. Thus, the components of the non-networked readers 132 may be similar to or identical to the components of the readers 128, except that the non-networked readers 132 may lack a communication interface for communicating with the access control network 108 or such interface may be disabled or unused.

Mobile device 116 can correspond to any type of electronic device, and as the name implies, electronic devices are portable in nature. As some examples, mobile device 116 can correspond to a cellular phone or smart phone carried by a user. Other examples of mobile device 116 include, but are not limited to, wearable devices (e.g., glasses, watches, shoes, clothing, jewelry, wristbands, stickers, etc.). As shown in Figure 1, mobile device 116 can be provided with access control application 120, which stores one or more keys 124. (Multiple) keys 132 can be transmitted to readers 128, 132 associated with the holder of mobile device 116 attempting to enter the asset protected by reader 128, 132. For example, the user or holder of mobile device 116 can present mobile device 116 to reader 128, 132.

In some embodiments, the key(s) 124 may be distributed from the access control server 140 to the mobile device 116 via the communication network 104. In other embodiments, the key(s) 124 may be transmitted to the mobile device 116 via a check-in device 148, which receives the keys from the access control server(s) 140 via the access control network 108. Additional details of the first key delivery mechanism are described in U.S. Patent No. 8,074,271 to Davis et al. and U.S. Patent No. 7,706,778 to Lowe, both of which are hereby incorporated by reference in their entireties. Additional details of the second key delivery mechanism (e.g., the use of the check-in device 148) are described in U.S. Patent No. 8,730,004 to Elfstrom et al., the entire contents of which are hereby incorporated by reference in their entireties. The access control module described in the 004 patent may have features similar to those of the readers 128 and 132 described herein. Still further, the networking and communication behavior of the reader 128 may be similar to the parent-child device described in US Pat. No. 8,102,799 to Alexander et al., the entire contents of which are hereby incorporated by reference herein.

If NFC is used for the communication channel 136, the readers 128, 132 and the mobile device 116 may inductively couple their interfaces/antennas to one another at a point where the readers and/or mobile device 116 authenticate one another or each other. Following authentication, the readers 128, 132 may request the key 124 or keys from the mobile device 116 or the mobile device 116 may provide the key 124 or keys to the readers 128, 132. Upon receiving the key(s) 124 from the mobile device 116, the readers 128, 132 may analyze the key(s) 124 and determine whether the key(s) 124 are valid, and if so, allow the owner/user of the mobile device 116 access to the asset protected by the readers 128, 132. It should be understood that the mobile device 116 may alternatively or additionally be configured to analyze information received from the readers 128, 132 in connection with making access control decisions and/or in connection with determining whether to provide the key(s) 124 to the readers 128, 132.

If BLE or some other non-sensing protocol (e.g., Wi-Fi) is used for the communication channel 136, then the readers 128, 132 and the mobile device 116 may perform a discovery routine to establish the communication channel 136 before pairing or otherwise connecting with each other. However, after establishing the channel 136, the readers 128, 132 and the mobile device 116 may authenticate each other and exchange information related to, for example, the key(s) 124 so that an access control decision can be made. If a positive access control decision is made (e.g., a determination that the key(s) 124 are valid and that the mobile device 116 is allowed to access the asset protected by the readers 128, 132), then the readers 128, 132 may initiate one or more actions to enable the owner or user of the mobile device 116 to access the asset protected by the readers 128, 132.

As will be discussed further herein, reporting of information from the networked reader 128 to the access control server 140 and/or to the property management system 144 is relatively straightforward. For example, when a user presents the mobile device 116 to the reader 128, information regarding the exchange can be provided from the reader 128 to the access control server 140 or the property management system 144 via the access control network 108. On the other hand, the non-networked reader 132 does not have the native ability to report the same type of information directly to the access control server 140 or the property management system 144. Therefore, it is desirable for the non-networked reader 132 to utilize the communication channel 136 as a mechanism for transmitting information regarding the first interaction (or first key use or some other transaction information) back to the access control server 140 or the property management system 144. Furthermore, once the mobile device 116 (or more specifically, the access control application 120 running on the mobile device 116) has the interaction data from the non-networked reader 132, the mobile device 116 can decide whether to report the information to the access control server 140 via the communication network 104 or whether the information can and should be reported directly to the property management system 144 using the trusted network 112. As a non-limiting example, the non-networked reader 132 can indicate to the mobile device 116 that the trusted network 112 will be used to transmit the interaction data back to the property management system 114 because the trusted network 112 may be under the control of the entity that manages the property management system 144 (e.g., the hotel operator). In some embodiments, the mobile device 116 can report the interaction data to the access control server(s) 140 and the property management system simultaneously via the communication network 104 and the trusted network 112 (via two reporting messages).

2 , additional details of the mobile device 116 will be described in accordance with at least some embodiments of the present disclosure. Among other items, the mobile device 116 is shown as including computer memory 204 storing one or more operating systems (O/S) 208 and a key 212. The mobile device 116 is also shown as including a processor 216, one or more drivers 220, a user interface 224, a reader interface 228, a network interface 232, and a power module 236. Suitable examples of the mobile device 116 include, but are not limited to, smartphones, PDAs, laptops, personal computers, tablets, netbooks, wearable devices, and the like.

The memory 204 may correspond to any type of non-transitory computer-readable medium. In some embodiments, the memory 204 may include volatile memory or non-volatile memory and controllers therefor. Non-limiting examples of the memory 204 that may be used in the mobile device 116 include RAM, ROM, cache memory, flash memory, solid-state memory, or variations thereof.

O/S 208 may correspond to one or more operating systems. The nature of O/S 208 may depend on the hardware of mobile device 116 and the form factor of mobile device 116. O/S 208 can be considered an application stored in memory 204 and executable by the processor. O/S 208 is a special type of general-purpose application that enables other applications stored in memory 204 (e.g., a browser, an email application, an SMS application, etc.) to utilize the various hardware components of mobile device 116 and driver(s) 220. In some embodiments, O/S 208 may include one or more APIs that facilitate interaction between applications and certain hardware components of mobile device 116. In addition, O/S 208 may provide a mechanism for viewing and accessing the various applications stored in memory 208 and other data stored in 208.

Key 212 may be similar to or identical to key 124 described in FIG. 1 . In some embodiments, key(s) 212 may be stored in the same physical memory 204 as O/S 208. In other embodiments, key(s) 212 may be stored in physical computer memory separate from the computer memory used to store O/S 208 and other applications. Even more specifically, key(s) 212 may be stored in secure or encrypted computer memory to prevent the keys contained therein from being obtained or manipulated by unauthorized parties. Access to the keys may be predictable based on the occurrence of certain events and/or user input. For example, a user may be required to enter a valid password or PIN at user interface 224 before key(s) 212 are distributed to reader 128 , 132 .

Processor 216 may correspond to one or more microprocessors contained within the housing of mobile device 116 with memory 204. In some embodiments, processor 216 incorporates the functionality of the central processing unit (CPU) of mobile device 116 on a single integrated circuit (IC) or several IC chips. Processor 216 may be a multi-purpose programmable device that receives digital data as input, processes the digital data according to instructions stored in its internal memory, and provides results as output. Processor 216 may implement sequential digital logic due to its internal memory. As is well known with microprocessors, processor 216 may operate on numbers and symbols represented in the binary number system.

Driver(s) 220 may correspond to hardware, software, and/or controllers that provide specific instructions to the hardware components of mobile device 116, thereby facilitating their operation. For example, user interface 224, reader interface 228, and network interface 232 may each have a dedicated driver 220 that provides appropriate control signals to affect their operation. Driver(s) 220 may also include software or logic circuitry that appropriately controls various hardware components according to desired protocols. For example, driver 220 for reader interface 228 may be adapted to ensure that reader interface 228 complies with an appropriate proximity-based protocol (e.g., BLE, NFC, infrared, ultrasound, IEEE 802.11N, etc.) so that reader interface 228 can exchange communications. Similarly, driver 220 for network interface 232 may be adapted to ensure that network interface 232 complies with an appropriate network communication protocol (e.g., TCP/IP (at one or more layers of the ISI model), UDP, RTP, GSM, LTE, Wi-Fi, etc.) so that network interface 232 can exchange communications via communication network 104, trusted network 112, etc. As can be appreciated, the driver(s) 220 may also be configured to control wired hardware components (eg, USB drivers, Ethernet drivers, etc.).

As mentioned above, the user interface 224 may include one or more user input devices and/or one or more user output devices. Examples of suitable user input devices that may be included in the user interface 224 include, but are not limited to, buttons, keyboards, mice, pens, cameras, microphones, and the like. Examples of suitable user output devices that may be included in the user interface 224 include, but are not limited to, display screens, lights, speakers, and the like. It should be understood that the user interface 224 may also include combined user input and user output devices, such as, touch-sensitive displays, and the like.

The reader interface 228 may correspond to hardware that facilitates communication between the mobile device 116 and the readers 128, 132. The reader interface 228 may include a Bluetooth interface (e.g., an antenna and associated circuitry), a Wi-Fi/802.11N interface (e.g., an antenna and associated circuitry), an NFC interface (e.g., an antenna and associated circuitry), an infrared interface (e.g., an LED, a photodiode, and associated circuitry), and/or an ultrasound interface (e.g., a speaker, a microphone, and associated circuitry). In some embodiments, the reader interface 228 is specifically configured to facilitate proximity-based communication via the communication channel 136 or multiple communication channels 136.

The network interface 232 may include hardware that facilitates communication with other communication devices over the communication network 104 or the trusted network 112. As described above, the network interface 232 may include an Ethernet port, a Wi-Fi card, a network interface card (NIC), a cellular interface (e.g., an antenna, filters, and associated circuitry), etc. The network interface 232 may be configured to facilitate connections between the mobile device 116 and the communication networks 104, 112 and may also be configured to encode and decode communications (e.g., data packets) according to the protocols used by the communication networks 104, 112.

The power module 236 may include a built-in power source (e.g., a battery) and/or a power converter that facilitates conversion of externally provided alternating current (AC) power to direct current (DC) power for powering the various components of the mobile device 116. In some embodiments, the power module 236 may also include some implementation of surge protection circuitry to protect components of the mobile device 116 from power surges.

3 , additional details of the non-networked reader 132 will be described in accordance with at least some embodiments of the present disclosure. The non-networked reader 132 is depicted in FIG3 , but it should be understood that similar components may be included within the networked reader 128 . The distinction between the networked reader 128 and the non-networked reader 132 may correspond to the fact that the networked reader 128 has a network interface that connects the reader 128 to the access control network 108 via a wired or wireless communication channel. However, the non-networked reader 132 lacks a network interface or such an interface is deactivated or unavailable by the non-networked reader 132 . In some embodiments, a reader that has intermittent, but non-continuous, communication capability with a network may be considered a non-networked reader 132 . Thus, any reader that does not have the ability to communicate on demand via a communication network may be considered a non-networked reader 132 .

Reader 132 is shown as including computer memory 304 storing, among other items, access control logic 308, usage log 312, and first use information 316. Mobile device 132 is also shown as including processor 320, one or more drivers 324, user interface 224, credential interface 332, and power module 336.

In some embodiments, access control logic 308 is implemented as firmware, although it is also possible to implement access control logic 308 as software or in an application specific integrated circuit (ASIC). In some embodiments, usage log 312 may include information about interactions between reader 132 and credentials, such as between mobile device 116 and a traditional access control card or key fob, which may be referred to as a credential-like device. The types of information that may be stored in usage log 312 include the date and time of the interaction with the credential-like device, whether such interaction corresponds to the first or subsequent interaction with a particular device, which key was used during the interaction, the results of the access control decision made by access control logic 308, and the like. In addition to usage log 312, memory 304 may also include first-time use information for instances of first-time use of a key and/or the first instance of interaction between a particular credential-like device and reader 132.

In some embodiments, a key 124, 212 can be updated after its first use, so that all subsequent readers know that they are not receiving the key 124, 212 as the first instance of that key being used in an access control system. For example, after the key 124, 212 is first transmitted to a reader 128, 132, the key 124, 212 can be updated with a flag or identifier. Subsequent transmissions or uses of the key 124, 212 include an updated flag or identifier indicating that the key is no longer being used for the first time. Thus, when a reader 128, 132 receives a key 124, 212 and the key is not marked as previously used, the reader 128, 132 will know that it received the key 124, 212 during its first use. This information can be stored in first-use information 316 along with the transaction time, the identity of the mobile device 116, the identity of the reader 128, 132, and whether access was granted or denied. The first-time usage information 316 and/or information from the usage log 312 may then be transmitted by the reader 132 back to the mobile device 116 via the communication channel 136 and subsequently transmitted to the access control server(s) 140 and/or the property management system 144 .

The processor 320 of the reader 132 is substantially similar to the processor of the mobile device 116. In some embodiments, the processing power of the processor 320 may be limited compared to the processing power of the processor 216. For example, the processor 320 may include an IC chip or multiple IC chips configured to execute hardware or instructions stored in the memory 304.

Likewise, driver(s) 324 may include software, firmware, or embedded hardware that facilitates the operation of components of reader 132. For example, user interface 328 may have a dedicated driver 324. Credentials interface 332 may also have a dedicated driver 324. Other components of reader 132 may also have their own drivers 324.

The user interface 328 may correspond to a user input and/or user output device. Within the reader 132, the user interface 328 is traditionally a relatively simple device, but simplicity is not a requirement. For example, the user interface 328 may include a simple visual display (e.g., a light, an LED, an eight-segment display, etc.) or a more sophisticated visual display (e.g., an LCD screen). The user input portion of the user interface 328 may include a PIN pad, a fingerprint sensor, a retinal scanner, etc. The user interface 328 may also facilitate auditory interaction with the reader 132. For example, the user interface 328 may include a buzzer, a speaker, a microphone, a photodetector, a proximity detector, etc. Alternatively or additionally, the user interface 328 may include a combined user input and user output device, such as a touch-sensitive display with configurable buttons.

Credential interface 332 may include hardware, circuitry, and the like that facilitates establishment of communication channel 136. As some non-limiting examples, credential interface 332 may include an antenna, a tuning circuit, a BLE antenna, a Wi-Fi antenna, a magnetic stripe reader, a photodetector, an infrared transmitter, a microphone, a speaker, and the like.

The power module 336 may correspond to a dedicated power supply and/or a power converter that facilitates conversion of externally provided alternating current (AC) power to direct current (DC) power for powering the various components of the mobile device 132. In some embodiments, the power module 336 may also include some implementation of surge protection circuitry to protect components of the mobile device 132 from power surges.

With reference now to FIG. 4 , a method for transmitting keys 124 , 212 to a mobile device 116 will be described in accordance with at least some embodiments of the present disclosure. The method begins when a request for an electronic key or set of electronic keys is received at a property management system 144 (step 404 ). The request may be received in response to a guest confirming a desire to stay at a hotel, in response to a guest confirming a desire to enter a room, in response to an office guest confirming a meeting at the office, and so forth. The request for the key may then be forwarded from the property management system 144 to the access control server 140 . Upon receiving the request for the electronic key from the property management system 144 , the access control server(s) 140 determine whether the request is a valid and viable request (e.g., whether the request is from a trusted source, is in a trusted format, and should result in the generation of an electronic key). Authentication between the access control server(s) 140 and the property management system 144 may be accomplished using any type of authentication protocol.

If authentication is successful, the access control server(s) 140 determine the attributes of the electronic key (step 408). These attributes may include a property or site code to be assigned to the electronic key, the encryption of the electronic key, the validity period of the electronic key (which may be indeterminate or deterministic), and other attributes that may belong to the key. Based on these attributes, the access control server(s) 140 generates the electronic key(s) (step 412) and then determines one or more targets for the key (step 416). The targets of the key(s) may include one or more mobile devices 116 identified in the request for the key in step 404. Alternatively or additionally, the targets of the key(s) may include credentials other than mobile devices 116, such as conventional smart cards, key fobs, and the like.

After determining the destination of the key, the access control server(s) 140 determine whether it is time to distribute the key (step 420). The distribution time may be based on the amount of time before the guest's expected arrival or check-in. Alternatively or additionally, the distribution time may be event-based or triggered by a series of events. Of course, distribution can be both time-based and event-based. As an example of time-based distribution, electronic keys may not be distributed to the target device until a predetermined amount of time before the guest's expected check-in at the hotel has occurred. As another example of time-based distribution, electronic keys may not be distributed to the target device until a predetermined amount of time before a scheduled meeting has occurred. As an example of event-based distribution, electronic keys may not be distributed until the guest is within a predetermined distance or proximity of the hotel, room, or office building. Another example of event-based distribution is to wait until the mobile device 116 connects to a predetermined communication network 104 or trusted network 112. An example of a combination of time-based and event-based distribution is to limit key distribution until a predetermined amount of time before the guest's expected check-in and until the guest's mobile device 116 has connected to the trusted network 112 of the property where the guest is checking in.

If the query at step 420 is negatively responded to, then the access control server(s) 140 continue to monitor events, time, and other triggers to determine an appropriate time for delivery (step 424). If the query at step 420 is positively responded to, a suitable distribution protocol and channel are determined for the delivery of the electronic key(s) (step 428). For example, it may be determined that the keys can be delivered to the mobile device 116 over the communication network 104 using a cellular network and cellular communication protocol. As another example, it may be determined that a more secure delivery channel is required, in which case the trusted network 112 may be required for the delivery of the keys.

After determining the appropriate channel and protocol, the electronic key(s) are transmitted to their destination via the determined channel and protocol. The key(s) can be transmitted using conventional protocols such as HTTP/HTTPS, SNMP, FTP, SMS messaging, MMS messaging, RTP, UDP, etc., or non-conventional/proprietary protocols. In some embodiments, the path used to transmit the key to the destination may be referred to as a key delivery path and may follow a specific set of nodes when propagating across the communication network 104 or the trust network 112.

With reference now to Figure 5, a method for reporting first interaction data will be described according to an embodiment of the present disclosure. The method begins when the mobile device 116 is presented to the reader 128, 132 (step 504). This may include bringing the mobile device 116 within the communication range of the reader 128, 132, pairing the mobile device 116 with the reader 128, 132, and the like. Once these devices are within the communication range of each other, an initial authentication may be performed (step 508). Depending on user selections and management settings at the reader 128, 132 and/or the mobile device 116, authentication may be bidirectional or unidirectional. If authentication fails (step 512), the method will end or a retry of authentication will be allowed (step 516).

If authentication is successful (step 512), the two devices may proceed by exchanging access control information (step 520). During this step, the mobile device 116 may transmit one or more electronic keys to the readers 128, 132 via the communication channel 136 established between the two devices. During this step, the readers 128, 132 may also provide identification information and/or keys to the mobile device 116. Any other type of information used in making access control decisions may be exchanged between the two devices via the communication channel 136 (in either direction).

Based on the information exchanged in step 520, the reader 128, 132 and/or the mobile device 116 may make a decision as to whether to allow the owner of the mobile device 116 to access the asset protected by the reader 128, 132 (step 524). If the query is negatively responded to, the reader 128, 132 may update its usage record 312 (step 528). The reader 128, 132 may then end the exchange or allow a retry (step 516).

If the query at step 524 is answered affirmatively, the reader 128, 132 determines whether this is the first interaction of the mobile device 116 with the access control system (e.g., whether this corresponds to a first entry event) (step 532). This determination may correspond to determining whether the interaction between a particular mobile device 116 and the reader 128, 132 is generally a first interaction. This determination may also include determining whether the key used by the mobile device corresponds to a first use instance of the key, either globally (e.g., across all readers of the access control system) or locally (e.g., specific to the current reader 128, 132). As discussed above, the reader 128, 132 may analyze the properties of the key to determine whether it has been previously used, for example, by analyzing the key for some indication of first use (or subsequent use, as indicated by a usage flag in the key). Analyzing the key in contrast to the mobile device 116 may be useful, particularly for frequent property guests. For example, a guest may stay at a particular hotel several times in a year, but the guest's mobile device 116 may use a different key during each of these stays. If the mobile device 116 itself is analyzed for the first interaction, then all subsequent stays during the year will not be registered as check-in events. On the other hand, if the key used for a particular stay is analyzed, then an appropriate check-in can be determined for each stay instance.

It should be understood that when the mobile device 116 is denied access, the analysis of step 532 may be performed at step 528. For ease of understanding and simplicity, step 532 is shown as only beginning with a positive access control decision, but should not be construed as limiting embodiments of the present disclosure.

If the interaction corresponds to a first interaction (or the first use of a key by mobile device 116), readers 128, 132 may generate a set of first interaction data and attempt to report the first interaction data back to access control server(s) 140 and/or property management system 144. If the reader 128 is a networked reader, the first interaction data may simply be sent to the access control server 140 and/or property management system 144 via access control network 108. On the other hand, if the reader corresponds to a non-networked reader 132, reader 132 will provide the first interaction data to mobile device 116 (step 536). In some embodiments, the first interaction data is provided to mobile device 116 over communication channel 136 used to exchange access control information. If the decision is made quickly enough in step 532, non-networked reader 132 may even provide the first interaction data back to mobile device 136 during the same presentation instance used to transmit the access control information. In other words, the user does not need to present mobile device 116 to reader 132 twice to facilitate the communication of steps 520 and 536. Conversely, when the mobile device 116 is held in front of the reader 132 and awaiting an access control decision, the first interaction data can be efficiently transmitted back to the mobile device 116 .

Non-limiting examples of the type of information that may be provided in the first interaction data include the identity or identification number of the reader 132, a key or guest identifier, the time of the transaction, the date of the transaction, whether the access control decision was positive or negative, the current temperature, reader 132 status information (e.g., low battery), and the like.

Thereafter, the reader 128 , 132 authorizes the mobile device 116 and its owner to access the assets protected by the reader 128 , 132 (step 540 ).

6 , a method for distributing first interaction data will be described according to an embodiment of the present disclosure. The method begins when the mobile device 116 receives first interaction data from the reader 132 (step 604). The first interaction data may be received via the communication channel 136 used during authentication and/or during access control information exchange.

When the mobile device 116 receives the first interaction data, it determines the recipient address of the first interaction data (step 608). This information may be included within the first interaction data, provided to the mobile device 116 as a separate instruction from the reader 132, or the mobile device 116 may include functionality to make such a determination (e.g., it may be included as part of the access control logic 308). The mobile device 116 may also determine which communication channel or path should be used to transmit the first interaction data to the recipient address (step 612). In some embodiments, the mobile device 116 may determine that the first interaction data should be transmitted along the reverse path of the key delivery path. In other words, the mobile device 116 may simply send the first interaction data to the same entity from which it received its electronic key, and the mobile device 116 may use the same communication channel/network to send the first interaction data. In other embodiments, the administrator of the access control system may direct that the first interaction data be delivered directly to the property management system 144 and that the information be delivered via the trusted network 112 delivery path rather than along the reverse path of the key delivery path.

Once the recipient address and the appropriate communication channel are determined, the mobile device 116 generates an appropriate message or set of messages containing the first interaction data (step 616). The mobile device 116 then sends the message(s) to the determined recipient address (step 620).

Referring now to FIG. 7 , additional details of the communication path for delivering electronic keys and first interaction data will be described in accordance with at least some embodiments of the present disclosure. The process described in FIG. 7 begins when the property management system 144 sends an electronic key request to the access control server(s) 140 (step S701). In response to receiving the request, the access control server(s) 140 sends one or more electronic keys to the target mobile device 116 (step S702). In some embodiments, the delivery of the electronic keys in step S702 utilizes a communication network and may include the use of multiple network types (e.g., the Internet and a cellular communication network). Therefore, the path propagated by the message(s) carrying the electronic keys may traverse multiple network boundaries and multiple network boundary elements.

Mobile device 116 then receives the electronic key and stores it in its access control application 120 or memory 204. Mobile device 116 retains the key until it is presented to non-networked reader 132 (or networked reader 128), at which point communication between the two devices can begin and authentication occurs (step S703). If a trust relationship can be established, the electronic key can be delivered to non-networked reader 132 using communication channel 136 (step S704). Non-networked reader 132 can then make an access control decision based, at least in part, on the contents of the electronic key. Non-networked reader 132 may also determine that its receipt of the electronic key from mobile device 116 corresponds to the first use of the electronic key. In this case, non-networked reader 132 may generate and deliver initial interaction data back to mobile device 116, again via communication channel 136 (step S705). In some embodiments, steps S703, S704, and S705 may be performed upon a single presentation of mobile device 116 to reader 132. Of course, these steps do not need to be performed at exactly the same time, but they can be performed within an amount of time that the user perceives as simultaneous to the user holding the mobile device 116. In other embodiments, step S705 can occur after the mobile device 116 is first presented to the reader 132 and the reader 132 can prompt the holder of the mobile device 116 to present the mobile device 116 to the reader 132 again, so that the check-in process can be completed and the reader 132 can deliver the first interaction data back to the mobile device 116.

The mobile device 116 then provides an indication of the result of the access control decision implemented on the reader 132 to the access control server(s) 140 (step S706). In addition, the mobile device 116 may deliver the first interaction data back to the access control server(s) 140 during step S706. The access control server(s) 140 may then provide the first interaction data to the property management system 144 (step S707). Alternatively or in addition, the mobile device 116 may deliver the first interaction data directly to the property management system 144 (step S708). As will be appreciated, the key delivery path and the first interaction data delivery path may generally match each other, but in reverse order. In other embodiments, the use of the communication channel 136 may correspond to the only commonality between the key delivery path and the first interaction data delivery path.

8 , a method for executing a check-in process in response to receiving an indication of a first entry at a property management system will be described in accordance with an embodiment of the present disclosure. The method begins when an indication of a guest's first entry is received at the property management system 144 (step 804). This indication may be received in response to the property management system receiving first interaction data from the access control server(s) 140 or the mobile device 116. The first interaction data may indicate that a particular guest (or a key associated with the guest) has reached a particular reader 128 , 132 and that the reader 128 , 132 has completed the first interaction instance with the guest's mobile device 116 for that particular stay.

Upon receiving the indication of a first-time entry, the property management system initiates a guest check-in process, wherein a new user account is created for the user, wherein the account is specific to the particular guest's stay and the room assigned to the guest (step 808). If the guest has a frequent guest account, the newly created account may be associated with the frequent guest account in the customer relationship management database. In some embodiments, at least some information in the first-time interaction data is used to populate the newly created account (step 812). For example, if the first-time interaction data includes an identifier of a reader 128, 132 that first interacts with a mobile device 116, and the reader 128, 132 corresponds to a room assigned or assignable to the guest (e.g., a vacant room), the reader identifier included in the first-time interaction data may be included in the newly created account to identify the room assigned to the guest. As another example, if the guest presents the mobile device 116 to a reader associated with a point-of-sale (PoS) machine for the first time, the reader identifier and the guest's transaction data may be merged into the newly created account.

The property management system 144 determines whether a passport is required for the guest's stay and then continues the method at step 816. If the query is answered negatively, the method continues by finalizing other check-in items for the user's account (e.g., confirming the guest's credit card on file, queuing the guest's itinerary, etc.).

However, if the query at step 816 is answered affirmatively, the guest may be asked to provide additional information to confirm their identity and that they possess a valid passport (step 820). In some embodiments, the guest can enter their passport information via the reader and/or mobile device 116. In some embodiments, the guest can provide a passport photo and transmit the photo to the property management system 144. In some embodiments, a customer service representative of the hotel is assigned to meet with the guest at a known location (e.g., toward the location of the reader where the initial interaction occurred) to verify the passport information.

After the passport analysis is complete (step 824), the method may continue to step 828 where other check-in items for the guest are completed.

Referring now to FIG. 9 , a method for generating a direct-to-room check-in report will be described according to an embodiment of the present disclosure. The method begins by determining that a remote hotel check-in has been requested (step 904). This request can be specifically provided during the guest's purchase of their room. Alternatively, after the purchase is complete, the user can be presented with a choice, which the user can accept or reject.

When the property management system 144 determines that the guest wishes to check in remotely, thereby allowing the user to bypass the front desk, the property management system 144 assigns a room to the guest prior to check-in or expected arrival (step 908). The assigned room may correspond to a specific room or suite of rooms that the guest has selected as available to the guest. The identification of the room assigned to the guest may be communicated via a message transmitted to the guest's mobile device 116.

The property management system 144 then creates a guest account before the guest arrives (step 912). The method then waits until a user's first entry or arrival is detected. Once the user's arrival is detected, first-time interaction data associated with the first arrival is sent from the reader 128 to the property management system 144 (step 924). The property management system 144 then generates a direct-to-room check-in report at the hotel front desk, just like a normal check-in.

It should be noted that these embodiments are described as processes depicted as flow charts, flow diagrams, data flow diagrams, structure diagrams, or block diagrams. Although a flow chart may describe operations as sequential processes, many operations may be performed in parallel or simultaneously. In addition, the order of operations may be rearranged without departing from the scope of the present disclosure. After these operations are completed, the process ends, but there may also be additional steps not included in the figure.

While illustrative embodiments of the present disclosure have been described in detail herein, it should be understood that the inventive concepts may be otherwise differently embodied and employed in other various ways and that the appended claims are intended to be interpreted to encompass such variations in addition to those limited by the prior art.

Claims (6)

1. A method for managing an access control system for a multi-room property with multiple locks, at least one of the locks being an offline lock and having no direct wired connection to the backend of the access control system, the method comprising: Confirm that the guest has requested remote check-in for the multi-room property; Assign rooms to the guests from the multi-room properties; Determine the lock used to secure the room; Generate an electronic key containing initial information supporting access to the identified lock; The electronic key is sent to the guest's mobile device, wherein the electronic key is sent to the mobile device via a wireless communication network; Determine that the mobile device is presented to the lock for the first time; The electronic key sent to the mobile device and the first information contained within the electronic key are analyzed at the electronic lock. Based on the analysis of the electronic key and the first information contained within the electronic key, it is determined that the guest is authorized to access the room; In response to determining that the guest is authorized to access the room, second information is sent from the lock to the mobile device, wherein the second information is sent to the mobile device only when the mobile device is first presented to the lock and the guest is authorized to access the room, and wherein the second information sent from the lock to the mobile device includes a room identifier, success information, and/or a first-time use indication; and Upon receiving the guest's first entry instruction, a guest account is created within the property management system of the multi-room property. 2. The method of claim 1, wherein the electronic key is provided to the lock via NFC coupling, and wherein the second information transmitted from the lock to the mobile device is also provided during the same NFC coupling, thereby eliminating the need for multiple connections between the mobile device and the lock. 3. The method of claim 1, wherein the electronic key is provided to the lock via a Bluetooth connection, and wherein, during the same Bluetooth connection, the second information sent from the lock to the mobile device is also provided, thereby eliminating the need for multiple connections between the mobile device and the lock. 4. The method of claim 1, wherein the second information sent from the lock to the mobile device is subsequently sent to the property management system and stored in the guest account. 5. The method of claim 1, wherein the second information regarding the first use of the mobile device together with the lock is deleted from the lock's memory after being sent from the lock to the mobile device. 6. The method according to claim 4, wherein the property management system generates a report at the front desk confirming the guest's registration and check-in.