FI20225047A1

FI20225047A1 - Managing tool for a process managing keys, and a key managing process

Info

Publication number: FI20225047A1
Application number: FI20225047A
Authority: FI
Inventors: Marko Määttä
Original assignee: Lukkopro Oy
Priority date: 2022-01-21
Filing date: 2022-01-21
Publication date: 2023-07-22
Also published as: WO2023139311A1

Abstract

The present invention relates to rental apartment key handling and management system for keys involving a programmable part. The system comprises a processor, a database and a piece of software, and automated package locker systems and/or distribution devices in desired key retrieval and return locations. The key retrieval devices comprise a PIN code reader, user interface and possibly a screen. The key retrieval devices also comprise at least one camera, and/or RFID sensing means for reading the programmable keys after returning. The key handling system presents various messaging between the system and the customer, provides assistive information, and lets the customer to choose from a web page interface either from a map or an address list, where to retrieve or return the key(s) concerned. The handing-over process of the keys (100), and the returning process of the keys (500) are both enabled with the same system and devices.

Description

MANAGING TOOL FOR A PROCESS MANAGING KEYS, AND A KEY

MANAGING PROCESS

Technical field

The present invention relates to distribution and collecting processes of physical keys and management of these processes, relating e.g. to rental apartment provid- ers and their clients (residents), and respective other service providers.

Background

Real estate agencies and rental apartment providers handle and manage a vast amount of keys for accessing their premises on sale or available for rent. Certain other service providers such as hotels, hospitals, nursing homes and short-term of- fice space providers may also need to handle and manage keys or other respective access tools for managing control of the various premises securely, where (i.e. to whom) the keys have been released, and gathered back when e.g. the contract ends.

Traditionally, the keys have been fully mechanical access tools, where no program- ming or electric parts have been involved within the keys themselves. Of course, the managing tool of the keys may have involved some electrical database comprising e.g. the release date (&time), gathering date (&time) and ID information of the cus- tomer to whom the key has been validly given based on a certain basis (i.e. a rental contract, other contract or accommodation reservation in hotels).

N Currently, there are novel solutions involving “intelligent” keys, where there is an

N electronic and programmable part embodied e.g. in a form of a microchip, a memory 5 and data transmission means between the intelligent key and the service provider's n 30 system. Finnish company iLOQ Oy is one example of a provider, which has created

I intelligent locking systems and keys, involving the idea where the required input = power for the locking system locally is taken from the insertion (i.e. pushing) move- s ment of the key into the lock itself by the human user.

LO

N

S 35 US 2021/0019979 A1 (“Mackenzie”) discloses a key transfer system and a method with independently accessible storage units. Mackenzie relates especially to keys of various vehicles, and it provides an automated locker system for transporting keys safely between the owner and the maintenance personnel of the related service intentionally purchased for the user's car. The locker may comprise the key distri- bution of spare cars to the customers. The locker has internet connection to a cloud service, and there is a payment module and a user interface.

US 2013/0024222 (“Dunn”) discloses a system and method for controlling access to electronic locks. This is a reservation system for managing access to access con- trolled locations by issuing an access code that is valid at a particular lock for a particular time. Dunn also enables booking of a hotel room, and the generation of a

PIN code. The key is a fully electronic one, without mechanical key parts.

US 8,516,250 (“Lohiniva”) discloses a lock administration system for self-powered locks. Lohiniva's system comprises an intelligent key system and a related server and encryption/decryption means provided by the intelligent key system provider.

The system provider is iILOQ Oy (from Oulu, Finland), and we refer to this system later as the iLOQ's system.

US 2001/0025250 (“Gale”) discloses a method of managing a real estate unit in a remote connection. In this method, the user may make a connection to a server from a remote location (from own local computer) via a web page, and the user may download various options regarding the managing of the rental apartment; e.g. re- lating to financial obligations such as the rent of the flat or parking costs, and relating to general information and amenities of the tenement building. It is notable that there are no locks or keys mentioned relating to the management system of Gale.

WO 2020/191445 (“Mitris”) discloses key safe and key access systems for tempo- rary service providers or other temporary users of premises, such as cleaners of the 3 premises. The system provides a locker arrangement, where the manager of the & system may set the proper keys to the locker, in connection with respective QR- 5 codes. The information is updated in the cloud server. Designated cleaners (or other n 30 desired temporary users of the premises) are managed so that an administrator

I gives access to the selected cleaner by sending a withdrawal message (a OR code) = to him/her for retrieval of the key. When the key is retrieved from the locker by the s cleaner, the system updates this status change of the key into the cloud server. a There may also be a user interface offered via a dedicated web site.

S 35

Traditionally, rental apartment providers have managed the handing over and re- turning processes of the keys with the customers by inviting the customer to their office, where the ID check, possible completing and signing of the rental contract and the release of the keys to the verified customer all take place manually and face-to-face between the service provider's representative and their client.

The technical problem in the above prior art is that no complete, automated key handling and managing system has been presented for deliveries of keys, which involve both a mechanical part and an intelligent (i.e. electrically storable and read- able) key part, and their programming according to the emerged situation during the key handling operations. Some locker systems are known for distribution of goods and even keys (see in the above), but there is no fully automated key distribution management system involving intelligent keys.

Summary

The present invention solves the above mentioned technical problem, by providing a complete management and handling systems involving intelligent keys. The man- agement system is especially applicable for rental apartment providers and their customers, but the present invention is not restricted solely into that application area.

The present invention introduces a key handling process for keys involving both a mechanical part and a programmable (i.e. electrically readable) part. Such keys can be shortly called as intelligent keys (“alyavain” in Finnish). The present invention is well suitable for rental apartment service providers or other tenement house apart- ment providers or student housing management systems. Still, other application ar- eas involving e.g. accommodation services, temporary office spaces, temporary storage space providers, and the like are also possible for the present invention.

N

N In other words, the present invention introduces, in its first aspect, a key handling 5 system for handing out intelligent keys (100) based on a contract made between a n 30 rental apartment provider and its customer, comprising a processor, a database and

I a piece of software. The key handling system is characterized in that the key han- = dling system is configured to perform the steps of: s - reading a new contract data from the rental apartment provider's database by a the key handling system (101);

S 35 - sending a message from the key handling system to a terminal device of a customer, reguesting the customer to select a retrieval location of the key or keys (102);

- presenting to the customer, by the key handling system, all possible retrieval locations comprising compatible key parts (104); - letting the customer to select a retrieval location (105); - sending, from the key handling system, information of the selected retrieval location and a PIN code to the terminal device of the customer (106); and - when the key(s) have been picked by the customer using the correct PIN code from the selected retrieval location (107), registering the retrieval to the database of the key handling system comprising a customer name, date and time of the retrieval, and one or more photographs taken from a situation of the retrieval and/or data obtained by other identification tool identifying the handed-out key(s) (116).

In an embodiment of the present invention, the key handling system is configured to initiate the following step, when the retrieval location has been selected by the customer, - finishing an intelligent key from a compatible semi-finished key product by pro- gramming the correct key data into the intelligent key based on the information of the read contract data.

In an embodiment of the present invention, the key handling system is configured to perform the steps of: - if after the retrieval of the key(s), at least one key does not work for the rented apartment according to the contract data (111), - letting the customer inform a non-working key to the key handling system via email or phone call (112); - creating a new intelligent key for the customer based on the contract data (113); and 3 - handing out the new intelligent key to the customer according to the steps

N of claim 1, starting from the step of sending a message.

O n 30 In an embodiment of the present invention, the key handling system is configured

I to define a sub-group of retrieval locations where the customer has a retrieval loca- = tion preference, and basing the retrieval location preference either on shortest dis- s tances to the rental apartment address, or shortest distance of the current address a or current location of the customer, or both.

S 35

In an embodiment of the present invention, if no compatible semi-finished key prod- ucts exist in any of the sub-group of retrieval locations where the customer has a retrieval location preference, the key handling system is configured to perform the steps of: - ordering new compatible semi-finished key products from the rental apartment provider, and when the semi-finished key products arrive at least to one retrieval 5 location among the sub-group of retrieval locations, - starting the key retrieval process from the beginning according to the steps of claim 1.

In an embodiment of the present invention, the key handling system comprises in each desired key retrieval and return location an automated package locker system or a distribution device, which further comprises a camera capable to photograph handed-out and returned keys, and a user interface for PIN code insertion.

In an embodiment of the present invention, the automated package locker system or the distribution device comprises a display providing further instructions to the customer, or alternatively, the key handling system is configured to provide further instructions to the customer via a message to the terminal device of the customer after the successful retrieval.

In an embodiment of the present invention, the key handling system is configured to perform the following step: - letting the customer to select the retrieval location (104, 105) of the key(s) from a map interface, or from a list of addresses with possible additional assistive infor- mation relating to each address.

In an embodiment of the present invention, after the successful retrieval of the 3 key(s), the key handling system is configured to perform the following step:

N - allowing the customer to place and to program all received keys in a key pro- 5 gramming device, or in a key programming lock, locating in the key retrieval and n 30 return location (109). = = In an embodiment of the present invention, the key handling system further com- s prises: a - a time frame interpreter (302), configured to examine (304) key returning time

S 35 frame rules, and to compare a key return date with a contract end date by taking mid-week holidays and weekends into account; and - a contract interpreter (303), configured to examine and interpret (305) the con- tract start and end dates, the rental apartment name or address or other identification information, and related occupant name and related identification in- formation relating the occupant.

In an embodiment of the present invention, the key handling system is configured to perform the following steps: - allowing the customer to make a request for purchasing at least one extra key (401); - sending an SMS or email comprising a web link for a payment of the extra key(s) to the customer (402); - allowing the customer to pay the payment of the extra key(s) via a web pay- ment service (402); and when the payment is approved, - initiating a handing-out process of the extra key(s) (403) according to the steps of claim 1.

In an embodiment of the present invention, the other identification tool is an RFID reader performing RFID identification via an RFID chip in a respective handed-out key.

The present invention introduces, in its second aspect, a key handling system for returning intelligent keys (500) based on a contract made between a rental apart- ment provider and its customer, comprising a processor, a database and a piece of software. The key handling system is characterized in that the key handling system is configured to perform the steps of: - reading a key returning action information from the rental apartment provider's database by the key handling system (501), comprising the customer identification information and the number of initially retrieved keys by the customer; and 3 - when a contract information for the customer is interpreted to be expired or

N expiring in incoming days by the key handling system (502), the key handling system 5 is configured to perform a step of n 30 - creating a key returning reguest message to the customer (502), which

I key returning request message comprises a selection query, allowing the customer = to select, where the customer desires to return the key(s); and s - when the customer has selected the return location (503), sending a PIN a code to the customer by the key handling system, and more detailed information

S 35 concerning the returning of the key(s) to the selected return location (505); - when the key(s) have been returned by the customer using the correct

PIN code to the selected return location (505), assisted by instructions either on a screen of the return location or of a terminal device of the customer, examining the returned key(s) (601) by a camera and image processing software (603), and/or by other identification tool (602), comprised in the key handling system, and if the num- ber of returned keys matches the number of retrieved keys and/or an identification information of the returned keys matches the identification information of the re- trieved keys (604, 605), - determining the returning action of the key(s) to be successful (606-608).

In an embodiment of the present invention, when the customer has selected the return location, the key handling system is configured to perform the following step: - reserving a locker from an automated package locker system or a distribution device of the selected return location (504).

In an embodiment of the present invention, if the key returning does not happen in a predetermined time frame, the key handling system is configured to perform the step of: - sending a reminder to the terminal device of the customer either via SMS or email (509).

In an embodiment of the present invention, after the key(s) have been successfully returned to the selected return location, the key handling system is configured to perform the steps of: - sending key programming information to a locking system over an interface (506); - blacklisting the returned key(s) (507), and - marking, over the interface, the returned key(s) as available for new use (508). 3 In an embodiment of the present invention, the other identification tool comprises

N RFID-based identification (602), and the return location comprises an RFID reader, 5 wherein identifying of a returned key is made electronically via an RFID chip of the

N 30 key. = = In an embodiment of the present invention, return location with either the camera or s the RFID reader is provided with a conveyor belt -based transfer system and/or a a revolver-type drum from each cavity or locker of the return location for the keys,

S 35 towards the vicinity of the camera or the RFID reader, the transfer system being powered by at least one motor.

In an embodiment of the present invention, the transfer system within the automated package locker system or the distribution device is configured to move the returned keys one by one from the locker or cavity to the vicinity of the camera or the RFID reader, so that the type and/or condition of each returned key is sensed, and the total number of correct and valid keys is sensed with respect to the returning cus- tomer.

In an embodiment of the present invention, the key handling system is configured to perform the following step: - if the returned number of key(s) does not match with the number of the handed- out key(s) or the RFID identification gives a wrong key identification information con- cerning the returning customer, - creating a service request from the key handling system to a mainte- nance worker of the system, for checking manually the returned keys of the selected return location (604).

In an embodiment of the present invention, the key handling system is configured to perform the following step: - when the automated or manual inspection for the number, type or condition of the returned keys is completed as successful (605), - sending a message from the key handling system to the rental apartment provider, that the keys relating to a specific contract have been successfully returned (606).

In an embodiment of the present invention, the key handling system comprises an automated package locker system in a desired key retrieval and return location, 3 which further comprises a camera viewing each locker, a user interface for PIN code

N insertion, and a display providing instructions to the customer.

O n 30 In an embodiment of the present invention, the key handling system comprises a

I distribution device capable also to collect the returned keys, in a desired key re- = trieval and return location, where a camera is able to take a photograph of an inser- s tion/returning cavity of the distribution device (603).

LO

N

S 35 In an embodiment of the present invention, the key handling system comprises a distribution device capable also to collect the returned keys, in a desired key re- trieval and return location, where an RFID reader is able to sense items within an insertion/returning cavity of the distribution device (602).

In an embodiment of the present invention, the key handling system is configured to perform the following step: - reading a programmed part of the returned intelligent key(s) in order to verify that the returned key(s) concern a correct address according to the specific contract (602).

In an embodiment of the present invention, the key handling system is configured to perform the following step: - letting the customer to select the return location of the key(s) from a map in- terface (503), or from a list of addresses with possible additional assistive infor- mation relating to each address.

In an embodiment of the present invention, the key handling system further com- prises: - a time frame interpreter (302), configured to examine (304) key returning time frame rules, and to compare a key return date with a contract end date by taking mid-week holidays and weekends into account; and - a contract interpreter (303), configured to examine and interpret (305) the con- tract start and end dates, the rental apartment name or address or other identifica- tion information, and related occupant name and related identification information relating the occupant.

Brief description of the drawings

Fig. 1 illustrates a handing-over process of the key(s) to the customer of the rental apartment service provider, its first part,

N

N Fig. 2 illustrates a handing-over process of the key(s) to the customer of the rental 5 apartment service provider, its second part, = 30

I Fig. 3 illustrates software robot interpreters handling the rental contract details and + the time frame, 3 a Fig. 4 illustrates a handing-over process of extra key(s),

S 35

Fig. 5 illustrates a returning process of the key(s) from the customer of the rental apartment service provider, its first part, and

Fig. 6 illustrates a returning process of the key(s) from the customer of the rental apartment service provider, its second part.

Detailed description

Rental apartment providers and corresponding service providers may have a vast number of rentable premises in many cases where the service provider is a large company or a municipal authority. Thus, the system designed for handling the man- agement of the keys or other respective access tools may become complicated when there is a large number of physical keys to be held safely in designated loca- tions. The rental apartment provider may operate in a larger city, where there are various neighbourhoods where the rental apartments locate; therefore, a single of- fice for key retrieval would not offer the best possible service quality for a new cus- tomer coming to fetch his/her keys to a new apartment. The same also applies to nationally operating rental apartment providers, which have rental apartments or other respective spaces (e.g. office / storage) available in a group of various cities or towns, and/or in a countryside across a larger area.

Some automated solutions have been created, but they are usually automated pack- age lockers or respective systems available in a certain public place, or within e.g. a lobby of the tenement apartment provider's office. The lockers meant for delivering packages now commonly used in many public places are good for delivering regular packages, but not very good when delivering a personalized object, like a program- mable intelligent key. The present invention goes deeper into this problem, and pre- sents a system-like solution where the complete key handling, programming and related messaging options are provided for clients desiring a rental apartment utiliz- 3 ing intelligent keys; thus, comprising also a convenient way of a reception of the

N keys for the new apartment.

O n 30 The present invention introduces a system for intelligent key management and pro-

I gramming, meant both for handing over (i.e. retrieval of) the respective key(s) to - (by) the customer, and also for an opposite step, where the client returns the key(s) s to the service provider after the rental contract has been ended or is about to end.

LO

N

S 35 Thus, the handing-over (i.e. retrieval) process of the keys 100, and the returning process of the keys 500 are both enabled with the same system and devices.

Figure 1 is hereby referred to. It illustrates a handing-over process of the key(s) 100 to the customer of the rental apartment service provider, concerning its first part, and concerning an embodiment of the present invention.

At a first step 101, the rental contract system sends an API interface message con- cerning a new or updated rental contract or concerning a payable extra key (the latter in discussed in connection with Figure 4). This message is thus sent to the key handling and management system. In other words, a new contract information is read from the system of the rental apartment service provider, concerning a pre- defined customer. Naturally, this contract has been created earlier and stored in the database of the service provider, when the customer has established and agreed on the rental contract with the apartment provider. The customer as well has re- ceived a copy of the finished and signed rental contract.

At a second step 102, the API interface message is read into a so-called “EasyKey” system, and sending an SMS comprising a web page link to the customer, request- ing to select a key retrieval location. In other words, the key management and han- dling system retrieves the identification data of the customer from the new contract information, and secondly, the key management and handling system sends an

SMS comprising a dedicated web page information, where the customer is re- quested to proceed and select a suitable retrieval location for the key or keys.

The relevant programming information for these dedicated keys is sent to an intelli- gent key supplying company, i.e. to their system over an interface. This is the step 103; in other words, providing the key programming information over the interface to the locking system.

N

N On the other hand, the handing-over process proceeds to step 104, where an illus- 5 tration tool in the dedicated web page shows distribution locations on a web page, n 30 possibly in a list form, or illustrated on a map, or in both forms. The distribution

I location may comprise an automated vending machine or a locker system, where = keys can be stored and distributed to an identified customer. The shown, available s distribution locations must be in line with available key slabs (i.e. preliminary physi- a cal piece of a key) being present in that respective location. Also, some locationing

S 35 information based on the customer's current location may be used as an assisting tool for the system to propose the most reasonable retrieval locations for the keys.

Usually, the most reasonable locations are the most closest ones physically with respect to the customer's current location. In other words for step 104, the EasyKey system lists and/or illustrates all automated retrieval locations which comprise com- patible key slabs available for distribution.

Then, at a next step 105, the customer selects the retrieval location of the keys by pressing appropriate tab in his/her web page interface.

Next, at step 106, the customer receives a PIN code in another SMS, and infor- mation of the retrieval location, and the customer is directed to fetch the keys based on this information.

Based on this arrival information, the customer will proceed to the location of the selected automatic key vending device (or the like), at a time freely selected by the customer him/herself. The automatic key vending device may comprise a group of controllably lockable locker spaces, an interface for PIN code entry such as a key- board or a touch screen, and a related visualization device in form of a separate screen (or the touch screen). The screen may provide an area where instructions for the customer are given. It also may show a schematic illustration of all the lock- ers, where the correct locker may be pointed out by graphic means e.g. by coloured indications or a pointing arrow or the like. Another option is to provide the lockers with a running numbering and by giving the customer a correct number in the screen which marks the correct locker with the correctly programmed keys. Yet another option is to blink a LED on the correct locker or right next to the correct locker. Many directing tools are possible for guiding the customer to the correct locker. Further- more, a camera or several cameras may be included in the system for photo- graphing the customer during the actions made with the vending device, and/or for photographing also the returned keys with an internally placed camera (this is de- 3 scribed later in more detail). Also, the camera may be set up to take image(s) of the

N released keys (i.e. for the handing-over), before the customer comes to retrieve 5 them, or by taking a photograph from the release cavity or locker just when the n 30 retrieval action is ongoing (i.e. right after the correct PIN code has been entered, but

I before the opening of the locker or cavity for the customer). It is also possible to take = a photograph of the same location when the retrieval action has been concluded by s the customer, to just verify and log into the system that the released keys have a indeed been picked up by the customer. Such an intrinsic camera of course needs

S 35 a functioning flashlight in order to allow good guality for the taken images inside the cavities and/or lockers.

The number of the released and actually picked-up keys by the specific customer may be stored as a numerical parameter into the database of the key handling sys- tem, besides the customer ID information (i.e. customer name) and the time/date information concerning the actual key retrieval.

In step 107, the customer inputs the received PIN code via the input interface of the automated locker system, and receives the keys designated to him/her. This is em- bodied by showing e.g. the correct locker on the screen, after the correct and valid

PIN code has been entered by the customer. See the previous paragraph for other possible pointing means of the correct locker. Simultaneously or subsequently when guiding the customer to a correct locker, the automated retrieval device guides the customer to check and test all received keys in step 108. This is important for the reason, that a possible mis-programming of some or several of the received keys can be corrected as soon as possible, and not after the first and the only correctly operative key goes missing. The steps in connection with the testing of the keys are shown in Fig. 2. We thus proceed to Fig. 2.

Figure 2 illustrates a handing-over process of the key(s) to the customer of the rental apartment service provider, its second part.

The process now proceeds to steps 109 and 116 (shown as parallel steps). In step 109, the customer places and programs all received keys in a key programming device, or in a key programming lock. In an embodiment, in parallel or subsequently with this step, the keys are signed for the customer with the retrieval action data in the key register; comprising date/time stamp, customer ID information, taken pho- tograph(s) e.g. from the keys and/or from the customer, and/or RFID identification

N of the handed-out keys. This is the step 116. Some other required information may

N also be included in the retrieval action data, such as the number of released keys 5 for this customer, and/or the (sub-)type of the provided keys (if there are different n 30 intelligent key types available for the retrieval to the customer). This (= step 116) is

I the same as storing all relevant retrieval action data concerning specific keys and a = specific customer to the database of the system. 3 a After the programming of the all received keys in a dedicated key programming de-

S 35 vice or in a key programming lock 109 (e.g. locating right next to the key vending device), the customer is free to leave the retrieval location. The device acknowl- edges the retrieval process as finished, and becomes available for the next incoming customer.

The customer is now able to go to the rental apartment itself with all the received keys. Now the customer should test all received keys 110 for verifying that all keys function as planned and all programmings are indeed correct in the electrical parts of the keys. The testing was instructed on the screen of the vending device (in step 108 of Fig. 1), but additionally, a similarly guiding SMS could be sent to the customer as well e.g. like one hour after the retrieval of the keys was completed. This is an optional step.

If for some reason a key (or several of them) does not work 111, then the customer should submit a message to the key managing service provider 112 (the applicant is here marked as an example). The message may be sent via a web link, or via an

SMS; naturally other messaging channels can be used as well, such as calling to a service desk of the key managing service provider.

The service provider will then guide the customer to a programming service point for updating the programming of such a key 113. The service point may be the same as initially during the first retrieval of the keys, or another service point which for instance could locate closer to the current customer location. Alternatively in step 113, the customer may be supplied with new keys; according to the earlier pre- sented process. One further option is that the customer may try the updating of the programming once in the service point, and if after further testing of the updated key(s), it/they do not still work in the lock of the apartment's front door, then the system initiates the supplying of new keys for the customer according to the previ- ously disclosed handing-over process of the key(s).

When after the testing (and possible re-programmings and key changes) all the keys 3 work properly in the lock of the apartment's front door 114, no error message is

N anymore created, and the handing-over process of the keys is set to end at step 5 115. = 30

I Next, we present software robot interpreters handling the rental contract details and = the time frame according to Figure 3. The flow chart will continue from step 101 of s Figure 1; namely, "Rental contract system sends an API interface message con- a cerning a new or updated rental contract or concerning a payable extra key” at the

S 35 start of the handing-over process of the keys.

Figure 3 proceeds next to step 301, which is an interpreter of a “software robot”.

Alternatively, this block can be called a processor and a piece of software (i.e.

computer program) and a clock & calendar, where the computer program is created to search certain fields of data in the rental contract and to compare certain time- related parameters between the real-time actions and the dates marked in the con- tract. The desired steps are run when the computer program is executed in the pro- cessor.

The interpreter comprises two aspects: a time frame interpreter 302 and a contract interpreter 303.

The role of the time frame interpreter 302 is to examine the key returning time frame rules, and to compare the key return date with the contract end date by taking mid- week holidays and weekends into account 304. The time frame rules may state for instance that the key retrieval is possible starting at the start date of the rental agree- ment validity period (e.g. on a first day of a certain month; but of course any other date is also possible), starting at 12:00 PM (midnight). Concerning the returning of the keys (discussed in connection with Figures 5-6), the time frame rules may state for instance that the actual key returning must happen at the latest on the last day of the rental agreement validity period, before 12 PM (before midnight). On the other hand, the keys themselves could proceed to a non-working state electronically at the final validity date at 12 PM, but the returning of the key(s) could still be possible for instance for the next 1, 2 or 3 days (depending on the selected parameter by the organizing body i.e. the service provider) after the rental agreement has ended.

Many other possible time frame rules may be created and applied in the disclosed key handling and management system.

The contract interpreter 303 may examine and interpret the contract start and end 3 dates, the rental apartment name/address/other ID information, and related occu-

N pant (i.e. the customer in this context) name and related ID information 305.

O n 30 Thus, as a summary of Fig. 3, all relevant data of the rental agreement contract is

I used and “mirrored” against the real time information of the made actions and the - customer ID information. 3 a Figure 4 illustrates a handing-over process of extra key(s) 400.

S 35

The customer, who needs an additional key for the rental apartment, may make a reguest for purchasing extra key or keys 401. This of course means that this cus- tomer has already a valid contract in force, and has retrieved validly the keys in the first place (i.e. a desired number of keys at the start of the contract). As situations may change, and the number of occupants may for instance change over time, there might emerge a sudden need for additional keys. After the made request (step 401), the customer receives an SMS/email comprising a web link for payment of the extra key(s), and he/she can pay for the extra key(s) in e.g. Paytrail web service or in any other related service 402. When the payment is approved, a handing-out process of the extra key(s) can be initiated 403. At this stage, the extra key(s) handing-over process proceeds to step 101 according to Figure 1; and continues along that se- quence of steps.

As a summary of Fig. 4, this process extension broadens the service offering to later purchases of the keys, whenever there is a proper reason for such a request. Alt- hough this process is shown as a separately chargeable buying process, this may also be a free-of-charge process included in a certain part of the present contracts, or included in all present contracts in force. Furthermore, the service provider may set the chargeability of the requests for the additional keys, naturally based on a number of required additional keys in a single request as well, in an embodiment.

Figure 5 illustrates a returning process of the key(s) 500 from the customer of the rental apartment service provider, its first part. The customer is usually the occupant of the rental apartment, but it is also possible that a relative or a friend could return the keys in favour for the occupant. The next process however concentrates on di- rect returning of the keys by the occupant of the rental apartment him/herself.

The following operational logic (i.e. the key return controlling logic) may activate when a rental agreement end date has been agreed and signed; or if the rental 3 agreement validity dates have been agreed already when the contract was initially

N founded and signed, the key return controlling logic may start e.g. a few days before 5 the actual end date of the rental period. = 30

I At first, the rental contract system sends an API interface message concerning a = discontinued rental contract 501. This message is thus sent to the key handling and s management system. Thereafter, the software product interprets data of an expired a contract, makes a request for key returning, and requests the customer to select a

S 35 returning location of the keys with a web link 502. The reguesting message to the customer may be an SMS comprising the appropriate web link, and guidance to proceed there with the appropriate location selection. The time, when this message is sent to the occupant of the rental apartment (simultaneously, the possessor of the keys), can be determined by the key handling and management system as a tune- able parameter. Also the manager of this system may set up this time constraint as an input parameter.

Next, the customer clicks the web link in the received SMS message, and opens a web page illustrating basic facts of the relevant rental contract. Furthermore, the web page illustrates a map interface of a nearby environment in view of the rental apartment's address. A dedicated area of the web page shows the clickable map and another dedicated area may show the basic contract information, including the end date (and possibly time) of the rental contract. Thereafter, the customer selects a return location for the keys from the map 503. Alternatively, the selection may be made from a list of possible returning locations, including their street addresses (e.g. in the form of "Nuottasaarentie 1, 90400 Oulu”) and other related information con- cerning e.g. their surrounding services (mentioned like “In a northside main lobby of the Prisma Limingantulli”, for instance). If required, also opening times of the key returning locations may be provided for assisting the selection.

When the occupant of the rental apartment with an ending contract has selected the most preferred location for returning the keys, the key handling and management system will reserve a locker from the selected automated locker system 504, or an- other respective key handling device with storage facilities and with processing ca- pabilities. The returning location and the automated locker system (or a similarly functioning other device) may naturally be the same returning location with similar “distribution boxes”, as what was the key retrieval location. As there may be several locations even within a single city, naturally the customer may select any location of all possible locations, and not necessarily the same location which was used for the 3 key retrieval by him/herself. After this step 504, on the other hand, the system ded-

N icates an exact place for the keys for the specific customer which is about to arrive 5 to the key returning location. = 30

I At first though, a PIN code for the key returning is supplied as well to the customer - 505 as part of the second SMS, and the message may also comprise returning in- s structions for the customer. The above street address, descriptive information of the a selected location and opening times may well be mentioned here in the second SMS

S 35 for assisting purposes.

Thereafter, the occupant of the rental apartment having an ending contract may travel to the instructed key returning location and arrive at the automated key handling device. The device is effectively the same which was used for the handing- over of the keys (regarding its working principle, and internal parts and functions); thus, it may comprise a group of lockable boxes or insertion/release “platforms” for the keys, and a user interface involving a graphical illustration means in a form of a screen, and inputting means in the form of a keyboard or in form of a touch screen.

At the device, the user may enter the PIN code which he/she has received earlier in the second SMS (concerning returning of the key). Another alternative option is that the customer identifies him/herself with an identification card showing a respective bar code to a bar code reader (or a QR code to a QR code reader, for instance) installed in connection with the automated key handling device.

The user interface (involving the screen) will then inform the reserved locker (num- ber/location) to the customer for the key returning. The information may be assisted by certain graphical features showing the exact location of the correct locker among the group of lockers. A door of the locker may open accordingly, pointing out the correct locker to the customer self-evidently. Thus, the customer is now able to place and return the keys to the guided locker 505 which has been guided via the user interface of the device and/or via the SMSs. After all the keys have been entered into the correct space of the key handling device and possibly the door of the return locker has been closed as well (or certain key being pressed marking the completion of the returning), the system will proceed to the checking of the returned keys; see step 601 in Figure 6.

Instead of the graphical instructions on the screen of the key handling device, or instead of providing any locker number on that screen either, it is possible that the key handling and management system informs the correct locker number already in

N the second SMS sent earlier in connection with the key return location selection.

N Thus, the screen is not an absolute necessity in the automated key handling device.

O n 30 Before proceeding to the checking process of the received keys, the system per-

I forms certain “intrinsic” steps, which update the status and availability information = for the returned keys in connection with the locking system and their own database. s In other words, for the key handling and management system's side, there are steps a 506-508; see Figure 5 in the left hand side. After the customer has actually returned

S 35 all the keys to the key handling device in the latter part of step 505, the respective key programming information is sent to the locking system over an interface 506.

The locking system and the respective service provider is a separate entity manag- ing the programming information and production/selling of the actual intelligent keys and also for the intelligent locks themselves. Many different locking systems are possible to be used in connection with the disclosed key handling and management system. At a next step, the respective keys related to this customer are thereafter blacklisted 507, meaning that these keys with their current programming do not an- ymore work in the previously designated lock(s); not even if the keys (or some of them) somehow end up with some malicious user.

Still, concerning the steps shown in Fig. 5 in the left hand side, the key(s) is/are marked as available for new use, over the interface 508. These keys become once again available “key slabs”, which can be reprogrammed later for any new customer requesting keys for his/her new rental apartment. Naturally, the programmed apart- ment can be any available apartment, and the programming information does not have to be the same as the previous one was.

Concerning a reminding process, Fig. 5 finally shows step 509, according to which the system will calculate the time, how much time has passed since the second SMS comprising the instructions and the PIN code was sent to the customer. If the elapsed time exceeds a certain threshold without the keys being returned, the sys- tem will send a reminder to the customer by a further SMS. This SMS will mention politely that key returning should happen according to a given time frame or as soon as possible (depending on the situation). The process otherwise goes back to step 505, when the customer finally arrives at the key handling device and returns the keys for real.

Next, we proceed to Figure 6, step 601, where the returned keys are checked, con- cerning the number of keys and the type of the keys.

N

N The identification/examination of the received keys may be performed via RFID- 5 based technology 602 or via photograph-based examination 603. In the RFID iden- n 30 tification 602, the key is electronically identified via an RFID chip of the intelligent

I key, applying also an RFID reader part of the automated locker system (= key han- = dling device). 3 a In the photograph-based examination 603, the number of keys is identified by

S 35 image processing tools, and this is compared to the number of handed-out keys to the customer. In practice this means using at least one camera for the returned keys, and possibly a processing logic analysing the taken photographs e.g. by applying image processing and analysis tools. Also the types of the received keys can be verified with a camera or with several cameras, with appropriate assisting image processing tools. The handed-out keys can be photographed as well during the handing-out process, or the number of the released keys (for retrieval) can be saved as a parameter in the database of the key handling system. One option is to use manual checking for the images, if required. This is the last resort in a situation, if there is some malfunctioning, misuse or other fraudulent actions on the key vending machines, or for some other reason the service provider needs to examine earlier actions happened on the key vending devices. In any case, if the number of keys does not match, or the RFID identification gives a wrong key ID, the system will proceed to a manual checking 604; otherwise, the system will proceed to step 605.

Next, we go deeper into the photograph-based examination 603, and the use of various different camera configurations.

There are at least two separate options for creating a checking process for the re- turned keys via the photograph-based examination, and a respective device with required physical elements. The first option is that the receiving locker or other space or hole or “platform” where the keys have been entered, comprises a con- veyor belt (endless one or some other type) or a respective key moving means so that any received key in any locker (or “insertion point”) can be physically transferred towards a checking point. Alternative, the key moving means may be a revolver- type i.e. a drum-like element which can be rotated for moving the keys locating in- side the open drum. Of course, the arrangement may also be a certain combination of conveyor belt structure(s) and of revolver-typed rotating drum(s). The checking point may comprise a single camera along the moving path for the keys. The camera is set to verify at least the type of the received keys (based on the visual appearance 3 of the key, and possibly applying Al tools for this), and the number of the received

N keys from this dedicated and identified customer. The pathway may also include a 5 reading point for these keys, which is set to read the programming information of n 30 each received key. The reading point may technically be based on the RFID tech-

I nology, for instance. In this option, the steps 602 and 603 will merge in a sense. = Thus, the exact correctness of each received key can be verified in connection with s the identified returner of the keys. In other words, if the system already has the a RFID-based identification information of the handed-out keys to this particular cus-

S 35 tomer, the system will inspect the returned keys from this customer via the RFID identification tools i.e. via the RFID reader in the vending device, and by reading the

RFID chip in the returned intelligent keys. The RFID identification in both the hand- ing-out step and the returning step provides the key ID data, which individualizes each handled key. If the key IDs match in the RFID sensing process between the handed-out keys (the respective data is picked from the database/memory) and the returned keys, then the key returning is deemed to be accepted; see steps 604 and 605. If there is a mismatch (or missing RFID information in the returned key) in at least some of the key IDs, the returning process proceeds to a manual checking 604. If the manual inspection by e.g. a maintenance worker ends up to an accepta- ble return of all the keys, then the process goes onwards from step 605.

Another option for returned key verification is to supply each locker or “insertion space/point” within the device with an own camera. Such a camera per each locker space may take a photograph from the total inner space of the locker, so that the exact placement of the keys within the locker (i.e. on the bottom plane of the locker) would not be a problem. In this way, a single photograph is able to achieve the data concerning the number of all returned keys, and also the type of the returned keys, if required (available from the outer appearance of the keys). A drawback of this solution is that the device requires a lot of separate cameras increasing the respec- tive cost of the key handling and management device. An advantage is that a pos- sibly complex conveyor belt system can be avoided in the device, when taking the photographs of the returned keys by such a multi-camera system.

An additional option in the key handling and management device is that within the device, near the keyboard and the screen, there may be an additional camera, which is set to take a photograph (or several photographs) from the customer in connection with his/her identification process. The taking of the photograph(s) may happen sim- ultaneously with the ID card reading, PIN code entering, or in a subsequent manner with these actions. Naturally, the photograph must be taken in a time instant, when 3 the customer locates in front of the user interface of the device and also faces the

N device (and not e.g. in a moment during walking towards the receiving locker, if the 5 system is larger in size). The taken photographs during the key handing-over situa- n 30 tion and the key returning situation may also be saved to a database of a memory.

I If desired, an Al algorithm may for instance even compare the two images from the = same customer to verify that the key retriever and the key returner is the same per- s son. At least a manual inspection possibility is there, if there ever emerges a need a for checking these actions later.

S 35

In case the extra key is e.g. purchased by another person (e.g. by a domestic part- ner, or by a parent) than the flat occupant (meaning the first key retriever) him/her- self, it is possible to deactivate such a person comparison logic using the photographs. It is also possible that a husband of a couple retrieves the original keys and a wife of the couple returns them, so in that situation, the person comparison logic between the photographs is not reasonable to be applied at all. There might be other respective situations as well. Generally, the taken photographs may be used as additional identification tools for the persons acting at the automated key handling devices if there emerges a reason to inspect this data later, for some rea- son.

After the checking of the returned keys has been completed as successful 605, the system may print an acknowledgement receipt for the customer 608 so that the whole key returning action is provenly deemed as successfully completed, and the key returning action is now finished successfully concerning the customer side.

Concerning the system side, a respective message is sent as an API interface mes- sage or as another type of message concluding the accepted key return action from the customer 606. After this step, the key return process is set to end successfully 607.

The above described process and the respective optional details show certain em- bodiments of the present invention.

One option for the automated key handling device may be embodied by building a cylindrical vending machine which comprises small spaces for keys in a roll-shaped (i.e. round) and horizontally placed arrangement. The cylinder may then be rolled around its central vertical axis, and each lockable space may be driven across/near a statically placed camera. In this way, the returned keys in some of the spaces 3 (meaning: in any space) can be photographed by a single camera by rotating the

N arrangement and taking photographs along the whole rotation round (i.e. 360 de- 5 grees). The camera may be set on top of the spaces pointing downwards towards n 30 the bottom of the spaces, or in a slightly tilted alignment angle. Flashlight is of course

I required, as this camera system with a single camera will locate intrinsically within = the key handling device. An advantage of such a device is that it is smaller than s regular automated package distribution lockers, it will thus reguire only a small a space, and it will also be cost-effective because only a single camera is reguired.

S 35 Many vending machine vendors may still be used, and also otherwise shaped and aligned structures could be possible in creating a small-volumed and cost-effective solution.

The disclosed concept involves a method, a device applying a processor and a memory, a system, a respective computer program(s) executing the method, and a respective computer program product. The disclosed key handling and manage- ment system may apply any locker system, vending machine system, distribution box system or other respective system which is capable to controllably and lockably release and store intelligent (i.e. programmable) keys. The actual intelligent key pro- viders are not restricted. This means that the present invention is free to use any desired locking system providers, and the data transfers do not depend on the used locking system. Hence, this provides an advantage that the operator of the key han- dling system may select freely the applied locking system. The presented system also uses telecommunication means and devices for sending and receiving SMSs, and a web page interface as well. A network connection is thus required, when the customer makes his/her selections on the retrieval/returning locations. Any telecom- munication device, such as a smartphone, may be used for this purpose. A separate

PC is not required for the customer.

On the service provider side, the controlling logic may be implemented in a PC or server locating locally within the service provider's premises or in the cloud. The key handling device also requires a processor within the device, which also controls all input and output associated with the functions of the device. The locations of the key handling devices may be freely selected among various indoor spaces, and in some situations, even outdoor locations could be possible. One possible location is a lobby of the service provider's office (e.g. a locking company), which could be entered even after regular business hours, if the lobby is separated from the rest of the office space. Another good option is to use public indoor spaces which are cur- rently used for automated package distribution lockers, such as indoor / lobby / hall-

N way spaces of large markets and shopping centres. Other public spaces such as

N libraries, lobbies of chemist's or public indoor walkways and tunnels are also possi- 5 ble options. The main criterion is the accessibility for larger groups of customers and n 30 for potential future customers. = = The present invention is not restricted merely to the embodiments disclosed above, s but the present invention may vary within the scope of the claims.

S

N

Claims

1. A key handling system for handing out intelligent keys (100) based on a con- tract made between a rental apartment provider and its customer, comprising a pro- cessor, a database and a piece of software, characterized in that the key handling system is configured to perform the steps of: - reading a new contract data from the rental apartment provider's database by the key handling system (101); - sending a message from the key handling system to a terminal device of a customer, reguesting the customer to select a retrieval location of the key or keys (102); - presenting to the customer, by the key handling system, all possible retrieval locations comprising compatible key parts (104); - letting the customer to select a retrieval location (105); - sending, from the key handling system, information of the selected retrieval location and a PIN code to the terminal device of the customer (106); and - when the key(s) have been picked by the customer using the correct PIN code from the selected retrieval location (107), registering the retrieval to the database of the key handling system comprising a customer name, date and time of the retrieval, and one or more photographs taken from a situation of the retrieval and/or data obtained by other identification tool identifying the handed-out key(s) (116).

2. The key handling system according to claim 1, characterized in that the key handling system is configured to initiate the following step, when the retrieval loca- tion has been selected by the customer, - finishing an intelligent key from a compatible semi-finished key product by pro- 3 gramming the correct key data into the intelligent key based on the information of N the read contract data. O n 30 3. The key handling system according to claim 1 or claim 2, characterized in that I the key handling system is configured to perform the steps of: - - if after the retrieval of the key(s), at least one key does not work for the rented s apartment according to the contract data (111), a - letting the customer inform a non-working key to the key handling system S 35 via email or phone call (112); - creating a new intelligent key for the customer based on the contract data (113); and

- handing out the new intelligent key to the customer according to the steps of claim 1, starting from the step of sending a message.

4. The key handling system according to claim 1, characterized in that the key handling system is configured to define a sub-group of retrieval locations where the customer has a retrieval location preference, and basing the retrieval location pref- erence either on shortest distances to the rental apartment address, or shortest dis- tance of the current address or current location of the customer, or both.

5. The key handling system according to claim 4, characterized in that if no com- patible semi-finished key products exist in any of the sub-group of retrieval locations where the customer has a retrieval location preference, the key handling system is configured to perform the steps of: - ordering new compatible semi-finished key products from the rental apartment provider, and when the semi-finished key products arrive at least to one retrieval location among the sub-group of retrieval locations, - starting the key retrieval process from the beginning according to the steps of claim 1.

6. The key handling system according to any of claims 1-5, characterized in that the key handling system comprises in each desired key retrieval and return location an automated package locker system or a distribution device, which further com- prises a camera capable to photograph handed-out and returned keys, and a user interface for PIN code insertion.

7. The key handling system according to claim 6, characterized in that the auto- 3 mated package locker system or the distribution device comprises a display provid- N ing further instructions to the customer, or alternatively, the key handling system is 5 configured to provide further instructions to the customer via a message to the ter- n 30 minal device of the customer after the successful retrieval. =

= 8. The key handling system according to any of claims 1-7, characterized in that s the key handling system is configured to perform the following step: a - letting the customer to select the retrieval location (104, 105) of the key(s) from S 35 a map interface, or from a list of addresses with possible additional assistive infor- mation relating to each address.

9. The key handling system according to any of claims 1-8, characterized in that after the successful retrieval of the key(s), the key handling system is configured to perform the following step: - allowing the customer to place and to program all received keys in a key pro- gramming device, or in a key programming lock, locating in the key retrieval and return location (109).

10. The key handling system according to any of claims 1-9, characterized in that the key handling system further comprises: - a time frame interpreter (302), configured to examine (304) key returning time frame rules, and to compare a key return date with a contract end date by taking mid-week holidays and weekends into account; and - a contract interpreter (303), configured to examine and interpret (305) the con- tract start and end dates, the rental apartment name or address or other identifica- tion information, and related occupant name and related identification information relating the occupant.

11. The key handling system according to any of claims 1-10, characterized in that the key handling system is configured to perform the following steps: - allowing the customer to make a request for purchasing at least one extra key (401); - sending an SMS or email comprising a web link for a payment of the extra key(s) to the customer (402); - allowing the customer to pay the payment of the extra key(s) via a web pay- ment service (402); and when the payment is approved, - initiating a handing-out process of the extra key(s) (403) according to the steps 3 of claim 1. & 5

12. The key handling system according to any of claims 1-11, characterized in n 30 that the other identification tool is an RFID reader performing RFID identification via I an RFID chip in a respective handed-out key. s

13. A key handling system for returning intelligent keys (500) based on a contract a made between a rental apartment provider and its customer, comprising a proces- S 35 sor, a database and a piece of software, characterized in that the key handling system is configured to perform the steps of:

- reading a key returning action information from the rental apartment provider's database by the key handling system (501), comprising the customer identification information and the number of initially retrieved keys by the customer; and - when a contract information for the customer is interpreted to be expired or expiring in incoming days by the key handling system (502), the key handling system is configured to perform a step of - creating a key returning reguest message to the customer (502), which key returning reguest message comprises a selection guery, allowing the customer to select, where the customer desires to return the key(s); and - when the customer has selected the return location (503), sending a PIN code to the customer by the key handling system, and more detailed information concerning the returning of the key(s) to the selected return location (505); - when the key(s) have been returned by the customer using the correct PIN code to the selected return location (505), assisted by instructions either on a screen of the return location or of a terminal device of the customer, examining the returned key(s) (601) by a camera and image processing software (603), and/or by other identification tool (602), comprised in the key handling system, and if the num- ber of returned keys matches the number of retrieved keys and/or an identification information of the returned keys matches the identification information of the re- trieved keys (604, 605), - determining the returning action of the key(s) to be successful (606-608).

14. The key handling system according to claim 13, characterized in that when the customer has selected the return location, the key handling system is configured to perform the following step: - reserving a locker from an automated package locker system or a distribution 3 device of the selected return location (504). O N 5

15. The key handling system according to claim 13, characterized in that if the n 30 key returning does not happen in a predetermined time frame, the key handling sys- I tem is configured to perform the step of: = - sending a reminder to the terminal device of the customer either via SMS or s email (509). S S 35

16. The key handling system according to claim 13, characterized in that after the key(s) have been successfully returned to the selected return location, the key han- dling system is configured to perform the steps of:

- sending key programming information to a locking system over an interface (506); - blacklisting the returned key(s) (507); and - marking, over the interface, the returned key(s) as available for new use (508).

17. The key handling system according to claim 13, characterized in that the other identification tool comprises RFID-based identification (602), and the return location comprises an RFID reader, wherein identifying of a returned key is made electroni- cally via an RFID chip of the key.

18. The key handling system according to claim 13 or 17, characterized in that return location with either the camera or the RFID reader is provided with a conveyor belt -based transfer system and/or a revolver-type drum from each cavity or locker of the return location for the keys, towards the vicinity of the camera or the RFID reader, the transfer system being powered by at least one motor.

19. The key handling system according to claim 14, characterized in that the transfer system within the automated package locker system or the distribution de- vice is configured to move the returned keys one by one from the locker or cavity to the vicinity of the camera or the RFID reader, so that the type and/or condition of each returned key is sensed, and the total number of correct and valid keys is sensed with respect to the returning customer.

20. The key handling system according to claim 14, characterized in that the key handling system is configured to perform the following step: - if the returned number of key(s) does not match with the number of the handed- 3 out key(s) or the RFID identification gives a wrong key identification information con- N cerning the returning customer, 5 - creating a service request from the key handling system to a mainte- n 30 nance worker of the system, for checking manually the returned keys of the selected I return location (604). a s 21. The key handling system according to claim 13 or 20, characterized in that a the key handling system is configured to perform the following step: S 35 - when the automated or manual inspection for the number, type or condition of the returned keys is completed as successful (605),

- sending a message from the key handling system to the rental apartment provider, that the keys relating to a specific contract have been successfully returned (606).

22. The key handling system according to any of claims 13-21, characterized in that the key handling system comprises an automated package locker system in a desired key retrieval and return location, which further comprises a camera viewing each locker, a user interface for PIN code insertion, and a display providing instruc- tions to the customer.

23. The key handling system according to any of claims 13-21, characterized in that the key handling system comprises a distribution device capable also to collect the returned keys, in a desired key retrieval and return location, where a camera is able to take a photograph of an insertion/returning cavity of the distribution device (603).

24. The key handling system according to any of claims 13-21, characterized in that the key handling system comprises a distribution device capable also to collect the returned keys, in a desired key retrieval and return location, where an RFID reader is able to sense items within an insertion/returning cavity of the distribution device (602).

25. The key handling system according to any of claims 13-24, characterized in that the key handling system is configured to perform the following step: - reading a programmed part of the returned intelligent key(s) in order to verify that the returned key(s) concern a correct address according to the specific contract 3 (602). 5

26. The key handling system according to any of claims 13-25, characterized in n 30 that the key handling system is configured to perform the following step: I - letting the customer to select the return location of the key(s) from a map in- = terface (503), or from a list of addresses with possible additional assistive infor- s mation relating to each address. LO N S 35

27. The key handling system according to any of claims 13-26, characterized in that the key handling system further comprises:

- a time frame interpreter (302), configured to examine (304) key returning time frame rules, and to compare a key return date with a contract end date by taking mid-week holidays and weekends into account; and - a contract interpreter (303), configured to examine and interpret (305) the con- tract start and end dates, the rental apartment name or address or other identifica-

tion information, and related occupant name and related identification information relating the occupant.

N

QA

O

N

S

N

I a a

NN

+

O

LO

N

O

N