GB2527660A - Shared vehicle systems and methods - Google Patents

Abstract

A map indicating respective locations of a plurality of vehicles included in a ride-sharing service is generated 315. A vehicle is identified in the plurality of vehicles that is in need of relocation 320, for example to rebalance the locations of vehicles in a shared fleet. A user is identified 335 in a vicinity of the identified vehicle for an offer to use the identified vehicle. The offer is transmitted 350, via a network, to the user for use of the identified vehicle in a manner to support the relocation. A user may be identified based on a common user destination and a common route of travel. The offer may include a discount in pricing for use of the identified vehicle in exchange for user assistance in relocating the shared vehicle

Description

ShARED VEHICLE SYSTEMS AND METHODS

BACKGROUND

100011 Personal vehicles generally provide a flexible form of transportation for commuters and passengers within urban environments. 1-lowever, owning and operating a personal vehicle can be expensive when costs for the vehicle, fue', insurance, and maintenance are factored in. In addition, personal vehicles increase congestion and pollution in urban environments. Public transit systems, including buses, trains, subways. etc., that operate on a fixed schedule, provide alternate lower cost options for conmiuters. Shared transportation options reduce iI1city congestion and improve air quality. However, a commuter may have limited flexibility in terms of departure and arrival times, as well as departure and arrival locations.

100021 Another shared transportation option thai provides a good mix of flexibility, cost, ease of use, and environmental impact is a shared vehicle system. Therein, a fleet of vehicles are distributed over an operating zone (e.g., a city) and a user can rent any ehicle of the fleet for a short period (e.g., a few hours of a day). Once a user account is set up, the user can identify a vehicle he or she wishes to rent based on its location within the operating zone, and rent the vehicle without requiring additional paperwork, The user can then return the vehicle to the point of origin or drop off the vehicle at an alternate location, per the user's convenience. The shared vehicle s stern reduces the user's commuting costs while also reducing in-city congestion and pollution. At the same time, the ability to pick-up and drop-off a vehicle at a time and location determined by the user increases the user's flexibility, 10003] Unfortunately, shared vehicles intermittently have to be relocated to provide for rebalancing locations of vehicles in a shared fleet, Specifically, to ensure ii niform or sonic other desired distribution of vehicles over an operating. zone, once user rides are completed, based on the location of the fleet vehicles, one or more vehicle may have to he driven to a different part of the operating zone so that they are accessible to users there, In some cases, this may include driving a vehicle across the city' In addition to the cost of relocating th.e vehicle, the fleet management system may have to hire dedicated drivers to drive the vehicles to the specific iccattons where rebalancing is achieved. As such, this adds cost and time to fleet management.

SUMMARY OF THE INVENTION

100041 According to a first aspect of the present invention, there is provided a system as set forth in claim 1 of the appended claims.

100051 According to a second aspect of the present invention, there is provided a method as set forth in claim 11 of the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

100061 Figure 1 is a block diagram of an exemplary shared vehicle system.

0007] Figure 2 is a high level representation of an implementation of the system of Figure 1.

100081 Figure 3 is a process flow diagram illustrating an exemplary process for relocating a shared vehicle as part of providing a shared vehicle to a user.

100091 Figure 4 is a process flow diagram illustrating an exemplary process for relocating a shared vehicle including providing transport to a user.

DESCRIITION

in one example, rebalancing problems may be addressed by a method that provides targeted advertisements to users based on fleet rebalancing needs. For example, if one or more vehicles have to be relocated from a first region to a second region of the shared vehicle system's opcrating zone (eg,, due to a larger ratio of vcliiclcs in the first region relative to the second region), a ccntral server i'nay identify users in thc first region who have a history of riding into the second region! This and other opcrations disclosed hcrein may he provided according to instctions included in the central server or the ike that is communicatively coupled to one or niore shared vehicles, mobile devices, etc!, eg., via a wide area network that i'nay include cellular, WiFi. and/or other technologies 1000111 For example, based on user profile settings, preferenccs, and well as user trip history, the server may he programmed to make a prediction or predictions about a user's likely! destination. II' the user's destination matches a region where it is desired to relocate the vehicle, a targeted notification may he sent to the user advertising a discounted fare for the trip! in one example, it maybe desired to relocate a vehicle to an area in the vicinity of a user's home location, A notification may then be pushed to the user. e.g., to a user's mobe cotr4)Uting device such as a smartphone or the like. advertismg a discounted fare for driving the vehicle home. The notification may be pushed to an application running on a mobile device, such as a smart phone, of the user, while the user is in the vicinity of the vehicle needing relocation. In one example, the notificaEion may be pushed when the user is passing by the vehicLe needing relocation.

000121 in some examples, the user may also be notified about ride sharing opportunities that then factor can in rebalancing requirements. For example, ride shares that achieve rebalancirg may be discounted more heavily than ride shares that require subsequent rebalancing.

1000131 In still other examples, users may be given a monetary incentive for relocating a vehicle for rebalancing purposes. The user selection may be based on user preferences. user settina's. as well as user location relative to a location of the vehicle that requires relocation.

1000141 in some examples, the user may be rated upon completion of the relialancing job. For example, after a first user has relocated the vehicle via their ride, a second user may request the vehicle. The second user may be queried about the status of the vehicle, such as whether the vehicle is clean, if fuel level is sufficient, vehicle maintenance is adequate, etc. Based on the second user's input, the rebalancing job performed by the first user may be rated and the rating updated in the first user's profile. i* uture rebalancing notifications may then be pushed based on the user's rehalancing rating. For example, users who have a higher rating may receive rebalancing requests more often tha.n those with a lower rating. Alternatively, users who have a higher rating may receive better incentives for rehalancing jobs than those with a lower rating.

1000151 Note that the rebalancing operation and management may be operated through a central rebalancing system that receives information on user locations, vehicle locations, reservations, past routes, statistically likely routes in the future, weather, etc. Further, the rcbalancing system may factor in the vehicle's state of charge and/or fuel level in managing rebala.ncing advertisements and notifications, as well a.s to parcel deliveries as part of the overall rcbalancing goals. Users may be offered reduced rates that help increase the balance of the vehicle fleet to the desired spatial and geographic distribution suid/or that enable a parcel or another user (for shared vehicle use) to reach a desired destination as part of the rebalaneing.

1000161 Maintenance may also be factored into the rehalancing management system For example, a user may he notified ofa discount if the user assists with a quick service of the vehicle during the journey/renta.I and/or if they user modifies a drop off location to improve rebalancing. Vehicle charging and/or refueling ma' also he part of the rebalancing operation, such that a user may he incentivized to move vehicles to a certain location as well as to plug the vehicle in for charging at the specified location, The system may monitor whether the vehicle not only reaches the specified Location, hut whether the vehicle enEers a charging condition, I00017 The system may incentive certatn rebalancing actions by providing incentives such as an increase user rating, increased discounts. etc. [00018] Jgain, the vehicle itself may advertise, or a central appilcatlon may push advertisements to users near the ehicle, tile advertisements based on the particular user's profile that are near the vehicle. The advertisements (sometimes also called offers) may be focused on rebalancing the vehicle to a new location and target users more likely to be headed toward the rebalanced location.

00019] Further, the users may be rated based on their likelihood of leaving the vehicle in a position with high, or low, need for rebalancing afterward. Such a rating may be further based on whether the user leaves the vehicle with a low charge, low fuel, dirty, unlocked, window open, etc. 0002O] Turning now to the drawings, Figure 1 is a block diagram of an exemplary shared vehicle system 100 that includes at least one, and typically a plurality, of vehicles 101, e.g., a shared vehicle such as a motorcycle, car, van, etc. Each vehicle 101 includes a computer 105 communicatively coupled with a network 120. The vehicle 101 may further include a global positioning system (GPS) device 16 or the like in a vehc1e 101. Vehicles 101 may share roadways with vehicles 102 that are not part of the shared vehicle system IOU, i.e., that are not available for sharing via a server 1 25 1000211 A vehicle 10 computer lOS may be configured for communications on a controller area network (CAN) bus or the like, and/or other wire or wireless protocols, e.g.. Bluetooth, etc., i.e., the computer can communicate via various mechanisms that maybe provided in a vehicle 101, and can accordingly receive data from vehicle sensors, communications via the network 125, e.g., from the server 125, etc. The computer 105 may also have a connection to an onboard diagnostics connector (OBD-11). Via the CAN bus, OBD-I1, and/or other wired or wireless mechanisms. Further, a navigation system 106 may be provided in the vehicle 101 and communicatively coupled to the computer 105 to provide location data, e.g., via a global positioning system (OPS) or the like. The computer 105 may provide data, including location information of the vehicle 101, to the server 125 via a network 120.

1000221 I'he network 120 represents one or more mechanisms by which a vehicle computer 105 may communicate with a remote server 125 and/or a user device 150.

Accordingly, the network 120 may be one or more of various wired or wireless communication mechanisms, including any desired combination of wired(e,g,, cable arid fiber) and/or wireLess (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or topologes when multiple commnuncation mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g..

using Bluetooth, iEEE 802.101, etc.), local area networks (LAN) and/or wide area networks (WAN), including the internet, providing data communication services.

1000231 The server 125 may be one or more computer servers, each generally including at least one processor and at least one memory, the memory storing instructions executable by the processor, including instructions for carrying out various steps and processes described herein.

The server 125 may include or be communicatively coupled to the data store 130 for storing data received from one or more vehicles 101.

000241 A user device 150 may be any one of a variety of computing devices including a processor and a memory, as well as communication capabilities. For example, the user device 1 50 may be a portable computer, tablet computer, a smart phone, etc. that includes capabilities for wireless communications using IEEE 802,101, Bluetooth, and/or cellular communications protocols, Furthcr, the user device 150 may use such communication capabilities to communicate via the network 12.5 including with a vehicle coniputer 105. .A user dcvicc 1 50 could communicate with a vehicle 0 computer 05 the other mechanisms, such as a network in the vehicle 01, a known protocols such as Bluetooth, etc. Further, a user device 150 could he ii sed to provide a human machine interface (T'ITVET) to the computer 105.

1000251 Figure 2 is a high level representation of an implementation of the system 100 of Figure 1 in a geographic area 200. Vehicles 01 in the geographic arca 200 may communicate with the server 125, e.g., via the network 120 (as seen in Figure I). Further, vehicles 102 that are not part of the system 100, as mentioned above, may be included in the geographic area 200.

Vehicles 101 in the geographic area 200 may be available for use by anartcipant in the shared vehicle system 100, or in use. For example, vehicles 101 in Figure 2 represented by unshaded scuares may be considered to he available for use whereas vehicles 101 represented by shaded squares may be considered to be in use. For reasons such as described herein it may sometimes be desired that vehicles 101. that are available for use. i.e., currently unused, be relocated, sometimes referred to as rebalanced. from a first Location in the geographic area 200 to a second location in the geographic area 200.

1000261 Figure 3 is a process flow diagram illustrating an exemplary process 300 for relocating a shared vehicle 101 as part of providing a shared vehicle 101 to a user. The process 300 begins in a block 310, in which the server 125 receIves data from vehicles 101, generally including location data, e.g., geocoordinates specifying latitude and longitude information, from vehicle OPS systems 106. Data from a vehicle 101 may include other information, e.g., whether the vehicle 101 is currently in use, i.e., occupied by a user and/or being used to transport cargo.

1000271 Next, in a block 315, the server 125 generates and/or updates a map for a geographic area 200 of locations of shared vehicles 101. Such map niay be stored in a niemory of the server 125 and/or in the data store 130.

1000281 Next, in a block 320, the server 125, analyzing the map, determines whether it is necessary or desirable to relocate any of the shared vehicles 101 included in the map and not in use. Such relocation may sometimes be referred to as rebalancing, as mentioned above. tf rebalancing is warranted, then a block 330 is executed next, Otherwise, the process 300 proceeds to a block 325.

1000291 Tn the block 325, the server 125 makes vehicles available for use without rehalancing, and may schedule a ride for a user pursuant to a received request according to regular, undiscounted, unincentivized. etc. fares. The process 300 then ends.

1000301 Tn the block 330, the sen'er 125 determines relocation details for a rebalancing, including, for example, an identification of particular vehicles 101 that should be relocated, a cou.nt of the vehicles 1 01 that should be relocated, an identification of respective desired drop-off locations for each vehicle 10! to be relocated, any fueling requirements, e.g., recharging for an electric vehicle 101, etc. 1000311 Next in a block 335, the server 125 identifies potential user& if any, in the vicinity..

within 20 meters, 50 meters, 100 meters, 500 meters, etc.. of each shared vehicle 101 needing relocation.

1000321 Following the block 335, in a block 340, if any users have been identified in the block 335., the server 125 retrieves from the data store 130. and analyzes.. profiles for such. users.

The sen'er 125 generally also retrieves and analyzes a profile for the user having made the ridesharing request In the bLock 305. As part of the analysis of the block 340, the server 125 generally executes programming to find potential matches between users' ride needs, e.g., looking at frequentLy traveled bus routes, frequently traveled vehicle trip routes, known home locations, work locations. etc. [00033] Following the block 340. in the block 345, the server 125 determines whether any potential users for a vehicle 101 relocation were identified in the block 340. if so, a block 350 is executed next. Otherwise, a block 355 is executed next.

1000341 in the block 350, the server 125 sends ride proposals to one or more users identified in the block 335. and then determined to match a planned ride as described with respect to the block 340. For example, a ride a proposal could offer to allow a user to ride a shared vehicle 101 home for a discounted fare, a coupon for a future ride, or sonic other incentie. Once the ride proposal or proposals are sent, the process 300 may continue with steps described as pail of the process 400 of Figure 4. Aiternatively, the ride proposal could simply be accepted, whereupon a user or users could be provided with access to the vehicle 101, and the process 300 would then end.

1000351 in the block 355, because no second users have been matched to the ride planned for the first user 101, the server 125 proceeds to schedule rebalancing, e.g., using designated, hired drivers for that purpose, Following the block 355, the process 300 ends.

1000361 Figure 4 is a process flow diagram illustrating an exemplary process 400 for relocating a shared vehicle 1W including providing transport to at least one user pursuant to an offer provide.d as described above with respect to the process 300. The process 400 begins ir a block 405 in which, as in the block 355 described above, the sen'er 125 pushes an offer for a ride in a shared vehicle 101 to a user.

[00037] Tn the block 410, the server 125 determines whether the offer provided in the block 405 has been accepted, e.g., a user device ISO may be used to transmit an acceptance to the server 125 via, the network 120. If the offer is not accepted, then the process 400 ends.

Otherwise, the process 400 proceeds to a block 415.

1000381 in the block 415, the server 125 determines whether there is a further transportation opportunity for the vehicle 101 to he relocated. For example, another user may he in the viclnity of the vehicle 10.1, there may he a.n opportunity to transport cargo, etc. If there is no further transport opportunity, then the process 400 proceeds to a block 435. Otherwise, a block 420 is executed next.

1000391 In the block 420. the sen'er 125 notifies the user who accepted the ride offer ln the block 405 concerning the transport opportunity identified in the block 415. For example, a user device 150 may he sent a message by the server 125 via the network 12ft I'he message could include an incentive, e.g., pick up a second user at a location near your planned route to receive a percent ride discount, etc. 1000401 Next, in a block 425, the server 125 determines whether the opportunity offered in the block 420 has been accepted, ag., a user device 150 could send a message to the server 125 indicating acceptance or declination of the offer, the server 125 could determine that the offer was declined after not receiving a response for a predetermined period of time, e.g., three minutes, etc. in any case, if the offer is accepted, then a block 430 is executed next. Otherwise, the process 400 proceeds to the block 435.

1000411 in the block 430, the server 125 provides transportation details to the user whose has accepted the offer of the block 420. For example, pickup and dropoff locations of another user, cargo such as a parcel, etc., may be identified.

1000421 Next, in the block 435 that follows the block 430, the server 125 receives notifi cation that a rebalancing trip has been completed. For example, a vehicle 101 could be used to pick up a second user, a parcel, etc., drop-off the second user, parcel, etc., and he used by the first user to reach an intended destination, whereupon a vehicle 101 computer 105 could provide the notification to the server 25.

1000431 Next, in a block 440, the server 125 determines whether a new request for a relocated vehicle 01 has been received. If not, then the process 400 ends Otherwise, the process 400 proceeds to a block 445, 1000441 Tn the block 445, the server 125 provides a survey to a new user of the vehicle 101 relocated as described above. For example, cleanliness, thel levels, etc., of the vehicle 101 may be described according to responses to the survey, which may he conducted via questions provided to a user device 150 via the network 120 1000451 Next in a block -450, the server 125 updates a first user's profile in the data store 130 according to responses received to the survey provided in the block 445. Accordingly, a user may be rated or otherwise tracked, and such information may be used to provide future offers and/or opportunities to the user. Following the block 450, the process 400 ends.

1000461 Computing devices such as those discussed herein generally each include instructions executable by one or more computing devices such as those identified above, and for carrying out blocks or steps of processes described above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of progmmming languages and/or technologies, including without limitation, and either alone or in combination, JavaTM, C, C++, Visual Basic, Java Script, Perl, HTML4 etc. In general, a processor (e.g. a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media.. A file in a computing device is generally a collection of data stored on a computer readable medium, such as a storage medium, a random access memory, etc. 1000471 A computer-readable medium includes any medium that participates in providing data (e.g. instructions), which may be read by a computer. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, etc. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes a main memory Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVI), any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM. a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.

Claims (4)

1. Clainis A system, comprising a computer including a processor and a memory, the memory storing Instl-ucElons executable by the processor such that the computer is programmed to: generate a map indicating respective locations of a phirality of vehicles included in a ride--sharing service; identify a vehicle in the plurality of vehicles that is in need of relocation; identify a user in a vicinity of the identified vehicle for an offer to use the identified vehicle; and transmit the offer, via a network, to the user for use of the identified vehicle in a manner to support the relocation.
2. 2, The system of claim 1, wherein the computer is further programmed to identify the user according to retrieved user information including at least one of a common user destination and a conunon route of travel.
3. 3, The system of claim 1 or 2., wherein the computer is further programmed to identify a plurality of users to receive a message including the offer or a second offer relating to use of the identified vehicle.
4. 4. The system ofclaims 1 to 3, wherein the conipuler is thrther programmed to idenlify cargo to he transported during' relocation of the identified vehicle.3, The system of claims 1 to 4, wherein the computer is further programmed to take at least one of fuel and maintenance requirements into account in identifying the vehicle that is in need of relocation, 6, The system of claims 1 to 5, wherein the computer is further programmed to provide a survey to a second user concerning a state of the identified vehicle following a relocation.7. The system of claim 6, wherein the computer is further programmed to adjust a user profile based on data from the survey.8. The system of claims 1 to 7, wherein the offer includes a discount in pricing for use of the identified vehicle in exchange for user assistance in relocating the shared vehicle.9. The system of claims 1 to 8, further comprising a user device including a processor and a memory, the memory storing instructions executable by the processor such that the user device is programmed to receive and respond to the offer via the network.10. The system of claims 1 to 9, further comprising a user device including a processor and a memory, the memory storing instructions executable by the processor such that the user device is programmed to provide a user location to the computer via the network 11. A method, comprising: generating a map indicating respective locations of a plurality of vehicles included in a ride-sharing service; identifying a vehicle in the plurality of vehicles that is in need of relocation; identifying a user in a vicinity of the identified vehicle for an offer to use the identified vehiclç and transmitting the offer, via a network, to the user for use of the identified vehicle in a manner to support the relocation.12. The method of claim!!, further comprising identifying the user according to retrieved user information including at least one of a common user destination and a common route of travel.13. The method of claim!! or 12, further comprising identifying a plurality of users to receive a message including the offer or a second offer relating to use of the identified vehicle.14. The method of claims ii to 13, further comprising identifying cargo to be transported during relocation of the identified vehicle. *l115. The method of claims 11 to 14. tiFrther comprising taking at least one of fueL and maintenance requirements into account in identifi1ng the vehicle that is in need of relocation.16. The method of claims Ii to 15, further comprising providing a survey to a second user concerning a state of the identified vehicle foLlowing a relocation.17. The method of claim 16, further comprising adjusting a user profile based on data from the survey.18. The method of claims 11 to 17, wherein the offer includes a discount in pricing for use of the identified vehicle in exchange for user assistance in relocating the shared vehicle.19. The method of claims 11 to 18, further comprising receiving and responding to the offer via the network.20. The method of claims Ii to 19. further comprising providing a user location to the via the network.