Method, system, server, mobile device and system for facilitating sharing of car use

© 1031908

Patent Center

The Netherlands

<img file="NL1031908C2_D0001.tif" />

C PATENT²⁰ © Patent application: 1031908 © Filed: 30.05.2006

Int.CI .:

G08G1 / 123 (2006.01)

<td>© Registered:</td><td>© Patent holder (s):</td>

<td>03.12.2007 IE 2008/02</td><td>Dirk Tangemann in Zaltbommel.</td>

<td>© Date:</td><td>© Inventor (s):</td>

<td> 03.12.2007</td><td>Dirk Tangemann in Zaltbommel.</td>

<td>© Published:</td><td>© Authorized representative:</td>

<td>01.02.2008 IE 2008/02</td><td>Ir. FE Hoeben at 3507 LC Utrecht.</td>

© Method, system, server, mobile device and system for facilitating the sharing of car use.

The present invention relates to a method for facilitating the sharing of car use via a central processing server, comprising steps for:

- keeping records of routepoints served by at least one car available to a passenger and times at which these routepoints are based on initial input by a driver and / or from a driver's car navigation system during facilitation by car,

- on the basis of input by a passenger during the facilitation, keeping records of a desired route to be traveled,

- calculating a correspondence between driver and passenger time and route,

- sending additional route points for the driver and / or a new calculated route for the passenger based on the agreement to the car navigation system for presentation of an adapted route to the driver.

NL C1031908

The contents of this patent correspond to the original filed description with claim (s) and any drawing (s).

The Netherlands Patent Office is the Office for Industrial Property, an agency of the Ministry of Economic Affairs

METHOD, SYSTEM, SERVER, MOBILE DEVICE AND SYSTEM FOR FACILITATING THE SHARING OF CAR USE.

The present invention relates to a method, system, server, mobile device and system for facilitating car sharing.

The fact that traffic jams occur on public roads, and in particular on main traffic networks, is known. Reducing the number of cars during times of traffic jams may reduce the number of traffic jams. To this end, efforts have been made for several years to, for example, allow people to ride together, which can reduce the number of cars on the roads.

For commuters who use public transport, there is often a problem that in addition to using the train for the longest distance, for example, there is often a pre-section from the departure location to the train station and a post-section from the arrival train station to the destination point. public transport takes a relatively long time to get from departure point to destination.

It is an object of the present invention to overcome such drawbacks by efficiently sharing car use.

This object is achieved according to the present invention by means of a method for facilitating car sharing through a central processing server, comprising steps for:

- keeping records of route points reached by at least one car available for a passer 1 0 3 1 9 08 vulture based on initial input by a be30 driver and / or from a driver's car navigation system during facilitation and times when these waypoints are reached by the car,

- on the basis of input by a passenger during the facilitation, keeping records of a desired route to be traveled,

- calculating a correspondence between driver and passenger time and route for determining a passage option,

- sending additional route points for the driver and / or a new calculated route for the passenger based on the agreement to the car navigation system for presentation of an adapted route to the driver.

An advantage of such a method according to the present invention is that, on the basis of an initial input by a driver, the driver can be provided with the possibility of taking a passenger with him, while the driver does not have to perform any actions for this before or during driving. For example, the driver only needs to accept a suggested route change by making it known at the touch of a button or in an equally straightforward manner. Possibilities for this are, for example, a (soft) button to be displayed on a touchscreen of the navigation system. Touching a specific button on the navigation system or, for example, entering a voice command such as accept.

A further advantage of this is that the driver can receive a predetermined compensation for taking the passenger, the advantage of which depends on the amount of detour compared to the distance to be driven by the passenger. For the passenger, the costs for their own transport and / or public transport are saved. Since selection of a match between the driver's and passenger's route is performed by the system, the distribution of such benefit will be objectively performed based on the initial input. Because the 'via points' that the driver must visit for picking up and dropping off the passenger are entered directly into his navigation system, the driver does not need to perform any programming operations.

Furthermore, as part of the route presented to it, it is possible that the driver will be able to read, for example, the extra duration and possibly even a map of the proposed changes. The director will also be able to observe any financial advantage immediately. For example, due to such stated benefits, a car sharing system will be practically acceptable to the users such as the drivers and passengers. Furthermore, people who are drivers at one time can be passengers at other times and vice versa. Such a system can work with very current data based on the so-called 'real-time' principle, but passages can also be planned further in the future.

In a first preferred embodiment, the method comprises steps for calculating a new route based on a route and the additional new route points. Depending on practical design parameters of such a system, this calculation can be performed by means of a calculation module on the central server or by means of a calculation module in the car navigation system. An advantage of the calculation in the car navigation system is that recalculations can be performed or that a driver uses calculation results from a system that works exactly the same as he is used to.

A further advantage of this is that use is made of this centrally available calculation capacity, whereas the central model requires a large amount of calculation capacity on the server for all routes to be taken. To make the matches for the purpose of offering a passage, the central server must have a certain amount of computing capacity.

In a further preferred embodiment, the method comprises steps for guiding the driver based on a route comprising points of a route and the additional route points. The route is the route that the driver would have traveled without a passenger from his starting point to his destination point. The additional points concern at least the pick-up point of the passenger and the drop-off point of the passenger. According to the present invention, therefore, the route of the driver is extended by waypoints determined by the route of the passenger.

As far as driving times are concerned, the passenger should, if necessary, adapt somewhat to the driving times of the driver. It is also possible that the passenger sets limits on the driving times acceptable to him and that these are nevertheless accepted by the driver when reporting a passage message to the driver. Preferably, both parties indicate a margin in which travel can be made so that making matches in the light of mutual benefit is made easier. Reasons for this can be for both parties that there is a financial advantage to be gained. The trip can be cheaper for both parties than a trip with an alternative transport system.

For the passenger there is also a comfort aspect, namely that he is picked up and dropped off at a point to be chosen by him. However, it is equally possible that the system or the passenger himself, for example, on the basis of data relating to public transport systems, proposes a boarding point or a drop-off point with relatively good transfer possibilities to the public transport system.

For example, if along a city bypass, there is a metro station with a timetable of passing high-frequency metro trains or a bus station with similar benefits, then the system can make a travel proposal where the passenger is taken from the house, for example, by a driver up to the metro or bus station, after which the remaining route, for example towards the city center, is carried out on the basis of the public transport service. This can, for example, reduce the travel time compared to a travel time that is fully performed by the passenger's public transport or reduce the number of transfers.

In a further preferred embodiment, the method comprises steps of using a mobile device for communicating between passengers and drivers and the central server. An advantage of a mobile device is that it generally carries with it and that it generally features a unique identifier that can be associated with the identity of its user. As a result, no manual identification steps need to be carried out when working with a known device or at least with a device using, for instance, a known telephone number or a known IMEIN number. Further identification numbers can be, for example, network card numbers for WIFI or other identifiers used in standard communication protocols.

Preferably, further steps are used for transmitting data relating to a passenger and / or a passenger identification between the central server and the car navigation unit and / or mobile devices. An advantage of such an embodiment is that the recognition of the persons and / or the pick-up point can be facilitated or that general basic knowledge of the persons using the invention can be used for this.

For example, if the passenger lives in or is present in a conspicuous house or building, conspicuous features may be passed on. It is also possible to send a photo of the passenger and / or the driver as additional identification so that the passenger knows that he is the correct driver and the driver knows that he has the correct passenger in front of him.

A further aspect of the present invention relates to a car navigation system for calculating routes and guiding a driver of a car, comprising:

- at least one memory for storing map data and route data and a processing unit for calculating routes and accompanying the driver on the basis of the map data and route data,

- at least one receiver for receiving data from which a position on Earth and / or relative to the map data can be determined,

- a receiving means for receiving data regarding additional route points that can be added to a route,

processing means for processing the received additional route points in a route for obtaining a route, wherein the additional route points form 'via points' in the route. By analogy with what has been described above, Such a car navigation system offers the advantage that pick-up points and drop-off points can be received automatically, as well as any other intermediate points for facilitating the calculation of a new route and / or displaying points based on such data and the display of which the driver can decide to accept a passenger including, for example, its financial benefit and acceptance of any detours. Further advantages as described above also apply.

In a preferred embodiment, the car navigation system comprises a communication device for communication via a wireless communication network such as a GSM, GPRS, EDGE, UMTS and / or WIMAX network. Alternatively, the receiving means comprises means for connecting to such a communication device. This makes it possible to establish two-way communication between the central server and the car navigation system in a manner suitable, for example, for a communication subscription already available to the user of the system, in this case the driver. The car navigation system connects, for example, by means of a USB cable or a Bluetooth connection, to a mobile phone of the driver, which mobile phone establishes communication with the central server serving the car navigation system.

Preferably, the car navigation system further comprises means for receiving an identification from a passenger. Examples include a card reader for a passenger's smart card or chip card or a connection such as a Bluetooth or USB connection for connecting to a passenger's mobile device. This allows the passenger to be identified with greater certainty in a simple and almost automatic manner.

A further aspect of the present invention pertains to a central server for performing a method of facilitating car sharing, comprising:

- at least one memory and one processing unit,

- at least one database for keeping records of passengers, drivers and maps,

- means of communication for communicating with passenger input devices,

means of communication for communicating with car navigation devices, and

- means for providing information to the car navigation devices regarding additional route points for inclusion thereof in a route. Such a server has advantages as indicated above with reference to the previous aspects and as explained in more detail below with reference to preferred embodiments.

A further aspect of the present invention relates to a mobile communication device for communicating with a central server according to claim 11 comprising:

- means for entering data related to routes, and

- means for communicating this data to the central server. Preferably it includes means for accepting or rejecting a passenger / route and / or means for accepting or rejecting a driver / passage. Such means can be implemented as a dedicated software module, but well-known communication modules such as a browser or an SMS application can also be used for this.

Further advantages, features and details of the present invention will be explained in more detail below with reference to preferred embodiments with reference to the attached figures, in which:

Fig. 1 is a schematic representation of a system comprising subsystems according to preferred embodiments of the present invention;

Fig. 2 is a flow chart of a method according to a preferred embodiment of the present invention;

Fig. 3 is a flow chart of a further method according to a preferred embodiment of the present invention;

Fig. 4 is a flow chart of a further preferred embodiment of a method according to the present invention.

A system comprising subsystems according to preferred embodiments of the present invention is shown in Fig. 1. Central to this system is a central server 105 which is arranged to determine suitable matches (matches) on the basis of which a potential passenger could suitably ride with a driver of a car. For this purpose, the central server 105 is provided with at least one processing unit 107. Furthermore, the central server is provided with a database for keeping suitable data regarding drivers, passengers, waypoints, routes, times and the like. The server is further adapted to make connections to a car navigation system 112 located in a rider's car 101 that can carry passengers.

To establish a connection between the central server 105 and the navigation system of the car 101, a wireless network is preferably used with which data can be transferred. Such networks are preferably suitable for two-way communication. Suitable two-way communication networks include, for example, GSM networks, GPRS networks (a separate protocol over a GSM network) and further protocols such as EDGE. Further networks suitable for this include UMTS networks, WIMAX networks. In the field of wireless communication networks, a number of developments are also underway, which may result in further networks which are currently still unnamed for use in the present invention.

The driver of the car can furthermore input data in advance from a fixed internet connection with regard to, for example, starting points and end points and the expected times thereof, and confirming such journeys at the start of the journey via the navigation system and the network connections described above. In this case, the driver can use the same connection options as the passenger.

A passenger who can make use of the passenger options that a rider can offer him can enter parameters related to his journey such as starting point and end point and desired times in the central server via, for example, a computer network such as the Inter11 network. Other connectivity options available to the passenger include public telephone networks (PSTN), wireless telephony and data networks as described above using the connectivity options provided by the car's navigation system and any other means of transmitting data to and from an a networked computer.

The passenger can use, for example, a computer (PC), a wireless device such as a hand computer (PDA), mobile phone or a combination thereof, or, for example, an information column that is provided with software and input means for connecting to the central server. . In each of these mentioned devices it is possible to use general applications such as web browsers that connect to a web server of the central server or specific software present on these devices. An advantage for the passenger when entering information by means of an information column or a computer is that on such devices with a generally large screen it is easier to display a graphical user interface and to input data.

However, it is preferable to use a passenger message, for example, to send a passage to the mobile phone of the passenger, to which he can respond by means of an SMS message because when leaving the house or immediately computer environment, the passenger may not receive the message.

On the basis of data with regard to routes to be driven by drivers of cars 101 and passenger rides desired by passengers, the central ser12 can determine a machine far on the basis of, for instance, the greatest possible match between times and routes.

In FIG. 2, a possible method for this purpose is schematically shown. The method starts in step 200, after which in step 201 the central server receives a passenger request or travel request from a potential passenger by means of, for example, the passenger's mobile device. In step 202, the central server stores information related to the travel request.

In step 203, the central server receives itinerary information from a car navigation system of a driver who has indicated that he wants to take a passenger. In step 204, the specific driver and travel schedule information is stored in the database of the server. Step 205 determines whether the position of the car has changed since a previous database update. If so, in step 209 the current position of the car in the database is changed. In step 206, a passenger's travel request is matched with the actual positions of the drivers' existing travel schedules and a matched itinerary is sent to a navigation system of the driver's car comprising waypoints regarding the potential passenger's journey .

Based on this, in step 207 the navigation system proposes the alternative route to the driver with the request to accept or reject it. If the driver rejects the modified route, the navigation system in the car continues with the previously entered route. If the driver accepts the passenger and the associated route, the car navigation system continues with the new route. In step 208, the central server processes the decision of the driver of the car and if any other passenger requests are present, the procedure is continued in step 206. If in step 207 the passenger is not accepted by the driver of the car, step 210 the next car with an appropriate itinerary selected or the matching process is repeated in step 206.

In FIG. 3 shows a preferred embodiment of a method to be carried out by the car navigation system. The car navigation system functions in cooperation with the central server 105 to enable matches to be established on the basis of current data. The method of this embodiment begins in step 300. In step 301, the car navigation system sends data regarding the route to be driven to the central server. It is possible that the car navigation system only transmits the starting point and the end point, but it is also possible that the car navigation system transmits a number of intermediate points of the route to be driven.

In addition to transmitting route points, it is possible to send an estimate of the times at which such points are passed. Alternatively, it is possible for the central server to independently estimate the times associated with waypoints. For example, it is practical to be able to offer a driver during the ride an offer to request a ride away at some distance for, for example, an exit that the driver should take to pick up a passenger. Including a reasonable acceptance time for the driver to decide whether to accept the possible passenger, it is advantageous if the notification with the offer to pick up this passenger is given in time14 as soon as the required turnoff is passed.

In step 301, after the itinerary and confirmation of availability during this trip of the car is sent to the central server, in step 302 an alternative driving schedule is received by the car navigation system from the central server. It is possible for the central server to send data relating to a fully developed new route to the car navigation system. It is also possible for the central server to send data relating to the passenger's pick-up point or drop-off point, on the basis of which the car navigation system calculates an alternative route and presents it to the driver. In an even simpler way, it is possible that the car navigation system only gives a notification about the passenger and the pick-up point and drop-off point.

An advantage of such an embodiment is that because data about the new route is passed on from the central server directly to the navigation system in the car, it becomes possible for the driver to pick up passengers from which he or she is guided by the navigation system. has no knowledge of how to reach the pick-up points. Furthermore, it is possible, for example, that when determining the route, the central server takes into account current information with regard to the situation on the road network such as traffic (traffic jams), maintenance, blockades and if not temporary situations of, for example, one-way traffic. This makes it possible to guide drivers to passengers and drop-off points with an efficiency that the driver could not of his own accord have achieved. It is not necessary for the driver to enter such route data into his navigation system himself.

In step 303, the driver determines whether to accept the alternative route and therefore the offer to take the passenger. In step 307, a message is sent to the central server that processes this data. If the driver's result is that the passenger is taken, the passage decision is processed. If the driver has decided not to take the passenger, the central server will have to make a new match.

In step 304, the car navigation system will update the new route to be driven based on the received route points from the passenger's route such as the boarding point and the drop-off point. According to this embodiment of the present invention, the car navigation system will insert the received route points of the passenger into the existing route so-called 'via points'. An advantage of this embodiment is that because the car navigation system can automatically process such via points according to the present invention, the driver does not have to pay attention to (re-) programming his navigation system on the basis of a possible decision to take a passenger with him. The driver just has to accept the passenger by a simple push of a button or even a voice command, after which he will be automatically directed to the pick-up point.

In the event that, for example, while driving on a motorway between two exits, the driver accepts a passenger for whom he must take the next exit, the car navigation system will automatically notify the driver of the exit as soon as he approaches it. . In order to make one and other possible, the car navigation system is provided with means for recording the new route points. These means comprise, for example, means for reading in, for example, the contents of an SMS message comprising such route data. Furthermore, it is possible that the car navigation system is provided with a link to, for example, a GPRS, EDGE, UMTS, WIMAX or other wireless networks with a virtually continuous connection.

Furthermore, for the purpose of receiving an offer from a passenger, the method of the car navigation system optionally includes a retransmission method step 308 which transmits either periodically or at some distance before an important intersection or in any other suitable manner regarding the current position of the vehicle. With the help of such data, the central server can make flexible or even real-time matches and make proposals for ride-along.

In step 305, the navigation unit in the car receives further information regarding the passenger, for example for easier identification or for easier identification of the pick-up point. For example, it is possible that the passenger indicates to be picked up at an easily recognizable point or that he has made a photo available or information regarding easier identification of his house. Further information regarding the passenger to be transferred includes information regarding baggage or any disabilities.

In alternative embodiments, it is also possible to include such information when offering the ride, so that the driver can take this into account. Furthermore, it is possible for both a driver and a passenger to enter certain preferences with regard to the desired match in a preferred profile. An advantage of this is that people are only linked to persons or vehicles that meet these preferences.

The driver then drives to the pick-up point, where he picks up the passenger. When this happens, it is sent to the central server by means of a communication according to step 306 so that it is known when and where the passenger was picked up. A further communication according to step 306 is a message sent from the car navigation system to the central server regarding passenger drop-off. Furthermore, if desired, it is possible to send interim reports regarding the progress of the trip. It is possible here to return to step 302 if, for example, the central server tries to allocate an additional passenger to the driver or his car.

After the passenger has been dropped off, the procedure will end or return at the start, so that any other passengers can be assigned. In accordance with the profiles mentioned above, it is possible that a driver indicates that he wants to take a maximum of one passenger, for example. Such information can be entered along with the initial input.

In FIG. 4 shows an embodiment of a method for an apparatus for requesting a passage for a passenger. The method starts in step 400. In the present embodiment, use is made of a mobile device such as a mobile phone or a PDA. In a similar manner, however, use can be made, for example, of an information pillar in a public place or a computer with an internet connection and / or a web browser in a public place or a residential house.

In step 401, a travel request with at least a passenger identification, a pick-up point and a drop-off point is transferred from the mobile device to the central server. If at any subsequent time the central server can make a match between this request and the offer, the central server will send a passage offer to the passenger's mobile device. In step 402, this message is received by the mobile device, and in step 403, the passenger enters the mobile device to accept the journey with the associated driver information.

In step 406, the message regarding the acceptance or non-acceptance of the ride is sent to the central server which then processes this data and attempts to make a new match if necessary.

In step 404, the mobile device then receives further detailed information regarding the driver and / or his vehicle for simplifying recognition at the time of pick-up. The passenger then successively confirms the pick-up moment and / or the drop-off moment by means of his mobile device in step 405. This gives the central server a second confirmation thereof in addition to the confirmation of the car navigation system.

If either communication is not received correctly, the central server may request a reconfirmation based on the correctly received message from either. Then, the method ends in step 407.

Similarly to the method of Figure 3, it is possible for the passenger to receive detailed information regarding the driver at the same time as the offer. In this case, receiving detailed information does not affect road safety, since when receiving the information the passenger is not driving a vehicle.

Alternatively, as described with reference to FIG. 3, it is equally possible that a driver already communicates his availability information to the central server at an earlier time than when he gets into the car before starting the journey. In such a case, the driver may use the same type of input devices as the passenger and may also receive information through those devices. A mobile device is preferred for receiving information as it is relatively more likely that a person will have it at hand when the information is sent and thereby received.

A further possibility for confirming the pick-up of the passenger by the driver is, for example, the coupling of an identification of the two. According to the present invention, the following possibilities are hereby provided. It is possible for a passenger to enter an identifier such as a smart card into a smart card reader of the navigation device. Other options for identifying a passenger and / or a driver include, for example, reading a fingerprint, entering a PIN code and / or recognizing biometric features such as face or voice.

Furthermore, it is possible that the mobile device of the passenger is coupled to the car navigation device or the mobile device of, for example, the driver. Such a coupling provides a connection method that demonstrates a direct proximity, such as a cable connection (USB), a Blue Tooth connection, a near field wireless connection, a WiFi connection and the like. Based on the presence of the passenger in the vehicle determined by such a link in either the passenger's mobile device, the driver's mobile device and / or the car navigation system, each of these devices can send a message to the central server for this confirmation.

When using a system such as the present invention it becomes possible to make the information processing and in particular the simplicity thereof as simple as possible for the users. All previously entered data regarding the persons, the pick-up points and the times can be remembered by the system and retrieved and represented for later (repeat) journeys in such a way that the users only have to indicate or click for confirmation. . For example, an entire trip including all route points and times can be clicked on or, for example, only the times can be adjusted.

In the foregoing, the present invention has been described with reference to some preferred embodiments. Different aspects of different embodiments are considered to be described in combination, with all combinations that can be made by a skilled person based on this document to be read. These preferred embodiments do not limit the scope of this text. The requested rights are defined in the attached claims.

0 3 1 9 08