Patent Description:
<CIT> discloses a vehicle rental terminal with an associated key safe.

For some car dealers, there are a great number of vehicles for sale, e.g. in what is sometimes referred to as car supermarkets. Due to a restricted amount of parking space, some vehicles are often blocked in by other vehicles.

When a potential customer wants to test drive a vehicle, this can result in several vehicles needing to be moved to allow access to the vehicle for a test drive.

The blocking vehicles cause problems for test drives and can even make some potential customers go elsewhere if it takes too long to start the test drive.

One object is to improve how vehicles are selected and provided access for.

According to a first aspect, it is provided a method for providing access to a vehicle according to appended claim <NUM>.

The determining the number of blocking vehicles may comprise, for each one of the candidate vehicles: determining blocking parking bays that, if occupied, would block the respective candidate vehicle; and determining how many of the blocking parking bays are occupied with a vehicle.

The key release signal also requests to release keys for the blocking vehicles that block access for the selected vehicle.

According to a second aspect, it is provided a vehicle determination device, for providing access to a vehicle, according to appended claim <NUM>.

The instructions to determine the number of blocking vehicles may comprise instructions that, when executed by the processor, cause the vehicle determination device, to, for each one of the candidate vehicles: determine blocking parking bays that, if occupied, would block the respective candidate vehicle; and determine how many of the blocking parking bays are occupied with a vehicle.

According to a third aspect, it is provided a computer program for providing access to a vehicle according to claim <NUM>.

According to a fourth aspect, it is provided a computer program product comprising a computer program according to the third aspect and a computer readable means comprising non-transitory memory in which the computer program is stored.

Embodiments presented herein allow intelligent selection of a vehicle that matches a set of vehicle parameters, e.g. as specified by a potential vehicle buyer. The selection is based on determining the number of vehicles blocking each candidate vehicle, where each candidate vehicle is one that matches the set of vehicle parameters. A database stores, for each candidate vehicle, the parking bay in which it is stored. For each parking bay, it is also stored what parking bays are blocking parking bays. Based on occupancy of blocking parking bays, a vehicle determination device can thus derive, for each candidate vehicle, how many currently parked other vehicles there are that block access. The candidate vehicle with fewest blocking vehicles is selected and a key release signal is transmitted to a key cabinet to release a physical key for the selected vehicle.

<FIG> is a schematic diagram illustrating an environment in which embodiments presented herein can be applied. The context is a car dealership, offering a number of vehicles for sale. A limited parking space <NUM> is available, whereby the vehicles need to be parked (at least sometimes) such a manner that some vehicles are blocked by other vehicles, whereby blocking vehicle need to be moved for access to an inner vehicle for test drive and/or examination by a potential customer. In this example there are twelve parking bays 4aa-4dc, but the embodiments presented herein can be applied for any number of parking bays, as long as there is risk for blocking vehicles at least part of the time. For the reference numerals for the parking bays in the example of <FIG>, the format is 4ij, where i designates the row (in the range a to d) and j designates the column (in the range a to c).

When a potential customer wants to test drive a vehicle, a set of parameters defining the desired vehicle are specified. The set of parameters can include one or more parameters. One parameter can be the manufacturer, e.g. Volkswagen, Ford or Volvo. One parameter can be the model (which is a subset of the manufacturer), e.g. VW Golf, Ford Ka or Volvo XC40. One or more parameters can relate to equipment, e.g. leather upholstery, engine model, sunroof, paint colour, etc. The desired vehicle does not always need to be specified with the same granularity. For instance, one potential customer might have the desired vehicle defined broadly, e.g. VW Golf, and another potential customer might have the desired vehicle defined more narrowly e.g. VW Golf <NUM> Diesel with leather interior and a sunroof.

A vehicle determination device <NUM> is provided for determining a vehicle based on the set of parameters indicating the desired vehicle. The vehicle determination device <NUM> has access to a first database <NUM> and a second database <NUM>. The first database <NUM> contains details about vehicles, allowing candidate vehicles to be determined based on the set of parameters of the desired vehicle, where each candidate vehicle matches the set of parameters. The second database <NUM> contains data of parking bay layout, indicating for each parking bay what parking bays are blocking (if occupied). Moreover, the second database <NUM> contains information about occupancy of parking bays, including an identity of each vehicle and an identity of the parking bay in which the vehicle is parked. Each one of the databases <NUM>, <NUM> can be implemented in the form of a single or multiple tables in one or more relational databases, files on a file system or any other suitable digital representation (e.g. object database, graph database, etc.) of data enabling the functionality of embodiments presented herein. The first and second databases <NUM>, <NUM> can be located locally with the vehicle determination device <NUM> or on a remote server (also known as the cloud). Alternatively the first and second databases can be comprised in a data memory of the vehicle determination device <NUM>. The first and second databases <NUM>, <NUM> can be implemented in separate physical devices or provided as separate data structures within a single device.

The vehicle determination device <NUM> is also connected to an automated key cabinet <NUM> that contains the physical keys of the vehicles that are parked in the parking space <NUM>. The automated key cabinet <NUM> can controllably release any of the keys, to allow access to any of the parked vehicles using the released physical key. Optionally, the vehicle determination device <NUM> and the automated key cabinet <NUM> are combined in a single device.

In this example, there are eight vehicles parked in the parking bays. A potential customer expresses the set of parameters of her desired vehicle, e.g. a Volvo XC40 plug-in-hybrid. The set of parameters can be provided to the vehicle determination device <NUM> using an application executing on a user device (e.g. smart phone) of the potential customer or sales representative.

The vehicle determination device <NUM> queries the first database <NUM> to obtain a set of candidate vehicles 2a-c, matching the set of parameters. The candidate vehicles 2a-c are indicated with dashed filling in <FIG>.

For each candidate vehicle, the vehicle determination device <NUM> queries the second database <NUM> to find out the parking bays that are blocking if occupied, and the number of parked vehicles in those parking bays. In this example, a first candidate vehicle 2a has two blocking vehicles <NUM>, a second candidate vehicle 2b has two blocking vehicles 2c, <NUM> and a third candidate vehicle 2c has one blocking vehicle.

Hence in this situation, the third candidate vehicle 2c has the fewest number of blocking vehicles (of the candidate vehicles 2a-c). The vehicle determination device <NUM> thereby selects the third candidate vehicle 2c and transmits a signal to the automated key cabinet <NUM> to release the physical key for the third candidate vehicle 2c. Additionally, the vehicle determination device <NUM> transmits a signal to the automated key cabinet <NUM> to release the physical key for the blocking vehicle <NUM>. The sales representative conveniently takes the keys, moves the blocking vehicle <NUM> and takes out the selected (third candidate) vehicle 2c, allowing the potential customer to examine the vehicle and take it for a test drive.

<FIG> is a flow chart illustrating embodiments of methods for determining a vehicle. The method is performed by a vehicle determination device, such as the vehicle determination device shown in <FIG>.

In a receive request step <NUM>, the vehicle determination device <NUM> receiving <NUM> a request signal, indicating a set of parameters of a desired vehicle. The set of parameters can be entered by the potential customer or told by the potential customer to a sales representative that enters the set of parameters. The set of parameters can be entered in an application running on a user device (such as a smartphone, tablet computer, laptop or stationary computer) or the set of parameters can be entered using a user interface of the vehicle determination device <NUM>.

In a determine candidate vehicles step <NUM>, the vehicle determination device <NUM> determines, from a first database <NUM>, a plurality of candidate vehicles 2a-c matching the parameters of the desired vehicle.

In a determine blocking vehicles step <NUM>, the vehicle determination device <NUM> determines, from a second database <NUM>, for each one of the candidate vehicles 2a-c, a number of blocking vehicles <NUM> blocking access to the respective candidate vehicle.

This step optionally comprises, for each one of the candidate vehicles (2a-c), performing two sub-steps.

In a first sub-step, the vehicle determination device <NUM> determines blocking parking bays that, if occupied, would block the respective candidate vehicle. In a second sub-step, the vehicle determination device <NUM> determines how many of the blocking parking bays are occupied with a parked vehicle.

In a select vehicle step <NUM>, the vehicle determination device <NUM> selects the candidate vehicle with the fewest number of blocking vehicles. Optionally, if there are multiple candidate vehicles with the same lowest number of blocking vehicles, a list of these candidate vehicles with all specifications can be provided as output, allowing the potential customer to select the candidate vehicle that is preferred.

Optionally, the selection is based also a locality of where the keys are stored for the blocking vehicles. This is here illustrated in a couple of examples:.

In a first example, there is a first candidate vehicle with three blocking vehicles and the three keys are all stored in the same automated key cabinet that is near the user device. There is also a second candidate vehicle with only two blocking vehicles for which keys are stored in two different automated key cabinets that are far apart from each other. In this case, the first vehicle can be selected even though it has more blocking vehicles.

In a second example, one of the keys for a blocking vehicle is held by someone and may not thus be immediately retrievable (i.e. someone parked a vehicle blocking others but did not return the key to the automated key cabinet yet). In this case, it can be beneficial to select a vehicle that is not blocked by that blocking vehicle, even if this results in a larger number of blocking vehicle for the selected vehicle.

In one embodiment, the user is already holding one or more vehicle keys needed for the blocking vehicles. This fact can be considered by vehicle determination device <NUM> in the selection of vehicle.

In a transmit key release signal step <NUM>, the vehicle determination device <NUM> transmits a signal to release a physical key to the selected vehicle. The key release signal also requests to release keys for the blocking vehicles that block access for the selected vehicle. In this case, the key release signal can be transmitted in a single signal or over multiple sub-signals for this purpose.

By selecting car based on model and number of blocking cars, the test drive can be arranged with minimum inconvenience and wait time.

<FIG> is a schematic diagram illustrating components of the vehicle determination device <NUM> of <FIG> according to one embodiment. A processor <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), graphics processing unit (GPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions <NUM> stored in a memory <NUM>, which can thus be a computer program product. The processor <NUM> could alternatively be implemented using an application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc. The processor <NUM> can be configured to execute the method described with reference to <FIG> above.

The memory <NUM> also comprises non-transitory persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid-state memory or even remotely mounted memory.

Optionally, the data memory comprises the first database <NUM>, containing vehicle details and the second database <NUM> containing data of parking bay layout and occupancy of parking bays. Each one of the databases <NUM>, <NUM> can be in the form of a one or more tables in one or more relational databases, files on a file system or any other suitable digital representation of data enabling the functionality of embodiments presented herein.

The vehicle determination device <NUM> further comprises an I/O interface <NUM> for communicating with external and/or internal entities, such as the automated key cabinet <NUM>. Optionally, the I/O interface <NUM> also includes a user interface.

Other components of the vehicle determination device <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> shows one example of a computer program product <NUM> comprising computer readable means. On this computer readable means, a computer program <NUM> can be stored, which computer program can cause a processor to execute a method according to embodiments described herein. In this example, the computer program product is in the form of a removable solid-state memory, e.g. a Universal Serial Bus (USB) drive. As explained above, the computer program product could also be embodied in a memory of a device, such as the computer program product <NUM> of <FIG>. While the computer program <NUM> is here schematically shown as a section of the removable solid-state memory, the computer program can be stored in any way which is suitable for the computer program product, such as another type of removable solid-state memory, or an optical disc, such as a CD (compact disc), a DVD (digital versatile disc) or a Blu-Ray disc.

Claim 1:
A method for providing access to a vehicle, the method being performed by a vehicle determination device (<NUM>), the method comprising:
receiving (<NUM>) a request signal, indicating a set of parameters of a desired vehicle;
determining (<NUM>), from a first database (<NUM>), a plurality of candidate vehicles (2a-c) matching the set of parameters of the desired vehicle;
determining (<NUM>), from a second database (<NUM>), for each one of the candidate vehicles (2a-c), a number of blocking vehicles (<NUM>) blocking access to the respective candidate vehicle;
selecting (<NUM>) the candidate vehicle with the fewest number of blocking vehicles; and
transmitting (<NUM>) a key release signal to an automated key cabinet to release a physical key to the selected vehicle and to release physical keys to any blocking vehicles that block access for the selected vehicle, to thereby provide access to the selected vehicle.