HK1217799B - Methods and systems for management of key exchanges - Google Patents

Description

Method and system for managing key exchanges

Citation of Related Applications

This application claims priority to U.S. Application No. 61/765,618, filed on February 15, 2013, entitled “METHODS AND SYSTEMS FOR MANAGEMENT OF KEY EXCHANGES.” For United States purposes, this application claims the benefit of U.S. Application No. 61/765,618, filed on February 15, 2013, entitled “METHODS AND SYSTEMS FOR MANAGEMENT OF KEY EXCHANGES,” which is hereby incorporated by reference for all purposes.

Technical Field

The technology described herein relates to methods and systems for processing key exchanges.

Background Art

It is often necessary to provide one or more individuals with access to a locked property. For example, a visitor who has arranged to stay at the property may need access. Family, friends, property managers, tour guides, couriers, or service providers (e.g., cleaners, dog walkers, contractors, real estate agents, gardeners, etc.) may also need access. People may also need access to locked vehicles, storage units, or other types of properties. If the person holding the keys to the property cannot meet with the individual to provide access to the property, the individual may have difficulty accessing the property.

Sometimes, keys are hidden outside the property, and instructions for finding the keys are provided to individuals requiring access. In some cases, keys are stored in a lockbox outside the building. Typically, the lockbox has a keypad lock. Lockboxes are subject to security issues because any individual with the lockbox's PIN code can open the lockbox at any time to obtain the keys. Furthermore, lockboxes may not be feasible for multi-unit properties (e.g., apartments), which typically require individual key fobs, access cards, or building keys to access the building.

Sometimes, the keys may be given to a neighbor or other third party who can meet the individual to give him or her access to the asset. This solution relies on the presence of someone who can meet the individual at a specific location at a specific time. The logistics of coordinating such an event can be tedious, especially since the individual's arrival time may not always be as expected.

Methods and systems for addressing the aforementioned problems are generally desired. In particular, methods and systems for enabling individuals to obtain keys or sets of keys are desired. Methods and systems for facilitating access to assets in urban areas, including multi-unit structures, vehicles, warehouse units, and other assets requiring keys are desired.

The foregoing examples of the related art and limitations related thereto are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent to those skilled in the art upon reading the specification and studying the drawings.

Summary of the Invention

The technology described herein has various aspects including, but not limited to, methods for exchanging keys for accessing assets, computer systems for coordinating the provision of keys to individuals, devices for storing and making available keys, and systems for facilitating the provision of keys to individuals.

One aspect provides a method for facilitating the exchange of keys at a key access location. The method can be "asynchronous," meaning that preparatory steps for enabling an individual to obtain a key at a key access location do not need to occur simultaneously with the individual gaining access to the key. The method includes scanning to obtain a unique key identifier encoded on a key or a device attached to the key; identifying a key access location; assigning a storage bin to the key at the key access location; and associating the storage bin and the key access location with the identifier. Access rules for the key are received from an administrative user, wherein the access rules identify an authorized party and an authorized access period. The key access location is issued to the authorized party. An access request for the key is received from the authorized party via a client device, the access request providing user credentials. The access request is authenticated by verifying the user credentials provided in the access request against a set of credentials associated with the authorized party and comparing the time of the access request with the authorized access period. Authentication can additionally include comparing the identified individual location with the key access location associated with the identifier. If the access request is authenticated, an access instruction for submitting the key is sent.

In another aspect, verification of the key being presented is provided by receiving an identifier from a scanner (either on a client device or in a key storage device) that scans the key at a key access location.

Other aspects provide systems for implementing the above methods.

In addition to the exemplary aspects and embodiments described above, further aspects and embodiments will become apparent by reference to the drawings and by study of the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments are illustrated in the reference figures of the accompanying drawings. It is intended that the embodiments and figures disclosed herein be considered illustrative rather than restrictive.

FIG1 schematically depicts components of a system for handling key exchanges between individuals, according to one embodiment.

FIG. 2 is a flow chart illustrating a method for an administrative user to assign access rights to a key according to one embodiment.

FIG3 is a flow chart illustrating a method that may be performed at a key handover according to one embodiment.

4 is a flow chart illustrating a method that may be performed at key pickup for providing an individual with access to keys, according to one embodiment.

5 is a flow chart illustrating a method that may be performed at key pickup for providing an individual with access to keys according to another embodiment.

6A , 6B, and 6C are exemplary screenshots of a graphical user interface of a key exchange application, according to one embodiment.

7A-7D illustrate a key fob including a key tag that may be used in certain embodiments.

FIG. 8 illustrates an exemplary cabinet for storing sets of keys.

FIG9 illustrates an exemplary method for notifying a user.

DETAILED DESCRIPTION

Throughout the following description, details are set forth to provide a deeper understanding for those skilled in the art. However, to avoid unnecessarily obscuring the present disclosure, well-known components may not be shown or described in detail. Accordingly, the specification and drawings are to be understood in an illustrative rather than a restrictive sense.

In the embodiments described herein, a key exchange system and method are provided to facilitate the exchange of keys between individuals in multiple locations in a key exchange network. As used herein, an "asset" refers to any locked real estate, warehouse, business, vehicle, or other asset that a person may wish to grant or obtain access to. As used herein, a "key" or "keys" refers to any tool or device or group thereof that can be used to operate one or more locks to access an asset. Keys include, for example, house keys, key fobs, key cards, car keys, digital devices or mobile devices that can be used to unlock or lock one or more locks, etc. A "key set" is a group of one or more keys that are directly or indirectly associated with a key identifier. A single key is an example of a key set. A key identifier is ideally unique. A key set can include keys for one or more assets (for example, a set of keys can include a key to access a building, a key to access an apartment in the building, and a car key).

A key exchange system includes a key exchange location where one or more sets of keys are held for access by authorized individuals. A computer system tracks the sets of keys held at the key exchange location and has rules that determine when and to whom a set of keys can be released. The computer system can perform steps to authenticate an individual attempting to receive the sets of keys.

The following is a non-limiting example of how such a system might be used. Consider a scenario where an owner occasionally rents an apartment to a traveler for a few days. Rather than arranging to meet the traveler at a specific location and time to hand over the apartment's keys, the owner deposits the apartment's set of keys at a key exchange location, where they are securely stored. When the keys are handed over at the key exchange location, one or more steps can be taken to authenticate the keys. The owner also provides the key exchange system's computer system with information identifying the traveler and rules governing when the traveler is authorized to access the set of keys. The owner can take these steps at any convenient time before the traveler arrives.

The key exchange system can automatically notify the traveler of the key exchange location at the appropriate time. The key exchange location can be located within a business, such as a local café near the apartment. The traveler can request to receive their set of keys from the key exchange location within a specified timeframe and then access the apartment. As described below, the authentication of the traveler and the issuance of the set of keys to the apartment can be automated to varying degrees. The traveler can then return the set of keys to the key exchange location.

As will be appreciated, a system such as the one described in the non-limiting example above offers the advantage of enabling keys to an apartment or other property to be exchanged without requiring a face-to-face meeting between the owner and the traveler. Furthermore, such a system can optionally manage payment for the use of an apartment or other property without requiring the owner to access the traveler's credit card or other payment information. In certain embodiments, the owner and traveler can interact with the system via a networked portable device, such as a smartphone, tablet, or the like. Such a system can be highly user-friendly for both owners and travelers while providing the desired security for both.

Preferably, the key identifier is machine-readable. In a particular embodiment, the key identifier is encoded on a key or device, or is embedded in a key or device that is physically attached to a key or a set of keys, such as via a key chain. A "key tag" is a physical structure that can be scanned to read the key identifier. Any suitable technology can be used to read the key tag. For example, the key tag can include a near-field communication ("NFC") tag, an optional scannable barcode (e.g., a UPC code, a QR code, etc.), a series of symbols (e.g., characters, numbers, and/or other symbols) marked on the key or on a tag attached to the key, a Bluetooth tag, etc. Ideally, each key set does not have a human-readable label that would allow an unauthorized party to associate the key set with the asset to which it belongs.

In one useful and novel embodiment, a key tag is provided in a key chain. The key chain comprises a metal pendant and a chain or other attachment for coupling the pendant to a plurality of keys or key sets. The pendant comprises an NFC tag in a non-metallic material embedded in a recess in the metal of the pendant. For example, the NFC tag can be bonded in the recess by an adhesive layer comprising an isolation layer that allows the NFC tag to be read even if metal is nearby. NFC tags that include such an isolation layer are labeled as "metal-resistant" NFC tags. The tag can be covered by a layer of plastic, epoxy resin, etc. The presence of metal in the vicinity of the NFC tag generally interferes with reliable scanning of the NFC tag. However, it has been found that an NFC tag embedded in a recess as described above can be reliably read by an NFC scanner located on the recess in the vicinity of the NFC tag.

An exemplary key chain is shown in Figures 7A to 7D. The key chain has a metal pendant with a depression on one side. An NFC tag is attached to the depression with a barrier between the tag and the metal body of the pendant. A layer of epoxy, plastic, or the like covers the tag. A logo, company name, or other designation may be marked on the pendant. A unique serial number or other unique human-readable identification information may be marked on the pendant.

NFC tags can be encoded with a unique URL as the key identifier. A unique serial number (or keychain name) can be printed on the NFC tag or keychain during the encoding or manufacturing process. The serial number can be linked to a unique URL in the computer system used to manage the key exchange (e.g., a key exchange server database as discussed below).

There are various advantages to using such a key fob in a key exchange system, including: 1) the metal fob will be sufficiently durable for a key exchange system that requires constant use and transfer of keys between multiple parties and physical contact with the hard walls of a storage box - the majority of the surfaces of the fob that will come into contact with other surfaces or objects is durable metal; 2) the metal key fob can be formed to operate in conjunction with a particular key retaining device - in some embodiments, the metal can include magnetic metal and the key retaining device can magnetically retain the key fob in whole or in part in a storage position; 3) securing a metal-resistant NFC tag of non-metallic material within a recess in the metal fob enables the use of an NFC tag with such a metal fob; 4) the NFC tag enables the key fob and key identifier to be detected by a smartphone, enabling interaction with client devices and large-scale distribution of the key exchange system; 5) the embedding of a URL as a key identifier combined with smartphone interaction with the NFC tag enables extended information and marketing possibilities to assist in large-scale distribution of the system; and 6) the inclusion of a linked serial number (or name) enables a user to visually distinguish between multiple key set chains and identify the desired key set even when a scanner is not available.

The key exchange system includes a computer system having authorized users. The computer system can authenticate users in any suitable manner. For example, a user can log in to the computer system using username/password authentication. Any suitable authentication method can be used. Different users can have different rights associated with any particular set of keys. A user (e.g., an asset owner or asset manager) can have administrative rights associated with a particular set of keys (this user can be referred to as a "key administrator"). Administrative rights can allow the key administrator to authorize others to access the set of keys.

A computer system maintains a database that records key sets and the permissions associated with the key sets made by key managers. Such a database can be implemented in a variety of different ways. For example, in one embodiment, each key set is associated with an asset and the access rights granted by the key manager are associated with the asset. In such an embodiment, the access rights are indirectly associated with the key sets. In other embodiments, the database is structured so that access rights (via key identifiers) are directly associated with each key set. In other cases, the key manager can add access rules that indicate the conditions for issuing key sets held in a key exchange location. The key manager typically has the authority to add/change and delete such access rules. Regardless of the form the rules take and regardless of the specific arrangement selected for the database, given a key identifier tagged according to a key associated with a key set, the computer system is configured to access the rules directly or indirectly associated with the key identifier and determine, based on the rules, whether a particular individual is authorized to access the key set.

For the convenience of the key manager, the system may allow the key manager to associate names with different assets and/or different key sets. For example, if the asset is an apartment in Geneva, the key manager may choose to associate the name "Geneva Apartment" with the asset and/or its key set; if the asset is a yacht, the key manager may choose to associate the name "Yacht" with the asset and/or its key set.

The physical transfer of keys from one individual to another is performed at a key exchange center or key access location. A key exchange center can be located anywhere that facilitates the handover and collection of keys. For example, a key exchange center can be located in a cafe or coffee shop, restaurant, convenience store, lobby, shopping mall, airport, public transportation hub, marina, parking garage, parking lot, and so on.

In some embodiments, each key exchange center includes a scanner capable of reading key tags. The scanner can be integrated into the key storage device or provided separately via a suitably equipped networked computer or handheld device. At each key exchange center, the key tags are scanned when a key set is surrendered or collected. Scanning the key tags reads the key identifier. The key identifier can then be forwarded from the key exchange center to a key exchange server, which tracks the location of all key sets in the key exchange network.

The key exchange server can verify that each key set is in its expected location. The key exchange server also verifies that the individual at the key exchange center is authorized to retrieve the key set. If an access request is made and it is determined that the individual is authorized to retrieve the key set, the key exchange server provides instructions to the device at the key exchange center to enable the authorized individual to access the key set. The key exchange server can also coordinate the placement of the key set at the key exchange center by receiving the scanned tagged key identifier and then providing instructions to the device at the key exchange center to store the key set and updating the key location associated with the key on the server.

FIG1 illustrates an exemplary system 100 for processing the exchange of key groups between individuals in a key exchange network. FIG1 shows representative individuals 102, 104, and 106, as well as representative keys 103, 105, and 107. For purposes of explanation herein, individual 102 is an administrative user who has the privilege of assigning access rights to one or more key groups. Individuals 104 and 106 are guest users who can be granted access to one of the key groups by an administrative user (e.g., individual 102). Alternatively, user 102 can be a guest user with respect to other key groups.

System 100 includes a key exchange server 108, which is configured to track the location of a key set and to manage and coordinate key transfers between individuals, such as between an administrative user 102 and one or more guest users 104 and 106. Administrative user 102 can communicate with key exchange server 108 to grant access to a key set. Guest users 104 and 106 can communicate with key exchange server 108 to request access to a key set. Interactions between individuals 102, 104, and 106 and key exchange server 108 can be handled through a key exchange interface displayed on a client device 112 used by the individual. The client device can be any device configured to communicate with key exchange server 108. The client device can, for example, include a personal computer, a terminal, a kiosk, or a networked controller or other device integrated with a key cabinet. In some cases, the client device can include a mobile device, such as a tablet computer, a laptop computer, a smartphone, etc. In certain embodiments, all users may have the same type of account and use a single integrated interface, but in that interface have administrative privileges associated with certain key sets and only guest privileges associated with certain other key sets.

In order to enable the key exchange server 108 to track the location of key sets and manage the access rights assigned to key sets, a unique key identifier is assigned to each key set in the key exchange network. The key identifier can be encoded in a key tag. For example, in the embodiment of Figure 1, the unique key identifier of key 103 can be encoded in an NFC (near field communication) tag 103B on a key chain 103A, which is attached to key 103. Although Figure 1 shows only one representative key 103 attached to the key chain 103A, it is understood that multiple keys can be attached to the chain 103A. For example, if the asset is an apartment unit, all keys required to access the unit, such as a key fob for the common asset and a house key for the unit, can be attached to the key chain 103A. In certain embodiments, where the key set includes multiple keys, a tag can optionally be attached to or embedded in each key so that the system can verify the presence of all keys that should be part of the key set.

Assume that administrative user 102 has the privilege to control access rights to key sets 103. For example, if administrative user 102 wishes to transfer his key set 103 to guest user 104, he can grant these access rights to guest user 104 by transferring the access rights to key exchange server 108. Access rights can include restrictions on access, such as time periods during which guest user 104 is allowed to access key sets 103. Key exchange server 108 includes an access rule database 134 that stores access rules assigned by key administrators to key sets. Each access rule can be linked (directly or indirectly) to a specific key identifier and to an authorized user.

The administrative user 102 may transfer access rights to the key exchange server 108 through an administrative key exchange interface 110 provided on a client device 112A used by the administrative user 102. The client device 112A may communicate with the key exchange server 108 over the Internet.

If the administrative user 102 owns the key set 103, he or she can place the key set 103 at a key exchange center so that an authorized guest user 104 can later collect the key set 103. The key exchange center may have a key cabinet or other key holding device 120 for storing the key set as shown in Figure 1. In a specific embodiment, when the key set 103 is placed at the key exchange center, its key tag (e.g., key fob 103A) is scanned to read the encoded unique key identifier. The keys 103 are placed in an available storage box (e.g., storage box 125C in Figure 1) in the key cabinet 120. In some cases (e.g., where the key set has just been returned to the key exchange center by a previous user), the key set 103 may already be at the key exchange center and therefore does not need to be handed over.

Once the key set 103 has arrived at the key exchange center, the key identifier of the key set 103 and the location of the key set 103 (e.g., the key exchange center location and the key storage box number where the key set 103 is stored) are transmitted to the key exchange center 108. The key exchange server 108 maintains a key inventory database 133 that associates key identifiers with locations (and other information related to the key set). The key exchange server 108 associates the location information with the key identifier of the key set held at that location in the key inventory database 133. In some embodiments, the key storage box is designated by the key exchange server 108 (which can, for example, determine which key storage boxes are available by using the key inventory database 133) and the location is transmitted to the key exchange center.

Approximately when the guest user 104 is authorized to access the key set 103 according to the access rules set by the administrative user 102, the key exchange server 108 may automatically provide the guest user 104 with a notification of the location of the key exchange center where the key set 103 is stored. The notification may be provided in the form of an email, a text message, a voice message, a message that appears on the guest user's key exchange account page, etc. The notification may optionally include additional information, such as the key exchange location's operating hours, instructions for arriving at the key exchange location, etc.

To obtain the key set 103, the guest user 104 can visit the key exchange center where the key set 103 is located and transmit his or her key retrieval request to the key exchange server 108. This request can be transmitted by the guest user 104 to the key exchange server 108 through a guest key exchange interface 111 provided on a client device 112B used by the guest user 104. The guest user may be prompted to log in or provide other authentication information. The client device 112B can communicate with the key exchange server 108 over the Internet.

Based on the information provided in the key retrieval request, the key exchange server 108 checks the access rules database 134 to verify that the guest user 104 is authorized to access the key set 103. If it is determined that the guest user 104 is so authorized, the key exchange server 108 forwards instructions to the key exchange center to enable the guest user 104 to access the key set 103. In some embodiments, the instructions include an identifier of a storage box number that identifies the specific storage box in the key cabinet where the key set 103 is stored. The storage box number can be received on the client device 112 at the key exchange center. A person at the key exchange center who has access to the key cabinet 120 (e.g., an employee of the merchant who hosts the key exchange center) can then open the corresponding storage box and hand over the key set 103 to the authorized guest user 104.

In some embodiments, particularly where the client device 112B used to request the keys is not controlled by the operator of the system 100 (e.g., where the client device 112B is a tablet or mobile phone of a guest user), the key exchange server 108 may request location information from the client device 112B. This location information may be provided, for example, by the GPS system of the client device 112B. The key exchange server 108 may compare the location information received from the client device 112B with the known coordinates of the key exchange location and authorize the release of the requested key set to the guest user only if the location information received from the client device 112B closely matches the location of the key exchange location.

Before handing the key set 103 to the guest user 104 , the key set 103 may be scanned to read the key identifier and verify that the correct key set has been found.

In some embodiments, the key sets are stored in an automated key holding device that automatically controls the issuance of key sets. For example, under the direction of the key exchange server 108, the opening of a storage box or drawer in a key cabinet or other method of key delivery can be automated and controlled by a control and processing unit. An automated key cabinet or kiosk can be placed in a key exchange center to handle key exchanges between users. In some embodiments, an automated key cabinet for managing key exchanges is placed as part of an automated reception system, replacing the human reception/service desk in a hotel, motel, or other facility where people access keys.

In particular, the embodiment illustrated in FIG. 1 includes a key cabinet having a control and processing unit 122 for controlling the opening and closing of drawers or doors of various compartments or storage boxes containing sets of keys (e.g., storage boxes 125A, 125B, and 125C of FIG. 1 ).

Upon receiving instructions from the key exchange server 108, the control and processing unit 122 causes a particular compartment door to open, or slides out a storage box drawer, or dispenses a key set into a dispensing opening, etc. Opening the storage box drawer allows a key set stored in the storage box to be retrieved by a guest user, or allows a key set to be placed in the storage box by an administrative user or other user. In another embodiment, the automated cabinet may have a single receptacle for placing and retrieving key sets by a user, with the cabinet mechanically moving the associated storage box or key set for presentation to the user.

Client devices 112 (including client devices 112A and 112B in FIG. 1 ) may include smartphones, mobile devices, personal computers, laptops, tablets, or any other devices (including custom computer terminals and kiosks) capable of connecting to the Internet and communicating with key exchange server 108. In some embodiments, client device 112B is incorporated into a key cabinet 120 at a key exchange location.

Some of the steps described herein include scanning a key tag to read a key identifier. For example, as discussed above, a key tag is scanned during the handover of a key set at a key exchange center. The key tag can also be scanned during the collection of keys at a key exchange center. The key tag can be scanned by a device capable of reading an encoded key identifier. In embodiments where the key identifier is encoded into an NFC tag on a key chain, the key can be scanned by an NFC-enabled device, such as, for example, an NFC-enabled smartphone or tablet. These devices can be configured to run a key exchange application that sends the key identifier to the key exchange server 108.

The system 100 of Figure 1 or some parts thereof can be configured to implement one or more of the methods described herein. These methods are described in more detail below with reference to Figures 2 to 5.

FIG2 illustrates a method 150 for assigning access rights to a key set by an administrative user, according to one embodiment. For example, method 150 can be executed to enable administrative user 102 to grant guest user 104 access to key set 103 ( FIG1 ). Method 150 can be repeated each time the administrative user wishes to create new access rules for an individual. Method 150 can be implemented as software contained in a program memory accessible to a processor of key exchange server 108 of FIG1 . The processor implements the method by executing software instructions provided by the software. An administrative user can provide input to the software via administrative key exchange interface 110 of FIG1 .

Method 150 begins at block 152 by receiving the credentials of the administrative user. Such credentials can include, for example, the user's account name, email and/or password 153 provided by the user. Such credentials can be provided by the administrative user at the login page of logging into the account using the administrative key exchange interface 110 provided at the client device 112A of FIG. 1 . After the administrative user's credentials have been verified by the key exchange server 108, the administrative user can be provided with access to his or her personal management page 114 (see FIG. 1 ), where he or she can see a list (depending on the representation of the interface) of assets, keys and/or key identifiers for which he or she has management privileges. The list can also indicate the current location of each key group (for example, if the key group is being kept at a key exchange center, then indicate the key access location, or if the key group has been picked up by a previous user, then indicate the known last whereabouts of the key group). At block 154 , the key exchange server 108 receives the administrative user's selection from a list (eg, key names or identifiers 155 ) that directly or indirectly identify one or more key groups with which the access rule is to be directly or indirectly associated.

Method 150 continues by creating access rules for the selected key set(s) by receiving, at block 156, identifiers 157 of authorized visitors who may access the selected key set from the administrative user, and, at block 158, details of the time period 159 during which the authorized visitor may have access. Visitor identifier 157 may be an email address, user account name, phone number, credit card information, name and address, or any other identifier that uniquely identifies a user in the key exchange network. Time period 159 may indicate the day(s) and/or hour(s) during which the authorized visitor may access the key set (e.g., an authorized visitor may book a one-night stay and be granted access between 3:00 PM on February 7th and 10:00 AM on February 8th). In some cases, time period 159 may include a recurring time period (e.g., an authorized visitor is a cleaning staff member authorized to access the keys between 12:00 PM and 4:00 PM on the second Monday of each month) or the time period may be specified as unlimited. In some cases, no specific access period may be specified, ie, a guest user may be authorized to receive the key set at any time after the key set has been deposited at the key access location.

Before assigning the authorized time period 159 at block 158, the key exchange server 108 may check to determine whether the time period 159 conflicts with previously assigned access rules for the key set. For example, if different guest users have already been assigned access to the same key set during the same time period or overlapping time periods, the time period 159 may generate a warning or not be assigned.

Once access rules have been created at blocks 156 and 158 , the method 150 may repeat by proceeding to block 154 if the administrative user wishes to create additional access rules affecting the same key set or other key sets.

An administrative user can be assigned administrative privileges for a key group identified by a key token and its key identifier upon recycling. For example, a user who wishes to use a key exchange system associated with an asset can obtain a new key token (e.g., in the form of an NFC key fob). An NFC-enabled client device executing an application can tap the key fob to cause the key identifier to be read from the NFC key fob and sent to the key exchange server 108. The administrative user can provide their user credentials through an interface on the client device and request that they be assigned as a key administrator. The key exchange server 108 can then update the database 132 of administrative users (see FIG. 1 ) to associate the administrative user with the key identifier.

Other methods can be used to associate a key identifier with an administrative user. For example, before the key token is shipped or otherwise provided, the user can enter a unique serial number visible on the key token into their account, or a key exchange service can link the key identifier to the user's account. The key identifier can then be added to a list of key groups or other data representations containing access rules in the user's account, and the administrative user can add access rules to or associate them with assets based on the list of key groups.

FIG3 illustrates a method 200 that can be executed whenever a key set is surrendered at a key exchange center. For example, method 200 can be executed when administrative user 102 surrenders key set 103 at a key exchange center so that the key set can later be collected by authorized guest user 104 ( FIG1 ). Method 200 can also be executed when guest user 104 returns/hands over key set 103 at a key exchange center after using the key set. Method 200 can also be implemented as software contained in a program memory accessible to a processor of key exchange server 108 of FIG1 . The processor implements the method by executing software instructions provided by the software.

Method 200 is initiated by scanning a key tag at a key exchange center. For example, when a user arrives at a key exchange center to hand over a set of keys, an NFC-enabled client device 112B can tap a key fob containing the key tag to read a key identifier encoded on the NFC tag. The key identifier can be sent to a key exchange server 108 by a key exchange application on the client device 112B. In some embodiments, the client device 112B can be any of the following: a client device specifically associated with a key exchange location (which can include a separate device or a device integrated with a key storage cabinet, such as a controller) or a portable device such as a user's tablet or smartphone. At block 202, method 200 receives a key identifier 203 from the client device 112B.

At block 204, the method 200 identifies the key location. This can be accomplished in various ways. For example, the method 200 can receive location data 205 from the client device 112B and determine the key location (e.g., the key exchange center location) based on such data. Such location data 205 can include GPS data, mobile network location data, and/or user data input, or device identification data that the key exchange server 108 can link to a location in its database, and/or other content.

At block 206, a storage bin number 207 is assigned to the key, identifying an available storage bin in the key cabinet for storing the key. The assignment of the storage bin number can be performed by the key exchange server 108 or the control and processing unit 122, or a human can select an available storage bin for the key set to be registered. If the key exchange server 108 does not assign a storage bin, the selected storage bin is transmitted to the key exchange server 108.

At block 208, the identified key location and the assigned storage bin number are associated with the key identifier 203 received at block 202. At block 209, the key exchange server 108 sends a signal to the control and processing unit 122 of the key cabinet 120 to open the assigned storage bin so that the key set can be placed in the storage bin. In other embodiments where the key cabinet 120 does not have a control and processing unit 122, the step at block 209 can be replaced by sending the assigned storage bin number to a client device at a key exchange center so that personnel working at the key exchange center know which storage bin to store the key in, or by having personnel working at the key exchange center place the key in an open storage bin and sending this information to the server via a storage bin sensor or by the worker via a client device interface.

In some embodiments, for example, a key administrator can be prompted to provide optional instructions or other information to be issued to a guest user after the guest user receives a key set, or when the guest user becomes entitled to receive a key set according to specific rules. This information can include, for example, a map of the asset associated with the key set, instructions for caring for the asset, and so on. In some embodiments, the system provides a template for such instructions, which includes information available in the system, such as the asset's location. In some embodiments, the key administrator can choose to store a set of instructions for an asset so that the system can automatically provide the same instructions to guest users of the asset.

The method 200 proceeds to block 210 by retrieving any access rules 211 that have been directly or indirectly associated with the key identifier 203. If there is a user who has been granted access to the key set according to one of the access rules 211 and the start of the user's authorized access period is within a predetermined time (e.g., less than a day), the method 200 proceeds to issue the current key location 213 and any required collection instructions or codes 215 to the authorized user. Such collection instructions or codes 215 can be generated by the system or key administrator to authenticate a guest user at the time of key collection.

In other embodiments, steps 210 and 212 of method 200 may be performed at other times. For example, key exchange server 208 may be configured to periodically read or process access rules and, if the start of an upcoming authorized access period for an authorized user is within a predetermined time, issue a current key location 213 of the key to the authorized user. For example, key exchange server 208 may be configured to issue current key location 213 and pick-up instructions or code 215 to the authorized user one day before the start of the authorized access period.

FIG4 illustrates a method 250 that can be performed at key pickup time for providing an individual with access to a key set, according to one embodiment. For example, method 250 can be performed when guest user 104 arrives at a key exchange center to pick up key set 103 ( FIG1 ). Method 250 can be implemented as software contained in a program memory accessible to a processor of key exchange server 108 of FIG1 . The processor implements the method by executing software instructions provided by the software.

Method 250 begins at block 251 by receiving credentials 253 for a guest user. Such credentials may include, for example, a user account name, email, and/or password 253 provided by the user. Such credentials may be provided by the guest user at a login page of the guest key exchange interface 111 provided at the client device 112B ( FIG. 1 ). The credentials may additionally or alternatively include one or more of a PIN (e.g., the PIN provided with the access instructions or code 215 at block 252 ), two-factor authentication via a mobile phone, or submission of a unique physical access token (e.g., an NFC tag containing a unique identifier associated with the guest).

The guest user's credentials 253 entered can be verified by the key exchange server 108 by comparing them to a set of credentials associated with the user in the user credential database 131 (see FIG1 ). After the guest user's credentials are verified, at block 252 , the guest user can be prompted to provide additional access instructions or codes 215 . For example, the guest user can be notified in advance of a key set collection access code 215 ( FIG3 ) at block 212 of method 200 . The access code 215 can assist the key exchange server 108 in determining which key set the guest user is requesting access to, as it is conceivable that a guest user could have access privileges to multiple different key sets at the key access location, such as a guest user who is a cleaning staff member with access to keys for many different assets. If an additional access code 215 is not required and it is unclear which key set the guest wishes to access at the key exchange center, the guest can be prompted to select a key set for the access event.

At block 254, the method 250 identifies the time and location of the client device 112B making the key access request. The time of the key access request can be determined, for example, by the key exchange server 108 querying a source of timing information 257 accessible to the key exchange server 108. The location of the client device can be identified by receiving location data 255 from the client device 112B and determining the client device location (e.g., a key exchange center location) based on such data. Such location data 255 can include GPS data from the client device 112B, mobile network location data from the client device 112B, user data input from the client device 112B, device identity information from the client device 112B that the key exchange server 108 can link to a location in a database of the key exchange server 108, or physical submission verification at the key exchange location via a button, scanner, or some other interactive device, and/or the like.

At block 256, the associated access rules 211 for the requested key are retrieved, which specify the guest user's key access rights. At block 258, method 250 proceeds to authenticate the guest user's request. For example, at block 258, the time of the key access request can be compared with the authorized access period specified in the access rules to determine whether the key access request was properly made within the authorized access period. Additionally, at block 258, the location of the client device 112B determined at block 254 can be compared with the key access location associated with the key identifier of the requested key set. This can help determine whether the guest user is in the correct location to retrieve the key set. If the key set is elsewhere, or if the key access request was made outside of the authorized access period, the key access request is denied.

If the key access request is authenticated, the method 250 proceeds to block 260 by sending an access instruction to the client device 112B. For example, in the illustrated embodiment, the access instruction includes the storage box number 207 of the storage box in which the key set is stored. The storage box number 207 has been previously associated with the key identifier of the requested key set when the key set was surrendered or when the key inventory was recently scanned (e.g., as described with reference to block 208 of method 200 of FIG. 3 ). A person with access to the key cabinet at the key exchange center can use the access instruction provided at block 260 to open the storage box and retrieve the requested key set from the designated storage box.

At block 262, method 250 verifies that the correct key set has been found by receiving the key identifier 203 for the key set. For example, before handing the key set to a guest user, the person who opened the storage box and found the key set can tap the key fob to the NFC-enabled client device 112B to read the key identifier encoded on the NFC tag of the key fob. The key identifier can be sent by the key exchange application on the client device 112 to the key exchange server 108. The key exchange server 108 can then verify whether the scanned key identifier corresponds to the key identifier of the requested key set.

FIG5 illustrates a method 300 that can be performed at key collection time for providing an individual with access to a key set according to another embodiment. For example, when a guest user 104 arrives at a key exchange center to collect a key set 103 ( FIG1 ), the method 300 can be performed. The method 300 is similar in some respects to the method 250 of FIG4 . Similar reference numerals are used to represent similar steps or components. The method 300 can be implemented as software contained in a program memory accessible to a processor of the key exchange server 108 of FIG1 . The processor implements the method by executing software instructions provided by the software. Input can be provided to the software via the guest key exchange interface 111 displayed on the client device 112B (see FIG1 ).

Method 300 may be performed if the key cabinet includes a control and processing unit 122 ( FIG. 1 ) that controls access to the set of keys held in the key cabinet (e.g., by opening and closing a drawer or storage compartment within the key cabinet). The control and processing unit 122 of the key cabinet 120 may communicate with the key exchange server 208 over the Internet. Method 300 includes steps 251, 252, 254, 256, and 258, similar to those of method 200. However, method 300 begins differently from method 250 at block 264 of method 300. At block 264, instead of sending an access instruction to the client device 112B (according to block 260 of method 250), method 300 verifies that the correct set of keys is present in the storage compartment associated with the key's identifier. This verification step may be accomplished by a scanner located within the key storage compartment that is capable of scanning an NFC tag on a key tag contained within the storage compartment. For example, the key exchange server 208 may forward an instruction to the control and processing unit 122 of the key cabinet 120 to activate the scanner to read the key identifier 203 of the key tag in the identified storage box (or all storage boxes in the key cabinet 120 during the search for the key identifier 203). The scanned key identifier is then forwarded by the control and processing unit 122 to the key exchange server 208 for verification. If it is determined that the correct key set is present in the storage box, then at block 268, the key exchange server 208 sends an instruction 269 to the control and processing unit 122 to open the storage box containing the key set or otherwise make the key set accessible. In some embodiments, the system automatically provides additional information related to the key set (e.g., instructions for getting to the asset to which the key set belongs from the key exchange location) to the recipient of the key set (e.g., via email, text message, etc.).

The key verification steps at block 262 of method 250 and block 264 of method 300 can help prevent the incorrect set of keys from being provided to a guest user. For example, a key set different from the requested key may have been inadvertently placed in a storage box, and the verification step will detect this error. The above verification steps are not required for all embodiments. In certain embodiments, the verification step may be omitted or performed in some other manner.

The key exchange server 108 may optionally implement one or more notification generators 140, as shown in FIG1 , that determine when one or more users (e.g., guest users and/or administrative users) receive notifications of one or more events. These notifications may be generated by the key exchange server 108 and/or may include or incorporate user-provided information (e.g., a key administrator may provide content to be included in one of the notifications provided to a guest user—such content may be uploaded or input to the key exchange server 108 from a client device 108 via a user interface).

The notification generator can be configured to distribute one or more different notifications. Each notification can be associated with a corresponding criterion. The notification generator 140 can be configured to search one or more databases of the key access server 108 to identify situations in which notifications should be distributed. In certain embodiments, the notification generator 104 is configured to search databases accessible to the key exchange server 108 (e.g., the key inventory database 133 and the rules database 134) to identify when notifications should be distributed and to whom. For example, the notification generator 140 can automatically notify the key manager when the guest user 104 has received the key set 103 from the storage box 125.

As another non-limiting example, notification generator 140 may determine the earliest time that guest user 104 can access key set 103 (based on access rules associated with key set 103) and, when that time approaches (e.g., when that time is one day later, a few hours later, or some other time period later), may check to verify that the key set 103 to be exchanged is present at the key exchange location (e.g., in storage box 125 of key holding device 120). If key set 103 is present (e.g., as indicated by key inventory database 133), notification generator 140 may automatically notify guest 103 that key set 103 will soon be accessible at the key exchange location where it is held. If key set 103 is not present, notification generator 140 may notify the corresponding key handler that key set 103 is not yet in key holding device 120 and, in some embodiments, may provide information or instructions to assist the key handler in promptly delivering key set 103 to the key exchange location.

The notification may be, for example, by means of an email, a text message, a voice message, a message presented on the user's key exchange account page, and/or other forms. The notification generator 140 may generate a notification at the same time as a particular event occurs, and/or may generate a warning notification before such an event occurs. For example, the notification generator 140 may notify the visitor that the key set 103 has been placed in the storage box 125 (as discussed above) before the earliest time that the key set 103 is available, or the notification generator 140 may postpone the notification until the moment when the key set 103 is available. The following example uses the latter approach, but the example may be adapted to provide notifications before a deadline or other determined time.

FIG9 illustrates a non-limiting exemplary notification scheduling method 400 that may be performed by a notification generator. At block 410, the notification generator determines a time period during which the guest user 104 is allowed to access the key set 103. This may be performed by checking the access rules database 134 for time-based access restrictions. When the time period begins (i.e., when the guest user 104 is allowed to access the key set 103), the notification generator proceeds to block 415 and determines whether the key set 103 is present in the key exchange location (e.g., in the storage box 125C in FIG1 ).

If the key set 103 does not exist, the notification generator proceeds to block 420 and, depending on the configuration of the notification generator, sends a notification to the key administrator associated with the key set 103 to remind them to check in the key set 103, sends a notification to the guest user 104 to inform them that the key set 103 has not been checked in, or both. Otherwise, if the key set 103 does exist, the notification generator proceeds to block 425 and informs the guest user 104 that the key set 103 has been checked in and is accessible.

From block 425, notification generator 140 proceeds to block 430, where it determines a time by which the key set 103 is expected to be removed from the key exchange location. If the key set 103 is provided to the guest user before this time, notification generator 140 proceeds to block 437 and detects the removal of the key set. After detection, notification generator 140 proceeds to block 445, where it notifies the key administrator of the removal event. If the key set 103 is not removed before this time, notification generator 140 proceeds to block 435 upon detecting that the time has expired. After block 435, notification generator 140 proceeds to block 440, where it notifies the key administrator that the key set 103 has not been removed up to the relevant time. If the key set 103 is subsequently removed, key generator 140 proceeds to block 437.

From block 445, the notification generator proceeds to block 450, where it determines a time by which the guest user 104 is scheduled to return the key set 103 to the key exchange location. If the key set 103 is deposited at the key exchange location before this time, the notification generator proceeds to block 465 and detects the return of the key set 103. After this detection, the notification generator proceeds to block 470, where it notifies the key administrator that the key set 103 has been returned. If the key set 103 is not returned before this time, the notification generator proceeds to block 455 when the detection time has expired. After block 455, the notification generator proceeds to block 460, where it notifies the guest 104 that the key set 103 was not removed until the relevant time. If the key set 103 is subsequently returned, the notification generator 140 proceeds to block 465.

The notification generator 140, if provided, may be implemented as software running on the key exchange server 108, as hardware incorporated into or accessible to the key exchange server 108, or as a hybrid of software and hardware. The notification generator 140, if provided, may be integrated with other portions of the key exchange server 108 or may be implemented as a separate component or subsystem.

Figures 6A, 6B, and 6C are screenshots of an exemplary graphical user interface for a key exchange application, according to one embodiment. Figures 6A and 6B illustrate exemplary screen shots of an administrative key exchange interface that an administrative user can use to assign access to the administrative user's key set to a guest user. Figure 6C illustrates an exemplary screen shot of a guest user key exchange interface that displays a notification to a guest user that a requested key set is available for pick-up at a specific key exchange center.

Various client computing devices can be used to facilitate the storage and retrieval of key sets and otherwise interact with the key exchange server 108. For example, an NFC-enabled tablet or other similar device can be used to handle key collection/handover. The device can include an application that performs key exchange center functions, such as scanning a tag on the key set. The server 108 can authenticate the application using credentials associated with the operator of the key exchange location. These credentials can be associated with the physical location of the key exchange location. Information used to store or locate the key set (e.g., a storage bin number) can be provided via the tablet or other device.

FIG8 illustrates an exemplary key storage cabinet 500 that can be located at a key exchange location. Cabinet 500 includes multiple storage boxes 502, each of which is accessed through a separate door 504 in this embodiment. Each door 504 can be locked and closed by an electronically controlled mechanism 506. A controller 510 is connected to mechanism 506 and can thereby lock or unlock door 504, allowing a user to open the door to place a key set into or remove a key set from a corresponding storage box 502.

The controller 510 has a wired or wireless network interface that allows it to communicate with a server (e.g., server 108 shown in FIG1 ) via the Internet. For example, the controller 510 may include a wireless network interface, such as a WiFi interface or a cellular data interface. The key storage cabinet 500 includes a power supply 512 for supplying power to the controller 510. In some embodiments, the power supply is connected to an external source, such as mains electricity. In other embodiments, the power supply includes a battery and/or a solar cell.

A scanner 514 for scanning key tags is associated with each storage box 502. The scanner 514 is in data communication with the controller 510. In some embodiments, the controller 510 includes a user interface (not shown) that allows the controller 510 to be used by a guest user as a client device communicating with the key exchange server 108 to request the issuance of a key set, or to be used by a key administrator as a client device communicating with the key exchange server 108 to hand over a key set. The storage cabinet 500 may include a display or other system for indicating a specific storage box to the user. For example, an LCD display configured to display the storage box number, an LED or LCD associated with each storage box, etc.

As will be understood upon reading this specification, the key exchange systems and methods described herein provide several benefits to asset owners or asset managers (or occupiers of an asset). For example, these systems and methods provide an asset owner or asset manager (e.g., a real estate management company) with a convenient way to provide one or more individuals with access to keys to the asset owner's or asset manager's (e.g., real estate management company) assets without having to install a lockbox, hide the keys outside the asset, or physically meet with the individual on site. The asset owner or asset manager can control access rights for multiple consecutive visitors by limiting the time each individual can access the keys through a client device (e.g., a smartphone) that communicates with a key exchange server. This can be useful in situations where the asset owner or asset manager rents an asset to visitors or needs to grant temporary access rights to specific visitors (e.g., contractors, cleaning staff, real estate agents, appraisers, etc.). In addition, using the systems and methods described herein, the asset owner or asset manager can grant access rights to multiple sets of keys to the same asset. For example, a property owner or property manager may make one set of keys available to current guests renting the property, while another set of keys may be available to the property's cleaning staff.

The key exchange systems and methods described herein can also provide several benefits to property visitors. For example, using these key exchange systems and methods, a property visitor who is renting a property does not need to coordinate their arrival time with the property owner's availability. Visitors can obtain keys to the property at any time during their authorized access period and the key exchange center's operating hours. The key exchange systems and methods also provide a convenient way for visitors to return keys after their visit.

Merchants (such as, for example, cafes) that serve as key exchange centers can also benefit from increased business brought in by users who come to pick up or hand in sets of keys (in addition to potential direct compensation that may be provided to the merchant by the operator/owner of the key exchange network in exchange for the merchant's services in holding, managing or operating the key exchange center).

The value of such foot traffic can be increased through embodiments in which the system is configured to support a loyalty program in which each time a user makes a purchase at a merchant in the key exchange center network, the user can accumulate credit or value in the key exchange system when the client device verifies the purchase activity and the user's identity. Such a loyalty program encourages users of the key exchange program to become customers of merchants in the key exchange center network.

The system described herein is easily scalable. For example, a single key access server (e.g., 108) can service a large number of key access locations. Some of these key access locations may be of different brands or presented to the public in different ways. In certain embodiments, different client software (e.g., software used by users to manage access rules for key sets or client software used at key exchange locations) may be different for different users. In such embodiments, the server system 108 can manage key sets at various brands of key exchange locations. In certain embodiments, one or more key access servers 108 may be part of a network that services several key cabinets 120 or automated key exchange kiosks distributed across multiple key access locations and logged into the network. The key exchange server system may have an application programming interface (API) that allows programmers to write their own applications to access the functionality provided by the key access server system 108. Such applications may include, for example, applications that provide customized interfaces to enable the key cabinet 120 or automated key exchange kiosk to interact with the key access server 108 and client devices to perform specific key exchange functions, and applications that provide monitoring of the status of the key cabinet 120 or automated key exchange kiosk at the key access location. Customized applications and updates to customized applications can be pushed remotely to the key cabinet or automated key exchange kiosk.

As non-limiting examples, a car rental company may wish to use such an API to transition from a staffed model to an automated key exchange system at car rental locations, a property management or reservation company may wish to integrate such an API to provide its customers with access to its own branded key exchange centers distributed through a network of local merchant partners, a car sharing company may wish to use such an API to offer car sharing options using car keys rather than installing new technology in vehicles, a building with a lobby or front desk/service desk may use such an API to implement an automated reception system for its residents or visitors, or other businesses that distribute keys to different individuals at different times (such as, for example, a movie theater or a transportation company) may use such an API to provide a key management system to manage their key logistics.

In some embodiments, an individual user may choose to allow the system to automatically generate access rules (or the system may be configured to automatically generate access rules). For example, the system may include a reservation function in which a person may wish to allow the system to automatically generate rules that would allow service providers to access assets in response to service requests from users. For example, an approved provider of cleaning, shopping, delivery, repair, or other services requested by a user could automatically obtain a set of keys. As another example, a property reservation company (e.g., a car rental company or a home rental company) could establish a system in which access rules are automatically generated or for approval by an administrative user based on reservation data when a reservation occurs.

In addition to individual service requests, continuous service requests are also possible. As a non-limiting example, a key exchange service could offer users the option of having a package delivered to a virtual address. This package could then be delivered to the user's home by a delivery person, who would automatically be provided access to the user's keys upon arrival. This authorization could be granted for a limited time period. If the key set is not returned in a timely manner, the system could provide an automatic warning.

In some embodiments, personnel at a key exchange center can periodically scan the key sets in key storage boxes using a client device or an embedded sensor in the storage box to update the key set inventory of the key exchange system. Each storage box can have a scannable identifier indicating the identity of the storage box, so that the scan detects either or both the key identifier and the storage box identifier. Such periodic inventory scans can control for human error or interference with key placement, detect security breaches, provide updated location data for publication to users' accounts, or provide inventory confirmation for reassurance to key administrators.

In some embodiments, the system may provide a reservation service that allows guest users to make reservations for access to different properties. Some users may wish to allow the system to automatically generate rules to allow guest users who have reserved their properties to access the key set for the reserved property during the reserved time period. The system may be configured to automatically generate such rules.

In some embodiments, the system includes a calendar and other tools for managing property bookings. Users who are key managers can use such features to manage access schedules and aggregate access schedules into a single system (even if these users provide messages to visitors in a way that is external to the system).

It is understandable that the system described herein can be applied to support a series of different business models. The system can provide specific features to support these business models. For example, in certain embodiments, the owner or other personnel wishing to transfer the key set to other personnel can pay for this use of the system. In such an embodiment, before allowing the owner to hand over the key set to be exchanged, the system can collect payment (for example, credit card payment, bank transfer, debit card payment, etc.) from the owner. In an optional manner, the system can automatically bill the owner before or after the exchange of the key set has occurred. Such payment or billing can be a flat rate or can be based on the details of the key exchange (for example, how long the key is kept before being collected by the expected recipient). When billing is based on the details of the key exchange, the system can automatically monitor such details.

In some embodiments, users of the system can pay for access to the system (e.g., on a subscription basis). In some cases, users can pay a fee to qualify as key administrators. The fee can be in the form of a subscription for a period of time, for example. The system can automatically bill users and may refuse to accept key sets in exchange from users who have not paid the appropriate fee to date.

The system as described herein can optionally be configured to deliver advertisements or coupons to users of the system. For example, the system can deliver advertisements and/or coupons for local merchants of assets related to the key set to all or selected key recipients (the merchants are typically also local to the key exchange location). The system can deliver offers for event tickets to events occurring approximately at the time of the key exchange in the city or town where the key exchange location is located, or in the surrounding area.

A system as described herein may include or be associated with a reservation system that allows people to reserve access to a property and pay for such property access.The system may include charging a fee for key exchanges.

In certain embodiments, the system can be configured to support the provision and/or billing of value-added services provided by merchants managing key exchange centers and incorporated into the reservation and payment systems of the key exchange services. As non-limiting examples, key managers at key exchange centers can be offered the following options: the key management center checks or scans the visitor's ID before issuing a key, pre-purchases food and beverages (e.g., at a key exchange center that is a cafe) for the visitor to pick up upon arrival, or handles key pickup after business hours by placing designated keys in a lockbox outside the merchant's location. In addition, tools can be introduced to track service levels and activities, such as user satisfaction, frequency of key inventory scans, average number of key pickups, amount of money spent by customers on value-added services, etc.

In some embodiments, a key identifier can be associated with a voucher that can be purchased by a key keeper for use at a merchant that manages a key exchange center or at other merchants that have been added to the network to accept such vouchers. Vouchers can be purchased by a key keeper for use by a visitor, such as a tourist, to enhance their travel experience. For example, a key keeper might purchase a certain amount or quantity of food and drinks at a local cafe, purchase tickets to a local attraction, and so on, and associate them with a specific key set and/or visitor for use during the visitor's stay. Such vouchers can be redeemed when a client device scans the key tag and the key exchange server receives the key identifier, checks the voucher, and sends a notification to the client device indicating that the specific voucher is available for redemption at that location.

In different embodiments, payment can take various forms, triggered by various events. A key keeper can pay each time they use the key exchange system, in which case they are billed for each collection and/or handover of a key set. Such billing can include an "overnight fee" to align billing with time-based use of the key exchange facility. Alternatively, for package use, a recurring subscription fee can be paid. Payments can be linked to different events in the system, such as reservations, value-added service or voucher purchases, service requests, guest reservations for assets, key handovers or collections, and so on.

In some embodiments, the system is configured to allow key managers to co-manage other assets through a key exchange system that relies on access technology other than physical keys or to transition assets in a key exchange system from keys to digital lock technology. In such cases, the key exchange system can support such asset addition and transition by: a) providing a system that incorporates digital locks that can seamlessly replace systems that rely on exchanging physical keys, b) integrating its reservation system with other digital lock providers (e.g., via an API), or c) allowing key managers to store digital keys (e.g., such as in the form of low-cost mobile devices) that provide access to digital locks at a key exchange center if the digital lock provider does not provide or refuses to provide an integration point. Cross-platform and technology-agnostic embodiments can provide access to a variety of assets to guest users and authorized service providers in a secure and controlled manner.

The foregoing is merely a non-limiting example of features that may be incorporated into the systems described herein for the purpose of supporting various business functions.

Where a component (e.g., a server, a client device, a database, a software module, a processor, a program memory, a key, a key chain, a key cabinet, a storage box, etc.) is referred to above as such a component (including references to "device"), unless otherwise indicated, the component should be interpreted as including any component that performs the function of the component (i.e., that is, is functionally equivalent) as an equivalent of the component, including components that are not structurally equivalent to the disclosed structure that performs the function in the illustrated exemplary embodiments.

While a number of exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain modifications, permutations, additions, and sub-combinations thereof. For example:

In the embodiments described herein, the key identifier is encoded on a key fob attached to a key or set of keys. In other embodiments, the key identifier may be encoded on some other object attached to the key, or even directly on the key itself.

In certain embodiments, a unique serial number may be printed or engraved on each key fob used in a key exchange network. The serial number may be linked to the key's unique key identifier so that the serial number can be used to identify the key (as an alternative to scanning the key fob). For example, the serial number may be used if an NFC-enabled device is unavailable or if it is more convenient to perform a visual inspection of the key fob to identify the key.

In the embodiment illustrated in FIG1 , the key exchange server 108 includes a user credential database 131, an administrative user database 132, a key inventory database 133, and an access rules database 134. Such databases need not reside on the key exchange server 108 as shown. In other embodiments, one or more of these databases may be provided on another server or storage device accessible to the key exchange server 108.

Therefore, it is intended that the appended claims and claims hereafter introduced should not be limited to the embodiments set forth in the examples, but should be given the broadest interpretation consistent with the description as a whole.

Claims (59)

1. A method for facilitating the exchange of a key set comprising one or more keys at a key access location, the method comprising: Scan the key tag attached to the key group to obtain a unique key identifier; identify the key access location; assign a storage box to the key group at the key access location; and associate the storage box and the key access location with the key group; Receive access rules for the key group, wherein the access rules identify the authorized party; Publish the key access location to the authorized party; The client device receives an access request for the key group from the authorized party, the access request providing user credentials. The access request is authenticated by verifying the user credentials provided in the access request against a set of credentials associated with the authorized party; and If the access request is authenticated, an access instruction to submit the key set is sent. 2. The method of claim 1, further comprising: determining the location of the client device, wherein authenticating the access request further comprises comparing the location of the client device with the key access location associated with the key group. 3. The method of any one of claims 1 or 2, comprising: identifying the key access location by receiving one or more of the following from the client device: GPS data, mobile network location data, device identity data, physical interaction with the device, and user data input. 4. The method of claim 2, further comprising: determining the location of the client device by receiving one or more of the following from the client device: GPS data, mobile network location data, device identity data, physical interaction with the device, and user data input. 5. The method of claim 1, wherein the access rule includes an authorized access period, the method includes identifying the time of the access request, and authenticating the access request includes comparing the time of the access request with the authorized access period. 6. The method of claim 1, further comprising: receiving a plurality of access rules for the key group, wherein each access rule identifies an authorized party and a corresponding authorized access period. 7. The method of claim 6, further comprising: publishing the key access location to each of the authorized parties during a predetermined time period of the respective authorized access period. 8. The method of claim 1, further comprising: verifying that the correct key set has been submitted by initiating a scan of the key marker at the key access location. 9. The method of claim 1, wherein sending an access instruction for submitting the key group includes sending a storage box associated with the key group to the client device. 10. The method of claim 1, wherein the storage box is controllable by a control and processing unit, and sending an access instruction to submit the key set includes sending a signal to the control and processing unit to make the key set accessible. 11. The method of claim 1, further comprising: verifying that the requested key set is in the storage box by activating a scanner in the storage box to read the key identifier of the key set from the key mark. 12. The method of claim 1, wherein the key identifier includes a URL. 13. The method of claim 12, wherein the URL is linked to unique identification information assigned to the key group. 14. The method of claim 13, wherein the identification information includes numbers, letters or other alphanumeric strings. 15. The method of any one of claims 1, wherein the key identifier is encoded on a key chain attached to the key group. 16. The method of claim 15, wherein the key identifier is encoded in an NFC tag on the keychain. 17. The method of claim 1, further comprising: periodically scanning key tags of a key group at one or more key exchange locations and updating the association between the key group and the storage box and the key access location based on information from the periodic scans. 18. The method of claim 1, wherein publishing the key access location to the authorized party includes sending the key access location to a user account page or email account accessible to the authorized party. 19. The method of claim 1, further comprising: automatically generating a notification to a user associated with the key group in response to submitting the key group to the authorized party and handing over one or more items of the key group at a key access location. 20. The method of claim 1, further comprising: automatically generating a notification to the user associated with the key group if the key group has not been submitted to the authorized party by a specified time. 21. The method of claim 5, further comprising: automatically generating a notification to be sent to the authorized party at a predetermined time prior to the expiration of the access period. 22. The method of claim 1, further comprising: automatically generating a notification to be sent to the authorized party in response to submitting the key set to the authorized party. 23. The method of claim 22, further comprising: receiving, from an administrative user associated with the key group, the content of a notification to the authorized party, and including the content in the notification to the authorized party. 24. The method of claim 1, further comprising: automatically providing the authorized party with one or more pre-purchased items, coupons, or other offers for goods or services local to the key exchange location. 25. The method of claim 1, further comprising: automatically generating the access rules in response to one or more of a user request for a home service, an asset reservation, a recurring access request, and a request made by a third-party system authorized to request the key exchange service. 26. A system for facilitating asynchronous exchange of a key group comprising one or more keys at one of a plurality of key access locations, the system comprising a key exchange server configured to: Receive a unique key identifier encoded on a key tag attached to the key; Determine the key access location; A storage box is assigned to the key group at the key access location; Associate the storage box and the key access location with the key set; Receive or generate access rules for the key group, wherein the access rules identify the authorized party; Publish the key access location to the authorized party; The client device receives an access request for the key group from the authorized party, the access request providing user credentials. The access request is authenticated by verifying the user credentials provided in the access request against a set of credentials associated with the authorized party; and If the access request is authenticated, an access instruction is sent to submit the key set to the authorized party. 27. The system of claim 26, wherein the key access server is configured to determine the location of the client device and is configured to authenticate the access request by means of the following steps, the steps including comparing the location of the client device with the key access location associated with the key group. 28. The system of any one of claims 26 or 27, wherein the key access server is configured to identify the key access location by receiving one or more of the following from the client device: GPS data, mobile network location data, device identity data, physical interaction with the device, and user data input. 29. The system of claim 27, wherein the key access server is configured to determine the location of the client device by receiving one or more of the following from the client device: GPS data, mobile network location data, device identity data, physical interaction with the device, and user data input. 30. The system of claim 26, wherein the access rule includes an authorized access period and the key access server is configured to identify the time of the access request and is configured to authenticate the access request by means of a step including comparing the time of the access request with the authorized access period. 31. The system of claim 26, wherein the key access server is configured to receive or generate a plurality of access rules for the key group, wherein each access rule identifies an authorized party and a corresponding authorized access period. 32. The system of claim 26, wherein the key access server is configured to publish the key access location to each of the authorized parties within a predetermined time period of the respective authorized access period. 33. The system of claim 26, further comprising a key cabinet subsystem, the key cabinet subsystem including a plurality of storage boxes at the key access location. 34. The system of claim 33, wherein each of the plurality of storage boxes is adapted to receive a combination of a key and a keychain. 35. The system of claim 33, wherein the key cabinet subsystem includes a control and processing unit and the key exchange server is configured to send an access instruction for submitting the key group by sending a signal to the control and processing unit to enable the key group to be accessed by the authorized party. 36. The system of claim 35, wherein the key cabinet subsystem includes a scanner in the storage box, wherein the key exchange server is configured to send a signal to the control and processing unit to activate the scanner to read the key identifier of the key set to verify that the requested key set is in the storage box. 37. The system of claim 26, wherein the key exchange server is configured to receive the key identifier from a scan of the key group and is configured to verify, based on the key identifier, that the key group to be submitted to the authorized party is a correct key group. 38. The system of claim 26, wherein the key exchange server is configured to send an access instruction for submitting the key by sending the storage box associated with the key group to the client device. 39. The system of claim 26, wherein the key identifier associated with the key group includes a URL. 40. The system of claim 39, wherein the key identifier is linked to a visible unique identification information on the key chain. 41. The system of claim 26, wherein the key mark is located on a key chain attached to the key set. 42. The system of claim 26, wherein the key identifier is encoded in the NFC tag. 43. The system of claim 42, wherein the NFC tag is embedded in a recess in the metal pendant. 44. The system of claim 43, wherein the NFC tag is separated from the metal of the pendant by an anti-metal layer and is fixed in the metal recess by an epoxy resin layer. 45. The system of claim 26, wherein the key exchange server is configured to process a plurality of access rules for the key group, wherein each access rule identifies an authorized party and a corresponding authorized access period. 46. The system of claim 45, wherein the key exchange server is configured to publish the key access location to each of the authorized parties during a predetermined time period of the respective authorized access period. 47. The system of claim 26, wherein the key exchange server is configured to periodically trigger scans of key tags on the key group at one or more key exchange locations and is configured to update the association between the key group and the storage box and the key access location based on information from the periodic scans. 48. The system of claim 26, wherein the key exchange server is configured to publish the key access location to the authorized party by sending the key access location to a user account page or email account accessible to the authorized party. 49. The system of claim 26, further comprising a notification generator configured to generate a notification to a user associated with the key set in response to submitting the key set to the authorized party and handing over one or more items of the key set at a key access location. 50. The system of claim 49, wherein the notification generator is configured to automatically generate a notification to the user associated with the key group if the key group has not been submitted to the authorized party by a specified time. 51. The system of claim 30, further comprising a notification generator configured to generate a notification, wherein the notification generator is configured to automatically generate a notification to be sent to the authorized party at a predetermined time prior to the expiration of the access period. 52. The system of claim 26, wherein the key exchange server includes a notification generator configured to automatically generate a notification to be sent to the authorized party in response to submitting the key set to the authorized party. 53. The system of claim 52, wherein the key exchange server is configured to receive and store the content of a notification sent to the authorized party from an administrative user associated with the key group, and is configured to include the content in the notification sent to the authorized party. 54. The system of claim 26, wherein the key exchange server is configured to automatically provide the authorized party with one or more pre-purchased items, coupons, or other offers for goods or services local to the key exchange location. 55. The system of claim 26, wherein the key exchange server is configured to generate access rules from one or more system requests based on user requests for home services, asset reservations, recurring access requests, and requests from third-party systems authorized to request key exchange services. 56. The system of claim 33, wherein the key exchange server is configured to download an interactive application to the key cabinet subsystem, the interactive application including instructions that enable the key cabinet subsystem to interact with the key exchange server. 57. The system of claim 56, wherein the key exchange server is configured to download updates to the interactive application to the key cabinet subsystem. 58. The system of claim 33, wherein the key exchange server is configured to monitor the status of the key cabinet subsystem. 59. A method for facilitating the exchange of a key set comprising one or more keys at a key access location, the method comprising: Receive a unique key identifier encoded on a key tag attached to the key group; Determine the key access location; A storage box is assigned to the key group at the key access location; Associate the storage box and the key access location with the key set; Publish the key access location to the authorized party; The client device receives an access request for the key group from the authorized party, the access request providing user credentials. Obtain the access rules associated with the key group, wherein the access rules identify the authorized access period of the authorized party; The access request is authenticated by verifying the user credentials provided in the access request against a set of credentials associated with the authorized party, and by verifying that the access request was made within the authorized access period; and If the access request is authenticated, an access command is sent to the key cabinet controller to unlock the storage box.