Vehicle fleet allocation method for centralised vehicle sharing management system

Abstract

A vehicle fleet allocation method for a centralised vehicle sharing system with round-trip infrastructure. Vehicle allocation requests are received from client device(s) and categorised into round-trip requests and one-way requests. Each vehicle allocation request includes a start station, end station, start timeslot and end timeslot. A vehicle is allocated to each round-trip request and information related to the allocated vehicle is transmitted to the client device from which the round-trip request originated. Request matching is performed on a vehicle fleet level by matching the one-way requests to form a plurality of closed loops, allocating the same vehicle to the one-way requests of each closed loop, and transmitting information related to the allocated vehicle to the client devices from which the one-way requests of each closed loop originated. Preferably, for a closed loop, the end station and timeslot of a first one-way request corresponds to the start station and timeslot of a second one-way request, and the vehicle ends where it started. Prospective users may be financially incentivised to generate one-way requests that match with unmatched one-way requests.

Description

TECHNICAL FIELD

[0001] Hiis disclosure is related generally to vehicle sharing, and more specifically to vehicle fleet allocation methods and systems for a vehicle sharing management system. BACKGROUND

[0002] In a round-trip (or A-to-A) vehicle sharing system, the infrastructure is such that each vehicle is assigned or allocated to a specific station. The vehicles are rented out to users who have an obligation to return the vehicle to the same station from which the vehicle was rented. As a result, such vehicle sharing system is unable to accept or fulfil one-way requests (or A-to-B) due to constraints or limitations in the infrastructure, thereby leading to sub-optimal vehicle fleet utilisation.

[0003] An existing system proposes a decentralized location-based (station free) peer-to-peer car sharing system and method, wherein the system takes the travel information from a first user U1 such as the start time, start location and end location as input and calculates and matches a prospective user U2 who can take the car from user U1. However, such system is decentralized and based on one-to-one matching, and does not cany out globally optimal user matching, i.e., the system does not simultaneously generate optimal matching decisions at the fleet level. The system also does not have a mechanism to predict future demand and plan user matching by anticipating future demands. Furthermore, the system does not include any mechanism to incentivise the users to match and complete partially complete demands (e.g., A-to-B demand is available and B-to-A demand can be created by incentivizing the potential users). Therefore, such system still potentially suffers from sub-optimal vehicle fleet utilisation. SUMMARY

[0004] It is an object of the present disclosure to provide a vehicle fleet allocation method for execution by a centralised vehicle sharing management system to allocate vehicles to both round-trip (A-to-A) requests and one-way (A-to-B) requests to maximise vehicle usage on a fleet or global level whist using the same round-trip vehicle sharing infrastructure. In some embodiments, a plurality of user requests may be matched simultaneously and in an optimal manner to complete the “loop” (i.e., a tuple of trip A-to-B and B-to-A). In some embodiments, the matching of the user requests may take into account future user demands. In some embodiments, the method may seek to incentivise users to generate one-way requests that complement existing one-way requests to increase the probability of successfully closing the loops of user requests to optimise vehicle fleet usage.

[0005] The object of the present disclosure is solved by the subject-matter of the independent claims, wherein further embodiments are incorporated into the dependent claims.

[0006] It shall be noted that all embodiments of the present disclosure concerning a method might be carried out with the order of the steps as described, nevertheless this has not to be the only and essential order of the steps of the method. The herein presented methods can be carried out with another order of the disclosed steps without departing from the respective method embodiment, unless explicitly mentioned to the contrary hereinafter.

[0007] To solve the above technical problems, the present disclosure provides a vehicle fleet allocation method for a centralised vehicle sharing system with round-trip infrastructure, comprising: receiving, from one or more client devices, requests for vehicle allocation, each request comprising a start station, an end station, a start timeslot, and an end timeslot; categorising the received requests into a first category comprising round-trip requests wherein the start station is the same as the end station, and a second category comprising one-way requests wherein the start station is different from the end station; allocating a vehicle to each round-trip request of the first category and transmitting information related to the allocated vehicle to tire client device from which the round-trip request originated; and performing request matching on a vehicle fleet level by matching the one-way requests of the second category to form a plurality of closed loops and allocating the same vehicle to the one-way requests of each closed loop, wherein each closed loop comprises two or more one-way requests ordered to form a round-trip, and wherein the allocated vehicle is available or expected to become available at the start timeslot and the start station of a first-ordered one-way request of the closed loop and is available for the duration between the start timeslot of the first-ordered one-way request of the closed loop and the end timeslot of the last-ordered one-way request of the closed loop, and transmitting information related to the allocated vehicle to the client devices from which the one-way requests of each closed loop originated.

[0008] The vehicle fleet allocation method of the present disclosure is advantageous over known methods as the method allows the vehicle sharing system with round-trip infrastructure to also accept, process, fulfil, and be used for one-way requests, which would otherwise not be possible due to the infrastructure constraints. The method is also advantageous as it may increase the overall number of user requests that can be fulfilled by the vehicle fleet and may increase the overall usage of vehicles in the fleet. This is achieved by enabling vehicle fleet systems with round-trip infrastructure to accept both round-trip and one-way user requests, carrying out user request matching on a fleet or global level by a centralised system, and allowing two or more one-way requests to be matched to form closed loops.

[0009] A preferred method of the present disclosure is a vehicle fleet allocation method as described above, wherein the vehicle allocated to each round-trip request of the first category is a vehicle that is available or expected to become available at the start station at the start timeslot of the round-trip request, and is available for the duration between the start timeslot and end timeslot of the round-trip request.

[0010] The above-described aspect of the present disclosure has the advantage that taking into account vehicles that are expected to become available at the start station of a request increases the likelihood of successfully accepting user requests as the vehicle pool is not limited to vehicles that are available at the current timeslot, but also includes vehicles that are expected to be available at future timeslots, thereby potentially increasing the overall number of user requests that can be accepted by the vehicle fleet system and the overall usage of vehicles in the fleet.

[0011] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein request matching is performed using an integer linear programming-based optimisation model, and optionally meta heuristic-based methods.

[0012] The above-described aspect of the present disclosure lias the advantage that linear programming-based optimisation models are efficient and are able to solve large-scale problems efficiently, thereby allowing request matching on a fleet level to be carried out more efficiently. Meta heuristic-based methods may be used further improve the speed of user request matching to generate closed loops more quickly, thereby reducing the wait time of the users to get an allocated vehicle.

[0013] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein a first one-way request is matched with a second one-way request to form a closed loop using the following logic: the end station of the first one-way request corresponds to the start station of the second one-way request; the end timeslot of the first one-way request corresponds to or precedes the start timeslot of the second one-way request; and the end station of the second request corresponds to the start station of the first one-way request.

[0014] Hie above-described aspect of the present disclosure has the advantage that matching of requests with end timeslots that correspond to or precedes the start timeslot of the subsequent request increases the likelihood matching one-way requests by increasing the potential pool of requests that can be matched with each one-way request, thereby potentially increasing the overall number of user requests that can be successfully matched and accepted by the vehicle fleet system and the overall usage of vehicles in the fleet.

[0015] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein a first one-way request is matched with a second one-way request and a third one-way request to form a closed loop using the following logic: the end station of the first one-way request corresponds to die start station of the second one-way request; the end timeslot of the first one-way request corresponds to or precedes the start timeslot of the second one-way request; the end station of the second one-way request corresponds to the start station of the third one-way request; the end timeslot of the second one-way request corresponds to or precedes the start timeslot of the third one-way request; and the end station of the third one-way request corresponds to the start station of the first one-way request.

[0016] Hie above-described aspect of the present disclosure has the advantage that matching of requests with end timeslots that correspond to or precedes the start timeslot of the subsequent request increases the likelihood matching one-way requests by increasing the potential pool of requests that can be matched with each one-way request, thereby potentially increasing the overall number of user requests that can be successfully matched and accepted by the vehicle fleet system and the overall usage of vehicles in the fleet. Furthermore, matching more than two one-way requests also increases the likelihood of successfully matching one-way requests by increasing the potential pool of requests that can be matched with each one-way request, thereby potentially increasing the overall number of user requests that can be successfully matched and accepted by the vehicle fleet system and the overall usage of vehicles in the fleet.

[0017] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, further comprising: sending a notification to client devices of prospective users to request the generation of a one-way request that matches with any unmatched one-way request of the second category; receiving, from one or more client devices of prospective users, generated one-way-requests that match with any unmatched one-way request of the second category; and matching the generated one-way request with the unmatched one-way request of the second category, allocating the same vehicle to the matched one-way requests, and transmitting information related to the allocated vehicle to the client devices from which the matched one-way requests originated.

[0018] The above-described aspect of the present disclosure has the advantage that the vehicle allocation method actively encourages the generation of matching one-way requests, thereby potentially increasing the overall number of user requests and overall usage of the vehicle fleet.

[0019] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein the notification is sent to prospective users in the vicinity of the end station of the unmatched one-way request when there is no available vehicle at the start station of the unmatched one-way request, or when there is no vehicle expected to become available at the start station at the start timeslot of the unmatched one-way request, wherein the notification requests the generation of a oneway request with a start station corresponding to the end station of the unmatched one-way request, an end timeslot corresponding to or preceding the start timeslot of the unmatched request, and an end station corresponding to the start station of the unmatched one-way request.

[0020] The above-described aspect of the present disclosure has the advantage that tire number of prospective users that are notified are limited to those who have the highest likelihood of generating the requested matching one-way request. The computing power needed may be reduced as only prospective users located in the vicinity of the desired station are detected and the number of clients that the system needs to send notifications to is kept to a minimum.

[0021] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein in the notification is sent to the prospective users in the vicinity of the end station of the unmatched one-way request when there is an available vehicle at the start station of the unmatched one-way request, or when there is a vehicle expected to become available at the start station at the start time slot of the unmatched one-way request, wherein the notification requests the generation of a one-way-request with an end station corresponding to the start station of the unmatched one-way request, a start timeslot corresponding to or succeeding the end timeslot of the unmatched one-way request, and a start station corresponding to the end station of the unmatched oneway request.

[0022] The above-described aspect of the present disclosure has the advantage that the number of prospective users that are notified are limited to those who have the highest likelihood of generating the requested matching one-way request, thereby reducing the number of client devices that the system needs to send notifications to. The computing power needed may be reduced as only prospective users located in the vicinity of the desired station are detected and the number of clients that the system needs to send notifications to is kept to a minimum.

[0023] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein the notification includes an incentive to encourage the generation of a one-way request that matches with any unmatched one-way request of the second category.

[0024] The above-described aspect of the present disclosure has the advantage that the provision of an incentive may further encourage the generation of matching one-way requests, thereby potentially increasing the overall number of user requests and overall usage of the vehicle fleet.

[0025] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein the incentive is determined by calculating a minimum incentive required such that at least one user is likely to generate the one-way request that can be matched with the unmatched one-way request of the second category.

[0026] The above-described aspect of the present disclosure has the advantage that the calculated incentive provides a balance of keeping the cost incurred to the vehicle sharing management to a minimum while ensuring that a user is likely to generate a matching request. In other words, the probability of loop completion is increased at minimum cost to the vehicle sharing system. Furthermore, the calculated minimum incentive also ensures that a minimal number of users is likely to generate the requested one-way request, thereby-preventing the generation of additional one-way requests without a matching one-way request.

[0027] A preferred method of the present disclosure is a vehicle fleet allocation method as described above or as described above as preferred, wherein the incentive is determined using a user price threshold function.

[0028] The above-described aspect of the present disclosure has the advantage that the calculated incentive is customised to each prospective user, thereby enabling the calculation of a better minimum incentive to be provided while ensuring that a user is likely to generate a matching request. This may lead to increase in probability of user acceptance and optimised notification. Furthermore, the calculated minimum incentive also ensures that a minimal number of users is likely to generate the requested one-way request, thereby preventing the generation of additional one-way requests without a matching one-way request.

[0029] The above-described advantageous aspects of a vehicle fleet allocation method of tire disclosure also hold for all aspects of a below-described centralised vehicle sharing management system of the disclosure. All below-described advantageous aspects of a centralised vehicle sharing management system of the disclosure also hold for all aspects of an above-described vehicle fleet allocation method of the disclosure.

[0030] The present disclosure also relates to a centralised vehicle sharing management system comprising one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for carrying out a vehicle fleet allocation method according to any of the preceding claims.

[0031] The above-described advantageous aspects of a vehicle fleet allocation method or centralised vehicle sharing management system of the disclosure also hold for all aspects of a below-described computer program, a machine-readable storage medium, or a data carrier signal of the disclosure. All below-described advantageous aspects of a computer program, a machine-readable storage medium, or a data carrier signal of the disclosure also hold for all aspects of an above-described vehicle fleet allocation method or centralised vehicle sharing management system of the disclosure.

[0032] The present disclosure also relates to a computer program, a machine-readable storage medium, or a data carrier signal that comprises instructions, that upon execution on a processor and / or control unit, cause the processor and / or control unit to perform the steps of the vehicle fleet allocation method according to the present disclosure. The machine-readable medium may include any medium and / or mechanism for storing or transmitting information in a fonn readable by a machine (e.g., a computing device). The machine-readable medium may be any medium, such as for example, read-only memory (ROM); random access memory' (RAM); a universal serial bus (USB) stick; a compact disc (CD); a digital video disc (DVD); a data storage device; a hard disk; electrical, acoustical, optical, or other forms of propagated signals (e.g., digital signals, data carrier signal, carrier waves), or any other medium on which a program element as described above can be transmitted and / or stored. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] These and other features, aspects, and advantages will become better understood with regard to the following description, appended claims, and accompanying drawings where:

[0034] Fig. 1 is a schematic illustration of a centralised vehicle sharing management system, in accordance with embodiments of the present disclosure;

[0035] Fig. 2 is a schematic illustration of a vehicle fleet allocation method executed by a centralised vehicle sharing management system with round-trip infrastructure, in accordance with embodiments of the present disclosure; and

[0036] Fig. 3 is an illustration of a logistic regression-based model for the user price threshold function, in accordance with embodiments of the present disclosure.

[0037] In the drawings, like parts are denoted by like reference numerals.

[0038] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown. DETAILED DESCRIPTION

[0039] In the summary above, in this description, in the claims below, and in the accompanying drawings, reference is made to particular features (including method steps) of the disclosure. It is to be understood that the disclosure in this specification includes all possible combinations of such particular features. For example, where a particular feature is disclosed in the context of a particular aspect or embodiment of the disclosure, or a particular claim, that feature can also be used, to the extent possible, in com-bination with and / or in the context of other particular aspects and embodiments of the disclosure, and in the disclosure generally.

[0040] In the present document, the word “exemplary” is used herein to mean “serving as an example, instance, or illustration. Any embodiment or implementation of the present subject matter described herein as “exemplary” is not necessarily be construed as preferred or advantageous over other embodiments.

[0041] While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.

[0042] The present disclosure is directed to vehicle fleet allocation methods, vehicle sharing management systems, computer programs, machine-readable storage media, and data carrier signals which may be employed to allocate vehicles in a centralised vehicle management system with round-trip infrastructure. The centralised vehicle management system may receive round-trip and one-way requests from client devices for vehicles by way of wired or wireless connection, allocate vehicles on a fleet level to the requests received, and transmit information on the allocated vehicles to the client devices. The centralised vehicle management system may also match one-way requests to form closed loops. The centralised management system may also encourage the generation of matching one-way requests by notifying prospective users and optionally providing an incentive, thereby potentially increasing the number of user requests that are successfully accepted by the centralised vehicle sharing management system.

[0043] Fig. 1 is a schematic illustration of a centralised vehicle sharing management system 100, in accordance with embodiments of the present disclosure. In some embodiments, the centralised vehicle sharing management system may be used to manage a vehicle sharing system comprising a fleet of vehicles and a set of stations where the fleet of vehicles may be parked. A user may submit a request using a client device to the centralised vehicle sharing management system to rent one or more vehicles and the vehicle sharing management assigns a vehicle to such vehicle. In some embodiments, a request may be submitted by the user using a client device through an online application or interface or may be submitted in person to an operator of the centralised vehicle sharing management system who may input such request on the centralised vehicle sharing management system. In some embodiments, the vehicle sharing system comprises round-trip vehicle sharing infrastructure, such that each vehicle may be provided with a designated station (or parking lot), which is the location from which a user may pick up and return their assigned vehicle. In other words, with a round-trip vehicle sharing infrastructure, the user must pick up and return their assigned vehicle to the same station. In some embodiments, the centralised vehicle sharing management system may store information on vehicle and station availability in the form of a time grid, the time grid comprising columns which represent timeslots and rows which represent stations. In some embodiments, each grid square may indicate whether a vehicle is available at each station during each timeslot. In some embodiments, the duration of each timeslot may be large enough to accommodate travel-time uncertainties (e.g., 30 mins).

[0044] According to some embodiments, the centralised vehicle sharing management system 100 may comprise a demand recording module 104, an A-to-A demand scheduling module 108, a user matching module 112 and an A-to-B demand scheduling module 116. In some embodiments, the centralised vehicle sharing management system 100 may further comprise a user notification module 120. hi some embodiments, the demand recording module 104 may be configured to collect requests for vehicle allocation and categorise or segregate the received requests. Each request may comprise a start station, an end station, a start timeslot, and an end timeslot. In some embodiments, the requests may be categorised into two categories: a first category comprising round-trip (or A-to-A) requests; and a second category^ comprising one-way (or A-to-B) requests. In some embodiments, the round-trip requests may be recorded on an A-to-A demand log 124. In some embodiments, the oneway requests may be recorded on an A-to-B demand log 128.

[0045] According to some embodiments, the A-to-A demand scheduling module 108 may be configured to fulfil the round-trip requests directly by allocating 132 vehicles to users based on the A-to-A demand log 124. In some embodiments, the A-to-A demand scheduling module 108 may be further configured to update 136 the time grid of the centralised vehicle sharing management system.

[0046] According to some embodiments, the user matching module 112 may be configured to match requests on a vehicle fleet level by matching the one-way requests to form closed loops. In particular, the user matching module 112 forms closed-loops at global fleet level, finding the most optimal user-matches among multiple alternatives. In some embodiments, each closed loop may comprise two or more requests ordered to form a round-trip. In some embodiments, the two or more requests may be ordered such that the end station of each request corresponds to the start station of a subsequent request, and the start station of the first ordered request corresponds to the end station of the last-ordered request. In some embodiments, matched requests 140 are allocated 144 a vehicle by the A-to-B demand scheduling module 116. In some embodiments, the A-to-B demand scheduling module 116 may be further configured to reserve 148 the station where the transfer of the allocated vehicle between matched requests is predicted to happen for a specific time period (also termed the “transfer time period'’). In some embodiments, the A-to-B demand scheduling module 116 may be further configured to update 152 the time grid.

[0047] According to some embodiments, the centralised vehicle sharing management system may further comprise a user notification module 120 configured to receive any unmatched requests 156 and send a notification to prospective users to request the generation of a request that matches with any unmatched one-way request. In some embodiments, the notification may provide an incentive to encourage the generation of a request that matches any unmatched one-way request. In some embodiments, the optimal incentive may be determined using a user demand function learned using machine learning based method and may be determined as tire minimum incentive (e.g., discount in rental price) that must be given to ensure that there will be at least one user to complete the loop. In some embodiments, once a prospective user responds 160 and generates such a request, the request is added to A-to-B demand log 128, and die request is matched with the corresponding unmatched request by the user matching module 112.

[0048] Fig. 2 is a schematic illustration of a vehicle fleet allocation method 200 executed by a centralised vehicle sharing management system with round-trip infrastructure, in accordance with embodiments of the present disclosure. In some embodiments, the centralised vehicle sharing management system 100 may comprise one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs including instructions for carrying out the vehicle fleet allocation method 200. The one or more processors may be any data processing device on any architecture or system. For example, various architectures employing, for example, multiple integrated circuit (IC) chips and / or packages, and / or various computing devices and / or consumer electronic (CE) devices, such as multi-function devices, tablets, smart phones, etc., may implement the techniques and / or arrangements described herein. Method 200 may be stored as a computer program or executable instructions that, upon execution on a data processing device and / or control unit, cause the data processing device and / or control unit to perform the steps of method 200.

[0049] According to some embodiments, method 200 may comprise step 208 wherein requests for vehicle allocation are received from one or more client devices. In some embodiments, each request comprises a start station, an end station, a start timeslot, and an end timeslot. In some embodiments, step 208 may be carried out by demand recording module 104. In some embodiments, the start station may be the station from which the user intends to pick the vehicle up, and the end station may be the station at which the user intends to return the vehicle. In some embodiments, the start timeslot may be the timeslot in which the user intends to pick the vehicle up, and the end timeslot may be the timeslot in which the user intends to return the vehicle. The timeslot may be of any duration or interval. In some embodiments, each request may further comprise a user identification number. In some embodiments, the request or demand may be recorded in the format: <user u, start station lu, end station 1„. start timeslot tu, end timeslot t„>. In some embodiments, for a user u 6 U each choice or component (i.e., start location, end location, start timeslot, end timeslot) may be stored in the form of a one-hot vector. In some embodiments, each request may comprise four vectors: a start station vector, an end station vector, a start timeslot vector, and an end timeslot vector. For example, the start station 1„ may be stored as the following vector: 0000010000 wherein each column represents a station 7, and wherein the number “1” indicates the information selected by the specific user in the request. In the above example, the start station indicated by the user would correspond to the 6th station.

[0050] According to some embodiments, method 200 may comprise step 216 wherein the received requests are categorised into a first category comprising round-trip requests and a second category comprising one-way requests. In some embodiments, step 216 may be carried out by demand recording module 104. In particular, the received requests may be categorised into round-trip requests and one-way requests based on the start station and end station indicated in the request. Round-trip requests are requests where the user wants to rent and return the vehicle at the same station, therefore the start station is the same as the end station. One-way requests are requests where the user u e U wants a vehicle to go from a first station to a second station (or A-to-B), and therefore the start station is different from the end station. In some embodiments, the round-trip requests may be recorded on an A-to-A demand log 124 and the one-way requests may be recorded on an A-to-B demand log 128.

[0051] According to some embodiments, method 200 may comprise step 224 wherein a vehicle is allocated to each round-trip request. In some embodiments, step 224 may be carried out by A-to-A demand scheduling module 108. In some embodiments, allocating the vehicle may comprise sending vehicle information to the client device from which the roundtrip requests originated. The vehicle information may comprise a digital key and information about rental duration. In some embodiments, the vehicle allocated may be an available vehicle, i.e., an idle standing vehicle that is located at its corresponding station. In some embodiments, the vehicle allocated may be a vehicle that is or expected to become available at the start station at the start timeslot of the round-trip request and is available for the duration between the start timeslot and end timeslot of the request. The expected availability of the vehicle may be determined if the vehicle available status is updated via a system that tracks vehicles that are en-route and will become available at a station in the near future. In some embodiments, step 224 may comprise updating a time grid that denotes the availability of vehicles in stations. An example of a time grid is as follows: station 0 0 1 1 1 1 1 0 0 0 timeslot which indicates that the vehicle will be available in station i at the timeslots indicated as “w”. In some embodiments, the availability of the vehicles may be expressed as VQ^. L, t^. T) G {0,1} as a variable that stores if vehicle is available at start location 1^. L and start timeslot t^. T where L represents a list of all stations and T represents a list of all timeslots.

[0052] According to some embodiments, method 200 may comprise step 232 wherein request matching is performed on a vehicle fleet level by matching the one-way requests to form a plurality of closed loops and allocating the same vehicle to the requests of each closed loop, wherein each closed loop comprises two or more requests ordered to form a round-trip, and wherein the allocated vehicle is available or expected to become available at the start timeslot and the start station of a first-ordered request of the closed loop and is available for the duration between the start time slot of the first-ordered request of the closed loop and the end timeslot of the last-ordered request of the closed loop. In some embodiments, step 232 may be carried out by A-to-B demand scheduling module 112. In some embodiments, a first request may be matched with a second request to form a closed loop in step 232 if: the end station of the first request corresponds to the start station of the second request; the end timeslot of the first request corresponds to or precedes the start timeslot of the second request; and the end station of the second request corresponds to the start station of the first request. For example, to enable the matching of a first one-way request with an end timeslot that precedes the start timeslot of a second one-way request, step 232 may further comprise setting the timeslots adjacent to start timeslots and end timeslots in the timeslot vector as “1”, such that the trip can start or end m any of the specified timeslots. For example, a start timeslot vector of the received request of [0,0,0,0,1,0,0,0,0] may be set to [0.0.0,1,1,1.0.0.01, which implies that a user may start the trip one timeslot before or one timeslot after the initially received start timeslot.

[0053] In some embodiments, request matching may be performed using a user matching model. In some embodiments, the user matching model may be an integer linear programming-based optimisation model. For example, the linear programming-based optimization model may be a linear program that matches users fy and U2 that satisfy the following logic: (1^ • 1S2) x (tS, • O x (1^ • Ify) x VQ^. L, tSr T) wherein users Utand U2 can be matched if: end station of user fy is same as the start station of user U2, end timeslot of user Ui is same as the start timeslot of user U2, end station of user U2 is same as the start station of user [fy, and vehicle is available at start station of Ut 1^.

[0054] In some embodiments, the user matching model may further utilize meta heuristicbased methods, such as that disclosed in “Combining (Integer) Linear Programming Techniques and Metaheuristics for Combinatorial Optimization” by Raidl and Puchinger.

[0055] In some embodiments, the user matching model may be able to match users with a range of start and end timeslots. In some embodiments, the user matching model may be expressed as follows to match 2 users: “ax 2 2 x“>“= U |6U u2eU s. t Zx„ „ + x„ „ <1 Vu, e U Ujll2 U2U1 — u2eU xU1u2 (¾ ■ 1U x (¾ • ts2) X (1^ ■ 1S2) X 7(¾. L<.T) VU1 e U, U2 e U LU2 xU1u2x 0^(^)-7-1-(¾) -t)< VQ^UtT) vuieu,u2eu XU1U2 e {0,1} v U1 e U, u2 e U

[0056] In other words, users uv u2 6 U specifies information: < user u, start station lu, end station 1„, start timeslot t„, end timeslot t[j >and user matching model uses decision variable xU1U2 G {0,1} which decides if user ut G U is matched with u2 G U. For example, user ui may travel from A-to-B, and user U2 may travel from B-to-A. Function Imin(v) returns a one-hot vector with 1 at minimum index value of chain of Is; and function Imax(v) returns a one-hot vector with 1 at the maximum index value of chain of Is (e.g., v = [ 0 ,0 ,0 ,1, 1, 1,0, 0, 0]). Therefore lmin(v) = [ 0 ,0 ,0.1. 0, 0, 0, 0, 0] and Imax(v) = [ 0 ,0 ,0 ,0, 0, 1, 0, 0, 0],

[0057] In some embodiments, the user matching model may be expressed as follows to match 3 users: xU1u2 <(1^ • 1&2) X (¾ • ts2) X (¾ • IgJ x 7(¾. L, t^ . T) V U1 e U, u2 G U XU1U2U3 — Qui ■ lu2) x • tu2) X (1J3 • 1|2) x (t^ • tu2) X (1®3 • ly2) xvO^.LXjJvuteu.^eUusGU imln(tg2) xU1u2x(imin(tg2)-T-im^^       £ vO^.L.t^vu^u.^eu t=lmax(t^) imin(ts3) xu1U2u3x(imin(t£3)-T-ima^^ £ v(l^.L,tT) vU1eu,u2eu,u3eu ¢=1^(^,) XU1U2> XU1U2U3 e {0,1} v U1 e u, U2 e u, U3 6 u

[0058] In some embodiments, the decision variable of the user matching model xUiUz(for 2 users) and xU1u2u3 (for 3 users) may be 1 or 0. xU1U2 = 1 implies that user ui and U2 can be matched which means that user ui will start the trip, hand the vehicle over to the user U2 and user U2 will bring the vehicle back to the station from which user ui started their trip. xuiu2u3 = 1 implies that user ui, U2 and 113 can be matched such that user ul will start the trip hand the vehicle over to the user 112. user U2 will take the vehicle and hand the vehicle over to the user U3, and user U3 will bring the vehicle back to the station from which user ui started their trip. xUiU2 = 0 implies that the user ui and U2 cannot be matched, and xU1u2u3 = 0 implies that user ui, U2, and U3 cannot be matched.

[0059] In some embodiments, the user matching model may have the following constraints: 1) any user ui can either be matched to other user U2 if xU1u2 = 1, or two other users 112, and U3 if xU1u2u3 = 1 ■ and only one out °f XU1 u2 or xU1u2u3 can be equal to one due to the first constraint that ensures that each user is only matched in one loop. 2) user ui can be matched to user U2 if and only if, a) start station of user U2 is the same as the end station of ui, b) start timeslot of U2 is the same or follows the end timeslot of ui, and c) end station of 112 is same as the start station of in. 3) user in can be matched to 112 and 113 if and only if a) start station of user 112 is the same as the end station of ui, b) start timeslot of U2 is same as or follows the end timeslot of ui, c) start station of user U3 is the same as the end station of U2, d) start timeslot of U3 is the same as the end timeslot of U2, e) end station of U3 is same as the start station of ui. The logic from matching two users may be extended in a chain as the number of users increase. 4) user ui and U2 can only be matched if the total trip time which is given by the trip end time of user U2- trip start time of user ui must be not more than the time for which the vehicle is available at tire start station of the ui. 5) user ui, U2 and U3 can only be matched if the total trip time which is given by the trip end time of user U3— trip start time of user ui must be not more than the time for which the car is available at the start station of the ui.

[0060] In some embodiments, the user matching model may utilize an objective function that seeks to maximise the number of requests that are matched. In some embodiments, the user matching model may give more weight to 2-user or 3-user terms. For example, if more weight is to be given to 3-user terms to encourage the generation of closed loops comprising 3 requests, the objective function may be expressed as Sci-XU1u2 + c2-XU1u2u3 if cz >ci, e.g., ci =1 and C2 = 2 then more preference shall be given to longer chains.

[0061] According to some embodiments, when allocating a vehicle to the users of tire matched requests, the vehicle information may be transmitted to the client device from which the matched requests originated. The vehicle information may include a digital key, information about rental duration, and information on the transfer station (which may be the start station or end station depending on the position of the request in the closed loop), and the transfer time period (i.e., the time period within which the user must pick up and drop off the vehicle). In some embodiments, the time grid may be updated.

[0062] According to some embodiments, method 200 may comprise step 240 wherein a notification is sent to client devices of prospective users to request the generation of a request that matches with any unmatched one-way request. In some embodiments, step 240 may be carried out by user notification module 120. In some embodiments, the prospective users may be any user in the vicinity of the end station of the unmatched request.

[0063] In a first scenario, if there is no available vehicle at the start station of the unmatched request, or if there is no vehicle expected to become available at the start station at the start timeslot of the unmatched request, the notification is sent to prospective users in the vicinity of the end station of the unmatched request to request the generation of a request with a start station corresponding to the end station of the unmatched request, an end timeslot corresponding to or preceding the start timeslot of the unmatched request, and an end station corresponding to the start station of the unmatched request.

[0064] In a second scenario, if there is an available vehicle at the start station of the unmatched request, or if there is a vehicle expected to become available at the start station at the start timeslot of the unmatched request, the notification is sent to prospective users m the vicinity of the end station of the unmatched request to request the generation of a request with an end station corresponding to the start station of the unmatched request, a start timeslot corresponding to or succeeding the end timeslot of the unmatched request, and a start station corresponding to the end station of the unmatched request.

[0065] In some embodiments, the notification to prospective users may include information of the request to be generated, including the start station, end station, start timeslot, and end timeslot. In some embodiments, the notification to prospective users may include an incentive to encourage the generation of a request that matches with any unmatched oneway requests. Any incentive may be provided, such as discounts, preferential treatment in future vehicle requests, free upgrades, and / or vouchers. In some embodiments, the incentive may be determined by minimum incentive required such that at least one user is likely to generate the request that can be matched with the unmatched one-way request.

[0066] For example, where the incentive is a reduced rental price to be offered to the prospective user, die incentive may be determined using a user price threshold function. In some embodiments, incentivization of the user may be determined as follows: x x _ Cu>+Pu2 - cu+y y xu1V1 uxeU u2eU UiGUViCV * (pU1 - cU1 + PV1 - cV1) + XV1U1 * (pVi - CV1 + pUi - CU1) v±eV UiEU s. t xV1U1 <1 V vt e V UXEU x,„„, <(IS, ■ U x (ts, ■ IL) X O’, ■ IS,) X vQ;,.L,t^.T) vu, e u. u2 e u x,„„ <IS, (p „) • (IS, • ¢,) x (tS, ■) x (IS, ■ IS,) x v(8,.U«5,.T) v u, e B,v, e V XV1U1 <1“ (pV1) * (V^) x x (VluJ x vOlAt^.T) vut e U,V1 e V imln(tg2) xU1u2 x (lmin(tg2) • T - I™5^) • T) <£ VO^.ULT) VU1 e U,u2 e U t=imax(t^). imin( t?x) xU1V1 X ) • T — Imax(t^) • t) <V(l^.L,tT) VU1 e u,V1 e V t=lmax(tsj Imln(tSi) xV1U1 x (lmin( ) • T -1max(t^) • t) <£ VQ^. L, t T) v U1 e U, vt e V xU1u2 6 {0,1} v U1 e u, U2 e u Xu^ g {0>l} Viij gU, Vj eV XV1U1 G {0,1} VU1eU, V1EV wherein: uA : goes from A-to-B u2 : goes from B-to-A Vp may go from B-to-A if given sufficient incentive. I v (x) = 1 if x >a V1 V z 1^ (x) = 0 if x <a pu ■ rental price for user uA - Fixed pvl: rental price for user 14 - Needs to be decided. cul: cost of moving the vehicle as per u[s requirement, e.g., fuel cost etc.

[0067] 1“) (x) is defined as the user price threshold function. In some embodiments, the user price threshold function may be unique to each user e V this means that the threshold value a will reach at different price value pV1for each user. In some embodiments, the user price threshold function may be learned using historic data of user’s elasticity to price. In some embodiments, the mapping may be learned using logistic regression-based models.

[0068] Fig. 3 is an illustration of a logistic regression-based model for the user price threshold function, in accordance with embodiments of the present disclosure. In some embodiments, the user price threshold function (pV1) G {0,1} ® a(®pV1 ' Pv^ maP be an approximate map of price to the probability that user G V will be willing to move the vehicle from station B to A starting at timeslot k. This function o(9Pv^ ■ pV1)is called the user demand function which may be learned using machine learning based techniques such as logistic regression. The covariate information and the control variables may be separated and assuming the control variable is the rental price pV1, the function may be: a(>nV1 . pv, + = t + In some embodiments, a logistic regression model may be trained on historical data of user acceptance as a function of price, with the learned logistic function approximately represented by a user threshold function. A user threshold function is included to determine if a particular constraint corresponding to a user exists (i.e., if user threshold function is 1) or not.

[0069] According to some embodiments, method 200 may comprise step 248 wherein the generated requests that match with any unmatched one-way request are received from the client devices, and step 256 wherein the generated request is matched with the unmatched one-way request, allocating the same vehicle to the matched requests, and transmitting vehicle information of the allocated vehicle to the client devices from which the matched requests originated. In some embodiments, step 248 and step 256 may be carried out by demand recording module 104 and / or A-to-B demand scheduling module 112.

[0070] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present disclosure are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1. A vehicle fleet allocation method for a centralised vehicle sharing system with roundtrip infrastructure, comprising:receiving, from one or more client devices, requests for vehicle allocation, each request comprising a start station, an end station, a start timeslot, and an end timeslot;categorising the received requests into a first category comprising round-trip requests wherein the start station is the same as the end station, and a second category comprising one-way requests wherein the start station is different from the end station;allocating a vehicle to each round-trip request of the first category and transmitting information related to the allocated vehicle to the client device from which the round-trip request originated; andperforming request matching on a vehicle fleet level by matching the one-way requests of the second category to form a plurality of closed loops and allocating the same vehicle to the one-way requests of each closed loop, wherein each closed loop comprises two or more one-way requests ordered to form a round-trip, and wherein the allocated vehicle is available or expected to become available at the start timeslot and the start station of a first-ordered one-way request of the closed loop and is available for the duration between the start timeslot of the first-ordered one-way request of the closed loop and the end timeslot of the last-ordered one-way request of the closed loop, and transmitting information related to the allocated vehicle to the client devices from which the one-way requests of each closed loop originated.

2. The vehicle fleet allocation method of any of the preceding claims, wherein the vehicle allocated to each round-trip request of the first category is a vehicle that is available or expected to become available at the start station at the start time slot of the round-trip request, and is available for the duration between the start timeslot and end timeslot of the round-trip request.

3. The vehicle fleet allocation method of any of the preceding claims, wherein request matching is performed using an integer linear programming-based optimisation model, and optionally meta heuristic-based methods.

4. The vehicle fleet allocation method of any of the preceding claims, wherein a first one-way request is matched with a second one-way request to form a closed loop using the following logic:the end station of the first one-way request corresponds to the start station of the second one-way request;the end timeslot of the first one-way request corresponds to or precedes the start timeslot of the second one-way request; andthe end station of the second request corresponds to the start station of the first oneway request.

5. The vehicle fleet allocation method of any of the preceding claims, wherein a first one-way request is matched with a second one-way request and a third one-way request to form a closed loop using the following logic:the end station of the first one-way request corresponds to the start station of the second one-way request;the end timeslot of the first one-way request corresponds to or precedes the start timeslot of the second one-way request;the end station of the second one-way request corresponds to the start station of the third one-way request;the end timeslot of the second one-w ay request corresponds to or precedes the start timeslot of the third one-way request; andthe end station of the third one-way request corresponds to the start station of the first one-way request.

6. The vehicle fleet allocation method of any of the preceding claims, further comprising:sending a notification to client devices of prospective users to request the generation of a one-way request that matches with any unmatched one-way request of the second category;receiving, from one or more client devices of prospective users, generated one-way requests that match with any unmatched one-way request of the second category; andmatching the generated one-way request with the unmatched one-way request of the second category, allocating the same vehicle to the matched one-way requests, andtransmitting information related to the allocated vehicle to the client devices from which the matched one-way requests originated.7 The veilic]e f|cct allocation method of claim 6, wherein the notification is sent to prospective users in the vicinity of the end station of the unmatched one-way request when there is no available vehicle at the start station of the unmatched one-way request, or when there is no vehicle expected to become available at the start station at the start timeslot of the unmatched one-way request, wherein the notification requests the generation of a oneway request with a start station corresponding to the end station of the unmatched one-way request, an end timeslot corresponding to or preceding the start timeslot of the unmatched request, and an end station corresponding to the start station of the unmatched one-way request.

8. The vehicle fleet allocation method of claim 6, wherein in the notification is sent to the prospective users in the vicinity of the end station of the unmatched one-way request when there is an available vehicle at the start station of the unmatched one-way request, or when there is a vehicle expected to become available at the start station at the start timeslot of the unmatched one-way request, wherein the notification requests the generation of a oneway request with an end station corresponding to the start station of the unmatched one-way request, a start timeslot corresponding to or succeeding the end timeslot of the unmatched one-way request, and a start station corresponding to the end station of the unmatched oneway request.

9. The vehicle fleet allocation method of any of claims 6 to 8, wherein the notification includes an incentive to encourage the generation of a one-way request that matches with any unmatched one-way request of the second category.

10. The vehicle fleet allocation method of claim 9, wherein the incentive is determined by calculating a minimum incentive required such that at least one user is likely to generate the one-way request that can be matched with the unmatched one-way request of the second category.

11. The vehicle fleet allocation method of any of claims 9 or 10, wherein the incentive is determined using a user price threshold function.

12. A centralised vehicle sharing management system comprising one or more processors and memory' storing one or more programs for execution by the one or more processors, the one or more programs including instructions for carrying out the vehicle fleet allocation method according to any of the preceding claims.5 13. A computer program, a machine-readable storage medium, or a data carrier signalthat comprises instructions, that upon execution on a processor and / or control unit, cause the processor and / or control unit to perform the steps of the vehicle fleet allocation method according to any of claims 1 to 11.

Images