WO2017068406A1 - Method and system for facilitating displacements of a set of pedestrians by means of a set of vehicles - Google Patents

Abstract

The invention relates to a method for facilitating displacements of a set (Ep) of pedestrians (P) each provided with a portable terminal (TP) by means of a set (Ev) of vehicles (V) associated or each provided with terminal (TV), this method comprising the following steps : - dispatching by pedestrians (P) of requests for rides; - dispatching by vehicles (V) or their drivers of offers of rides; - reception by a server (S) of the requests and of offers of rides, - compiling by the server (S) of a set (Ep) of requesting pedestrians (P) and of a set (Ev) of offering vehicles (V), - searching by the server (S), in respect of each of the pedestrians (Pi) of the set (Ep), for a vehicle (Vj) of the set (Ev) having a route compatible with that of the pedestrian (Pi) and formation of compatibility pairs [pedestrian (Pi); vehicle (Vj)]: - for each compatibility pair [pedestrian (Pi); vehicle (Vj) dispatching to the pedestrian (Pi); and to the driver of vehicle (Vj) requests for acceptance/refusal; this method being distinguished in that, for each compatibility pair [pedestrian (Pi); vehicle (Vj)]: - each ride request comprises fresh personal data (DFPi) relating to the pedestrian (Pi); - each ride offer comprises fresh personal data (DFVj) relating to the driver of the vehicle (Vj); and in that - the ride possibility signal dispatched to the pedestrian (Pi) comprises said fresh personal data (DFVj) relating to the driver of the vehicle (Vj); - the ride possibility signal dispatched at the vehicle driver (Vj) comprises said fresh personal data (DFPi) relating to the pedestrian (Pi).

Description

 The invention relates to a method and a system for facilitating the movement of a set of pedestrians by means of a set of vehicles. BACKGROUND OF THE INVENTION This method and system are intended in particular for urban areas.

Background of the invention

 There are known systems for connecting drivers and passengers such as the one known under the name Blablacar®. These systems require both drivers and passengers to seize, in addition to their destinations, the dates and times of their trips, and make an appointment with each other.

 It would be useful to have a more flexible and faster system that allows a pedestrian to easily find a vehicle to take him to his destination. This system would be even more interesting if it offered a driver wishing to take a passenger the opportunity to decide at the last moment and if he spared, both future pedestrian passenger and the driver, a tedious appointment.

 Various solutions have been proposed in the patent applications published under the numbers EP 1 251 475, DE 10 2009 056641, DE 10 2010 003610, WO 2007/139375, US 2008/277183, WO 2013/001553 and FR 2 908 210.

 Some of the obstacles to the development of these systems include the following:

 Too much complication: we must propose a simple solution if we want it to be used by a maximum of people, especially young people who jump from one novelty to another, or the elderly sometimes lost facing new technologies;

 a lack of responsiveness of the system!

a lack of flexibility of the system>^'for example, certain prior art systems do not provide for the case where a passenger may be taken to a fraction of the route of a vehicle;

and, certainly the biggest obstacle of all, safety: it goes without saying that it may not be reassuring to ride in an unknown vehicle driven by an unknown person, especially in the case of a driver ( man) and a passenger. Finally, it is imperative that these systems do not disturb or at least affect the normal traffic as little as possible, that they deconcentrate the drivers as little as possible in such a way as not to increase the risk of accidents, that they do not increase the consumption of fossil fuels, by not lengthening the journeys of the users, that they favor carpooling and thus reduce the number of vehicles circulating and therefore the exhaust emissions that are largely greenhouse gases.

 In addition, for such a system to be a real success, it must not involve additional costs for the driver or the pedestrian, for example by requiring them to buy devices to be able to implement this system.

Summary of the invention

 The major object of the invention is to propose solutions overcoming the aforementioned obstacles. This goal is achieved by a method of facilitating the movements of an assembly Ep of pedestrians each provided with a TV terminal, by means of a set Ev of motor vehicles V associated or each provided with a TV terminal, the terminals TP and TV having or being associated with devices for detecting their current positions GLP, GLV, this method comprising the following steps:

 pedestrian (P) requests for support requests, each request comprising at least the current position GLP and the destination (DP) of the pedestrian concerned;

^■ shipments by vehicles (V) or their drivers of takeover offers, each offer comprising at least the current position GLV and the destination (DV) of the vehicle concerned;

 - receiving by a server (S) requests and offers of support;

 - constitution by the server (S) of a set Ep of pedestrians applicants (P),

 "constitution by the server (S) of a set Ev of vendor vehicles (V),

 search by the server (S), for each pedestrian (Pi) of the set Ep, of a vehicle (Vj) of the set Ev having a path compatible with that of the pedestrian (Pi) and forming pairs of compatibility [pedestrian (Pi); vehicle (Vj)];

- for each compatibility pair [pedestrian (Pi), ^' vehicle (Vj)]:

 · Sending by the server (S) to the pedestrian (Pi) of each pair of compatibility

(pedestrian (Pi), vehicle (Vj)), a signal of possibility of assumption of responsibility and a request for acceptance / refusal of the assumption of responsibility;

 • if the pedestrian (Pi) sends to the server (S) a refusal response, return to the previous server search step (S);

 "If the pedestrian (Pi) sends a response of acceptance, sent by the server (S) to the vehicle (Vj) or to its driver, a signal of possibility of support and a request for acceptance / refusal of the assumption of responsibility;

• if the vehicle (Vj) or its driver sends a refusal response to the server (S), return to the previous server search step (S) and possibly send by the server (S) to the server (S). pedestrian (Pi) of a refusal of support signal; • in case of sending by the vehicle (Vj) or its driver to the server (S) an acceptance response, possible sending by the server (S) to the pedestrian (Pi) of a confirmation signal of taking load ^' ,

being specified that for each compatibility pair [pedestrian (Pi). ^' vehicle (Vj)]:

 - each request for care includes fresh personal data

(DFPi) relating to pedestrians (Pi);

 each offer of care includes fresh personal data (DFVj) relating to the driver of the vehicle (Vj);

 and

 the signal of the possibility of taking care of sent to the pedestrian (Pi) includes said fresh personal data (DFVj) relating to the driver of the vehicle (Vj) and possibly data relating to the vehicle (Vj), such as one or more photographs of this vehicle (Vj);

 the possibility of handling signal sent to the driver of the vehicle (Vj) includes said fresh personal data (DFPi) relating to the pedestrian (Pi).

It goes without saying that the request for acceptance / refusal could be submitted first to the driver and then to the pedestrian. However, it is better to start with the pedestrian because it is stopped and can take time, while the driver is probably already on the road, that is to say, driving his vehicle when receives a request for acceptance / refusal and should be disturbed as little as possible.

 According to a preferred embodiment, it is provided in the method according to the invention that whenever a treatment is refused, the person who has already accepted (usually the pedestrian) is informed, to avoid that she is surprised to receive a new offer of care when she has just accepted one or not to wait for a vehicle indefinitely. It goes without saying that the person who receives the second support proposal (normally the driver) can not receive a refusal.

 According to one variant, the pedestrian or the driver can deactivate generally (for example in the preferences of his account) or occasionally the step of displaying / accepting the support. This speeds up the operation of the system. Indeed, for example, a pedestrian in a hurry can skip this step in order to save time and thus accept to be supported by any vehicle with compatible route.

 According to an advantageous embodiment of the invention, the method furthermore comprises:

- a step during which each pedestrian (Pi) is taken or takes a photo with his / her terminal (TP) and the fresh personal data (DFPi) relating to the pedestrian (Pi) include this photo;

a step during which each vehicle driver (Vj) is taken or takes a picture using the terminal (TV) and the fresh personal data (DFVj) relating to the driver of the vehicle (Vj) include this picture ^• the possibility of taking charge signal sent to the vehicle (Vj) or to its driver may further include the indication of the pedestrian's gender (Pi); and

 - The possibility of management signal sent to the pedestrian (Pi) further possibly includes the indication of the sex of the driver of the vehicle (Vj).

 The photo taken by another person or by oneself (commonly called "selfie" for "self portrait photographic" or "selfie") is interesting, on the one hand, because it is taken using the terminal of the pedestrian or driver, that is to say with the terminal used to implement the process, and, secondly, because it allows the travel partner to be certain that the person with whom he will travel is the one visible in the photo.

 In addition, it allows rapid mutual recognition and therefore a rapid rise in the vehicle, which avoids too much disruption of traffic.

 According to a preferred embodiment of the invention, requests for acceptance / refusal of support are valid for a specified period; if at the end of this period, the pedestrian (Pi) or the driver of the vehicle (Vj) has not answered, it is considered that his answer is negative and there is return to the search step by the server compatibilities and compatibility couples training [pedestrian (Pi); vehicle (Vj)].

 It can further be provided that the aforesaid fixed period given to the driver is longer than that given to the pedestrian. Indeed, if the driver is driving his vehicle, it is advisable that he consults his terminal to make his decision at a time that lends itself safely, for example, when the vehicle is on the road. stop in front of a red traffic light.

The invention relates also to a displacement facilitation system a set Ep pedestrian P by means of a set of V Ev vehicles, having ^'■

 at least one terminal TP intended for a pedestrian P and comprising a device for determining its current position GLP,

 at least one TV terminal intended or associated with a vehicle V and comprising a device for determining its current position GLV, and

 an S server,

and wherein:

 the terminal (s) / TP and the terminal (s) / TV are capable and configured to communicate wirelessly with the server S;

 the server S is adapted and configured to communicate wirelessly with the terminals TP, TV;

 the different configurations being able to implement the method according to the invention.

According to another aspect, the invention relates to a method for determining the compatibility of the IP route of a pedestrian P equipped with a portable terminal TP with the route IV of a vehicle V equipped with a terminal TV, with a view to the latter taking over the pedestrian P, comprising the following steps: pedestrian P input or dictation of its destination DP to its terminal TP or reading by this terminal of a code corresponding to the destination DP;

^■ determining by the terminal TP of the current position of GLP;

 sending by the terminal TP of the destination DP as well as from the current position GLP to a server S;

^■ input or dictation by the driver of the vehicle V to the TV terminal of the destination DV of the vehicle V or reading by this terminal of a code corresponding to the destination DV;

 determination by the TV terminal of its current position GLV;

 sending by the TV terminal of the destination DV as well as the current position GLV to the server S;

^■ reception by the server S of the current positions GLP, GLV and DP and DV destinations of the pedestrian P and the vehicle V;

^■ calculation by the server S, for each point of the route IV of the vehicle V, the distance dO between the point considered and the pedestrian P and comparison of this distance dO with a predetermined maximum distance dmax

^■ if for all the points, the distance dO is greater than dmax, there is incompatibility of the routes IP and IV ', possible sending by the server S to the terminal TP and / or the terminal TV of a signal of absence of compatibility

 if, for at least one point, the distance d0 is less than or equal to dmax:

 · Calculation by the server S of the distance dl between the destination DP and the destination DV and comparison of this distance dl with dmax;

 • if dl is less than or equal to dmax, there is compatibility (of type l) of IP and IV routes;

 • if dl is greater than dmax,

 ■ calculation by the server S, for each of the points of the IV route, the distance d2 between the point in question and the DP destination and comparison of d2 with dmax;

 ■ if, for all the points, d2 is greater than dmax, there is incompatibility of the IP and IV routes;

 If, for at least one point, d2 is less than or equal to dmax, there is compatibility (of type 2) of the IP and IV routes, this point is stored as PTmin.

The route of the vehicle V between its current position GLV and its destination DV can be calculated by the server S. It is expected that the server S calculates several routes, for example the shortest in distance but not necessarily in time and the fastest but not necessarily the shortest, and asks the driver of the vehicle V to choose the one he prefers. It can also be envisaged that the driver communicates to the server S the points (streets, intersections, buildings, etc.) through which he wishes to pass. It is furthermore preferable that at least one vehicle supports several pedestrians and forms a pair of compatibility with each of them.

According to yet another aspect, the subject of the invention is a method for managing the connection of a vehicle V with a pedestrian P whose destination DP ^:

- is identical to the destination of the vehicle V or DV is removed at most a predetermined maximum distance dmax of travel DV ^'or

 is at a point PTmin of the vehicle V route IV or is at most a predetermined maximum distance dmax of a point PTmin of this route, the pedestrian P being equipped with a portable terminal TP and the vehicle V being equipped with a TV terminal, these terminals TP, TV comprising or being associated with devices for determining their current positions GLP, GLV, this method comprising the following steps:

- Determination by the terminal TP of its current GLP position and sending this position to the server S>^'

^■ determination by the TV terminal of the current GLV position and sending this position to an S server;

^■ reception by the server S of the current positions GLP and GLV;

 calculation by the server S of the current distance d3 between the vehicle V and the pedestrian P,

^■ comparing the distance d3 to a predetermined maximum distance da ^'

^■ if d3 is greater than da, return to the previous steps;

 ■ if d3 is less than or equal to da,

 • sending by the server S to the TV terminal a stop signal of the vehicle V; preferably, this signal includes fresh personal data relating to pedestrian P;

 • sending by the server S to the terminal TP of a signal inviting the pedestrian to join the vehicle V and to climb into it! preferably, this signal includes fresh personal data relating to the driver of the vehicle V as well as preferably data relating to the vehicle itself, advantageously, his picture!

^■ sending by the terminal TP to the server S a vehicle up signal and / or sent by the TV terminal a pedestrian rise signal,

 sending the TV terminal from its current position to the server S,

^■ in the case where the destination of the vehicle DV is identical or different to the maximum of dmax of the destination of the pedestrian DP (compatibility of type l), comparison by the server S of the current position of the vehicle V with the destination DV, in case difference, return to the previous step of sending by the TV terminal to the server S of its current position; if there is identity, possible sending by the server S to the TV terminal and possibly to the terminal TP of an arrival signal at destination;

^■ in the case where the destination of the pedestrian DP is at a point PTmin of the route IV of the vehicle V or distant from dmax at most of a point PTmin of this route (type compatibility 2), comparison by the server S of the current position of the vehicle V with the position PTmin, ^' if there is equality, sending by the server S to the terminal TV a stop signal for pedestrian descent and possibly to the terminal TP of an arrival signal at destination; if not return to the previous step of sending by the TV terminal to the server S of its current position!

Possibly, sending by the terminal TP to the server S an end of transport signal and / or sending by the TV terminal to the server S an end of transport signal.

 It goes without saying that during all this management of the connection, the driver of the vehicle must follow the route calculated by the server S and that he has chosen if any of other proposed routes.

 It is therefore preferable that after the calculation of the route by the server S and possibly its choice by the driver, the server S sends this route to the TV terminal so that it can display it permanently, except perhaps when the pedestrian's fresh personal data is displayed on the terminal screen. Of course, this route can also be communicated orally by the server S via the TV terminal. The server S can handle the movement of the vehicle V to its destination DV in the same way as the commercial GPS guidance systems.

 The stopping distance da may be the predetermined maximum distance dmax, especially when the system is intended to be used in a substantially urban area.

 According to a variant intended rather for non-urban areas where vehicles travel faster, the stopping distance da is that which is calculated generally and roughly for a motor vehicle and which is equal to the square of the number of tens of the speed of the vehicle. vehicle expressed in km / h. Thus, for a vehicle Vj moving at a speed VITj, da is equal to (VITj / 10) x (VITj / 10), or for a car traveling at 90 km / h, da is roughly 81 m. As this is an approximate speed is usually high because it is normally a rather abrupt stop, it is likely that the vehicle requires a greater distance to stop. Since da is measured from the pedestrian's position, this means that the vehicle will overtake the pedestrian. Nevertheless, unless the pedestrian has chosen a value for dmax much lower than the default value of 50 m (as we will see later), the vehicle will still stop at a distance from the pedestrian which will be lower. to dmax. The basic condition, that the pedestrian does not have to walk a distance greater than dmax to reach the vehicle, will therefore remain full.

 Thanks to the relationship management process, the task of the driver is not complicated by the presence of a passenger. He does not need to memorize the address where he must take care of the pedestrian or the address where he must deposit it. He can therefore remain focused on his driving, which is particularly interesting when the driver is distracted, has trouble remembering addresses or does not know the place well.

Moreover, the use of fresh or recent personal data, such as a "selfie", is particularly advantageous because it greatly facilitates mutual recognition when meeting future travel partners or "carpoolers". Indeed, if we used a non-recent photo, some traits of the person may have changed since, including, cutting and / or hair color, the presence / absence of a beard, tanning, makeup, wearing a scarf, a cleavage, a tattoo, etc.

 The fresh or recent personal data are therefore data that date from the moment of the request for the formation of the request for support by a pedestrian and the moment of the request for the formation of the offer of care by a driver . This data does not normally vary between the moment of the request / offer of care and meeting or actual connection of the pedestrian and the driver. This gives them a reassuring or reassuring role.

 As fresh personal data, in addition to photos or "selfies", we can also mention moving pictures that are in fact successions of images generally in the format ".gif" and that we will now call "gifies", as well as than videos, preferably of short duration, the videos having the advantage of having in principle sound.

 According to a preferred embodiment, the method of management of the connection comprises the sending by the terminal (TP) to the server (S) of an end of transport signal and the sending by the terminal (TV) to the server (S) of an end of transport signal and these shipments are accompanied by an evaluation ECj of the driver of the vehicle (Vj) by the pedestrian (Pi) and an evaluation EPi of the pedestrian (Pi) by the driver of the vehicle (Vj).

 According to an advantageous embodiment, it is furthermore provided:

 ■ the calculation by the server (S) of an average of the evaluations of the driver of the vehicle (Vj) to obtain an overall average rating EMCj of the driver, the incrementation of 1 of the number of transports he has made and the storage of these informations ; and

 - The calculation by the server (S) of an average of the pedestrian evaluations (Pi) to obtain an overall average rating EMPi of the driver, the incrementation of 1 of the number of transports he has benefited from and the storage of this information.

 According to another advantageous embodiment, for each compatibility pair [pedestrian (Pi); vehicle (Vj)]:

^■ each supported possibility of signal sent to a pedestrian (Pi) comprises the overall average evaluation EMCj of the vehicle driver (Vj) and preferably also the number of transports already carried out and on the basis of which the overall average evaluation EMCj has been calculated;

^■ each supported possibility signal to the vehicle operator (VJ) comprises the overall average evaluation Empi pedestrian (Pi) and preferably also the number of transports including the pedestrian (Pi) received and on the basis of which this overall average EMPi rating was calculated.

The use of evaluations - is also very interesting because the decision making of a human being generally a part of rational and irrational, taking into account its two aspects allows a better choice for the user. So the rational aspect here is the mathematical average of the previous assessments and the irrational aspect can here correspond to the desire or not to travel a person having a certain facies or a certain outfit.

 This combination of rational and irrational, or even intuitive, gives the user the impression of making the right decision about his partner trip.

 We can even refine the decision making by distinguishing between the sexes of people. Concretely :

 for each vehicle (Vj), each evaluation ECj and each end of transport signal received by the server (S) are stored by the latter in relation to the sex of the pedestrian (Pi) which has just been transported and the server (S) calculates an average of the evaluations assigned for EMCFj women's transport and / or an average of the evaluations received for the transport of EMCHj men;

 for each pedestrian (Pi), each evaluation EPi and each end of transport signal received by the server (S) are stored by the latter in relation to the sex of the driver of the vehicle (Vj) which has just transported it and the server (S) calculates an average of the evaluations received for journeys with EMPFi drivers and / or an average of the evaluations received for journeys with EMPHi drivers;

 and in which

 each opportunity signal sent to a pedestrian (Pi) includes

 o the average of the evaluations received by the driver of the vehicle (Vj) for the transport of women EMCFj and preferably also the number of women's transport carried out and / or

 o the average of the evaluations received for the transport of men EMCHj and preferably also the number of men's transports carried out;

 o as well as possibly the overall average EMCj assessment of the driver of the vehicle (Vj) and possibly the total number of transports already carried out! each carry option signal sent to a vehicle (Vj) or to its driver includes

 o the average of the pedestrian (Pi) evaluations for journeys made with EMPFi drivers and preferably also the number of trips made with women and / or

 o the average of the evaluations received for trips made with EMPHi drivers and preferably also the number of trips made with men!

 o as well as possibly its overall average EMPi pedestrian (Pi) assessment and possibly the total number of transports the pedestrian (Pi) has benefited from.

Distinguishing between the assessments provided by women and those provided by men makes it possible to refine the selection of the travel partner, taking into account, in particular, that some men do not have the same behavior as they are in the presence of a man or a woman. At the beginning, when a pedestrian (P) or a driver of a vehicle (V) registers, if the system plans to send his or her evaluations to his potential travel partner, he is assigned by default an average mark to this pedestrian (P) or driver. For example, if the possible assessments are ^:

 0: execrable, to avoid

 1: frankly bad

 2: rather bad

 3 way

 4: good

 5 ■ excellent,

 By default, the value of 3 is assigned to the pedestrian or driver who registers and will therefore use the system for the first time. In any case, if the number of transports is indicated, the travel partner will understand that it is a value that is based on the assumption that the person behaves correctly, which is normally the case for most people. .

 Of course, it can be expected that the driver indicates if and how many people travel with him. In this case, the system may ask him to take a picture of these people to display them simultaneously or sequentially on the pedestrian terminal so that he may or may not agree to travel with the driver and all his companions.

 It goes without saying that if it is people who have been supported by previous implementation of the method according to the invention on the same path of the vehicle, it can be expected to display in addition to the photos of these people, their evaluations as indicated above.

 The method may also include a step of archiving data relating to each transport.

 If we assume that the pedestrian is not moving, we can predict that his terminal TP sends only once his current position and that the step of

^■ determining by the terminal (TP) of the current position of the pedestrian (P) and sending this position to the server (S), ^'

 takes place only once.

 So for the second stage and the following stages of

^■ calculation by the server (S) of the current distance (d3) between the vehicle (V) and the passenger

(P),

 we use the previous position which is normally the initial position of pedestrian P.

This prevents the terminal TP from continuously sending its current position and prevents the server S from searching for this current position in the passenger base. The server then performs fewer operations and saves a little time.

The invention thus offers a pedestrian the possibility of being taken by car to his destination in a very simple and fast manner. Similarly, any driver can at any time offer a free seat to a passenger, or even several seats free to as many passengers.

 The invention is in a way a new type of carpooling in a modern form of autostop and retains its simplicity. Indeed, it allows the management of the movements of pedestrians (P) and vehicles (V), so that pedestrians (P) and drivers of vehicles (V), as human beings, execute themselves. same, physically, the following steps only:

^■ a single prior step, for each pedestrian (P) and for each vehicle (V), registration respectively in a registered pedestrian base and a registered driver base then

^■ for each pedestrian (P), at least one, preferably more than one, ideally a plurality of repetitions of all of the following steps only, one way:

 Launching a program capable of implementing the method according to the invention;

 · Possibly personal identification

 • communication of its destination (DP)

 • communication of fresh personal data, such as a photographic self-portrait;

• possibly, refusal of one or more proposals of assumption of responsibility; · Acceptance of a care ^' ,

 • confirmation of the climb in a vehicle (V);

 • communication of the end of the transport;

 • possibly evaluation of the driver of the vehicle (V);

 for each vehicle driver (V), at least one, preferably more than one, ideally a multitude of repetitions of all the following steps only, one way:

 Launching a program capable of implementing the method according to the invention;

 possibly personal identification

 · Communication of its destination (DV);

 communication of fresh personal data, such as a photographic self-portrait;

possibly refusal of one or more proposals for care>^' acceptance of care

 · Confirmation of a pedestrian (P) climbing into the vehicle (V);

 possibly, communication of the end of the transport and

possibly, pedestrian evaluation (P). The rest of the operations are performed by the server (S), the terminal TP and the TV terminal, so that most of the operation of the system is invisible to the user and above all, the latter does not have to to occupy.

 Other features and advantages of the invention will now be described in detail in the following description which is given with reference to the appended figures, which schematically represent:

 - Figure 1: a system according to the invention for facilitating the movement of a set of pedestrians by means of a set of vehicles;

 FIGS. 2 and 3 are diagrams illustrating, respectively, the possibility and the impossibility of taking charge in a first case;

- Figures 4 and 5 · ^' diagrams illustrating, respectively, the possibility and impossibility of support in a second case!

^■ Figure 6 and 7: diagrams illustrating, respectively, the possibility and impossibility of a support in a third case>^'

 FIGS. 8 and 8bis: an example of a program flow diagram comprising the essential steps of the principle of determining the compatibility of destinations and routes;

 FIGS. 9 and 9bis: an example of a program flow diagram comprising the essential steps of the principle of connecting a pedestrian with a vehicle

^■ figure 10 ■ an example of a program flow chart describing the steps in the operation of a website, including the prior registration of pedestrians or drivers, so that they can use the invention

^■ Figures 11 and ^llbis: an exemplary flowchart of a program for managing the operation of the terminal of a pedestrian in order to implement the invention;

^■ ■ Figures 12 and 12a an example of flowchart of a program for managing the operation of the terminal of a vehicle or of a driver in order to implement the invention ^'

 FIGS. 13 to 13 are parts of an example of a program flow diagram comprising the essential steps of the method according to the invention for facilitating the movement of pedestrians by means of vehicles.

Detailed exposition of the invention

The system for facilitating the movement of a set of pedestrians by means of a set of vehicles according to the invention is illustrated in FIG. 1, on which we can see a server S communicating via the Internet network with vehicles VI, V2, V3 and V4 and pedestrians PI, P2 and P3. Basic principles

 At least three elements are necessary for the invention to be implemented. It is a pedestrian P wishing to become a passenger, a vehicle V wishing to carry a passenger and a server S to put them in relation.

 Each pedestrian P must be provided with a terminal TP which is preferably provided with a device for determining its current position GLP and able to communicate with the server S to transmit information to it. In a variant, it may be envisaged that pedestrian P uses a terminal devoid of said device. In this case, the pedestrian P will have to enter his address and it can be transformed into current position by the terminal TP and sent to the server S, unless it is responsible for transforming the address in current position.

 Similarly, each vehicle V must be equipped with a TV terminal equipped with a device for determining its current position and capable of communicating information to the server S. The TV terminal may be part of the onboard electronics of the vehicle where may be the TV terminal of the driver of the vehicle V.

 The TP and TV terminals can have smartphones such as those marketed under the names SmartPhone®, iPhone®, etc., tablets such as an iPad®, an Android® tablet, etc. These devices have a powerful microprocessor enabling them to execute complex programs contained in their high capacity memory and various electromagnetic wave communication modules (radio, radiotelephone, mobile phone, 3G or 4G data transmission network, etc.). via a network such as the Internet. In addition, they have the advantage of being generally equipped with a geolocation system of the GPS type.

 As for the server S, it may be a computer with at least one high-capacity memory and at least one powerful microprocessor allowing it to execute complex programs. It comprises or is connected to a communication module able to communicate with the terminals TP and TV by electromagnetic waves (radio, radiotelephone, mobile phone, 3G or 4G data transmission network, etc.) possibly via a network such as the Internet. Preferably, the system used is that allowing the faster data transmission.

Determination of the possibility of taking care of a pedestrian P by a vehicle V

 This possibility of support can in fact also be called "compatibility of the routes of the pedestrian P and the vehicle V".

 For a vehicle V to support a pedestrian P future passenger, it is still necessary that he can first physically meet this pedestrian P, and normally without changing his route.

Several cases can then be considered. They are shown diagrammatically in FIGS. 2 to 7, in which a pedestrian P wishing to travel to his destination DP and a vehicle V wishing to travel to his destination DV are represented. Pedestrian P is supposed to be motionless to simplify the demonstration. He is willing to walk only a limited distance to reach a vehicle V or to reach his destination DP. This distance is a predetermined maximum distance called dmax. The system proposes a default distance which is for example 50 meters, but this distance depends on each pedestrian P and it can be modified. It is conceivable that an elderly person with reduced mobility does not wish to walk more than 10 meters while a student may be willing to walk 100 meters to reach a vehicle. It is therefore possible to associate with each pedestrian P its own predetermined maximum distance dmax.

 In FIG. 2, it can be seen that the route of the vehicle V passes near the pedestrian P, that is to say at a distance less than or equal to the distance d max. The vehicle V will be able to stop, when it will be close enough to the pedestrian P, to be able to take charge.

 In Figure 3, the pedestrian P is too far from the route of the vehicle V. It will always be at a distance greater than dmax with respect to the pedestrian P. It can not therefore support it.

 However, even if the vehicle V passes close enough to the pedestrian P to be able to take it on board, that does not necessarily mean that it can take it to its destination.

 Thus, in the case of FIG. 4, the destinations DP and DV of the pedestrian P and the vehicle V are separated by a distance less than d max. Vehicle V can therefore carry pedestrian P.

Once the vehicle V arrived at its destination DV, the ex-pedestrian passenger P must become pedestrian and walk a little, for a distance less than dmax, to arrive at its destination DP. The case where DV and DP destinations are identical or distant from a distance less than or equal to dmax is defined as compatibility type 1.

 In the case of FIG. 5, the destination of the pedestrian P is different from that of the vehicle V and it is distant from a distance greater than dmax. In this case, the pedestrian P can not be supported by the vehicle V, otherwise he should walk a distance longer than he is willing to accept.

 Figures 6 and 7 are diagrammatically two other cases. In the case of FIG. 6, the destination DP of the pedestrian P is remote from that DV of the vehicle V, but it is situated at a distance less than dmax from a point PTmin of the vehicle V-IV route. This means that the vehicle V can drop the pedestrian P near its destination DP, it will just stop along the way. The point PTmin will then be memorized by the server S. Then, once the vehicle is at the point PTmin, it will have to stop so that the pedestrian P can descend and reach its DP destination by walking a distance less than dmax. The case where the pedestrian DP destination is on the IV route of the vehicle V or a point PTmin distant from a distance less than or equal to dmax of this route is defined as the compatibility type 2.

On the other hand, in the case of FIG. 7, no point in the vehicle's route passes sufficiently close to the pedestrian's DP destination. This means that although the initial position of the pedestrian P is quite close to the route of the vehicle V so that it can do so the DP destination is too far from this route for the pedestrian to be sufficiently close by the vehicle V.

 An example of a flow chart detailing the steps for the server S of the principle of determining the compatibility of the routes is shown in FIGS. 8 and 8bis.

Connecting the pedestrian P with the vehicle V

 If it turns out, on the one hand, that the pedestrian P can be supported by the vehicle V and, on the other hand, that it can take him to his destination DP or drop him close to this, the system can then send a signal of possibility of support at the same time to the pedestrian P, to inform him that he can and will be taken to his destination DP or close to it and he also sends a signal of possibility of support to the vehicle P, so that it knows that it will have to stop to let pedestrian P.

 Preferably, the signal specifies whether the vehicle V must take the pedestrian P to its destination DV (type I compatibility) or if it must deposit it at an intermediate location PTmin located on its route IV (compatibility type 2) .

The connection of the pedestrian P with the vehicle V is preferably carried out in the following manner ^.

 the server S calculates the current distance d3 between the vehicle V and the pedestrian P,

- then he compares this distance d3 to dmax>^'

 if d3 is greater than dmax, this means that the vehicle V is still too far from the pedestrian

P to be able to take charge of it; the server S must therefore return to the previous step of determining d3!

 - and so on until d3 is less than or equal to dmax, in this case

 The server S sends the terminal a stop signal to inform the driver that he must stop the vehicle V;

 At the same time, or just before, or just after, the server S sends the terminal TP a signal of support to invite the pedestrian P to ride in the vehicle V after possibly walking if necessary to a lower distance or equal to dmax;

the pedestrian P then activates the keyboard and / or the screen of its terminal TP and / or vocally informs it, so that it sends a signal of rise in the vehicle to the server S to inform it that taking charge has taken place,

 and / or the driver of the vehicle V actuates the keyboard and / or the screen of the TV terminal and / or vocally informs the latter so that it sends a pedestrian signal to the server S to inform it that the care took place,

 - Then the TV terminal regularly sends its current GLV position to the server S> '

- in case of type 1 compatibility, the server S compares the current position of the vehicle V to the destination DV, if the difference is less than or equal to dmax, the server sends a stop signal to the vehicle V so that it stops and lets down the ex-pedestrian passenger P and the driver also descends in principle from his vehicle; the passenger P then activates his terminal TP so that it sends an end of transport signal to the server S and / or the driver actuates the TV terminal for it to send an end of transport signal to the server S;

 in the case of type 2 compatibility, the server S compares the current position of the vehicle V with the point PTmin; if there is a difference, then it waits for a new current position of the terminal

TV; if there is identity between the current position and the PTmin point, the server S sends a stop signal to the TV terminal so that the driver knows that he must stop his vehicle V to let down the passenger P; alternatively, it can be provided that the server S measures the distance between the current position of the vehicle and PTmin and as soon as it is below a certain threshold, it already sends the stop signal, this is preferable if one considers that the vehicle V can drive fast and that it needs a certain distance to stop;

 - After descent of the vehicle V, the passenger P can operate the keyboard and / or the screen of its terminal TP and / or vocally inform it, so that it sends to the server S an end of transport signal;

and / or once the pedestrian has gone down, the driver P can actuate the keyboard and / or the screen of his terminal TP and / or vocally inform it, so that he sends to the server S an end of transport signal .

 An example of a flowchart detailing for the server S the steps of the connection principle that has just been explained is shown in FIGS. 9 and 9bis.

Example of realization

 The server includes or has access to one or more memories that may contain in particular:

a database of registered pedestrian users, with personal data of pedestrians, these data being able to include, the identity (name, first name ...), sex, the predetermined maximum distance dmax desired, the refusal to travel in the company of a smoker or animal (dog, cat, ferret, etc.). ^'Possibly payment data such as the credit card number or Skype® account ID;

 - a registered user base with

o Data relating to these drivers, these data may include personal data of drivers, such as identity (name, first name ...), sex, being a smoker, the usual presence of an animal ( dog, etc.); o vehicle data, such as one or more photos (for example, front, back, side, perspective, etc.), vehicle type, model, color, license plate, number of people that the driver is arranged to simultaneously support ^' o data relating to the receipt of fees, for example, bank details or a Skype® account identifier, and the sum of the transportation distances traveled;

 a base of claiming pedestrians, with their initial positions and destinations and fresh personal data relating to these pedestrians, such as their "selfie";

 a base of service provider drivers, with their initial positions and destinations and fresh personal data relating to these drivers, such as their "selfie";

 - a basis of compatibility couples;

 a passenger base, that is to say, pedestrians who have just been associated with a vehicle and will be taken care of or are already in charge; this database contains information relating to the current positions GLP, to the signals transmitted by the terminals TP;

 - a carrier base, ie vehicles which have already been associated with one or more pedestrians and who will take care of them or have already taken charge of them> this database contains information relating to GLV current positions , to the signals transmitted by the TV terminals;

 possibly a geographic memory provided for calculating routes and / or containing the location coordinates of certain destinations.

 The central processing unit or the microprocessor of the server can regularly update the passenger base and the base of the drivers or leave this task to a coprocessor.

The server S is preferably able to receive at least the following signals ^:

 - Request Request signal from a PT pedestrian terminal;

 supply offer signal from a vehicle TV terminal or vehicle driver;

 vehicle climb signal from a pedestrian PT terminal! end of transport signal from a pedestrian terminal TP!

 - possibly a rising signal of a pedestrian from a vehicle TV terminal; possibly a rising signal of a pedestrian coming from a vehicle TV terminal; possibly end of transport signal from a vehicle TV terminal; possibly end of transport signal from a pedestrian terminal TP.

 These signals have in principle a coded form allowing the server to distinguish them and store them in the bases to which they correspond.

 The server S is preferably capable of transmitting at least the following signals:

a possibility of support signal for a pedestrian PT terminal including fresh personal data relating to a driver; Possibility of support signal for a vehicle TV terminal, including fresh personal data relating to a pedestrian and possibly an indication of compatibility type 1 or 2;

signal, intended for a pedestrian (or a driver) refusal of support by a driver (or respectively a pedestrian), ^'

 an invitation signal, intended for a pedestrian terminal TP, to invite the latter to get into a vehicle;

of pedestrian mounted stop signal for a vehicle TV terminal, so that the driver stops the vehicle in order to allow mounting a pedestrian ^'

 a passenger descent stop signal, intended for a vehicle TV terminal, for the driver to stop the vehicle in order to let a pedestrian go down;

 possibly arrival signal destined for a vehicle TV terminal for the driver to stop his vehicle;

possibly signal of arrival at destination intended for a pedestrian terminal TP, so that it descends from the vehicle carrying it. ^'

 possibly a signal of lack of compatibility for a vehicle or pedestrian.

 These signals can also be encoded. Registration of pedestrians and drivers

 The registration of pedestrians and drivers can be done by means of a computer or terminal connected to the Internet and accessing a website relating to the invention.

 Once on the site, the pedestrian or driver either register by choosing either a registration as a pedestrian user or as a driver user.

 He therefore chooses an identifier and a password in order to create a pedestrian or driver user account, then enters the aforementioned information that is intended to feed the registered pedestrian base or the base of the registered drivers.

 Alternatively, the pedestrian or driver user can register by means of its terminal TP or TV, by opening the Web browser of his terminal to go to the website of the invention or by opening an application reading a QR code returning to the website of the invention, to then download an application intended to implement the method according to the invention in cooperation with the server S. It can also go to a platform for downloading applications such as the platforms known under the names App store®, Google® Play Store, Windows Store®, etc.

When the application is first opened, the application invites the pedestrian or driver user to proceed with registration in a manner similar to what it could do on the website relating to the invention. When registering, the pedestrian user can choose between several pedestrian user formulas, including a subscription allowing him to use the system according to the invention for a fixed period, or a purchase of transport units.

 Payment may be made by means of a credit card payment module, or by means of a Paypal® account, or by any other appropriate means.

 As for the user driver, he can choose to receive a contribution to transport costs. He then enters his bank details, his e-mail address for the Paypal® system, etc., according to the payment modules available.

 In addition, a verification or validation of the identity of the pedestrian or the driver may be provided, for example, by crossing the personal data with that of another system or of another website, as for example the Airbnb® app by referring to the Linkedln® or Facebook® site.

 The registration is then completed and the pedestrian or the driver has a user account.

 An example of a flow chart detailing the steps of the prior entries is shown in Figure 10.

Common use - Travel management principle

 The invention is implemented optimally when the pedestrian or driver user has downloaded and installed on its terminal TP or TV an application implementing the invention.

 The user launches or opens the application. Depending on the configuration he has chosen, he can enter his username and password. The system recognizes it and immediately determines if it is a pedestrian or a driver and the application goes into the corresponding mode, pedestrian or driver.

 Of course, the user may have configured his application to have to retype every time his password, or to have nothing to grasp.

 The pedestrian or driver user then enters or dictates his destination DP or DV and provides fresh personal data about him, for example by simply doing a "selfie".

 One of the strong points of the invention is that the user then has little more to do, apart from accepting / rejecting the support offered to him.

Application in usual pedestrian mode

The application controls the pedestrian terminal TP to send a request for support signal to the server. That normally includes the user's identifier, current position, destination and fresh personal data, for example, a "selfie" that he has just made. If the pedestrian user uses the subscription formula, the server checks whether the pedestrian user subscription has expired or not. If so, the server S sends to the terminal TP a proposal to renew the subscription and a proposal to switch to the transport unit formula, indicating the minimum number of transport units to be purchased. has just calculated from the GLP home position and the DP destination. The server S then manages the communication with the terminal TP necessary for payment (payment module, etc.). When purchasing transport units (UT), it checks that the number of transport units purchased is greater than or equal to the minimum number mentioned above. If not, he repeats the aforementioned proposals.

 If the pedestrian user uses the transport unit formula, the server calculates the distance between the pedestrian GLP home position and its DP destination and the minimum number of transport units. It then compares this number with the number of transport units remaining on the user's account and, in the event of inferiority, offers the user to buy back units, indicating the minimum number he has just calculated. It checks that the number of transport units purchased is greater than the minimum number mentioned above. If not, he reiterates the above-mentioned proposal and also proposes to the pedestrian to switch to the subscription form. The server S then manages the communication with the terminal TP necessary for payment (payment module, etc.).

 The pedestrian is not supposed to move, because any movement can make him move away from the vehicle's route and he may not be able to be taken care of if he is beyond the distance dmax.

 Nevertheless, it can be expected that the application manages the terminal TP so that it regularly communicates its current position to the server S.

 The terminal TP then waits on behalf of the server S for a signal of possibility of support. Once this signal has been received, it emits an audible and / or visual signal and / or a vibration intended for the pedestrian, and it displays the fresh personal data relating to the driver (photo ...) as well as possibly the evaluation (s) ( female / male) of the driver, the number of transport or the number of transports (woman / man) made. The TP terminal also displays a request to accept or decline the support and waits. If the pedestrian refuses the support, the terminal communicates the information to the server which will seek a new compatibility and propose a new driver. The pedestrian must wait for a new signal of possibility of support.

If the pedestrian accepts the support, the terminal TP communicates the information to the server and then waits for the server S to send an audible and / or visual signal and / or an invitation vibration to be mounted in the vehicle, comprising information about the vehicle (photo, color, type, model ...) and the fresh personal data concerning the driver of the vehicle (photo ... so that the pedestrian can identify both the vehicle and the driver who will take it in This information is communicated by the PT terminal in a visual, audible and / or vibrating manner to the pedestrian. of the system. Indeed, if the pedestrian finds that the data of the vehicle or the fresh personal data ("selfie" ...) of the driver are different from those which had been announced to him, it is not the right vehicle, either the driver has changed or falsified his appearance, in this case the pedestrian can simply refuse to get into the vehicle.

 The terminal TP then waits for the pedestrian to inform him, by pressing a key on the keyboard, by clicking on the screen of the terminal if it is tactile, and / or vocally, that it is well mounted in the vehicle and then sends the server S a rise signal in the vehicle.

 Then, the vehicle starts and goes to its destination DV. It then goes through the PTmin point or joins its DV destination. The pedestrian then descends normally from the vehicle. The terminal TP waits for the pedestrian to inform him, by pressing a key on the keyboard, by clicking on the screen if the latter is tactile, and / or vocally, that he has come down from the vehicle V. The terminal TP then sends the server S a pedestrian signal of end of transport.

 It can also be provided that before the pedestrian's descent, the terminal TP of the pedestrian receives from the server S an arrival signal to destination and communicates this information visually, audibly and / or vibrating to the passenger. This information will confirm the announcement made by the arrival driver of the pedestrian at its destination DP or at a distance less than dmax of it.

 The application can then close.

 An example of a flowchart detailing the steps of the pedestrian mode of the application is shown in Figures 11 and 11bis.

Application in usual driver mode

 The application controls the TV terminal of the vehicle or driver to send to the server S a support offer signal. This normally includes the user's ID, current location, DV destination, and fresh personal data, such as a selfie that he has just made.

 The application manages the terminal TP so that it regularly communicates its current position to the server S.

The TV terminal then waits on behalf of the server S for a signal of possibility of support. Once this signal is received, it emits an audible and / or visual signal and / or a vibration to the driver, to inform him that he can take someone in charge. It displays the fresh personal data relating to the pedestrian (photo ...) as well as possibly its or its evaluations (woman / man), the number of transport or the numbers of transports (woman / man) of which it benefited. The TV terminal also displays a request for acceptance or refusal of support and waits. If the driver refuses the support, the TV terminal communicates the information to the server that will inform the pedestrian, seek a new compatibility and propose a new pedestrian to the driver. In the meantime, the driver can drive and continue to drive to his destination DV. The possibility of management proposed to the driver can possibly indicate what type of compatibility it is, that is to say if the driver will have to take the pedestrian to the destination of the vehicle V, or deposit it at an intermediate point PTmin of his route.

 The TV terminal then waits for the server S to send it a sound and / or visual and / or vibratory stop signal to let a pedestrian go up, including the fresh personal data relating to the pedestrian (photo ...). These data are communicated by the TV terminal to the driver. Provision can be made for the TV terminal to emit a preferably short-range signal, for example of the Bluetooth® type, to a beacon placed on the hood of the vehicle V and emitting a particular light, green for example, so as not to be confused with other vehicles (police, ambulance, etc.). It is also possible that the TV terminal actuates the vehicle V buzzer or the headlights of the vehicle (call lights, hazard lights ...), so that the pedestrian P can locate it.

 Since the vehicle V is at a distance less than or equal to dmax of the pedestrian, it has no difficulty in locating it.

 Thanks to the pedestrian-friendly personal data provided by the S server, the driver can make sure he is the right person. For example, if the photo of the pedestrian does not correspond to the one that was communicated during the proposal to take charge, there must be an error or a trap and the driver can not unlock the doors of his vehicle.

 The TV terminal then waits for the driver to inform him, by pressing a key on the keyboard or by clicking on the screen of the terminal if it is tactile, and / or vocally, that the pedestrian is mounted in the vehicle then it sends to the server S a conductive signal of support.

 Then, if one is in the case of type 1 compatibility, the TV terminal expects from the server S a stop signal to let down the passenger. The TV terminal then communicates this information in a sound, visual and / or vibrating manner to the driver.

 Optionally, the TV terminal waits for the driver to inform, by pressing a key on the keyboard or by clicking on the screen if the latter is tactile, and / or vocally, that the pedestrian is down. The TV terminal then sends the server S an end of transport signal.

 If the compatibility is of type 2, the vehicle V not having arrived at destination, it can still take a new passenger. The TV terminal therefore returns to the waiting step of a signal of possibility of support that the server S can send him or possibly a destination signal to destination. In this case, it communicates this information visually, audibly and / or vibrating to the driver and closes the application.

Of course, if the vehicle is intended to carry a second person, the TV terminal can receive, before having deposited the first passenger, a second signal of possibility of taking care to take this second person to its destination DV or at an intermediate PTmin point. As for the first person, the vehicle can accept or refuse this second support. If accepted, the S server processes then parallel the care and transportation of the ^2nd passenger in the same way as if it were a first passenger. It goes without saying that this second passenger does not necessarily have the same type of compatibility as the first passenger and that he can even, if necessary, go down before the first passenger.

 The same applies if the vehicle can carry a third passenger or other passengers.

 It is obvious that after depositing a passenger, the driver can close his application if he no longer wants to carry passengers.

 An example of a flowchart detailing the steps of the driver mode of the application is shown in Figures 12 and 12bis.

Overall operation of the S server

 The server S can operate both in an enrollment management mode for pedestrian users and in the driver and in a traffic management mode, these modes can operate successively or in parallel.

Registration Management Mode

 Once started, the server S can wait for the arrival of a request for registration of a pedestrian P. It then communicates with the terminal TP of the pedestrian P to receive pedestrian information and payment. It then stores pedestrian data P in the registered pedestrian base P.

 Then the server S waits for the arrival of a request for registration of a vehicle V. It then communicates with the TV terminal of this vehicle to receive information about the driver of the vehicle and banking information or Paypal®. It then stores the data relating to the vehicle P and its driver in the database of registered drivers.

 The details of the execution of pre-registration have already been described previously and illustrated by the flowchart in Figure 10. Traffic Management Phase

 The server S waits to receive a request for support from a pedestrian P, each request comprising at least the initial position GLP of the pedestrian, or rather, its terminal TP, and its destination DP.

Since this is a request for care, this means that the pedestrian P is already in the registered pedestrian base P. The server S then consults this database to find out if its subscription is still valid or if he still has transport units. If not, it manages the communication with the pedestrian terminal Tp, to allow it to have access to the system again, either by renewing its subscription or by purchasing transport units. The server S then stores the pedestrian P in its pedestrian base P applicants for support.

 The server S waits to receive a request for an offer of support from a vehicle V, each offer comprising the current GLV position of the vehicle, or rather of its integrated TV terminal (or belonging to the driver), as well as the DV destination of the V vehicle.

 Since this is a request for an offer of care, this means that the driver and his vehicle V are already in the base of the V vehicles registered.

 The server S then stores the vehicle V in its base of the vendor offering vehicles.

 By repeating these operations as it receives requests and offers of support, the server S feeds the corresponding bases.

 This way of feeding the basics of claimants and providers of support is illustrated by the flow chart part shown in Figure 13.

 If there is already at least one pedestrian P claimant support and at least one vehicle V provider support, we can already know if there is compatibility between them.

 Then, the server S takes one by one, all P pedestrians found in the pedestrian base P claimants, and search for each of them a compatible vehicle.

 For each pedestrian P, he will examine all the vehicles present in the base of vehicles V pickup providers and see if one of these vehicles has a route compatible with him, that is to say he looks first if the vehicle V will pass close enough to the pedestrian P to stop and make it go up. If this is not possible, it means that there is incompatibility of routes, so there is no point in examining the destinations of the DP pedestrian and the DV vehicle and we can then go to the next vehicle.

 But if the vehicle V will pass near the pedestrian P, he will be able to bring it on board. The server S then determines whether it can take it to its destination DV or drop it en route, somewhere at a point PTmin of the IV route of the vehicle V.

 This compatibility determination has already been described above and illustrated by FIGS. 8 and 8a.

 The route is not necessarily straight and its calculation can be done in various ways, by accessing a geographic memory or as an electronic map provided for the calculation of routes, as we have done for a long time (see FR 2 894 364, the patent applications cited in the introduction, Google® Maps, Michelin® applications, Le Routard®, Citymapper ™, Here ™ ...) or by looking for data provided by other systems (www.route4me.com, etc. .).

If a vehicle V has a route compatible with the pedestrian P considered, the server S forms a couple with these pedestrian and vehicle, called compatibility pair (Pi, Vj), and stores this pair in the basis of compatibility couples. Pi is here the pedestrian considered, among the n pedestrians present in the base of the pedestrians seeking support and Vj is the compatible vehicle or at least the first one that server has found, among the m vehicles contained in the base of the caregiver offering vehicles.

 If no vehicle V has a route compatible with the pedestrian P, it will have to wait until a vehicle with a compatible route makes its appearance in the base of the vehicles offering pickup.

 In the meantime, the S server goes to the next pedestrian and re-examines all the vehicles, trying to find one whose route is compatible.

 Thus, for the compatibility determination, i varies from 1 to n and j varies from 1 to m.

 Once a pedestrian is part of a couple of compatibility, he is no longer claiming take charge (since he found ...) and it can be removed from the base of pedestrians seeking charge and introduced into the passenger base.

 For vehicles, the situation is a bit more complicated because a vehicle can carry or accept to carry several passengers pedestrians at the same time. If we call "1" the number of passengers' that the driver of the vehicle is willing to take care of at the same time, once a couple of compatibility has been formed by this vehicle with a pedestrian, we must decrement by 1 value of 1. It is only when 1 is zero that the vehicle can be removed from the base of the vehicles offering take-charge. The vehicle is introduced into the base of the carriers.

 Once the vehicle V has taken a passenger, if the number 1 is still greater than or equal to 1, it can take another one that it will deposit before, after or at the same time as the first passenger. It remains in the base of vehicles offering care.

 In other words, a vehicle can be present at the same time in the base of the vehicles offering care and in that of carriers.

 Thus, the server S reviews all pedestrians and all vehicles, to form, whenever possible, couples compatibility (pedestrian, vehicle).

 Pedestrians who have not found takers remain temporarily in the base of pedestrians seeking care.

 Likewise, vehicles for which the server S has found no pedestrians remain in the pedestrian base. Provisionally, because the basics of pedestrian applicants and offering drivers are regularly enriched and new compatibilities can appear.

 This way of forming compatibility pairs is illustrated by the flowchart part of Figure 13a.

 The processing of requests for acceptance / rejection of support is illustrated by the flow chart part in Figure 13bis2.

Then, for all the compatibility couples formed, the server S can manage the connections. Specifically, for each pair of compatibility (Pi, Vj), the server S becomes the intermediary of the communications between the pedestrian Pi and a vehicle Vj, as explained above. The linking principle has already been explained previously and illustrated by Figures 9 and 9a.

 Once a passenger has been dropped and his terminal TP has transmitted to the server S a pedestrian end of transport signal, the server S can calculate the corresponding transport distance that has been traveled and add it to the sum of the distances have already been in the registered driver base, in relation to the driver who has just made the transport. The new sum is then stored in the registered driver base and will be used later to pay the Pi driver.

 Once a passenger has been dropped, the pair of compatibility that it formed with the vehicle Vj, (Pi, Vj) can be removed from the base compatibility couples.

 At this stage, it can be provided that the information relating to each pair of compatibility, such as the time (date, hour, minute) of their training and the time (date, hour, minute) of their output from the compatibility pair basis stored in an archival memory, which may be consulted by the police or the judiciary in case of crime or crime, etc., or for the establishment of statistics on the functioning of the system.

The generalization of the connections is illustrated by the flow chart part of FIGS. 13ter and 13quater, since FIGS. 13 to 13quinter illustrate in fact the method according to the invention of managing the movements of a set Ep of pedestrians (P) at means of a set Ev of vehicles (V).

 The server may be configured to perform periodically, for example once a month, preferably at the end of the month and advantageously at off-peak hours, that is to say, normally in the middle of the night, a compensation of the conductors. For this, it consults the base of the registered drivers and for each driver of this base, it multiplies for example the sum of the distances traveled by a coefficient of participation to the expenses.

 The money collected during subscriptions or purchases of transport units of registered pedestrians, is normally on an account (bank or Paypal®, etc.). The server S can search the database of registered drivers the payment data of each driver and transfer, from the aforementioned account to the account of each driver, the cost contribution to the latter.

 This calculation of financial participations is illustrated by the flow chart part of Figure 13quinter.

 Of course, it is possible to provide a total free system, but it is unlikely that the system will be a great success with drivers if they do not receive a share of the costs that transportation has caused them.

Thus, in current use, that is to say once the application installed on a terminal TP and the pedestrian P inscribed, whenever it will need to be transported, it will only have open the application, enter or dictate the destination, do a "selfie", wait for a support, accept / refuse this support, and once it has accepted a proposal (and that it has been accepted by the driver of the proposed vehicle), wait for the invitation to join the vehicle that will be indicated to get in and be transported to or near its destination.

 As for the driver, in current use, that is to say once the application installed on a TV terminal and the driver registered, whenever he is willing to carry a pedestrian, he will only have to open the application, to enter or dictate the destination, to make a "selfie", to wait for a proposal to be accepted, to accept / refuse this support, and once he has accepted a proposal, to wait until he is asked to stop to get this person up, then take him to his destination DV or drop it at an intermediate location PTmin on his IV itinerary and the server S will tell him.

Variants & complements

 The pedestrian mode of the application, which preferably offers the possibility of modifying pedestrian preferences, especially the distance dmax, can also provide a distance dmaxl for the initial support and a distance dmax2 higher for the arrival at destination. It can indeed be envisaged that for a transport from a high-density urban area to a destination in a remote rural area, the pedestrian does not wish to travel a great distance in the city but is ready to walk once more. in rural area.

 The pedestrian mode of the application can also provide in its preferences a red list of drivers, so as to avoid that it is proposed to the pedestrian to travel with certain people. For example, one can imagine that a woman does not want to be taken in charge by a vehicle driven by a man, etc.

 Similarly, the driver mode of the application can also exclude certain categories of people in their preferences.

 The pedestrian or driver modes of the application can also exclude the presence of an animal (dog, ferret, etc.).

 It can also be provided that the program in pedestrian or driver mode allows a cancellation of the planned support or cancellation is performed automatically in case of abrupt closure of the program. In this case, it is desirable for the server to inform the other travel partner.

 It is possible that a passenger, for one reason or another, asks the driver to let him get off the vehicle sooner. In this case, it can be envisaged that the passenger's terminal TP can inform the server of the end of the transport before the arrival at destination, so that the driver can still be paid on the basis of the shorter trip than expected traveled jointly with the ex-pedestrian passenger.

Terminals can be made to simplify the entry or dictation of a destination, by using keywords, for example, "Tour" for the Eiffel Tower (Paris, France), "Coli" for the Colosseum (Rome, Italy). ), "Jet" for the Geneva (Switzerland) water jet, "Copa" for the Copacabana district (Rio de Janeiro, Brazil, etc.). In pedestrian or driver mode, the verification of the identifier / password pair is performed locally, that is to say at the terminal TP or TV, but it can also be expected that it is performed by the server S .

 We can also provide:

 the applications or the server S are capable of managing a module, a subroutine or an iteration for retrieving or recreating a password,

 that the terminal TPi of the pedestrian Pi allows it to modify the predetermined maximum distance dmax and send the modified value to the server S and

 that the transport distance of the passenger P by a vehicle V is memorized and, where appropriate, added to the previous transport distances, a summary being made periodically for all the vehicles V and the total distance of transport of each vehicle V during a given period serving calculation for the repair of the driver of the vehicle V concerned.

Supplement A

 a) Method of facilitating travel

In the method of facilitating the movements of an assembly Ep of pedestrians (P) each provided with a portable terminal (TP) by means of a set Ev of vehicles (V) associated or each provided with a terminal (TV) , it can be expected that the server (S), before sending a pedestrian (Pi) a signal of possibility of support, estimates the approximate time required for the vehicle (Vj) compatibility torque [pedestrian (Pi) , ^' vehicle (Vj)], to reach the pedestrian. Then, this time is integrated into the pedestrian (P) -supported capability signal.

For the estimation of this time, the server (S) calculates the distance separating the vehicle (Vj) from the pedestrian (Pi), then several scenarios can be envisaged ^.

if the vehicle is in motion, the server (S) determines, thanks to the successive positions communicated to it by the geolocation, the speed of the vehicle and then calculates the time with the distance and this speed, ^"

 if the vehicle is stationary, the server (S) assumes that the vehicle will run at an average urban speed of 50 or 40 km / h and then calculates the time! it can also be provided that the server (S) determines, using the geolocation data, whether the vehicle is located in an urban area or in a rural area; then, if it is an urban area, it calculates its time by taking an urban speed of 50 or 40 km / hour; if it is a rural area, the server can do the calculation based on a rural speed of 80 or 90 km / hour.

 The fact of indicating to the pedestrian in how long it will be taken care of allows him especially not to worry if this long may seem long.

Of course, it can be expected that the server S also communicates this time to the driver of the vehicle Vj when he offers the support of a pedestrian Pi, in particular to inform him and not to surprise him when he will ask him to stop. Furthermore, when displaying the evaluation of a pedestrian or a driver (a case described in particular in the aforementioned European Patent Application No. 15003547), it can be provided for example by clicking on an area On the screen, by pressing a key or dictating an order, a detail of the evaluations is displayed, in particular, according to age groups. In this way, a driver could, for example, have an average rating based on the assessments made by women ages 18 to 28, an average rating based on the assessments made by women ages 29 to 39 and so on.

 This would further increase the feeling of security for some people.

 Finally, in general, it can be expected that by pressing a key or an area of the screen or dictating an order, any pedestrian and any driver can cancel the support at any time. b) Method of determining compatibility

 In the method for determining the compatibility of the IPi route of a pedestrian Pi equipped with a portable terminal TPi with the route IVj of a vehicle Vj equipped with a terminal TVj, for the purpose of taking charge of by this one of the pedestrian Pi, it can be expected that the server S takes into account the movement of the vehicle Vj. Indeed, it is necessary to avoid that the vehicle Vj has already passed the pedestrian when he receives the proposal to take charge of the latter.

 If the vehicle Vj is stopped, the problem does not arise.

 But if it is in motion, then it is necessary to calculate its speed, then the time necessary to reach the pedestrian (for example as indicated in the previous paragraph) and it is preferable to take into account the decision time (acceptance / refusal of taking in charge) of the pedestrian, preferably also the decision time (acceptance / refusal of the support) of the driver, possibly the telecommunication time of the signals, possibly the processing time of the information by the server (S) and the case pedestrian and driver terminals, and preferentially provide for a time (margin) of security, especially if the telecommunications network is slow and delay the sending of messages.

 Thus, if the time required to reach the pedestrian is less than the sum of the times mentioned above, the server should conclude that the routes are not compatible.

 It goes without saying that the existence of the predetermined maximum distance dmax should also be taken into account, because by allowing a vehicle to stop after having passed the pedestrian but remaining at a distance less than dmax, support should still be possible.

 Moreover, until now, for each pedestrian Pi, the vehicles Vj were examined to see if their route was compatible, then a couple of compatibility was formed as soon as the path of a pedestrian Pi was compatible with the route of a vehicle Vj.

It goes without saying that it is possible to start with the vehicles Vj rather than with the pedestrians Pi. In other words, for each vehicle Vj, it is possible to examine one by one all the pedestrians Pi for see if their route is compatible, then form a pair of compatibility as soon as the route of a vehicle Vj is compatible with the route of a pedestrian ^" Pi.

 In any case, these ways of doing things are interesting when the server has to handle a large number of pedestrians and / or vehicles.

 However, it is possible to envisage a variant when the server has little information to process with respect to its processing capabilities. Specifically, for each pedestrian Pi, we could review all vehicles Vj, not stopping when found compatibility. One could thus have several compatibilities and therefore several compatibility couples (pedestrian Pi, vehicle Vj). These couples would be memorized as and when they were formed. Once the last vehicle Vj examined, one could then compare all formed pairs of compatibility to determine and choose the one for which the distance between the vehicle Vj and the pedestrian Pi is the smallest. The other couples would then be eliminated. This would have the advantage of offering to a pedestrian Pi the vehicle Vj closest to him and therefore the fastest support, so that he can get to his destination as quickly as possible.

 The above applies obviously also when we start by taking a vehicle

Vj and then examine one by one all pedestrians Pi.

 Nevertheless, these ways of proceeding - by choosing from several compatibility couples - multiply the tasks executed by the server and can therefore slow down it if they are too numerous because of a number of pedestrians and / or vehicles too high.

 It can then be provided that the server chooses between the two accounting torque (s) determination systems. For example, if the number of pedestrians and / or the number of vehicles exceeds a certain threshold, one goes from the mode of determination of the compatibilities slow (choice among several couples of compatibility) to the mode of fast determination (stop as soon as a compatibility is found and training only of the pedestrian couple / corresponding vehicle).

 According to another variant, the determination of the compatibility is not based only on the routes and possibly the time of reaching and the distance pedestrian / vehicle as explained previously, but it takes into account the preferences indicated at the time of the initial inscription of the pedestrians and drivers.

 Thus, once a determined compatibility, it must still comply with the requirements of the pedestrian and the driver.

 In other words, once a compatibility based on the routes (and possibly the time of reaching and the distance) determined, one must verify that it is acceptable in view of the requirements or exclusions of the pedestrian and those of the driver.

For example, if a pedestrian has registered in his preferences when registering or later, that he does not want to travel with a man, if the server finds a compatibility on the basis of routes (and possibly the time of attack and from distance), he must then review the requirements of this pedestrian. He will then see this refusal to travel with a man and finally conclude a lack of compatibility. Similarly, if, for example, the pedestrian agrees to ride in a vehicle driven by a man but is with his dog and the driver has indicated in his preferences that he refuses to carry a dog, compatibility will be discarded on the basis of the preferences or exclusions of the driver and not those of the pedestrian.

This compliance with the requirements or exclusions of pedestrians and drivers can also be verified first by the server ^'■ it can therefore before seeking compatibility based on the routes (and possibly the hitting times and distances) eliminate some refusals, as in the example above, a vehicle whose driver is a man, before moving to the next vehicle, without examining the routes.

 It goes without saying that it is desirable to examine only a minimum of requirements of pedestrians and drivers because this review of all these conditions multiplies the tasks of the server and thus slows down the operation of the entire system. .

Supplement B

 a) Method of facilitating travel

 In the methods of the aforementioned patent applications facilitating the movements of an assembly Ep of pedestrians (P) each provided with a portable terminal (TP) by means of a set Ev of vehicles (V) associated or each provided with of a terminal (TV), it is now proposed that the server (S), before sending to a pedestrian (Pi) a signal of possibility of support ■

calculates the distance between the vehicle (Vj) of the pedestrian (Pi), ^'

 if and only if this distance is greater than a predetermined distance, for example of 10 kilometers, the server (S) estimates the approximate time required for the vehicle (Vj) of the compatibility torque [pedestrian (Pi); vehicle (Vj)], to reach the pedestrian. Then, this time is integrated into the pedestrian (P) -supported capability signal.

 For the estimation of this time, the server (S) calculates the distance separating the vehicle (Vj) from the pedestrian (Pi), then, several scenarios can be envisaged:

 if the vehicle is in motion, the server (S) determines, thanks to the successive positions that are communicated to it by the geolocation, the speed of the vehicle and then calculates the time with the distance and this speed;

if the vehicle is stationary, the server (S) assumes that the vehicle will run at an average urban speed of 50 or 40 km / hour and then calculates the time; it is also possible that the server (S) determined by the location data if the vehicle is in an urban area or rural area, ^'then, if it is an urban area, it makes the calculation of time taking an urban speed of 50 or 40 km / hour; if it is a rural area, the server can do the calculation based on a rural speed of 80 or 90 km / hour. The fact of indicating to the pedestrian in how long it is going to be taken care of allows him especially not to worry if this long may seem long or to take care in the meantime so as not to sit idly by probably getting bored.

 Of course, it can be expected that the server S also communicates this time to the driver of the vehicle Vj when he offers the support of a pedestrian Pi, in particular to inform him and not to surprise him when he will ask him to stop. b) Fresh data (selfies "gifies", mini-video, etc.)

 If the driver has at least one initial passenger, once he has taken his selfie (or "gifies", mini-video, etc.), it can be expected that he can add this initial passenger and take a picture ( or make a "gifie", a mini video, etc.).

 In the assumption proposal sent to the pedestrian, the two photos (or "gifies", mini-videos, etc.) will be displayed and they will be displayed later, just before the vehicle stops to let the pedestrian , in addition, of course, at that moment, from the picture of the car.

 But the server must account for this initial passenger in his calculations, as this decreases the number of seats available in the vehicle.

 If this initial passenger is known to the system (already registered as a passenger), the system preferably also displays his evaluations and preferably also the number of transports he has benefited from.

 Similarly, it can also provide the possibility for the passenger to add at least one person and take a picture (or make a "gifie" or a mini-video, etc.) of this additional person. This is interesting for example in the case where two friends want to travel together.

 When requesting driver support, both photos (or "gifies", mini-video, etc.) will be displayed on the driver's (or vehicle's) terminal.

 If this additional person is known to the system (already registered as a passenger) the system preferably also displays its evaluations and preferably also the number of transports it has benefited from.

 However the server must account for this or these additional people in his calculations, because it is necessary that the number of places available in the vehicle is sufficient for all passengers.

Supplement C

So far, it has been envisaged that the server will calculate pedestrian and vehicle routes. It follows that the role of their respective terminals can be considered as simple. Nevertheless, as the power of the terminals is already already significant and increasing rapidly, it is conceivable that each terminal calculates itself the route between the starting point and the destination of the pedestrian or the driver (or vehicle) and provides the results to the server. in a form quickly exploitable by it. This would have the advantage of saving calculations to the server and allow it to devote more resources to traffic management, thus making the system more responsive.

It should be noted that all the aspects, variants, supplements and / or supplements described in the present description can be combined partially or totally, of course, in case of incompatibility or technical impossibility, that the person skilled in the art will know how to determine.

Claims

claims 1.- A method of facilitating the movements of an assembly (Ep) of pedestrians (P) each provided with a portable terminal (TP) by means of a set (Ev) of vehicles (V) associated or each provided with a terminal (TV), the terminals (TP, TV) comprising or being associated with devices for detecting their current positions (GLP, GLV) comprising the following steps ^' ·  pedestrian (P) requests for support requests, each request comprising at least the current position (GLP) and the destination (DP) of the pedestrian concerned; ^• Sending by vehicles (V) or their drivers of offers of support, each offer comprising at least the current position (GLV) and the destination (DV) of the vehicle concerned! ^■ receipt by a server (S) of requests and offers of support;  - constitution by the server (S) of a set (Ep) of pedestrians applicants (P), ^■ constitution by the server (S) of a set (Ev) of vendor vehicles (V),,  search by the server (S), for each pedestrian (Pi) of the set (Ep), of a vehicle (Vj) of the set (Ev) having a route compatible with that of the pedestrian (Pi) and formation of compatibility couples [pedestrian (Pi); vehicle (Vj)];  for each compatibility pair [pedestrian (Pi); vehicle (Vj)]:  • sending by the server (S) to the pedestrian (Pi) of each pair of compatibility (pedestrian (Pi), vehicle (Vj)), a signal of possibility of assumption of responsibility and a request of acceptance / refusal of the supported ;  • if the pedestrian (Pi) sends to the server (S) a refusal response, return to the previous server search step (S); • if the pedestrian (Pi) sends a response of acceptance, sent by the server (S) to the vehicle (Vj) or to its driver, a signal of possibility of taking charge and of a request for acceptance / refusal of care, ^' • if the vehicle (Vj) or its driver sends a refusal response to the server (S), return to the previous server search step (S) and possibly send by the server (S) to the server (S). pedestrian (Pi) of a refusal of support signal, ^'  • in case of sending by the vehicle (Vj) or its driver to the server (S) an acceptance response, possible sending by the server (S) to the pedestrian (Pi) of a confirmation signal of taking charge ;  characterized in that for each compatibility pair [pedestrian (Pi); vehicle (Vj)]: each request for support includes fresh personal data (DFPi) relating to the pedestrian (Pi); each offer of care includes fresh personal data (DFVj) relating to the driver of the vehicle (Vj), in that  the possibility of taking care signal sent to the pedestrian (Pi) comprises said fresh personal data (DFVj) relating to the driver of the vehicle (Vj);  the possibility of handling signal sent to the driver of the vehicle (Vj) includes said fresh personal data (DFPi) relating to the pedestrian (Pi). The method of claim 1, further comprising: ^■ a step during which each pedestrian (Pi) is taken or takes a photo with his / her terminal (TP) and the fresh personal data (DFPi) relating to the pedestrian (Pi) include this photo ^' , ^■ a step during which each vehicle driver (Vj) is taken or takes a picture using the terminal (TV) and the fresh personal data (DFVj) relating to the driver of the vehicle (Vj) include this picture;  - the possibility of taking charge signal sent to the vehicle (Vj) or to its driver optionally further includes the indication of the sex of the pedestrian (Pi); and ^■ the possibility of management signal sent to the pedestrian (Pi) optionally further includes the indication of the sex of the driver of the vehicle (Vj). 3. - Method according to claim 1 or 2, wherein requests for acceptance / refusal of support are valid for a specified period; if at the end of this period, the pedestrian (Pi) or the driver of the vehicle (Vj) did not respond, it is considered that his answer is negative and there is return to the step of search by the compatibility and training compatibility compatibility server [pedestrian (Pi); vehicle (Vj)]. 4.- Method according to one of claims 1 to 3, wherein the search by the server (S) for each pedestrian (Pi) of the set (Ep), a vehicle (Vj) of the together (Ev) having a route (IVj) compatible with that of the pedestrian (Pi), and the formation of compatibility couples [pedestrian (Pi); vehicle (Vj)] is carried out as follows:  for each pedestrian (Pi) of all the n pedestrians (Ep) and going from the first (Vl) to the last vehicle (Vm) of the set Ev: ^■ calculation by the server (S), for each point of the route (IVj) of the vehicle (Vj), the distance (dO) between the point considered and the pedestrian (Pi) and comparison of this distance (dO) with a predetermined maximum distance (dmax) ^' ,  if for all the points, the distance (dO) is greater than (dmax), passing to the next vehicle (Vj + 1); ^■ if, for at least one point, the distance (OD) is less than or equal to the predetermined maximum distance (dmax): • calculation by the server (S) of the distance (dl) between the pedestrian destination (DP) and that of the vehicle (DVj) and comparison of this distance (dl) with the predetermined maximum distance (dmax);  • if the distance (dl) is less than or equal to the predetermined maximum distance (dmax), formation of the compatibility torque [pedestrian (Pi); vehicle (Vj)] and passage to the next pedestrian (Pi + 1);  If the distance (dl) is greater than the predetermined maximum distance (dmax), ^• ■ calculation by the server (S), for each point of the route (IVj) of the vehicle (V i) of the distance (d2) between such point to the destination (DP) of the pedestrian (Pi) and comparison of each distance (d2) with the predetermined maximum distance (dmax)! ■ if, for all points, the distance (d2) is greater than (dmax), passage to the next vehicle (Vj + l);  if, for at least one point (PTmin), the distance (d2) is less than or equal to the predetermined maximum distance (dmax), storing the point (PTmin), forming the compatibility pair [pedestrian (Pi); Vj)] and passage to the pedestrian (Pi + 1) following. 5. A method according to claim 4, further comprising the connection by the server (S), for each compatibility pair (pedestrian (Pi), vehicle (Vj)), the pedestrian (Pi) with the vehicle (Vj ), as follows : ^■ calculation by the server (S) of the current distance (d3) between the vehicle (Vj) and the pedestrian (Pi),  - comparison of the distance (d3) to a stopping distance (da)! ^■ if the distance (d3) is greater than (da), return to the previous computation step;  if the distance (d3) is less than or equal to (da),  • sending by the server (S) to the terminal (TVj) a vehicle stop signal (Vj), this stop signal comprising the fresh personal data (DFPi) relating to the pedestrian (Pi), such as his photo . '  • sending by the server (S) to the terminal (TPi) a signal inviting him to join the vehicle (Vj) and to mount it, this invitation signal comprising data relating to the vehicle (Vj), such as its photo, as well as fresh personal data (DFCj) relating to the driver of the vehicle (Vj), such as his picture;  - sending by the terminal (TPi) to the server (S) a vehicle up signal and / or sending by the terminal (TVj) to the server (S) a pedestrian rise signal, sending the terminal (TVj) from its current position (GLVj) to the server (S), ^■ if there was no memorization of a point (PTmin), comparison by the server (S) of the current position (GLVj) with the destination (DVj), in case of difference, return to step previous sending by the terminal (TVj) to the server (S) of its current position (GLVj); if there is identity, possible sending by the server (S) to the terminal (TVj) and possibly to the terminal (TPi) of an arrival signal at destination I  - if there has been memorization of a point (PTmin), comparison by the server (S) of the current position received with the position (PTmin) I if there is equality, sent by the server (S) to terminal (TVj) of a stop signal for passenger descent and possibly the terminal (TPi) of an arrival signal at destination; otherwise return to the previous step of sending by the terminal (TVj) from its current position GLVj to the server (S);  - possibly, sending by the terminal (TP) to the server (S) of an end of transport signal and / or sent by the terminal (TV) to the server (S) of an end of transport signal. 6. - The method of claim 5, wherein the stopping distance (da) is equal to the predetermined maximum distance (dmax). 7. - Method according to claim 5, wherein the server calculates the speed (VITj) of the vehicle (Vj) in km h and the stopping distance (da) is equal to the (VITj / 10) ² . 8.- Method according to one of claims 1 to 7, wherein the terminal (TPi) pedestrian (Pi) allows it to change the predetermined maximum distance (dmax) and send the modified value to the server ( S). 9. A method according to claim 5 or according to one of claims 6 to 8 dependent on claim 5, wherein, when there is sent by the terminal (TP) to the server (S) an end signal transport and / or sending by the terminal (TV) to the server (S) an end of transport signal, these shipments are accompanied by an evaluation (ECj) of the driver of the vehicle (Vj) by the pedestrian (Pi) and an evaluation (Epi) of the pedestrian (Pi) by the driver of the vehicle (Vj). 10. ' The method of claim 9, further comprising  the calculation by the server (S) of an average of the evaluations of the driver of the vehicle (Vj) to obtain an overall average rating (EMCj) of the driver, the incrementation of 1 of the number of transports he has made and the storage of this information! and  the calculation by the server (S) of an average of the pedestrian evaluations (Pi) to obtain an overall average assessment (EMPi) of the driver, the incrementation of 1 of the number of transports which he has benefited and the storage of these information. 11. The method of claim 10, wherein for each compatibility pair [pedestrian (Pi); vehicle (Vj)]: each pedestrian (Pi) possibility of taking charge signal includes the overall average rating (EMCj) of the driver of the vehicle (Vj) and possibly also the number of transports already carried out and on the basis of which this overall average estimate (EMCj) was calculated;  Each signal of possibility of support sent to the vehicle driver (Vj) comprises the overall average evaluation (EMPi) of the pedestrian (Pi) and possibly also the number of transports which the pedestrian (Pi) has benefited and on the basis of which this overall average assessment (EMPi) was calculated. The process of claim 10, wherein ^:  for each vehicle (Vj), each evaluation (ECj) and each end of transport signal received by the server (S) are stored by the latter in relation to the sex of the pedestrian (Pi) which has just been transported and the server (S) calculates an average of the evaluations assigned for the transport of women (EMCFj) and / or an average of the evaluations received for the transport of men (EMCHj);  for each pedestrian (Pi), each evaluation (Epi) and each end of transport signal received by the server (S) are stored by the latter in relation to the sex of the driver of the vehicle (Vj) which has just transported it and the server (S) calculates an average of the evaluations received for journeys made with female drivers (EMPFi) and / or an average of the evaluations received for journeys made with drivers (EMPHi);  and in which  each pedestrian (Pi) means of care signal includes the average of the ratings received by the driver of the vehicle (Vj) for women's transport (EMCFj) and possibly the number of women's transports made and / or the average of the evaluations received for the transport of men (EMCHj) and possibly the number of men carried! as well as possibly the overall average rating (EMCj) of the driver of the vehicle (Vj) and possibly the total number of transports he has made; each take-up signal sent to a vehicle (Vj) or to its driver includes the average of the pedestrian (Pi) evaluations for journeys with female drivers (EMPFi) and possibly the number of trips made with women and / or the average of the evaluations received for journeys made with drivers (EMPHi) and possibly the number of journeys made with men, ^' as well as possibly the overall average assessment (EMPi) of the pedestrian (Pi) and possibly the number total of transport from which it benefited. 13. A method according to claim 5 or one of claims 6 to 12 dependent on claim 5, wherein the passenger transport distance (Pi) by a vehicle (Vj) is memorized and if necessary added to the previous transport distances, a summary is made periodically for all the vehicles (Vj) and the total distance of transport of each vehicle (Vj) during a given period serves as a calculation for the defraying of the driver of the vehicle (Vj) concerned. 14.- Method for managing the movements of an assembly (Ep) of pedestrians (P) each provided with a portable terminal (TP) by means of a set (Ev) of vehicles (V) associated or each provided with a terminal (TV), the terminals (TP, TV) comprising or being associated with devices for detecting their current positions (GLP, GLV) comprising the following steps, executable by the pedestrians (P) and the drivers of the vehicles (V ):  a single prior step, for each pedestrian (P) and for each vehicle (V), for enrollment respectively in a registered pedestrian base and a registered driver base, and ^■ for each pedestrian (P), a multitude of repetitions of all the following steps only, one way:  Launching a program capable of implementing the method according to one of claims 1 to 13;  possibly personal identification; communication of its destination (DP)>^'  · Communication of fresh personal data!  possibly refusal of one or more proposals for care; acceptance of care;  confirmation of the climb into a vehicle (V);  communication of the end of the transport; · Possibly evaluation of the driver of the vehicle (V) ^' , ^■ for each vehicle driver (V), a multitude of repetitions of all the following steps: one per trip ■  launching a program adapted to implement the method according to one of claims 1 to 13;  · Possibly, personal identification;  communication of its destination (DV); Communication fresh personal data ^'  possibly refusal of one or more proposals for care; acceptance of care;  · Confirmation of a pedestrian (P) climbing into the vehicle (V);  possibly, communication of the end of the transport; and possibly, pedestrian evaluation (P). 15.- system for facilitating the movements of an assembly (Ep) of pedestrians (P) by means of a set (Ev) of vehicles (V), comprising  at least one terminal (TP) intended for a pedestrian (P) and comprising a device for determining its current position (GLP),  at least one terminal (TV) intended for a vehicle (V) and comprising a device for determining its current position (GLV), and  a server (S), and wherein:  the terminal (s) at (TP) and the terminal (s) at (TV) being able and configured to communicate wirelessly with the server (S);  the server (S) being adapted and configured to communicate wirelessly with the terminals (TP, PV);  the different configurations being able to implement the method according to one of claims 1 to 13 or the method according to claim 14.