Patent Description:
The management of keys in the real estate industry is a challenge. Typically, properties managers managing rental properties will manage a large number of properties, and as such have a large number of keys to manage. These keys need to be made readily accessible to property managers for inspections, to tradesmen and contractors for repairs, and to tenants.

Traditionally, property managers have used key cabinets, key numbers, and books or spreadsheets to manage their keys. In particular, when a key is borrowed, the details of the borrower are entered into the book or spreadsheet, and the key is taken.

A problem with such systems is that they are prone to error, and it is common for keys to go missing without any record in the book or spreadsheet. Furthermore, when a key is missing, this often goes unnoticed until the key is next required, which a) makes it almost impossible to relocate the key given that it may have gone missing a long time before being identified as missing, and b) requires the missing key to be rectified urgently.

Similar problems exist outside of the real estate industry. For example, cleaners and pool maintenance staff generally keep sets of keys for each of the properties in which they serve, which also are easily misplaced or go missing.

As such, there is clearly a need for an improved key management system.

<CIT> discloses an enhanced object tracking system for tracking and controlling access to a plurality of objects such as keys. The object tracking system includes: automated user identification using biometric data extracted from the user with a minimum of user interaction, tracking of objects both inside and outside their storage units, the locking of objects within slots of their storage unit to guard against illicit removal and return of keys and to insure random slot rotation, image and visual based inventory verification methodologies, and tracking of objects during times when they are checked out of the system.

<CIT> discloses methods and systems for facilitating exchanges of keys between individuals across multiple locations. Each key set is assigned a unique key identifier. The key identifier is encoded on a key chain attached to the key set. A key set is picked up or dropped off at a key exchange centre and is scanned to read the key identifier. The key identifier is relayed to a key exchange server which tracks key locations. The key exchange server verifies that an individual is authorized to pick up a key set and provides instructions to a device at the key exchange centre to enable access to the key set. The key exchange server coordinates drop-off of a key set by updating the key location associated with the key identifier at drop-off and providing instructions to a device at the key exchange centre for storage of the key set.

<CIT> discloses apparatus and methods for tracking, counting and inventorying keys throughout the supply chain, from manufacturing through retailing to the end user. The apparatus and methods generally rely on Radio Frequency Identification (RFID) technology, where information is stored to and collected from RFID tags that are located proximate to keys.

The present invention is directed to key management systems, which may at least partially overcome at least one of the abovementioned disadvantages or provide the consumer with a useful or commercial choice.

With the foregoing in view, the present invention in one form, resides broadly in a key management system as defined in claim <NUM>.

Advantageously, the system enables more efficient and accurate management of the keys, which in turn reduces the number of missing keys.

The system includes a plurality of key storage positions, each for storing one or more of the plurality of keys, wherein the at least one processor is configured to determine the presence of the one or more keys in the associated storage position.

Preferably, the at least one processor is further configured to determine the presence of a key in a storage position in which the key is not associated. An alert or notification may be issued based thereon, to enable the key to be repositioned correctly.

The key storage positions may be defined by retainers, such as hooks. The key storage positions may be provided in one or more key cabinets.

The at least one processor is configured to provide a graphical user interface to a user, the graphical user interface including a key loan interface, which enables a key of the plurality of keys to be loaned to a user.

The key loan interface may include a property search tool, enabling the user to search for a key based upon property information.

The at least one processor is configured to associate a loan period with the loan of the key by the user. The loan period may be defined at least in part using the key loan interface.

The key loan interface may further enable the user to book the key for a later time, thus defining a booked period. The key loan interface may then prevent the key from being loaned by another user during the booked period, or a period surrounding the booking period.

The processor is configured to provide a graphical representation of the plurality of key storage positions, the graphical representation illustrating the presence of a key associated therewith in the key storage position. The graphical representation may be colour coded to illustrate the presence or absence of a key in a key storage position.

Preferably, the RFID tag comprises an RFID key ring coupled to the key. Suitable, the RFID key ring is retained in the key storage position and thereby retains the key therein.

The system includes a visual indicator associated with each of the storage positions. The visual indicator indicates a status associated with one or more of the key storage positions, such as whether the key is correctly positioned or whether the key is overdue. The visual indicator may comprise an LED light.

The at least one processor is further configured to generate notifications based upon the status of one or more of the keys.

The notifications may include a notification to a borrower when a key is due or overdue. The notifications may include a notification to a property manager when a key is borrowed or returned.

Preferably, the system is configured to generate reports relating to a status of the keys. The report may include a missing key report, identifying each of the keys of the plurality of keys that is missing or overdue. This enables a user to promptly follow up missing keys, and thus have a greater likelihood of relocating same.

Preferably, the system is configured to generate a dashboard, providing an overview of the keys. The dashboard may indicate a number of keys that are available, and a number of keys that are not available.

The dashboard may indicate historical data relating to key returns, or overdue keys. The historical data may comprise trend data. This may be useful in identifying trends which may be utilised for efficiency, or to identify problems at an early stage (e.g. systematic overdue keys).

The system may further include a scanner, for scanning image data associated with a key. The key may be borrowed or returned, at least in part according to the scanned image data. The scanned image data may comprise a QR code or a barcode, for example.

At least one of the one or more processors may be remote to the RFID reader. The RFID reader may be coupled to the at least one processor by a wireless data interface.

Various embodiments of the invention will be described with reference to the following drawings, in which:.

Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way.

<FIG> illustrates a key management system <NUM>, according to an embodiment of the present invention. The key management system <NUM> is particularly useful in property management, as it enables property managers <NUM> to quickly see what keys <NUM> are available and not, and of the keys <NUM> that are not available who has them and when they are due back.

The system <NUM> includes a key cabinet <NUM> which is configured to receive and store the keys <NUM>, which provides automatic tracking of keys <NUM> into and out of the cabinet, and assists property managers <NUM> in identifying appropriate keys. <FIG> illustrates an enlarged view of the key cabinet <NUM>, according to an embodiment of the present invention.

The keys <NUM> are each coupled to an RFID key chain <NUM>, which includes data thereon in the form of a unique identifier. The cabinet <NUM> includes a plurality of predefined positions defined by hooks <NUM>, which are configured to receive the RFID key ring <NUM> and thus the key <NUM> coupled thereto. The key ring <NUM> is annular in shape and configured to extend over the hook <NUM>.

The cabinet <NUM> includes an RFID reader (not illustrated) associated with each of the predefined positions, the RFID reader configured to read data of an RFID key chain <NUM> in the respective position. The RFID reader may be configured to read data periodically or continuously, and as such, is able to determine whether a key <NUM> has been added or removed from the cabinet <NUM> by its ability to read the associated key chain <NUM> or not.

Data indicative of what keys <NUM> are present in the cabinet <NUM> is provided from the cabinet <NUM> to a remote server <NUM>. To achieve this, and outlined in further detail below, the cabinet <NUM> includes a controller, coupled to the RFID reader, the controller comprising a wireless data interface which is coupled to the remote server <NUM> using the Internet.

The remote server <NUM> is configured to receive the data from the cabinet <NUM> and generates cabinet data therefrom, including a virtual cabinet representation indicating a status of each of the keys associated with a cabinet.

Either upon configuration of the system <NUM> or when a new key <NUM> is added, each key <NUM> is associated with the RFID key ring <NUM> on the server <NUM>. This is generally achieved using a portal of the server <NUM>, which the property manager <NUM> or an administrative staff member associated therewith logs onto using a computing device <NUM>. A code or identifier of the RFID key ring <NUM> is then associated that with the particular property under management at the server <NUM>.

A position in the cabinet <NUM> is then allocated to that RFID key ring <NUM> (and thus key <NUM>), and the key is placed in the cabinet <NUM>. The position in the cabinet <NUM> may be automatically defined, e.g. next available position, or entered manually, e.g. on a website accessed using the computing device <NUM>.

The property manager <NUM> may log onto the server <NUM> as needed, using the computing device <NUM>, or another device, to obtain a status of cabinet <NUM>, such as what keys <NUM> are present, what a missing, what are overdue, etc..

Furthermore, the property manager <NUM> may search for a key <NUM> based upon property details or otherwise, and check out a key <NUM>. When the key <NUM> is checked out, the details of the property manager <NUM>, or the staff member that has checked out the key <NUM>, are associated with the checking out of the key <NUM>, as well as a term (loan period) in which the key <NUM> is checked out. The term may be automatically generated or manually entered.

Each position in the cabinet is associated with an indicator in the form of an LED light <NUM>. When a key <NUM> is checked out on the server <NUM>, the LED light <NUM> associated with the key <NUM> is updated to indicate same. As an illustrative example, the LED light <NUM> associated with the key <NUM> may illuminate blue when the key <NUM> is checked out (but still on the board) to make it easy for the property manager <NUM> to identify the correct key <NUM> to take (it should be the only blue light on the board).

The LED lights <NUM> illuminate in various colours to indicate a status of the associated key <NUM>. As an illustrative example, the LED light <NUM> may shine green when a key <NUM> is correctly positioned in the cabinet <NUM> and not checked out, red when the associated key <NUM> is missing and not correctly checked out, flash purple when the key <NUM> has been checked out and is overdue, yellow when the RFID key ring <NUM> is being read, and strobing red when there is an error in reading the RFID key ring <NUM>, or if the RFID ring <NUM> is not recognised or is invalid.

While the LED lights <NUM> are displayed adjacent to the hooks <NUM>, in other embodiments the LED lights <NUM> may be incorporated into the hooks <NUM>, or configured to illuminate the hooks <NUM>.

When a key <NUM> is returned to the cabinet <NUM>, the status of the LED lights <NUM> (which should turn green if the key <NUM> is correctly positioned) enables the property manager <NUM>, or whomever is returning the key <NUM>, to quickly confirm that the key <NUM> has been placed back in the correct position, and successfully registered into the system <NUM>. This thus prevents keys <NUM> from being accidentally placed in the wrong position.

The returning of the key <NUM> is reported to the server <NUM>, which is logged, and the status associated with the key <NUM> is then updated.

If a key is ultimately placed in the wrong position, and not repositioned, in addition to reporting this using the LED lights <NUM>, this is also shown on the virtual cabinet when viewed from the server <NUM>. As such, an administrator may log onto the server <NUM> to check a status of the keys and correct any incorrectly positioned keys immediately. Furthermore, notifications or alerts can be automatically sent to one or more administrators and/or to the property manager <NUM>, to enable such issues to be rectified promptly, avoiding later issues or confusion.

The cabinet <NUM> includes a pair of doors <NUM> which can be closed and locked. This enables the keys <NUM> to be kept secure from theft. The lock may be configured to be activated based upon the checking in or out of the key. As outlined below, however, the system may be adapted to store keys in any suitable form, including outside of a cabinet.

<FIG> illustrates a screenshot <NUM> of a virtual cabinet screen of the system <NUM>, according to an embodiment of the present invention. The virtual cabinet screen comprises a graphical representation of the cabinet <NUM>, which is colour coded according to a status of each associated key.

The cabinet screen includes a plurality of cells <NUM>, each colour coded according to an actual status of the cabinet <NUM>, and a booking status identifier <NUM> within the cell <NUM>, indicating a booking status associated with the key <NUM>.

The cells <NUM> are generally coloured light green, such as the cell <NUM>' to indicate that all associated keys <NUM> are present, light yellow to indicate that some of the keys <NUM> are present, and pink, such as the cell <NUM>", to indicate that none of the keys <NUM> are present.

The booking status identifier <NUM> that is within the cell <NUM> is coloured bright green, such as the identifier <NUM>', to indicate that all keys <NUM> are available to be booked, bright yellow to indicate that some keys <NUM> are available to be booked, and red, such as the identifier <NUM>", to indicate that no keys are available to be booked. The booking status identifier is further coloured purple, such as the identifier <NUM>‴, to indicate that the key <NUM> is checked out and overdue, and blue to indicate that the key has been checked out but not yet collected. Other colours may be used to indicate that a key is incorrectly positioned, missing without being checked out, or to indicate any other status associated with the key.

Finally, the cabinet screen includes a numerical key availability indicator, indicating numerically how many keys are available. This is particularly useful in case more than one set of keys is available for a property.

The cabinet screen is generally representative of the actual key cabinet <NUM>, and thus enables the property manager to associate a location on the cabinet screen with a location on the actual cabinet <NUM>. This is useful in case there is a problem with a particular key <NUM> or position, as the problem can be identified in the same place on the cabinet screen as it is in the actual cabinet.

The physical cabinet <NUM> (and the cabinet screen) generally do not include information about the property in which the key <NUM> is associated. This prevents persons from being able to rummage through the key cabinet <NUM> to identify a key for a particular property. Instead, each key ring <NUM> simply includes an identifier which is associated with the property at the server <NUM>.

As such, the system <NUM> includes a key search screen, which is access controlled and logged, which enables the property manager <NUM>, or authorised staff, to search for keys <NUM> based upon an address or key number.

<FIG> illustrates a screenshot <NUM> of a key search screen, according to an embodiment of the present invention. The key search screen enables the property manager <NUM> to search for keys <NUM> based upon details of the property or a key number.

The key search screen includes a search key component <NUM>, which includes a key number field and an address field, to enable the property manager <NUM> to search based upon key number or address. The fields are text fields enabling the property manager <NUM> to enter full or partial details thereof.

Once details are entered, the details of the associated keys <NUM> are provided in a results component <NUM>. The results component <NUM> includes a status of the key <NUM> (i.e. whether it is currently available), details of who the property manager <NUM> is, as well as specific instructions, security information or a textual description associated with the key <NUM>. This enables the property manager <NUM> to verify that the correct key has been identified.

The property manager <NUM> is then able to enter booking details relating to the key <NUM> in a booking section <NUM>, including a return date (essentially identifying a term associated with the loan), details of the recipient or borrower, and comments.

The booking section <NUM> includes reminder checkboxes and drop-down menus, which enable the user to enter details of when a reminder is to be sent (e.g. <NUM> hours before the return date). This is particularly useful in that such reminders may be assist in preventing keys from being overdue.

The key search screen further includes a transaction ledger component <NUM>, illustrating recent transactions that have taken place, including keys being borrowed and keys being returned.

Upon selection of a create loan button <NUM>, the booking is finalised and the cabinet screen, or a variation thereof, is shown to identify a location of the key <NUM> being booked. The key cabinet <NUM> is also updated such that the LED light <NUM> associated with the key is clearly identified.

Instead of checking out keys directly, keys can instead be reserved ahead of time to ensure they're in the office when they're needed. This is useful if a tradesperson is booked in at the property, or an upcoming inspection, as it will prevent the key from being borrowed out to someone else during that period.

In addition to enabling keys to be checked in and out, the system <NUM> enables reports to be quickly and easily generated relating to the cabinet <NUM>. Such reports may include checked out keys, or missing and overdue keys, and enable an administrator to get an overview of the system <NUM>, conduct audits and the like.

<FIG> illustrates a screenshot <NUM> of a missing keys screen, according to an embodiment of the present invention. The missing keys screen is an example of a report that that been generated in the system.

The missing keys screen includes a plurality of missing key rows <NUM>, each row <NUM> corresponding to a missing key <NUM>. In this case, the term "missing key" can refer to a key <NUM> that has been properly loaned by not been returned before its due date, or a key <NUM> that is missing for any reason.

Each of the missing key rows <NUM> includes a key number field <NUM>, an address field <NUM> and a date of last interaction field <NUM>.

The user, such as the property manager <NUM>, may search the list based upon key number, address and dates, to identify any patterns associated with missing keys.

Each row <NUM> is selectable, to obtain more details thereon. Such details may include logged data associated with the property (e.g. when the property has been searched for, and by whom), and details of associated bookings and returns. This may be particularly useful if the key has been manually identified as being returned, but never actually returned.

In addition to enabling reports to be generated, the system <NUM> includes a dashboard, which provides a quick overview of the system <NUM> and importantly the keys being managed.

<FIG> illustrates a screenshot <NUM> of a dashboard of the system <NUM>, according to an embodiment of the present invention. The dashboard provides an overview of the keys of the system <NUM>, including how many are available, upcoming bookings, trends and the like.

The dashboard includes an "all keysets available" element <NUM>, indicating how many keysets are fully available, a "some keysets available" element <NUM>, indicating how many keysets are partially available, a "no keysets available" element <NUM>, indicating how many keysets are not available, and an "unused position" element <NUM>, indicating how many unused positions are on the board. This enables the property manager <NUM> to get a quick overview of what is available and missing, as well as how far from filling the cabinet <NUM> they currently are.

The dashboard further includes a schedule overview element <NUM>, which provides an overview of the scheduled borrowings for that particular day, scheduled borrowings for the week, and overdue key returns. This assists the property manager <NUM> in planning for the day and week.

The dashboard includes a key trend element <NUM>, which provides a trend of key returns, which may be provided on a daily, weekly, or monthly basis, for example. The trend element shows, as a bar chart, how many keys were returned, and how many became overdue in for each period (e.g. day, week or month).

The key trend element <NUM> enables the property manager <NUM> to identify trends in the key returns, such as particular days in which key returns are higher than others, or sudden or gradual increases in overdue keys.

Finally, the dashboard includes a key overview element <NUM>, which provides an overview of each of the keys that is checked out according to whether the keys are with staff, with a contractor, with the owner, with the tenant, or with the agent, as well as whether the keys are overdue with the tenant or overdue with the contractor. This enables the property manager to quickly see where the keys are, and with whom.

According to certain embodiments, the system includes a notification module, which alerts the property manager <NUM> when keys are checked in and out and by whom. The notification module may include other information in the notification, such as when the keys are due back.

Similarly, the notification module may issue alerts when keys become overdue, with details of the person that has borrowed the keys. This enables the user receiving the alerts to be aware that that haven't been returned on time, and follow up immediately.

The notification module can also alert the borrower when the key is due back, as outlined above. Daily reminders may be automatically sent to the borrower when a key is overdue until it is returned.

Notifications or alarms may issue to the property manager if any problem is identified. For example, if a key is removed without checking it out an alert may immediately issue. The property manager may use the timestamps recorded from interactions with the server to see who was logged in at that time to help identify who may have taken the key. In many cases, the last person to look up a particular key prior to it going missing is the person who has taken it.

Notifications may issue when other agents are borrowing keys. In particular, the system may determine that the person borrowing the key is another agent (or otherwise a competitor), e.g. based upon a predefined list. This in turn enables the property manager to contact clients and remedy any issues, to avoid having management of the property transferred.

Finally, notifications may issue even when expected actions occur, such as confirmation notifications when keys are returned.

As outlined above, the cabinet <NUM> includes a controller, which enables communication with the server. <FIG> illustrates a schematic of a controller <NUM>, according to an embodiment of the present invention.

The controller includes a processor <NUM>, a memory <NUM> coupled to the processor, and a plurality of RFID readers 715a-n coupled to the processor <NUM>. The memory <NUM> includes instruction code executable by the processor <NUM> for reading data from key rings using the RFID readers 715a-n. The data may be read periodically or continuously.

The processor <NUM> is further coupled to a wireless data interface <NUM>, and the memory <NUM> is further configured to send the data from the key rings (or absence of data - to indicate that a key is not present) to a remote server. The wireless data interface <NUM> is advantageously a WIFI data interface, but could also comprise a cellular data interface (e.g. <NUM> or LTE data interface).

The processor <NUM> is further coupled to a plurality of LED lights 725a-m, and the memory <NUM> is configured to receive data on the wireless interface <NUM> (and from the server) and illuminate the LED lights 725a-m based thereon. As outlined above, the lights 725a-m may be illuminated to illustrate a status of the associate key position.

According to certain embodiments, the RFID key chain <NUM> also include remote tracking capabilities. As an illustrative example, the RFID key chain <NUM> may include a global positioning system (GPS) sensor and a data interface configured to send data from the GPS sensor to the remote server <NUM>. In case a key is missing or overdue, the system <NUM> may be used to request location data from the RFID key chain <NUM>. The received location data may then be presented to the user making the request, e.g. on a map, enabling the user to further investigate a location of the key.

The data interface may be any suitable interface including a Bluetooth, radio (e.g. UHF) or a cellular data interface. Similarly, Bluetooth or UHF capabilities may not only be used as a data interface, but also for indoor short-range location of keys. This is particularly useful as it enables keys to be searched locally without requiring any long-range communications means (e.g. a cellular interface) to be provided in the key chain <NUM>, and as such, enables key chains <NUM> to be produced at a low cost.

In addition to enabling a user to check a location of a key on-demand, the system may be configured to automatically request or determine a location of a key when certain conditions are met, such as when the keys become overdue, or when the keys become missing.

According to certain embodiments, the server includes an import tool, to simplify the import of a large number of keys into the system. The import tool may be configured to import key numbers by CSV file, or any other suitable way, to avoid having to enter each key manually. This is particularly useful when transitioning to the system from a manual or spreadsheet-based system.

In order to simplify checking in keys, a barcode may be provided on the key ring. When the key is returned, the barcode may be scanned by the system, and automatically identify a location to which the key is to be returned.

Similarly, keys may be checked out using a barcode, which may be printed on work orders or the like. As such, the user need not enter any data associated with the property to identify the key that is required.

While the above has been described with reference to a single property manager <NUM>, the skilled addressee will readily appreciate that multiple property managers will utilise the system and share key cabinets, as well as associated staff. In such case, different property managers may be issued with notifications depending on whether the property associated with the key is managed by them or not.

Furthermore, while the above has been described with reference to a single key cabinet, the skilled addressee will readily appreciate that multiple key cabinets may be used. In one embodiment, the system may be configured to identify in which cabinet a key is located, in addition to its location within the cabinet.

Furthermore, while the system is described above with reference to cabinets, the skilled addressee will readily appreciate that the system may take any suitable shape or form. As an illustrative example, a wall of keys may be provided, where the key hooks are positioned directly on a wall rather than in a cabinet. In such case, the system may be built of one or more key panels, which may be connected to each other, enabling the system to be expanded, as needed.

The system may be integrated with other systems, including rental management systems. This is particularly useful in that data need not be entered twice, and the system may automatically reserve keys when a work order is generated, or when a viewing or inspection is booked, for example.

The system <NUM> may also include security functionality, such as user controlled access to the cabinet to enable identification of those who may have taken keys. Furthermore, a scanner may be associated with an exit of a room or building in which the cabinet is located, to issue an alarm if a key is attempted to be removed from the room or building without having been properly checked out.

While the above is described with reference to property management, the skilled addressee will readily appreciate that such key management may be useful in other industries, such as for cleaners, maintenance businesses (e.g. pool maintenance), or any other business that must manage multiple keys.

Similarly, the skilled addressee will readily appreciate that the system may be used to manage other items, associated with a property or otherwise, such as access cards, garage door remotes, and the like. In such case, storage boxes, shelves or the like may be provided in association with cabinets, or instead of cabinets, with associated RFID readers, to enable storage and monitoring of the items.

Advantageously, the systems described above enable more efficient and accurate management of items such as keys, which in turn reduces the number of missing keys. Furthermore, when keys go missing, this may be quickly identified, increasing the likelihood that the key is found, thus reducing costs and issues associated with missing keys.

Furthermore, the system enables keys to be booked in advance, which prevents the situation where keys are double booked, such as when maintenance is booked in advance, but another person happens to check out the required keys shortly beforehand.

In the present specification and claims, the word 'comprising' and its derivatives including 'comprises' and 'comprise' include each of the stated integers but does not exclude the inclusion of one or more further integers.

Reference throughout this specification to 'one embodiment' or 'an embodiment' means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases 'in one embodiment' or 'in an embodiment' in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

Claim 1:
A key management system (<NUM>) comprising:
a plurality of keys (<NUM>), each key including an RFID tag (<NUM>) associated therewith;
a plurality of key storage positions (<NUM>), each key storage position being operable to store a particular one, or particular ones, of the keys, being the key or keys which is/are associated with that key storage position;
a visual indicator (<NUM>) associated with each key storage position;
at least one RFID reader (<NUM>) operable to read the RFID tags of the plurality of keys; and
at least one processor (<NUM>), coupled to the at least one RFID reader, the at least one processor being operable to determine the presence of the key(s) in the key storage position with which that/those key(s) are associated;
characterised in that the at least one processor provides a graphical user interface including a key loan interface, which enables a key or keys that is/are associated with a key storage position to be checked out for use by a user for a certain loan period, the loan period being defined in a checkout process, and
in that the visual indicator associated with each key storage position is operable to provide a visual indication of one of the following statuses as a current status of the key(s) associated with that key storage position:
a "checked in" status, when one or more key(s) that is/are associated with the key storage position is/are in the key storage position and not checked out for use by a user;
a "missing" status, when one or more key(s) that is/are associated with the key storage position is/are not in the key storage position and also have not been validly checked out via the key loan interface; and
an "overdue" status, when one or more key(s) that is/are associated with the key storage position is/are not in the key storage position, having been validly checked out via the key loan interface and removed from the key storage position previously, but the loan period for which said key(s) were checked out has expired.