GRAPH BASED OPTIMAL MATCHING FOR PEER-TO-PEER VEHICLE SHARING

A peer-to-peer (P2P) vehicle sharing method is disclosed. The method may include obtaining a list of rent requests and associated requested rental durations, and a list of available vehicles and associated vehicle availability time periods. The list of rent requests may represent first nodes and the list of available vehicles may represent second nodes of a vehicle-renter graph. The method may further include obtaining a list of edges that connects at least one first node and at least one second node. The method may further include receiving a predefined trigger event and updating the list of edges in response to receiving the predefined trigger event. Furthermore, the method may include transmitting a vehicle reservation notification to at least one renter and at least one vehicle owner based on the updated list of edges.

TECHNICAL FIELD

The present disclosure relates to a peer-to-peer vehicle sharing system and more particularly to dynamic graph-based optimal matching of a renter and a rent vehicle in a peer-to-peer vehicle sharing system.

BACKGROUND

With the advent of internet and web-based services, rental platforms are growing rapidly across the world. Rental platforms allow sharing or renting of a wide variety of assets, such as vehicles. For instance, peer-to-peer (P2P) vehicle sharing platforms allow users to rent or lease vehicles on a temporary basis. P2P vehicle sharing platforms are beneficial for vehicle owners as they facilitate in generation of additional income, for example, when the vehicle owners are not using their vehicles.

In a conventional vehicle sharing platform, vehicle owners offer their vehicles for rent, and a renter may choose a rent vehicle from the available vehicles that suits the renter's needs. Typically, the renter invests substantial effort in identifying the rent vehicle on conventional vehicle sharing platforms. In addition, identifying the rent vehicle is a time-consuming process, which may be inconvenient for the renter.

The renter may face additional inconvenience if rent vehicles are not available on the vehicle sharing platforms. Specifically, the vehicle sharing platforms need to ensure that abundant rent vehicles are available on the platforms, so that the renter may have options to rent a vehicle. Managing and maintaining vehicle supply on the vehicle sharing platform may be a challenge for the platform operator. While there exists ways to incentivize vehicle owners to offer their vehicles for rent, managing supply is still a challenge for the platform operator.

Thus, there exists a need in the industry for a vehicle sharing/renting system that optimizes vehicle supply and minimizes the effort required for identifying rent vehicles.

DETAILED DESCRIPTION

Overview

The present disclosure describes a P2P vehicle sharing platform that may allow vehicle owners to share their vehicles with a plurality of renters. A renter, who may want to rent a vehicle, may raise a rent request on the P2P vehicle sharing platform. In some aspects, the rent request may include a rental duration for which the renter may require the vehicle, a travel location (e.g., a location/city/airport name from where the renter may want to rent the vehicle), and/or the like. Responsive to receiving the rent request, the P2P vehicle sharing platform may identify an available vehicle or a set of available vehicles that may be available during the rental duration. In a scenario where the P2P vehicle sharing platform identifies more than one available vehicle, the P2P vehicle sharing platform may determine a rental duration overlap extent with availability periods of available vehicles. In some aspects, the P2P vehicle sharing platform may select an available vehicle whose availability period has a maximum overlap extent. The P2P vehicle sharing platform may reserve the selected vehicle for the renter and may transmit a reservation notification to the renter and an owner of selected vehicle.

In some aspects, the P2P vehicle sharing platform may use graph-based approach to select the available vehicle (e.g., a best match vehicle) from the set of available vehicles. In particular, the P2P vehicle sharing platform may generate a vehicle-renter graph of all rent requests and the set of available vehicles (or all the available vehicles). In an exemplary aspect, each rent request/available vehicle may be a node in the vehicle-renter graph. The P2P vehicle sharing platform may further generate edges to connect nodes associated with one or more available vehicles with nodes associated with one or more rent requests. In some aspects, the edges may connect nodes of rent requests with nodes of available vehicles, such that the rent requests may have associated rental durations within the available vehicles' availability time period. The P2P vehicle sharing platform may further select an edge for each rent request (or for each available vehicle.) based on one or more predefined criteria. The P2P vehicle sharing platform may select the edge to determine and reserve a best match available/rent vehicle for each rent request. The predefined criterion/criteria may include vehicle utilization maximization criteria, vehicle rent revenue maximization criteria, and/or the like.

In further aspects, the P2P vehicle sharing platform may dynamically re-evaluate the available vehicle reservation (or re-evaluate the edge selection) based on a receipt of a predefined trigger event. In some aspects, the predefined trigger event may include a new rent request, a new vehicle entry to the set of available vehicles, renter's rent request withdrawal, and/or available vehicle withdrawal by the owner. In some aspects, the P2P vehicle sharing platform may select a new renter for a rented vehicle if the new renter is a better match for the rented vehicle over the existing renter. For example, if the new rental duration overlap extent with the rented vehicle availability period is greater than the existing rental duration overlap extent with the rented vehicle availability period, the P2P vehicle sharing platform may replace the existing renter with the new renter for the rented vehicle. In some aspects, the P2P vehicle sharing platform may replace the existing renter with the next renter when the P2P vehicle sharing platform finds another available vehicle for the existing renter. The P2P vehicle sharing platform may further update the vehicle-renter graph (e.g., update the nodes, edges, and node states included in the vehicle-renter graph), when the P2P vehicle sharing platform replaces the existing renter with the new renter. In some aspects, the P2P vehicle sharing platform may select a new renter/vehicle over the existing renter/vehicle when the new renter/vehicle is a better match (e.g. have higher vehicle or revenue utilization) over the existing renter/vehicle.

The present disclosure provides a P2P vehicle sharing platform that saves renter's time and effort in selecting the best rent vehicle. In addition, the P2P vehicle sharing platform provides an advantage of optimizing vehicle supply as the rent vehicle selection is based on vehicle utilization maximization criteria. Furthermore, the graph-based approach of rent vehicle selection facilitates in increasing computational efficiency in matching a rent vehicle with a rent request, especially while performing re-evaluation of rent vehicle reservation.

These and other advantages of the present disclosure are provided in detail herein.

Illustrative Embodiments

FIG.1depicts an example environment100in which techniques and structures for providing the systems and methods disclosed herein may be implemented. The environment100may include a plurality of vehicles102a,102b,102c(collectively referred to as a plurality of vehicles102) that may be parked at a public place104. In one or more aspects, the public place104may be a parking lot in an airport (as shown inFIG.1), a train station, a mall, a public parking space, a private parking space and/or the like. In some aspects, the plurality of vehicles102may be registered with a peer-to-peer (P2P) vehicle sharing platform106. The P2P vehicle sharing platform106may be hosted on a server and may allow vehicle owners to share their vehicles with others. For instance, an owner108of a vehicle102amay be going out of town for a plurality of days. During these days, as the owner108may not use the vehicle102a, the owner108may offer the vehicle102afor rent through the P2P vehicle sharing platform106to a renter (for example, a renter110). In some aspects, the renter110may be travelling to the town, and may need a vehicle (e.g., the vehicle102a) to rent on a temporary basis.

The owner108may register (if not already registered) the vehicle102aon the P2P vehicle sharing platform106, to offer the vehicle102afor rent. The owner108may register via an owner device (e.g., a mobile phone, a laptop, a desktop computer, a vehicle infotainment system, and/or the like). The owner108may provide a plurality of details, such as owner name, social security number, vehicle details, year of vehicle purchase, owner's bank account details, and/or the like, while registering the vehicle102a. The vehicle details may include, but are not limited to, vehicle type, brand, model number, color, insurance documents, and the like. In some aspects, the owner108may upload vehicle pictures and the insurance documents to the P2P vehicle sharing platform106, while registering the vehicle102a.

The owner108may further provide details of a duration of time during which the vehicle102amay be available for rent, when the owner108registers the vehicle102awith the P2P vehicle sharing platform106. For instance, the owner108may provide vehicle availability period details before (e.g., 15 days in advance) the vehicle102abecoming available.

In a manner similar to the owner108registering the vehicle102a, the renter110may register on the P2P vehicle sharing platform106. The renter110may register via a renter device (e.g., a mobile phone, a laptop, a desktop computer, a vehicle infotainment system, and/or the like). The renter110may provide renter details (e.g., renter profile), details of vehicle(s) owned by the renter110, renter preferences, etc., while registering on the P2P vehicle sharing platform106. The renter profile may include renter name, address, bank account details, social security number, and/or the like. The renter vehicle details may include a type of a vehicle associated with (e.g., owned by) the renter, a vehicle brand, model number, color, renter's license, and/or the like.

The renter110may submit/send a request to the P2P vehicle sharing platform106for renting a vehicle, from the plurality of vehicles102, when the renter110registers on the P2P vehicle sharing platform106. The request may include, for example, a rental duration (e.g., a time period for which the renter110may require the rent vehicle), a travel location (e.g., a location/city/airport name from where the renter110may want to rent the vehicle), and/or the like.

Responsive to receiving the rent request, the P2P vehicle sharing platform106may determine a set of available vehicles, from the plurality of vehicles102, and corresponding availability periods. In some aspects, the set of available vehicles may be the vehicles that may be available for rent during the entire rental duration provided by the renter110.

In further aspects, the P2P vehicle sharing platform106may select and reserve a vehicle (e.g., the vehicle102a), from the set of available vehicles, for the renter110based on the rent request and a plurality of vehicle details corresponding to the set of available vehicles. The vehicle selection process details may be understood in conjunction withFIGS.2-6.

In some aspects, the P2P vehicle sharing platform106may transmit notifications to the renter110and the owner108(on the respective owner and renter devices) when the P2P vehicle sharing platform106reserves the vehicle102afor the renter110. In one or more aspects, the notification to the owner108may include a request from the renter110, sent via the P2P vehicle sharing platform106, for vehicle authorization. The P2P vehicle sharing platform106may transmit the notification to the owner108before and close to a rental duration start date (e.g., 2 days before the rental duration). Responsive to the notification receipt, the owner108may approve the request within a predetermined rental duration (e.g., within 24 hours of notification receipt). In one or more aspect, an agreement for renting the vehicle102ato the renter110may become binding when the owner108approves the request.

In some aspects, the notification to the renter110may include vehicle identification number (VIN) associated with the vehicle102a. The P2P vehicle sharing platform106may transmit the renter notification before the rental duration start date (e.g., 3 to 5 days before the rental duration) to initiate the request for vehicle authorization, as mentioned above. In one or more aspects, the P2P vehicle sharing platform106may transmit the notification to the renter device, so that the renter110may view the notification on a renter device display (e.g., display of renter's mobile phone).

On the day of vehicle availability, the owner108may park the vehicle102aat the public place104(such as a parking lot of an airport). Further, the owner108may send a notification, via the owner device, to the P2P vehicle sharing platform106confirming that the vehicle102ais ready (e.g., available for renting). Furthermore, the owner108may provide details of vehicle parking location (such as floor, zone, and/or the like) to the P2P vehicle sharing platform106. In one or more aspects, the owner108may leave a parking ticket inside the vehicle102aand may lock the vehicle102abefore leaving the vehicle102ain the public place104.

On the day of renting, the P2P vehicle sharing platform106may navigate the renter110to the vehicle parking location (e.g., by using Global Positioning System on the renter device), when the renter110arrives at the public place104. In addition, the P2P vehicle sharing platform106may unlock/open vehicle door when the renter110reaches near the vehicle102a. In some aspects, the P2P vehicle sharing platform106may determine that the renter110has reached the vehicle location by using GPS and/or based on a renter notification indicating that the renter110is near the vehicle102a.

In some aspects, the vehicle102amay communicatively couple with the P2P vehicle sharing platform106via a network (not shown inFIG.1). The P2P vehicle sharing platform106may send a vehicle door unlock command to the vehicle102a, when the renter110reaches near the vehicle102a.

Responsive to vehicle door opening, the renter110may set up the renter device (e.g., renter mobile phone) as a key. The renter110may then use the vehicle102afor the rental duration and may park the vehicle102aafter the rental duration expiry. While leaving the parking, the renter110may leave a parking ticket inside the vehicle102aand may lock the vehicle102a. The renter110may then send, via the renter device, a notification to the P2P vehicle sharing platform106, informing about the vehicle parking location. Responsive to receiving the renter notification, the P2P vehicle sharing platform106may notify the owner108that the vehicle102ais ready to reclaim. Additionally, in some aspects, the P2P vehicle sharing platform106may enable a rent payment from the renter110to the owner108(e.g., via the respective renter and owner bank accounts).

FIG.2illustrates an example Peer-to-Peer (P2P) vehicle sharing system200(hereinafter referred to as a P2P system200), in accordance with the present disclosure.

The P2P system200may include a plurality of vehicles202a,202b,202c(collectively referred to as a plurality of vehicles202) associated with owners204a,204b,204c(collectively referred to as vehicle owners204), respectively. The plurality of vehicles202may include, for example, a car, a truck, a sport utility vehicle, a crossover vehicle, a van, a minivan, a taxi, a bus, etc., and may be configured and/or programmed to include various types of automotive drive systems.

The vehicle owners204may register their vehicles, via respective vehicle owner devices206a,206b,206c, (collectively referred to as vehicle owner devices206), on a server208to share the plurality of vehicles202with other registered owners/users. In particular, the vehicle owner devices206and the server208may communicatively couple with each other via a network210. The vehicle owner devices206may include, for example, mobile phones, smart phones, mobile nodes, smart watches, scanners, personal digital assistants (PDAs), tablet computers, laptop computers, or the like with communication capabilities.

In some aspects, the server208may host a P2P vehicle sharing application that may facilitate the vehicle owners204to share their vehicles with other owners/users registered on the P2P vehicle sharing application. The server208, as described herein, can be implemented in hardware, software (e.g., firmware), or a combination thereof. In one or more aspects, the P2P vehicle sharing application may be accessible on the vehicle owner devices206, via the network210.

The P2P system200may further include a renter212(or renters) who may send a request, via a renter device214, to the server208(e.g., to the P2P vehicle sharing application) to rent a vehicle. The renter device214may communicatively couple with the server208via the network210. Renter device214examples are similar to the vehicle owner devices206examples, described above. In some aspects, the renter212may be a vehicle owner as well. For example, the renter212may be the owner204a,204b, or204c.

The network210may be, for example, a communication infrastructure in which the connected devices discussed in various embodiments of this disclosure may communicate. The network210may be and/or include the Internet, a private network, public network or other configuration that operates using any one or more known communication protocols such as, for example, transmission control protocol/Internet protocol (TCP/IP), Bluetooth®, BLE®, Wi-Fi based on the Institute of Electrical and Electronics Engineers (IEEE) standard 802.11, UWB, and cellular technologies such as Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), High Speed Packet Access (HSPDA), Long-Term Evolution (LTE), Global System for Mobile Communications (GSM), and Fifth Generation (5G), to name a few examples.

The server208may be part of a cloud-based computing infrastructure and may be associated with and/or include a Telematics Service Delivery Network (SDN) that provides digital data services to the vehicles202a,202b,202cand other vehicles (not shown inFIG.2), that may be part of a vehicle fleet.

In accordance with some aspects, the server208may include a plurality of components including, but not limited to, a transceiver216, a processor218, and a memory220, which may communicatively couple with each other. The memory220may store programs in code and/or store data for performing various P2P vehicle sharing application operations, in accordance with the present disclosure. Specifically, the processor218may be configured and/or programmed to execute computer-executable instructions stored in the memory220for performing various P2P vehicle sharing application functions in accordance with the disclosure. Consequently, the memory220may be used for storing code and/or data code and/or data for performing operations in accordance with the present disclosure.

In one or more aspects, the processor218may be disposed in communication with one or more memory devices (e.g., the memory220and/or one or more external databases (not shown inFIG.2)). The memory220can include any one or a combination of volatile memory elements (e.g., dynamic random-access memory (DRAM), synchronous dynamic random-access memory (SDRAM), etc.) and can include any one or more nonvolatile memory elements (e.g., erasable programmable read-only memory (EPROM), flash memory, electronically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), etc.).

The memory220may be one example of a non-transitory computer-readable medium and may be used to store programs in code and/or to store data for performing various operations in accordance with the disclosure. The instructions in the memory220can include one or more separate programs, each of which can include an ordered listing of computer-executable instructions for implementing logical functions.

The memory220may include one or more databases such as a first database222and a second database224, which may communicatively couple with each other. In some aspects, the second database224may include a subset of information stored in the first database222. The details of the first database222and the second database224are described later in the description below.

In some aspects, the transceiver216may be configured to receive a plurality of inputs associated with the vehicle owners204and the renter212, via the vehicle owner devices206and the renter device214respectively. In some aspects, the vehicle owners204and the renter212may send the plurality of inputs to the transceiver216during the registration process on the server208. For instance, the plurality of inputs associated with the vehicle owners204may include the plurality of vehicles202details, owner details (name, address, bank account details, etc.), and/or the like. The vehicle details may include, for example, vehicle type, brand, model number, color, vehicle insurance documents, and/or the like. In some aspects, the vehicle owners204may transmit (e.g., by uploading) vehicle pictures and the insurance documents to the transceiver216.

Similarly, the plurality of inputs associated with the renter212may include renter details (name, address, bank account details, etc.), and details of vehicle(s) associated/owned by the renter110. The renter vehicle details may include vehicle type, brand, model number, color, and renter's license. In some aspects, the renter212may upload pictures of his license and other documents to the server208(e.g., via the transceiver216).

In some aspects, the transceiver216may be configured to transmit the received owner details and the renter details, from the vehicle owners204and the renter212respectively, to the first database222as a user information226, for storage purpose. The information stored in the first database222may be stored as records in a request table400shown inFIG.4. The request table400is described in detail later in the description below.

The transceiver216may be further configured to receive vehicle availability information for the plurality of vehicles202from the respective vehicle owners204, via the vehicle owner devices206. The vehicle availability information may include information on the days on which the respective plurality of vehicles202may be available for rent/sharing. For example, the owner204amay send the vehicle202aavailability information to the transceiver216, informing that the vehicle202amay be available for rent from December 1 to December 10.

Responsive to receiving the vehicle availability information, the transceiver216may send the information to the first database222as a vehicle information228, for storage purpose. The vehicle availability information may be stored as records in the request table400. In further aspects, the memory220may be configured to store information associated with the plurality of vehicles202in the vehicle information228. In particular, the vehicle information228may include the vehicle type, brand, model number, color, and/or the like, associated with the plurality of vehicles202. In additional aspects, the transceiver216may transmit an available vehicle offer date (e.g., a date on which a vehicle is added on the server208for renting purpose) to the first database222as the vehicle information228, for storage purposes.

The transceiver216may be further configured to receive a plurality of requests from the renters212, via the renter devices214, to rent vehicles. The request may include a rental duration travel location. For instance, the renter212may send a request to the transceiver216to rent a vehicle in Georgia. The renter212may indicate that the renter212requires the vehicle for fixed dates (for example, for one week from December 1 to December 7).

Responsive to receiving the rent request(s), the transceiver216may send the rent request details to the first database222as a request information230, for storage purpose. The rent request details may be stored as records in the request table400.

The processor218may be configured to receive/fetch the plurality of inputs, the rent requests details (e.g., a list of rent requests and associated rental durations), and the vehicle availability information (e.g., a list of available vehicles and associated vehicle availability time periods), etc., from the memory220, when the transceiver216receives such information. The processor may additionally obtain vehicle information for the list of available vehicles, including available vehicle identification number (VIN), vehicle type, vehicle model number and/or the like, from the memory220.

In operation, the processor218may obtain the list of available vehicles (from the plurality of vehicles202) from the memory220when the renter212sends the rent request to the transceiver216. The processor218may compare the rental duration (included in the rent request) with the plurality of vehicles202availability periods (specifically, availability period associated with each vehicle), and may determine the list of available vehicles that are available during the rental duration. For example, if the rental duration is December 1 to December 7, and the vehicles202aand202bare available for rent during the entire rental duration, however the vehicle202cis not, then the processor218may determine the vehicles202aand202bas the list of available vehicles for the renter212.

In a scenario when no vehicle is available during the rental duration, the processor218may notify (via the transceiver216) the renter212accordingly. In further aspects, when only one vehicle (e.g., the vehicle202a) is available, then the processor218may reserve the available vehicle for the renter212and may transmit a notification to the renter212(e.g., on the renter device214) and the corresponding owner (e.g., on the vehicle owner device206a) that the vehicle202ais reserved. The processor218may transmit the notification via the transceiver216.

In some aspects, when more than one vehicle (e.g., the vehicles202aand202b) are available during the rental duration, the processor218may be configured to determine and select (e.g., reserve) a best rent vehicle for the renter212. In such scenarios, the vehicles (such as the vehicles202aand202b) may be potential matches for the renter212associated with the rent request, and the processor218may be configured to select a best/final match (i.e., a best rent vehicle from the vehicles202aand202b) for the renter212. In some aspects, the processor218may select the best rent vehicle based on a rental duration overlap extent with the vehicle availability period (to maximize vehicle utilization), vehicle rent offer date, vehicle rent revenue, and the plurality of inputs (such as the available vehicle types and the vehicle type owned by the renter212). For example, the processor218may select the vehicle that has the corresponding vehicle type (e.g., vehicle model) same as a vehicle type owned by the renter212.

Responsive to determining the best rent vehicle, the processor218may send a notification to the renter212and the corresponding vehicle owner. This may allow the renter212to receive the reservation notification for only one vehicle (e.g., the best match vehicle), and the renter212does not have to spend time and effort in selecting/reserving the rent vehicle. The process of best rent vehicle determination and selection may be understood as follows. In some aspects, the processor218may use a graph-based approach to determine the best rent vehicle. The graph-based approach may be understood in conjunction withFIG.3.

FIG.3depicts an example vehicle-renter graph300(hereinafter referred to as a graph300), in accordance with the present disclosure. The graph300may have a first plurality of nodes302a,302b,302c(collectively referred to as nodes302) and a second plurality of nodes304a,304b,304c(collectively referred to as nodes304). The first plurality of nodes302may be associated with the available vehicles (or vehicle owner(s)204) and the second plurality of nodes304may be associated with the rent requests (or renter(s)212).

The processor218may be configured to store information associated with the graph300(including the first plurality of nodes302and the second plurality of nodes304) in the first database222. The processor218may store the graph information as records in the request table400. In some aspects, the processor218may assign unique identifiers (or node identifiers) to each node (the first plurality of nodes302and the second plurality of nodes304) in the graph300. The processor218may further store node information corresponding to the node identifiers in the request table400.

In further aspects, the processor218may be configured to generate one or more edges (such as edges1-7) between at least one first node and at least one second node. In particular, the one or more edges may connect one or more available vehicles to one or more rent requests. More particularly, the processor218may generate edges between nodes (e.g., the second node304a) of rent requests and nodes (e.g., the first node302a) of available vehicles, such that the requested rental durations associated with the rent requests are subset of the vehicle availability time periods associated with the available vehicles.

In some aspects, the processor218may be configured to determine whether an available vehicle matches at least one rent request criteria (e.g., requested rental durations being subset of the available vehicle's availability time period) of one or more rent requests. Based on a determination that the available vehicle matches the rent request criteria, the processor218may generate one or more edges to indicate that the available vehicle matches the rent request criteria for the respective rent requests. Stated another way, the processor218may generate edges to determine “potential matches” between the one or more available vehicles and the one or more rent requests, based on the requested rental durations and the vehicle availability time periods. Hence, a node associated with the available vehicle may include more than one edges (each edge connected to the node associated with the rent request matching the rent request criteria). A person ordinarily skilled in the art may appreciate that since the graph300may be partially connected and not fully connected (e.g., no node associated with available vehicle is connected with a node associated with another available vehicle; similarly, no node associated with a rent request is connected with a node associated with another rent request), the graph-based approach of matching vehicles with rent requests is scalable to a larger number of rent requests.

In an exemplary aspect, the vehicle associated with the node302amay be available between June 5-June 12, the vehicle associated with the node302bmay be available between June 2-June 15, and the vehicle associated with the node302cmay be available between June 6-June 13. Further, the renters212may have submitted the rent request (represented as the node304a) for a rental duration between June 7-June 10, the rent request associated with node304bfor a rental duration between June 8-June 13, and the rent request associated with node304cfor a rental duration between June 5-June 11. In this case, the processor218may generate edges1and2to connect the node302awith the nodes304aand304c, as the requested rental durations associated with the requests associated with nodes304aand304cis within (or is subset of) the vehicle availability time period associated with the vehicle or node302a. Stated another way, the vehicle associated with the node302apotentially matches with the rent requests associated with the nodes304aand304c, as the vehicle associated with the node302ais available on all the days mentioned in the rent requests associated with the nodes304aand304c. The vehicle associated with the node302adoes not potentially match with the rent request associated with the node304b, as the vehicle associated with the node302ais not available on June 13th. Thus, the processor218may not generate an edge between the node302aand the node304b.

Similarly, the processor218may generate edges3,4, and5to connect the node302bwith the rent requests/nodes304a,304b, and304cas the vehicle associated with the node302ais available on all the days mentioned in the rent requests associated with the nodes304a,304b, and304c. Further, the processor218may generate edges6and7to connect the node302cwith the rent requests/nodes304aand304band not with304c, as the vehicle associated with the node302cis not available on June 5th. In some aspects, there may be a node with no edge. For example, if there is a rent request for a rental duration between December 30-January 2 and there is no available vehicle during this period (as all the vehicles may be rented), there may be no edge for the rent request. Further, a person ordinarily skilled in the art may appreciate that the edges exist between the nodes302and304, and there may not be an edge within the nodes302or within the nodes304.

The processor218may be configured to store the generated edges in the second database224. In some aspects, the processor218may store the generated edges (e.g., a list of generated edges) as records in an edge table402, as shown inFIG.4. The edge table402may store the list of edges in association with the node identifiers of nodes that the edges may connect. In further aspects, the processor218may store edge information associated with the list of edges in the first database222. In some aspects, the processor218may store the edge information as records in the request table400, as shown inFIG.4. In some aspects, the processor218may be configured to obtain the list of edges stored in the edge table402from the second database224.

In further aspects, the processor218may be configured to determine and select an edge for each rent request (or for each available vehicle) that may offer a best match for the rent request/available vehicle. Stated another way, the processor218may determine and select a best/final match available vehicle (from all the potentially matched vehicles) for each rent request by selecting an edge. For example, as discussed above, the processor218may generate two edges1and2that connect the vehicle associated with the node302awith the rent requests associated with the nodes304aand304c. The processor218may select one edge (either edge1or edge2) to rent the vehicle associated with the node302a. In other words, the processor218may reserve the vehicle associated with the node302afor either the rent request associated with the node304aor the rent request associated with the node304c.

The processor218may determine and select the edge based on one or more predefined criteria. The predefined criteria may include one or more of maximization of vehicle utilization, maximization of vehicle rent revenue, available vehicle rent offer dates (i.e., giving preference to vehicle/request added before others), maximization of a count of matches in the graph300and/or the like. In some aspects, the processor218may give preference to reserving the vehicle that may have been added to the P2P system200before others, to ensure that a maximum number of vehicles in the P2P system200are reserved. The edge selection may be further understood in conjunction withFIG.5.

In some aspects, the processor218may select the edge (i.e., the best/final match vehicle/renter) based on Mixed Integer Linear Program. In particular, the Mixed Integer Linear Program may be an objective function of a maximum number of matches (i.e., to match maximum number of available vehicles in the server208), maximum vehicle utilization, available vehicle rent offer dates/rent requests offer dates (i.e., giving preference to vehicle/request added before others), maximum vehicle rent revenue and/or the like. In one or more aspects, the Mixed Integer Linear Program may be a weighted sum of above-mentioned parameters. An exemplary Mixed Integer Linear Program is shown below:

N is set of nodesxmis match state (i.e., whether a match exists for the vehicle or the rent request), where xm(t)∈{0,1}0: unmatched1: matchedxuis utilization state (which may be a ratio of requested rental duration and vehicle availability period of time), where xu(t)∈[0,1]w1, w2, w3 are weights, where w1, w2, and w3 may be selected based on user preferences or statically by the server208xris node type (renter/vehicle owner), where xr∈{0,1}0: vehicle owner1: renteri represents indexeijrepresents edge state, where eij(t)∈[0,1]0: unconnected1: connected

∑i∈N⁢xmiNrepresents a function to maximize number of matchesΣi∈Nxuirepresents a function to maximize vehicle utilizationΣi∈Nxmi(N−i) represents a function to give preference to matching vehicles/requests added before others

xmi[t]=∑j≠i,j∈Neij⁢∀i∈Nrepresents match state

xui[t]=∑j≠i,j∈Neij⁢uij(1-xr)⁢∀i∈Nrepresents vehicle owner utilization

Responsive to the edge selection, the processor218may reserve the identified available vehicle for the rent request. For example, when the processor218selects the edge2, the processor218may reserve the vehicle associated with the node302afor the rent request associated with the node304c. Similarly, when the processor selects the edge4, the processor218may reserve the vehicle associated with the node302cfor the rent request associated with the node304b, and so on. In some aspects, the processor218may send, via the transceiver216, vehicle reservation notifications to the vehicle owners and the corresponding matched renters, when the processor218reserves the vehicles based on the edge selection.

Further, the processor218may store edge selection information in the second database224. In some aspect, the processor218may store the edge selection information in the first database222as well.

In some aspects, the processor218may be further configured to update the list of edges. In particular, the processor218may update the list of edges when the processor218receives or obtains a predefined trigger event. In some aspects, the processor218may obtain the predefined trigger event from the vehicle owner devices206or the renter devices214, via the transceiver216. The predefined trigger event may include at least one of a new rent request entry, a new available vehicle entry, an existing available vehicle withdrawal, or an existing rent request withdrawal.

In particular, when the processor218receives/obtains the predefined trigger event, the processor218may update the first database222(i.e., update the list of rent requests and/or list of available vehicles). For example, when the processor218receives a new available vehicle entry, the processor218may add the new available vehicle in the server208as a new node, and update the first database222(i.e., add another node and node identifier in the first database222) and may update the request table400. The processor218may then identify potential matches for the new available vehicle entry. Stated another way, the processor218may identify all the rent requests in which the requested rental duration is within new vehicle availability time periods. The processor218may further store the potential matches in the first database222, and may add the potential matches as new edges in the edge table402to form an updated edge table402.

Responsive to adding the new edges in the edge table402, the processor218may obtain the list of edges stored in the updated edge table402and perform rent vehicle reservation re-evaluation to identify best/final matches for all nodes in the graph300, based on the edges in the updated edge table402.

A person ordinarily skilled in the art may understand that performing the reservation re-valuation using the edge table402(instead of request table400) increases server208computational efficiency. This is because the edge table402only stores edge information (which may be a subset of information stored in the request table400). The process of rent vehicle reservation re-evaluation may be understood in conjunction withFIGS.4and5A-5Gdescribed below.

In some aspects, when the processor218performs the reservation re-valuation, the processor218may identify best/final matches for all the nodes in the graph300, such that no existing “matched” rent request/available vehicle goes to “unmatched” state. Further, the processor218may update final matches for all the nodes, such that the updated final matches offer same or better outcome (e.g., better vehicle or revenue utilization) to the renters/vehicles.

FIG.4depicts snapshots of example tables in the P2P vehicle sharing system200in accordance with the present disclosure. In particular,FIG.4depicts an exemplary request table400and an exemplary edge table402. The request table400may include information stored in the first database222and the edge table402may include information stored in the second database224.

For example, the request table400may store the node identifiers406(unique identification numbers or IDs) associated with the first plurality of nodes302and the second plurality of nodes304. The node identifiers may be a number, alphabet, or alphanumeric number. For example, the node identifiers406may be a number, as shown in the request table400and the edge table402. In some aspects, the request table400and the edge table402may indicate whether the node identifier is associated with available vehicle or rent requests, as shown as column408inFIG.4.

In some aspects, the request table400may further include the list of rent requests and associated requested rental durations (shown as columns410and412), and the list of available vehicles and associated vehicle availability time periods (shown as the columns410and412). For example, the request table400indicates that the vehicle having ID “2” may be available between Jan. 20, 2023 and Jan. 30, 2023. Further, the request table400indicates a rent request having ID “1”) may have an associated requested rental duration between Jan. 20, 2023, and Jan. 25, 2023.

The request table400may further indicate whether there exists an edge for the corresponding node identifier. Stated another way, the request table400may indicate whether there exists a match (or indicates final match status, shown as column414inFIG.4) for each node identifier. For example, the request table400indicates that there exists a best/final match for the rent request ID “1” and for the vehicle ID “2”, and not for the rent request ID “3”.

In a scenario when the processor218identifies the best/final match, the processor218may further indicate corresponding match ID in the request table400, shown as column416inFIG.4. For example, the request table400indicates that the vehicle having ID “2” may be matched to the rent request having ID “1”. The request table400may further indicate utilization state for each node, shown as column418inFIG.4. The utilization may be a ratio of the requested rental duration and the vehicle availability time period. For example, the utilization state for the vehicle having ID “2” may be 0.50, as the vehicle is available for 10 days and the number of rental days (or requested rental duration) for the matched rent request is 5 days. In other words, the renter needs the vehicle for 5 days and the vehicle is available for 10 days. Hence, the vehicle can only be utilized for 5 days in this case, and thus the utilization state is 0.50.

In some aspects, the request table400may also include a vehicle rent revenue state for each matched vehicle, shown as column426inFIG.4. The vehicle rent revenue state may be based on demand or surge pricing. For instance, the memory220may store information associated with surge or demand pricing that may indicate when and where surge pricing exists, for example, for different rent days (weekdays/weekends/holidays), rent time, rent location (such as busy locations). The processor218may obtain the surge pricing information from the memory220and determine whether surge pricing may be applicable on one or more days when the vehicle is available for rent. When the processor218determines that surge pricing may be applicable, the processor218may match the vehicle with a rent request that may have associated requested rental duration including the days in which the surge pricing is applicable. In this manner, the processor218may maximize revenue earning for the vehicle owner.

In some aspects, the column426may indicate “1” when surge pricing is applicable on at least one day when the vehicle is available for rent. When surge pricing is not applicable on any day when the vehicle is available, the column426may indicate “0”.

In accordance with the present disclosure, the edge table402may include a subset of information stored in the request table400. For example, the edge table402may store edge information associated with the first plurality of nodes302and the second plurality of nodes304. In particular, the edge table402may include information of all the edges (i.e., all the potentially matched rent requests/vehicles) formed between the first plurality of nodes302and the second plurality of nodes304. For example, the edge table402may include details of edges1-7discussed in conjunction withFIG.3.

FIG.4depicts that the edge table402includes the edges captured in the request table400. In particular, the edge table402may include nodes (node identifiers, as renter ID and vehicle ID) associated with the formed edges, along with the utilization state of each edge, shown as columns420-424inFIG.4. The nodes for which no edge is formed (i.e., no potential match is found) may not be stored in the edge table402.

As described above, the processor218may update the potential matches/edges in the edge table402when the processor218receives/obtains the predefined trigger event. In other words, the edge table402may be dynamic and may update based on the predefined trigger event. In some aspects, the processor218may further update the request table400based on the predefined trigger event. The details of updating the request table400and the edge table402may be understood in conjunction withFIGS.5A-5G.

FIGS.5A-5Gillustrate different examples for reserving a vehicle in the P2P vehicle sharing system200, in accordance with the present disclosure. As described above, when the processor218receives/obtains the predefined trigger event, the processor218may update the request table400and/or the edge table402. For example, when the processor218receives/fetches a new vehicle1(shown inFIG.5A) in the server208, the processor218may add an entry the new vehicle1in the request table400(or add a node in the graph300). The processor218may further assign a unique identifier to the new vehicle1. The processor218may further determine whether vehicle availability period associated with the new vehicle1matches with requested rental duration of a rent request. As there is no rent request in the server208in the example shown inFIG.5A, there is no potential match for the new vehicle1.

FIGS.5B and5Cindicate entries of two more vehicles2and3in the server208. The processor218may add entries of vehicles2and3in the request table400(or add nodes in the graph300). As there is no rent request in the server208in the examples shown inFIGS.5B and5C, there is no potential match for the new vehicles2and3.

FIG.5Ddepicts an entry of a new rent request4. Responsive to the entry of new rent request4, the processor218may add an entry of new rent request4in the request table400(or add a node in the graph300). The processor218may add the new request in the first database222. The processor218may then identify an available vehicle (or generate one or more edges) for the new rent request. In particular, the processor218may determine if the requested rental duration associated with the new rent request4is within the vehicle availability time period associated with any available vehicle (vehicles1-3, i.e., “potential matches”) in the server208. When the processor218identifies potential matches for the new rent request4, the processor218may update the second database224(or the edge table402). In other words, the processor218may add the information associated with the new rent request4and the potentially matched available vehicle(s) in the second database224.

For example,FIG.5Dindicates that the new rent request4potentially matches with all the available vehicles1-3, and thus the processor218may form three edges E1-E3and store edge information in the edge table402. In particular, the processor218may add node identifiers associated with the vehicles1-3and node identifier associated with the new rent request in the edge table402. The processor218may further determine utilization state of each edge. For instance, the utilization state of E1is 0.43, E2is 0.23, and E3is 0.43.

The processor218may additionally determine a best/final match (a best available vehicle) for the rent request4. In some aspects, the processor218may determine the best available vehicle (or select one edge out of E1-E3) based on the predefined criteria, as discussed above. For example, the processor218may select an edge having maximum vehicle utilization. Since E1and E3have same utilizations inFIG.5D, the processor218may select E3as the best match for the rent request4, as the vehicle1was added or offered first for rent on the server208. In other aspect, the processor218may select E3irrespective of the utilization state, as the vehicle1was offered/added first on the server208. In other words, the processor218may select the vehicle1for the rent request as the rent offer date of vehicle1is prior to the rent offer dates of vehicles2and3.

FIG.5Edepicts another example in which a new rent request5may be added to the server208. The processor218may add/enter the new request5in the request table500, as discussed above. Further, the processor218may generate the edges between the vehicles1-3and the rent requests1-2to identify potential matches for each rent request or each available vehicle. Furthermore, the processor218may perform rent reservation re-evaluation to identify best matches for each rent request or available vehicle. In this example, the processor218may match the vehicle1(as best/final match) with the rent request4. For the rent request5, the processor218may generate two edges E4and E5(as potential matches). E4may connect the rent request5with the vehicle3, and E5may connect the rent request5with the vehicle2. E4may have an associated utilization of 0.71 and E5may have an associated utilization of 0.38. In this scenario, the processor218may select E5as the best match, although E4may have higher utilization. This may be because the vehicle2rent offer date is before the vehicle3rent offer date. Stated another way, the vehicles that are offered first on the server208for rent may be allocated first, irrespective of the associated edge utilization.

A person ordinarily skilled in the art may appreciate that by allocating vehicles that are offered first on the server208for rent requests, the present disclosure may ensure that most available vehicles on the server208are matched with renter(s) on the server208. In this manner, the present disclosure ensures a higher vehicle allocation/rent rate on the server208, and thus incentivizes vehicle owners to offer their vehicles for rent on the server208. Stated another way, since a higher percentage of vehicles is matched with renter(s), owners have a higher percentage probability of their vehicles being rented out.

FIG.5Fdepicts another example of vehicle sharing. In this case, another rent request6may be added to the server208. The processor218may add the rent request6in the request table400. The processor218may again form edges for all the entries (i.e., for all the vehicles1-3and all the rent requests4-6and perform rent reservation re-evaluation) as described above and update the edges in the edge table402. Since in this case there are three vehicles1-3against three rent requests4-6, the processor218may determine best matches based on maximum vehicle utilization. In other aspects, the processor218may determine best matches based on maximum vehicle rent revenue.

Similarly, when the processor218receives an existing available vehicle withdrawal request or an existing rent request withdrawal request on the server208, the processor218may remove entries associated with the existing available vehicle or the existing rent request from the first database222(or the request table400). In addition, when edge entries associated with the existing available vehicle withdrawal or the existing rent request withdrawal are present in the second database224(or the edge table402), the processor218may remove the edge entries from the second database224(or the edge table402). The processor218may further perform the edge selection using the updated first database222and the second database224.

FIG.5Gdepicts an example withdrawal of vehicle3from the server208. In this scenario, the processor218may update the request table400by removing entries associated with vehicle3from the request table400and the edge table402. The processor218may further generate edges between the current available vehicles (e.g., vehicles1and2) and rent requests (e.g., rent requests4,5and6).100931FIG.6depicts an example embodiment of renting a vehicle in the P2P vehicle sharing system200in accordance with the present disclosure. In some aspects, an X-axis ofFIG.6depicts different days, e.g., Day 1, 2, 3 and so on (shown by a plurality of boxes1-24). Further, a Y-axis ofFIG.6depicts a renter602, and a plurality of vehicles (e.g., a vehicle604, a vehicle606, and a vehicle608) that may be available for rent. In particular,FIG.6illustrates a two-step process of renting the vehicle, from the plurality of vehicles, by the renter602. The process may be divided into two phases, e.g., a reservation phase and a confirmation phase.

In the reservation phase, the renter602may send a rent request to rent the vehicle for four days, as indicated by Days 17-20 corresponding to the renter602. The renter602may send the rent request on Day 3 to the P2P system200. As described above, responsive to receiving the rent request, the processor218may obtain a set of available vehicles for the renter602.

In the embodiment shown inFIG.6, a vehicle604owner (e.g., a first owner, not shown) may offer to rent the vehicle604on the P2P system200. As indicated inFIG.6, the first owner may offer the vehicle604on Day 1, and the vehicle604may be available for rent from Days 14 to 21. Thus, in this embodiment, the processor218may determine that one vehicle (e.g., the vehicle604) may be available for the renter602. As depicted inFIG.6, the vehicle604may be available for eight days, including the four days for which the renter602wants to rent the vehicle. Thus, the processor218may reserve the vehicle604on Day 3 for the renter602and may transmit a notification associated with the reservation to the renter602and the first owner. In some aspects, the notification transmitted in the reservation phase may not include the vehicle604VIN, and/or the first owner or the renter602details, until a confirmation phase start. For example, the notification in the reservation phase may include a message to the renter602, stating that “A vehicle is reserved for you”, and to the first owner stating that “A renter is assigned for your vehicle”.

In accordance with further aspects, the processor218may receive a new vehicle (e.g., the vehicle606) in the P2P system200on Day 7. The vehicle606may be available for rent from Days 17 to 22. Responsive to the vehicle606receipt, the processor218may add the vehicle606to the set of available vehicles. As discussed above, responsive to receiving a predefined trigger event (including the addition of a new vehicle), the processor218may dynamically re-evaluate the potential and best vehicle match for the renter602(or generate or update the list of edges). For instance, the processor218may determine a rental duration overlap extent (identified from the rent request) with the set of available vehicles' availability periods, for example, the vehicles604and606, to identify the best vehicle match. For example, in the embodiment depicted inFIG.6, the processor218may determine that the vehicle606is a better match over the vehicle604for the renter602, as the overlap extent is 50% for the vehicle604, and approximately 67% for the vehicle606. In other words, if the processor218reserves the vehicle604for the renter602, then four vehicle604available days may not be utilized, and thus the vehicle604utilization may not be optimum. On the other hand, if the processor218reserves the vehicle606for the renter602, then only two vehicle606available days may not be utilized. Thus, the processor218may reserve the vehicle606for the renter602and release the vehicle604for other requests/renters. In this manner, the processor218may optimize vehicle utilization for the available vehicles in the P2P system200.

In the scenario described above, the processor218may identify a different renter for the vehicle604, before the processor218releases the vehicle604reservation. Specifically, the processor218may reserve the vehicle606for the renter602only when there exists another match for the vehicle604. Stated another way, the processor218may change the “match” for the renter602if the processor218finds another match for the vehicle604(and the vehicle604may not go from matched state to unmatched state). In some aspects, the processor218may find the “other match” for the vehicle604such that the other match offers same or better vehicle utilization for the vehicle604than the renter602request. Thus, the processor218may update the match to have same or better outcome (i.e. better utilization, better revenue, etc.) for both the renter602and the vehicle604.

In accordance with further aspects, the processor218may transmit, via the transceiver216, the vehicle606VIN, to the renter602(e.g., via a renter device) at a confirmation phase start. In some aspects, the confirmation phase may begin a predetermined number of days (e.g., five days) before a rental duration start (e.g., Day 17). In addition to sending the vehicle606VIN, the processor218may transmit instructions to the renter602to submit a request for vehicle authorization to a vehicle606owner. Responsive to the VIN and the instructions receipt, the renter602may transmit, via the renter device, the vehicle authorization request to the vehicle606owner, via the P2P system200.

In one or more aspects, responsive to receiving the vehicle authorization request, the vehicle606owner may approve the request within a specific time period (e.g., within 24 hours of receiving the request). The agreement of vehicle renting may become binding when the vehicle606owner approves the request. At this stage, the processor218may transmit a remote key (or a vehicle access code) to the renter602, via the transceiver216, so that the renter602may use the vehicle606during the rental duration.

In some aspects, the processor218may fix or finalize the reservation of vehicle606for the renter602when the agreement becomes binding. In other words, the processor218may not re-evaluate (or may deactivate re-evaluation of) the vehicle606reservation, when the vehicle606is in the confirmation phase. For instance, as depicted inFIG.6, the vehicle608may become available during the confirmation phase and may offer a better match for the renter602, over the vehicle606. However, since the vehicle606is already reserved and confirmed for the renter602, the processor218may not re-evaluate the reservation process for the renter602, even if the vehicle608offers a better match (e.g., the vehicle608offers 80% overlap with the rental duration).

FIG.7depicts a flow diagram of an example method700for reserving a vehicle (by the processor218), in accordance with the present disclosure.FIG.7may be described with continued reference to prior figures, includingFIGS.1-6. The following process is exemplary and not confined to the steps described hereafter. Moreover, alternative embodiments may include more or less steps that are shown or described herein and may include these steps in a different order than the order described in the following example embodiments.

The method700may start at step702. At step704, the method700may include obtaining, via the processor218, a list of rent requests and associated requested rental durations. The list of rent requests may be associated with the renters112, and the processor218may obtain the list of rent requests via the renter devices114. The list of rent requests may represent first nodes (same as the second plurality of nodes304) of a vehicle-renter graph (e.g., the graph300). The details of the list of rent requests and the vehicle-renter graph300may be understood in conjunction withFIGS.2and3.

At step706, the method700may include obtaining, by the processor218, a list of available vehicles and associated vehicle availability time periods. The list of available vehicles may be associated with the vehicle owners204, and the processor218may obtain the list of available vehicles via the vehicle owner devices206. The list of available vehicles may represent second nodes (same as the first plurality of nodes302) of the vehicle-renter graph. The details of the list of available vehicles may be understood in conjunction withFIG.2.

At step708, the method700may include obtaining, by the processor218, a list of edges. The processor218may obtain the list of edges from the memory220. The edges may connect at least one first node and at least one second node. In some aspects, a requested rental duration associated with the at least one first node may be a subset of a vehicle availability time period associated with the at least one second node. The details of the edges may be understood in conjunction withFIG.3.

At step710, the method700may include receiving, by the processor218, a predefined trigger event. The predefined trigger event may include at least one of a new rent request entry, a new available vehicle entry, an existing available vehicle withdrawal, or an existing rent request withdrawal.

At step712, the method700may include updating, via the processor218, the list of edges responsive to receiving the predefined event. The details of updating the list of edges may be understood in conjunction withFIGS.2-6. At step714, the method700may include transmitting, via the processor218, a vehicle reservation notification to at least one renter and at least one vehicle owner based on the updated list of edges. In particular, the method700may include transmitting notifications to at least one renter and at least one vehicle owner to indicate mapping of the renter and the available vehicle, which indicates available vehicle reservation for the renter. The method ends at716.