Method for managing a mobility service

Abstract

The present disclosure proposes a method for managing a mobility service, comprising establishing a relationship between a platform of users and at least one platform of mobility service providers, through the exchange of user tokens and mobility service provider tokens, wherein at least the user token is established on the basis of user data through irreversible tokenization.

Description

Method for managing a mobility service

[0001] This disclosure falls within the field of data processing in the context of the management of a mobility service, in particular the management of a collective and / or shared travel service.

[0002] Limiting the use of fossil fuels, which can produce greenhouse gases, is becoming a major issue in the automotive sector. Strong growth in the use of electric power in this sector, replacing fossil fuels, is already being observed. However, forecasts of electric power requirements for travel show that collective vehicle travel will have to become the norm, while individual travel will be prohibited. Furthermore, the growing number of vehicles is already saturating road infrastructure on major roads.

[0003] The problems of individual and group mobility of people are increasing over the years, with serious impacts on energy consumption and the environment.

[0004] This is why carpooling and collective travel initiatives, in particular, are very successful and are encouraged in order to reduce as much as possible the number of vehicles on the roads, and thus reduce the energy used by all of these vehicles.

[0005] To organize such carpooling solutions, there are known applications for connecting a motorist using a vehicle, on the one hand, and one or more occasional passengers of this vehicle, on the other hand.

[0006] There are vast opportunities that are not yet being exploited today, for example the facts that:

[0007] - event organizing companies wish to promote green mobility for their clients;

[0008] - companies want to find solutions to minimize the carbon footprint of employees, particularly when groups of their employees travel;

[0009] - B2B2C and B2B2B federating platforms provide dedicated applications, which are aimed at individual customers or companies, but these platforms are not interconnected, particularly with event companies for example;

[0010] - the general public wants to travel to take part in an event, such as a concert or an Olympic Games event, but several limiting factors come into play: budget, the vagaries of public transport (strikes, timetables, incidents, etc.), traffic jams in the case of private cars. Individuals can contact known mobility platforms, but it is up to them to be proactive and search, platform by platform, for a carpooling solution by their own means. Thus, users must register on each platform. Furthermore, the data provided by users is then accessible to mobility actors even though the latter have not yet confirmed that they can take charge of these users. Summary

[0011] This disclosure improves the situation.

[0012] To this end, it proposes a method for managing a mobility service, comprising a connection between a user platform and at least one mobility actor platform, by exchanging user and mobility actor tokens, in which at least one user's token is established from user data by irreversible tokenization.

[0013] By "irreversible tokenization" we mean the action of an intermediary between the user platform and the mobility actor platform to interface between these two platforms in order to be able to access user data while prohibiting access to user data for the mobility actor platform.

[0014] Thus, in one embodiment, the connection is implemented by a mobility service management platform interfacing between the user platform and the at least one mobility actor platform, the management platform prohibiting, by said irreversible tokenization, visibility of the user data by the mobility actor platform.

[0015] Users are registered on the user platform and do not need to register directly on mobility provider platforms. Indeed, the mobility service management platform identifies the transport solution among the available mobility provider platforms.

[0016] The proposed solution therefore makes it possible to securely connect users, whether individuals or via a company (for example an events company), who wish to travel, with mobility providers, without directly revealing the identity of the users to the mobility providers (at least until the agreement between the user and the mobility provider for the service is definitively established).

[0017] According to one embodiment, the user platform comprises data from several users and the at least one mobility platform comprises data from several mobility actors each having at least one first mobility parameter. First mobility parameters comprise for example the route to be traveled, the planned travel times, the number of passengers that can be transported, attendance at an event, etc. The data from the mobility actors may comprise a first mobility parameter or several first mobility parameters.

[0018] Thus, in one of the possible applications of the connection within the meaning of the present disclosure, the mobility actor platform may comprise (store for example) data from several mobility actors comprising, for each mobility actor, identity data and at least one first mobility parameter. The user platform may comprise (store for example) data from several users comprising, for each user, identity data. The method may then comprise:

[0019] - upon receipt of a mobility request from a user comprising at least one second mobility parameter from the user platform, identifying, among said several mobility actors, at least one mobility actor having at least one first mobility parameter similar to the at least one second mobility parameter of the mobility request, according to a given similarity criterion,

[0020] - establishing a user token based on user identity data, and transmitting the user token with the at least one second mobility parameter to said at least one identified mobility actor having the at least one first mobility parameter similar to the at least one second mobility parameter;

[0021] - upon receipt of at least a first acceptance response from an identified mobility actor indicating that it wishes to establish a connection with the user according to the at least one first mobility parameter, establishing, based on identity data of the identified mobility actor, a token of the identified mobility actor, and transmitting to the user the token of the identified mobility actor with the at least one first mobility parameter.

[0022] The aforementioned identity data may include, for example, the user's personal data (name, address, telephone number, digital address or social network account, etc.), as well as preference data (for example, preferring to travel by train rather than by plane, etc.).

[0023] In one embodiment, the method may further comprise, after receiving a first acceptance response from the mobility actor, sending the user a verification request intended to verify whether he wants to establish a connection with the identified mobility actor.

[0024] Second mobility parameters may include, for example, the desired route to travel, the departure time, and the number of people who wish to travel to an event. The mobility request may include one or more second mobility parameters.

[0025] The aforementioned similarity criterion may be, for example, an exact match between the first and second parameters, or alternatively a closest match between the second parameters and the first proposed parameters (for example, as regards a precise departure or arrival destination, or a departure or arrival time).

[0026] Typically, in this case, the operation of sending the user a verification request involves sending the user a request to accept a connection with the identified mobility actor and receiving a second acceptance response from the user wishing to establish a connection with the identified mobility actor.

[0027] In one embodiment, several mobility actors are identified according to a priority criterion and a verification request is sent to the user to check whether he wants to establish a connection with said mobility actors identified according to this priority.

[0028] Thus, recruitment of said several mobility actors is carried out by registering new mobility actors or deleting old mobility actors.

[0029] The connection between the user platform and at least one mobility actor platform is carried out, for example, through respective secure APIs.

[0030] In one embodiment, the method may further comprise presenting a human-machine interface for entering an evaluation score, at least for the user, of the quality of a journey made with the identified mobility actor.

[0031] In a complementary or alternative embodiment, the method may further comprise presenting a human-machine interface available to a user to organize a payment from the user to the identified mobility actor, for a journey made together.

[0032] According to another aspect, there is provided a computer program comprising instructions for implementing all or part of a method as defined herein when this program is executed by a processor.

[0033] The present disclosure also relates to a device for managing a mobility service. This device may comprise a server with a communication interface with a wide area network and a processing circuit for establishing a connection between a user platform and at least one mobility actor platform, by exchanging tokens, in which at least one user's token is established from user data by irreversible tokenization.

[0034] The present disclosure also relates to a system for managing a mobility service comprising a device as defined above, a user platform and at least one mobility actor platform, the device being interconnected to said platforms to act as a mobility service management platform for establishing a connection between the user platform and the at least one mobility actor platform.

[0035] Other features, details and advantages will become apparent upon reading the detailed description below, and upon analyzing the attached drawings, in which: Fig. 1

[0036] illustrates an embodiment in which a user platform and mobility actor platforms are connected to a management platform. Figs. 2 to 5

[0037] ,,,illustrate a functional diagram of a method for managing a mobility service according to the present disclosure. Fig. 6

[0038] illustrates an embodiment in which an intermediary actor implements a method for managing a mobility service according to the present disclosure. Fig. 7

[0039] illustrates an embodiment in which messages are exchanged between the management platform, the user and the identified mobility actor to establish interconnections. Fig. 8

[0040] illustrates an embodiment in which messages are exchanged between the management platform, the user and the identified mobility actor to connect them. Fig. 9

[0041] illustrates the irreversible tokenization of user data and the identified mobility actor.

[0042] Reference is now made to the, on which a user platform 2 (for example an event organizing company such as a rugby club) is connected to respective user terminals A1, …, An (member base). Mobility actor platforms 4a, 4b, …, 4n (for example carpooling companies, train companies, private carriers, etc.) may also be connected to terminals or servers each dedicated to a mobility actor B1, …, Bn, C1, …, Cn, …, T1, …, Tn (customer and prospect base). In certain cases, users A1, …, An of the user platform 2 may correspond to mobility actors in relation to a mobility actor platform such as a platform used by a carpooling company.

[0043] The platforms of the mobility actors 4a, 4b, …, 4n include, for each mobility actor B1, …, Bn, C1, …, Cn, …, T1, …, Tn, identity data and at least one first mobility parameter defined later.

[0044] User platform 2 includes identity data of users A1, …, An defined further.

[0045] A management platform 6 of a mobility service is connected, preferably via a private network 8, to said user platforms 2 and mobility actor platforms 4a, 4b, …, 4n. The management platform 6 may comprise, or be implemented by, a mobility service management device. This management device may comprise a server.

[0046] In one embodiment, individuals X1, …, Xn can also connect to an interface 10 of the server 6 through a wide area network 12 such as the Internet.

[0047] On the, a user A2 of the event organizing company 2 wishes to travel by carpooling with other people, not necessarily to attend the same event (for example, to go to the same rugby match together) but simply to go to the same city at the same time. The mobility actor C1 (or several mobility actors C1, Bp, X1 as detailed below) is identified, among several mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn, as relevant for the carpooling trip, as described below.

[0048] The solution of the present description can for example find application in the context of an organization of a sporting event, for example the Olympic Games where an organizing company, for example the Olympic Committee, wants to encourage travel to and from its events for a greater number of tickets sold.

[0049] For each event reservation, a carpooling request may appear on an online ticketing page. Users enter their information (alias and driver / passenger choice, the event information being already known) and a carpool is offered to them. This offer may be revised, provided just before the event, or otherwise.

[0050] This disclosure is particularly advantageous for this application. Indeed, since the mobility solution sought is linked to the event that the user has planned, the user is not required to provide a large amount of information.

[0051] This disclosure applies to any event company:

[0052] - sporting events of all types (all sports federations);

[0053] - cultural events of all types (museums, operas, theaters, foundations, media libraries, associations, etc.),

[0054] - one-off events.

[0055] Figures 2 to 5 show a functional diagram of a method for managing a mobility service according to the present disclosure.

[0056] In a first step 500, the management platform 6 receives, via at least one of the platforms of the mobility actors 4a, 4b, …, 4n, a registration message from the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn who wish to register with the management platform 6.

[0057] In step 500, the management platform 6 further receives, via the user platform 2, a registration message from the user A2.

[0058] Registration messages include, for user A2, at least the user's identity data (e.g. personal data).

[0059] For a mobility actor B1, …, Bn, C1, …, Cn, …, T1, …, Tn, the registration messages may include identity data of the actors (personal data for example if they are natural persons offering for example carpooling). These registration messages of the mobility actors may also include at least a first mobility parameter. In particular, the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn have each associated at least a first mobility parameter, such as for example: the route to be traveled, the planned times of the trip, the number of passengers that it is possible to transport, the event to participate in, which is used in a particularly advantageous embodiment, etc.

[0060] In a step 502, the management platform 6 performs a negotiation for the connection with the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn and the user A2. The negotiation, described in more detail below with reference to the, is a step in which the management platform 6 evaluates the acceptance (or refusal of acceptance) of the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn and the user A2 who made the registration request and records their identity data in a secure database.

[0061] The management platform 6 may, for example, decide, in step 502, not to accept certain mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn due to predefined acceptance conditions linked to a quality of the service offered by the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn, for example a level of reliability or punctuality of the travel service or an obsolescence of the means of transport used.

[0062] The management platform 6 performs, in a step 504 and concurrently with step 500, a step of possible recruitment of new mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn, The recruitment step 504 comprises the reception of registration messages from new mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn who wish to register on the management platform 6 and the addition of these new mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn, in a systemic curation step 506, in the secure database. The systemic curation step 506 is therefore carried out by the management platform 6 to update the list of mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn with the registrations of new mobility actors or deletion of old mobility actors in the secure database kept up to date by the management platform 6.

[0063] After the recruitment step 504, the management platform 6 carries out the negotiation step 502.

[0064] Then, in a step 508, the management platform 6 obtains an agreement for the connection with at least one of the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn and the user A2.

[0065] In a step 510, the management platform 6 establishes the interconnections between the user platform 2 and the mobility actor platforms 4a, 4b, …, 4n. In one embodiment, the interconnections between the platforms are implemented through secure APIs (for “Application Program interface”) between the platforms.

[0066] Illustrates the steps for receiving requests (registration messages) from the user, as well as those from the mobility actors, including possible filtering of the mobility actors, in order to establish the connection channels of the management platform 6 with the user, on the one hand, and with the mobility actors, on the other hand.

[0067] The following Figures 3 to 5 illustrate the steps aimed at connecting user A2 with a mobility actor, in particular the identified mobility actor C1 mentioned above.

[0068] With reference to the, the management platform 6 receives, in step 512, a mobility request from the user A2. Afterwards, in the verification step 514, the management platform 6 checks whether the user A2 is known (because, for example, he has used the service previously and his data is present in the secure database kept up to date by the management platform 6).

[0069] In the negative case, a profiling step 516 of user A2 is performed to collect the data of user A2 and save them in the secure database. Afterwards, the process continues to the identification step 518 described below.

[0070] In the positive case, an identification step 518 is carried out in which the management platform 6 identifies the mobility actor C1 relevant for the connection with the user A2, as detailed below.

[0071] The identification step 518 comprises contacting all the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn that are relevant according to a given similarity criterion, to search for and qualify the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn of interest. In the present description, the term “contact” refers to sending data in the form of a request message, most often awaiting a response from the recipient of the message, as specified below with reference to Figures 7 to 9.

[0072] In particular, as mentioned above, the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn have each previously defined initial mobility parameters.

[0073] Users A1, …, An have also each defined second mobility parameters of their own, for example via human-machine interfaces connected to terminals available to the users respectively. Data from these "second parameters" may be, for example: the desired route to be taken, the departure time, the number of people who wish to travel, the event to participate in, etc.

[0074] These second mobility parameters are contained in the mobility request.

[0075] In the identification step 518 the mobility actor C1 is identified as relevant because its first mobility parameters are identified as similar to the second mobility parameters of the user A2.

[0076] Thus, in such an embodiment, the management platform 6 has these first and second parameters coming from the terminals of the users and the mobility actors and can determine the first parameters of a mobility actor which are closest to the second parameters of a user. The similarity criterion used to determine this proximity of the parameters can be based on predefined rules such as the departure and destination cities must be identical, but the destination addresses in particular may differ, or the expected time of arrival may be different but remain less than an expected time of arrival of the user (for example to attend an event which starts at a given time).

[0077] In an alternative implementation of the solution, several mobility actors Bp, C1, X1 (see) can be identified as relevant according to a priority criterion. In this alternative, these several identified mobility actors are presented to user A2 in an ordered list of several candidates, for multiple selection. User A2 is therefore asked to check whether he wants to establish a connection with the mobility actors Bp, C1, X1 identified according to this priority. In this implementation again, the order of priority can be set according to the aforementioned similarity criterion (the first closest data being at the top of the list).

[0078] The management platform 6, in step 520, contacts the identified mobility actor C1. In a following step 522, the management platform 6 verifies the agreement of the identified mobility actor C1 for this user A2.

[0079] The process then continues as illustrated in the and the management platform 6, in a step 524, proposes the identified mobility actor C1 to the user A2, for example by a notification on his terminal.

[0080] Then, in a step 526, the management platform 6 verifies receipt of the agreement of the user A2 for the connection with the chosen mobility actor C1.

[0081] In the positive case, the management platform 6, at step 528, connects the user A2 with the identified mobility actor C1 by exchanging user and mobility actor tokens between them, as detailed with reference to Figures 8 and 9.

[0082] Afterwards, user A2 and the identified mobility actor C1 make a trip together.

[0083] If no agreement is reached between user A2 and the identified mobility actor C1, steps 518 to 528 are repeated for other mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn, selected according to the order of priority mentioned above.

[0084] The method can continue as illustrated in the with a step 530 of receiving a message from the user terminal, this message being indicative of possible hazards during the journey (delays, traffic jams, breakdowns, etc.). The possible hazards are entered by the user on his terminal In a step 532, the user A2 is asked to possibly rate the effectiveness of the hazard management, by the identified mobility actor C1, until the end of the journey (for example as a hot evaluation).

[0085] When the trip is completed, the method according to the present disclosure further comprises a step 534 of payment for the trip taken and, in certain embodiments, then, a step 536 of evaluation of the trip.

[0086] The payment step 534 can also be implemented before the trip is made, for example by paying money to the management platform 6, then the management platform 6 makes a payment to the mobility actor C1 once the trip has been made.

[0087] In particular, as mentioned above, the payment step 534 can be carried out through the animation of a human-machine interface, on at least the user terminal, to organize a payment from the user A2 to the identified mobility actor C1, for the journey made together.

[0088] User A2 sends a payment message to user platform 2, which forwards this message to management platform 6. Management platform 6 makes the payment and then sends a confirmation of the payment to user platform 2. User platform 2 forwards this confirmation to user A2.

[0089] Symmetrically, the identified mobility actor C1 sends a payment waiting message to the mobility actor platform 4b, which transfers this message to the management platform 6. The management platform 6 makes the payment and then sends a confirmation of the payment made to the mobility actor platform 4b. The mobility actor platform 4b transfers this confirmation to the identified mobility actor C1.

[0090] Optionally, registration messages may also be exchanged between the management platform 6 and the user platforms 2 and mobility actors 4b for additional subscription services.

[0091] The evaluation step 536 can be carried out through the animation of a human-machine interface, on the terminal available to the user A2 and on a terminal of the identified mobility actor C1, to enter an evaluation score (typically cold) of a quality of journey made with the identified mobility actor.

[0092] According to one embodiment, an application runs on the terminal of the user A2 to present a human-machine interface so that the user A2 can enter an evaluation score or comment and send, via his terminal, a trip evaluation message to the user platform 2. The platform 2 transfers this message to the management platform 6, which completes the exchanges with the user platform 2 and updates the mobility actor platform 4b which, in turn, updates the identified mobility actor C1 with the data of this evaluation entered by the user A2 (for example an evaluation score rated out of five stars).

[0093] Symmetrically, the identified mobility actor C1 can send a trip evaluation message to the mobility actor platform 4b which transfers it to the management platform 6. The management platform 6 completes the exchanges with the mobility actor platform 4b and updates the user platform 2 which, in turn, updates the user A2 with this evaluation.

[0094] Evaluation information contained in the trip evaluation messages is stored in a memory.

[0095] This illustrates the case of an intermediary actor 14, for example a city or local authority, which wishes to execute a method for managing a mobility service according to the present description under its own brand 14, using its own interface 10' personalized by the management platform 6.

[0096] The benefits of the method for managing a mobility service according to the present disclosure are multiple:

[0097] - for event companies, to be able to actively offer their customers a carpooling solution. They could therefore offer a solution that strengthens their image among their customers;

[0098] - for users, benefit from the ease of carpooling with people who have the same interests as them, with a notion of practicality because in this case the outward and return journeys are offered. Of course, the confidentiality of user data (privacy) is protected, via the aforementioned token system.

[0099] Illustrated here is a schematic representation of the messages exchanged, during the negotiation step 502 mentioned above, to establish multiple interconnections which are made commercially on the basis of partner negotiations and technically via the APIs.

[0100] A first arrow 100 indicates the establishment of a connection between the user A2 and the management platform 6, a second arrow 102 indicates the establishment of a connection between a first mobility actor B1, …, Bn, C1, …, Cn, …, T1, …, Tn (in particular the actor C1) and the management platform 6 and a third arrow 104 indicates the establishment of a connection between the management platform 6 and a second mobility actor B1, …, Bn, C1, …, Cn, …, T1, …,Tn (in particular the actor T1). No direct connection between the user A2 and the mobility actors B1, …, Bn, C1, …, Cn, …, T1, …, Tn, nor between the mobility actors T1 is made.

[0101] Illustrated is a schematic representation of the messages exchanged between the management platform 6 and the user A2 and between the management platform 6 and the identified mobility actor C1 to put them in contact during the steps from step 512 to step 528 mentioned above.

[0102] An arrow 106 represents the sending of a mobility request from user A2, who wishes to move according to the contents of the second mobility parameters, to the user platform 2, this mobility request being transferred to the management platform 6 (arrow 106'). The arrows 106 and 106' together correspond to the step 512 of receiving the mobility request mentioned below.

[0103] After receiving the mobility request, the management platform 6 performs the identification step 518 mentioned above.

[0104] At the end of these first connections 100, 102, 104, 106, the management platform 6 can execute a tokenization 18 aimed at creating a user token and an identified mobility actor token. These tokens are generated for a given transaction (for example for each new request from a user and for each positive response to this request issued by a mobility actor) and are saved in the secure database that the management platform 6 can use to manage this transaction.

[0105] Tokenization 18, described in detail with reference to below, consists of establishing a token at least for each new entity declaring itself to the management platform 6. These tokens can then be used during the transmission of this mobility request from user A2 (with the user token) to the identified mobility actor C1 and vice versa during a proposal from the identified mobility actor C1 (with the mobility actor token) made to user A2 in response to his request.

[0106] For the implementation of step 18 of the commented here, the respective user and mobility actor tokens are established from the identity data of user A2 and the identity data of the identified mobility actor C1.

[0107] Typically, the user token represents an identity specific to the user A2 (his name, his address, a digital contact data such as for example the IMSI number of the user's telephone and / or his social network account and / or an email address). The user token can be for example a digital signature of this data (for example a hash or an encryption with a security key) that only the management platform 6 can use in order to retrieve all the initial data of the user A2. Thus, the tokenization is "irreversible" in the sense that only the management platform 6 can access the data of the user A2 from his token.

[0108] The identified mobility actor token C1 may contain identity data (name, physical and digital address) of the actor C1, whether a natural person or a transport company. This data is acquired at the end of the registration steps 500 and negotiation steps 502 of the.

[0109] In an alternative embodiment of the invention, the tokenization 18 can be carried out even before the reception of the mobility request, for example during the negotiation step 502 or, with reference to the, if the user A2 is not known at step 514, during the profiling step 516, which can be accompanied by the creation of the token specific to the user A2 and the mobility actor token of all the mobility actors who registered during the registration step 500, with recording of the tokens in the secure database.

[0110] In this embodiment, in the negotiation step 502 (or profiling step 516), usual wishes of the user A2 may be collected among the aforementioned identity data in order to refine his profile. Indeed, this identity data may typically include personal data such as the user's name, address, etc., as well as other user preference data, such as for example the preference to favor travel by train as much as possible rather than by plane, or other. For example, a web page may be proposed to the user A2 to click on his preferred options. In addition, identity data on transport constraints (person in a wheelchair, presence of children, etc.), or other may be collected. This identity data is used to establish the user token.

[0111] In this embodiment, the management platform 6 then has either the user token or the mobility actor token of all the mobility actors who registered during the registration step 500.

[0112] This token data can enable the management platform 6 to efficiently choose the mobility actor C1 that best meets the usual wishes of the user A2, at the identification step 518 of the. The platform 6 can for example carry out a first sorting of the mobility actors according to this token data and then finally select at least one of the identified mobility actors C1 on the basis of the specific request of the user A2 (particular destination and / or travel schedule and / or mode of transport, desired, etc., according to the second parameters of the mobility request).

[0113] Alternatively to prior tokenization 18 before any transmission of a user request (with storage in a secure database), tokenization can be carried out on the fly (at the time of transmitting the user request and / or at the time of transmitting the proposal of the identified mobility actor C1 in response to such a request).

[0114] Thus, it will be understood that the term "tokenization" designates both: - the allocation of a unique token to a given user or to a given mobility actor (for one or more subsequent transactions), - and the allocation of a unique token per transaction, for example to a given user, a token being established for this user for each of his travel projects for example.

[0115] Referring again to the, an arrow 108 indicates the sending, by the management platform 6 to the mobility actors platform 4b, of a proposal, for the identified mobility actor C1, of connection with the user A2, this proposal being transferred to the identified mobility actor C1 (arrow 108'). The mobility actors platform 4b obtains an agreement (arrow 110) from the identified mobility actor C1 and sends (arrow 110') to the management platform 6 a response of acceptance from the identified mobility actor C1 wishing to establish a connection with the user A2. The arrows 108, 108', 110 and 110' together correspond to the steps 520 and 522 of contacting the identified mobility actor C1 and receiving its agreement mentioned above.

[0116] An arrow 112 indicates the sending, by the management platform 6 to the user platform 2, of a proposal, for the user A2, of connection with the identified mobility actor C1, this proposal being transferred to the user A2 (arrow 112'). The user platform 2 obtains an agreement (arrow 114) from the user A2 and sends (arrow 114') to the management platform 6 a response of acceptance from the user A2 wishing to establish a connection with the identified mobility actor C. The arrows 112, 112', 114 and 114' together correspond to the steps 524 and 526 of proposal from the identified mobility actor C1 to the user A2 and obtaining his agreement mentioned above.

[0117] After receiving the agreements (arrows 110 and 110', 114 and 114'), the management platform 6 connects the user A2 with the identified mobility actor C1 (step 528) by exchanging the user token and the mobility actor token between them, as detailed below with reference to the. The user A2 and the identified mobility actor C1 then make the journey together, after exchanging mutual information through the tokens.

[0118] In an example, a company wishes to organize the travel of its employees to a private event. It therefore contacts a public transport organization platform, defines the date and time of the outward and return trips, and the number of people to be transported. The public transport organization platform sends the request, via the system according to this description, to various public transport companies, providing the details of the requested service.

[0119] This would involve the added value of the management platform 6 as a trusted third party, which would provide the public transport organisation platform with an orchestrator service, its experience on a history of requests and quality of services with various transport companies, and would return the various mobility possibilities to the requesting company. This company can therefore make its choice, from among a certain number of companies, based on reliable data on quality of service, updated in the aforementioned database.

[0120] The tokenization 18 of the is illustrated in detail on the, from the data of the user A2 for the user token and the data of the identified mobility actor C1 for the mobility actor token, for a connection between the user A2 and the identified mobility actor C1 by exchange of tokens.

[0121] User identity data 700 of user A2 are known by the management platform 6, for example recovered during the registration step 500 or profiling step 516 mentioned above.

[0122] The user identity data 700 is then transformed, during a first tokenization 701 with a first unique secret code, into secure user identity data 702 (to form a user token). The secure user identity data 702 (or "user token") is then associated with the second mobility parameters 702a contained in the mobility request to form the proposal to the identified mobility actor C1 (arrow 108).

[0123] Thus, it will be understood that if the tokenization 18 is done even before the reception of the mobility request, the user token can be stored in the secure database (for example, during the negotiation step 502) and can be recovered by the management platform 6 to be associated, after the reception of the mobility request, with the second mobility parameters 702a, in order to be sent together (arrow 108) to the identified mobility actor C1.

[0124] The management platform 6 also knows the identity data of the mobility actors 704 and in particular those of the identified mobility actor C1, recovered during the registration step 500 (or recruitment step 504) mentioned above.

[0125] The mobility actor identity data 704 are then transformed, during a second tokenization 705 with a second unique secret code, into secure mobility actor identity data 706 (mobility actor token). The secure mobility actor identity data 706 (or “mobility actor token”) are then associated with the first mobility parameters 706a to be shared with the user A2 (arrow 112). The first and second codes mentioned above may be different or identical.

[0126] Thus, the mobility actor token can be stored in the secure database (for example, during the negotiation step 502) and it is retrieved by the management platform 6 to be associated with the first mobility parameters 706a, to be sent together (arrow 112) to the user A2.

[0127] When the mobility actor platform 4b sends the acceptance response from the identified mobility actor C1 (arrow 110') to the management platform 6, it (the mobility actor platform 4b) also returns the user token received during the connection proposal to the management platform 6, so that the management platform 6 can use this token to identify the user A2 to whom this acceptance response from the identified mobility actor C1 must be transferred.

[0128] The management platform 6, after receiving the acceptance response from the identified mobility actor C1 ('arrow 110'), sends to the user A2 the mobility actor token with the first mobility parameters 706a (arrow 112), and waits for the acceptance response from the user A2 (arrow 114').

[0129] Only the management platform 6 has the reversibility keys to regain clear access to the identity data of the user and the mobility actor. Thus, the exchanges of identity data between user A2 and the identified mobility actor C1 are not accessible to the identified mobility actor C1 and user A2 respectively.

[0130] This is then an “irreversible tokenization” in that it allows user A2 and the identified mobility actor C1 to connect, while prohibiting access to user A2 data by the identified mobility actor C1 (and possibly also prohibiting access by user A2 to the data of the identified mobility actor C1). Tokenization thus prevents the identified mobility actor C1 from seeing user A2’s data and reconstructing it, however without the help of third-party data.

[0131] The benefits of this solution are multiple:

[0132] - for the requesting company, confidence in the platform it uses to organize the transport of its employees, but also in the virtuous dimension of travel;

[0133] - for employees, the satisfaction of being supported with a complete and “green” solution.

[0134] - for public transport organizing platforms, the assurance of being in contact, for transactions, with a trusted management platform 6.

[0135] This solution is fully multimodal:

[0136] - it simplifies the lives of the general public, but also of companies organizing events, whether recurring or one-off;

[0137] - it allows the connection of B2B2C and B2B2B federating platforms with individuals or legal entities, in a climate of trust, established with the token system;

[0138] - it allows the management platform 6 to position itself as a trusted reference in a chain of connections between different stakeholders and clients of virtuous mobility solutions.

[0139] This solution is scalable: the management platform 6 collects all the transactions that have taken place and “learns” the history of transactions (successes, hazards, evaluations, etc.) to refine its models and constantly improve its proposals to the different stakeholders but also to better manage hazards.

[0140] The subject of this description offers numerous advantages, by typically proposing a federating platform interfacing between B2B2C and B2B2B entities (the “mobility service management platform” as defined previously), which then manages the most relevant interconnection between users and mobility stakeholders, thanks to token management which allows the matching of profiles, contexts, wishes and constraints, while preserving the confidentiality of the data of all users.

[0141] The platform may also preserve the confidentiality of mobility stakeholders' data, particularly in auction mechanisms between mobility stakeholders offering the same service.

[0142] This unifying platform can thus present itself as a trusted third party for all stakeholders, both for recruitment, networking, identity verification, and for payment for the service.

[0143] The server of the management platform 6 comprises a data processing circuit for implementing a method for managing a mobility service (recruitment, profiling, networking, journey management, etc.) as detailed above.

[0144] The server is capable of executing the method presented above. Typically, the server can store in particular the instruction code data of a computer program within the meaning of the present disclosure.

[0145] The method for managing a mobility service according to the present disclosure ensures the tokenization of the processed information so that it remains confidential and secure.

Claims

Method for managing a mobility service, comprising a connection between a user platform (2) and at least one mobility actor platform (4a, 4b, …, 4n), by exchange of user and mobility actor tokens, in which at least the user token is established from user data by irreversible tokenization. Method according to claim 1, in which the connection is implemented by a mobility service management platform (6) interfacing between the user platform (2) and the at least one mobility actor platform (4a, 4b, …, 4n), the management platform (6) prohibiting, by said irreversible tokenization, visibility of the user data for the mobility actor platform. A method for managing a mobility service according to claim 1 or 2, wherein the at least one mobility actor platform (4a, 4b, …, 4n) comprises data from several mobility actors (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) comprising, for each mobility actor (B1, …, Bn, C1, …, Cn, …, T1, …, Tn), identity data and at least one first mobility parameter and the user platform (2) comprises data from several users (A1, A2, …, An) comprising, for each user, identity data, the method comprising: - upon receipt of a mobility request from a user (A2) comprising at least one second mobility parameter, from the user platform (2), identifying, among said several mobility actors (B1, …, Bn, C1, …, Cn, …, T1, …, Tn),at least one mobility actor (C1) having the at least one first mobility parameter similar to the at least one second mobility parameter of the mobility request, according to a given similarity criterion,- establishing a user token based on identity data of the user (A2), and transmitting the user token with the at least one second mobility parameter to said at least one identified mobility actor (C1) having the at least one first mobility parameter similar to the at least one second mobility parameter;- upon receipt of at least one first acceptance response from an identified mobility actor (C1) indicating that it wishes to establish a connection with the user (A2) according to the at least one first mobility parameter, establishing, based on identity data of the identified mobility actor (C1), a token of the identified mobility actor,and transmit to the user (A2) the token of the identified mobility actor (C1) with at least one first mobility parameter., Method for managing a mobility service according to claim 3, further comprising, after receiving the first acceptance response from the identified mobility actor (C1), sending the user (A2) a verification request intended to verify whether he wants to establish a connection with the identified mobility actor (C1). Method for managing a mobility service according to claim 4, in which sending a verification request to the user (A2) comprises:- sending to the user (A2) a request to accept a connection with the identified mobility actor (C1);- receiving a second acceptance response from the user (A2) wishing to establish a connection with the identified mobility actor (C1). Method for managing a mobility service according to one of claims 3 to 5, in which several mobility actors (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) are identified according to a priority criterion and a verification request is addressed to the user (A2) to check whether he wants to establish a connection with said mobility actors identified according to this priority. Method for managing a mobility service according to one of claims 3 to 6, in which recruitment of said several mobility actors (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) is carried out by registering new mobility actors (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) or deleting old mobility actors (B1, …, Bn, C1, …, Cn, …, T1, …, Tn). Method for managing a mobility service according to one of the preceding claims, in which the connection between the user platform and the at least one mobility actor platform is carried out through respective secure APIs. Computer program comprising instructions for implementing the method according to one of the preceding claims when this program is executed by a processor. Device for managing a mobility service comprising a server with a communication interface with a wide area network for establishing a connection between a user platform and at least one mobility actor platform, the server comprising a processing circuit for implementing the method according to one of claims 1 to 8. A system for managing a mobility service comprising a device according to claim 10, a user platform and at least one mobility actor platform, the device being interconnected to said platforms to act as a mobility service management platform for establishing a connection between the user platform and the at least one mobility actor platform.

Images