WO2025119809A1 - Procédé de gestion d'un service de mobilité - Google Patents

Procédé de gestion d'un service de mobilité Download PDF

Info

Publication number
WO2025119809A1
WO2025119809A1 PCT/EP2024/084243 EP2024084243W WO2025119809A1 WO 2025119809 A1 WO2025119809 A1 WO 2025119809A1 EP 2024084243 W EP2024084243 W EP 2024084243W WO 2025119809 A1 WO2025119809 A1 WO 2025119809A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobility
user
actor
platform
identified
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2024/084243
Other languages
English (en)
Inventor
Carine TARDIEU
Thierry GAILLET
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of WO2025119809A1 publication Critical patent/WO2025119809A1/fr
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G06Q50/43—Business processes related to the sharing of vehicles, e.g. car sharing

Definitions

  • 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.
  • carpooling and collective travel initiatives 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.
  • 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;
  • 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.
  • This disclosure improves the situation.
  • 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.
  • 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.
  • connection is implemented by a mobility service management platform interfacing between the user platform and at least one mobility actor platform, the management platform prohibiting, by said irreversible tokenization, visibility of the user data by the mobility actor platform.
  • the mobility service management platform identifies the transport solution among the available mobility provider platforms.
  • 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).
  • a company for example an events company
  • 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 include, 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.
  • the mobility actor platform may comprise (store for example) data of 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 of several users comprising, for each user, identity data.
  • the method may then comprise:
  • 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.).
  • 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.
  • 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.
  • 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, with regard to a specific departure or arrival destination, or a departure or arrival time).
  • 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.
  • recruitment of said several mobility actors is carried out by registering new mobility actors or deleting old mobility actors.
  • connection between the user platform and at least one mobility actor platform is carried out, for example, through respective secure APIs.
  • 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 trip made with the identified mobility actor.
  • 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.
  • a computer program comprising instructions for implementing all or part of a method as defined herein when this program is executed by a processor.
  • 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.
  • This 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.
  • FIG. 1 illustrates an embodiment in which a user platform and mobility actor platforms are connected to a management platform.
  • FIG. 1 illustrates a functional diagram of a method for managing a mobility service according to the present disclosure.
  • FIG. 1 illustrates an embodiment in which an intermediary actor implements a method for managing a mobility service according to the present disclosure.
  • FIG. 1 illustrates an embodiment in which messages are exchanged between the management platform, the user and the identified mobility actor to establish interconnections.
  • FIG. 1 illustrates an embodiment in which messages are exchanged between the management platform, the user and the identified mobility actor to connect them.
  • a user platform 2 for example an event organizing company such as a rugby club
  • Mobility actor platforms 4a, 4b, ..., 4n may also be connected to terminals or servers each dedicated to a mobility actor B1, ..., Bn, C1, ..., Cn, ..., T1, ..., Tn (customer and prospect base).
  • users A1, ..., An of the user platform 2 may correspond to mobility actors in relation with a mobility actor platform such as a platform used by a carpooling company.
  • 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 below.
  • User platform 2 includes identity data of users A1, ..., An defined further.
  • 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.
  • individuals X1, ..., Xn can also connect to an interface 10 of the server 6 through a wide area network 12 such as the Internet.
  • a wide area network 12 such as the Internet.
  • 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.
  • the solution of the present description may for example find application in the context of the organization of a sporting event, for example the Olympic Games where an organizing company, for example the Olympic Committee, wishes to encourage travel to and from its events for a greater number of tickets sold.
  • an organizing company for example the Olympic Committee
  • a carpooling request may appear on an online ticketing page. Users enter their information (alias and driver/passenger choice, since the event information is already known) and a carpool is offered to them. This offer may be revised, provided just before the event, or otherwise.
  • 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.
  • Figures 2 to 5 show a functional diagram of a method for managing a mobility service according to the present disclosure.
  • 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.
  • step 500 the management platform 6 further receives, via the user platform 2, a registration message from the user A2.
  • Registration messages include, for user A2, at least the user's identity data (e.g. personal data).
  • 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.
  • 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 covered, 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.
  • 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 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 of the user A2 who made the registration request and records their identity data in a secure database.
  • 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.
  • the management platform 6 carries out, 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.
  • the management platform 6 After the recruitment step 504, the management platform 6 carries out the negotiation step 502.
  • 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.
  • the management platform 6 establishes the interconnections between the user platform 2 and the mobility actor platforms 4a, 4b, ..., 4n.
  • the interconnections between the platforms are implemented through secure APIs (for “ Application Program interface ”) between the platforms.
  • 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).
  • 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 with the identification step 518 described below.
  • 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.
  • 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.
  • 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.
  • the mobility actors B1, ..., Bn, C1, ..., Cn, ..., T1, ..., Tn have each previously defined initial mobility parameters.
  • 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.
  • 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.
  • 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).
  • several mobility actors Bp, C1, X1 can be identified as relevant according to a priority criterion.
  • 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.
  • the order of priority can be set according to the aforementioned similarity criterion (the first closest data being at the top of the list).
  • 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.
  • the management platform 6 verifies receipt of the agreement of the user A2 for the connection with the chosen mobility actor C1.
  • 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.
  • 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.
  • the process 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.). Any hazards are entered by the user on his terminal.
  • 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 assessment).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • registration messages may also be exchanged between the management platform 6 and the user platforms 2 and mobility actors 4b for additional subscription services.
  • 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.
  • an application runs on the terminal of the user A2 to present a human-machine interface so that the user A2 can enter a score or an evaluation comment and send, via his terminal, a message evaluating the trip 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).
  • 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.
  • Evaluation information contained in the trip evaluation messages is stored in a memory.
  • an intermediary actor for example a city or local authority, which wishes to execute a method of 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.
  • 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
  • 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.
  • 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'). Arrows 106 and 106' together correspond to step 512 of receiving the mobility request mentioned below.
  • the management platform 6 After receiving the mobility request, the management platform 6 performs the identification step 518 mentioned above.
  • 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.
  • Tokenization 18 consists of establishing at least one token for each new entity declaring itself to the management platform 6. These tokens can then be used when transmitting this mobility request from user A2 (with the user token) to the identified mobility actor C1 and vice versa when a proposal from the identified mobility actor C1 (with the mobility actor token) is made to user A2 in response to his request.
  • 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.
  • 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.
  • the tokenization is " irreversible " in the sense that only the management platform 6 can access the data of the user A2 from his token.
  • the identified mobility actor token C1 may contain identity data (name, physical and digital address) of the actor C1, a natural person or transport company. This data is acquired at the end of the registration steps 500 and negotiation steps 502 of the .
  • 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 user A2 is not known at step 514, during profiling step 516, which may be accompanied by the creation of the token specific to user A2 and the mobility actor token of all mobility actors who registered during registration step 500, with recording of the tokens in the secure database.
  • this identity data can typically include personal data such as the name, address of the user, 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.
  • personal data such as the name, address of the user, etc.
  • 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.
  • a web page can be proposed to the user A2 to click on his preferred options.
  • identity data on transport constraints person in a wheelchair, presence of children, etc.
  • 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.
  • This token data can allow the management platform 6 to efficiently choose the mobility actor C1 best meeting the usual wishes of the user A2, at the identification step 518 of the .
  • the platform 6 can for example carry out an initial sorting of the mobility actors based on this token data and then finally select at least one of the mobility actors identified C1 on the basis of the specific request of the user A2 (particular destination and/or travel time and/or mode of transport, desired, etc., according to the second parameters of the mobility request).
  • 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).
  • tokenization also designates: - the allocation of a unique token to a given user or to a given mobility actor (for one or more subsequent transactions), - that the allocation of a unique token per transaction, for example to a given user, a token being established for this user for each of their travel projects for example.
  • 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.
  • 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.
  • the management platform 6 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 between them the user token and the mobility actor token, as detailed below with reference to the . User A2 and the identified mobility actor C1 then make the trip together, after exchanging mutual information through the tokens.
  • 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 journeys, 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.
  • 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.
  • Tokenization 18 of the is illustrated in detail on the , from the data of user A2 for the user token and the data of the identified mobility actor C1 for the mobility actor token, for a connection between user A2 and the identified mobility actor C1 by exchange of tokens.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the mobility actor platform 4b 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.
  • 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’).
  • management platform 6 Only 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.
  • the management platform 6 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.
  • 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.
  • the subject of this description offers numerous advantages, typically by 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.
  • the platform may also preserve the confidentiality of mobility stakeholders' data, particularly in auction mechanisms between mobility stakeholders offering the same service.
  • 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.
  • the server of the management platform 6 includes a data processing circuit for implementing a method for managing a mobility service (recruitment, profiling, networking, journey management, etc.) as detailed above.
  • the server is capable of executing the method presented above.
  • the server can store in particular the instruction code data of a computer program within the meaning of the present disclosure.
  • the method of managing a mobility service ensures the tokenization of the processed information so that it remains confidential and secure.

Landscapes

  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente divulgation propose un procédé de gestion d'un service de mobilité, comportant une mise en relation entre une plateforme d'utilisateurs et au moins une plateforme d'acteurs de mobilité, par échange de jetons d'utilisateur et d'acteur de mobilité, dans lequel au moins le jeton d'utilisateur est établi à partir de données de l'utilisateur par tokenisation irréversible.

Description

Procédé de gestion d’un service de mobilité
La présente divulgation relève du domaine du traitement de données dans le cadre de la gestion d’un service de mobilité, en particulier la gestion d’un service de déplacement collectif et/ou partagé.
La limitation de l'utilisation des énergies fossiles, susceptibles de produire des gaz à effet de serre, devient un enjeu majeur dans le secteur de l'automobile. Une forte croissance du recours à l’énergie électrique dans ce secteur, en remplacement des énergies fossiles, est déjà observée. Toutefois, les prévisions des besoins en matière d’énergie électrique pour les déplacements montrent que les déplacements collectifs en véhicule devront être la norme tandis que les déplacements individuels seront proscrits. Par ailleurs, le nombre croissant de véhicules sature déjà les infrastructures routières sur les grands axes.
Les problèmes de mobilités individuelles et de groupes des personnes s’accentuent au fil des ans, avec de graves impacts sur la consommation énergétique et sur l’environnement.
C’est pourquoi les initiatives de covoiturage et déplacements collectifs, notamment, rencontrent beaucoup de succès et sont encouragées afin de réduire autant que possible le nombre de véhicules sur les routes, et réduire ainsi l’énergie sollicitée par l’ensemble de ces véhicules.
Pour organiser de telles solutions de covoiturage, il existe des applications connues pour mettre en relation un automobiliste utilisateur d’un véhicule, d’une part, et un ou plusieurs passagers occasionnels de ce véhicule, d’autre part.
De vastes opportunités ne sont pas encore exploitées aujourd’hui, par exemple les faits que :
- des sociétés organisatrices d’évènements souhaitent favoriser la mobilité verte pour leurs clients ;
- des sociétés souhaitent trouver des solutions pour minimiser l’empreinte carbone des employés, notamment lors de déplacements de groupes de leurs employés ;
- des plateformes fédératrices B2B2C et B2B2B fournissent des applications dédiées, qui s’adressent à des clients particuliers ou des entreprises, mais ces plateformes ne sont pas interconnectées notamment avec des sociétés événementielles par exemple ;
- le grand public souhaite se déplacer pour prendre part à un évènement, tel qu’un concert ou une épreuve des jeux olympiques, mais plusieurs facteurs limitants rentrent en jeu : le budget, les aléas des transports en commun (grève, horaires, incidents…), les embouteillages dans le cas de la voiture individuelle. Les particuliers peuvent s’adresser aux plateformes de mobilité connues, mais c’est à eux d’être proactifs et de chercher, plateforme par plateforme, une solution de covoiturage par leurs propres moyens. Ainsi, les utilisateurs doivent s’inscrire dans chaque plateforme. Par ailleurs, les données renseignées par les utilisateurs sont alors accessibles à des acteurs de mobilité alors que ces derniers n’ont même pas encore confirmé qu’ils pouvaient prendre en charge ces utilisateurs.
Résumé
La présente divulgation vient améliorer la situation.
Elle propose à cet effet un procédé de gestion d’un service de mobilité, comportant une mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, par échange de jetons d'utilisateur et d’acteur de mobilité, dans lequel au moins le jeton d’un utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible.
Par « tokenisation irréversible », on entend l’action d’un intermédiaire entre la plateforme d’utilisateurs et la plateforme d’acteurs de mobilité pour venir s’interfacer entre ces deux plateformes afin de pouvoir accéder aux données des utilisateurs tout en interdisant l’accès aux données d’utilisateurs pour la plateforme des acteurs de mobilité.
Ainsi, dans un mode de réalisation, la mise en relation est mise en œuvre par une plateforme de gestion de service de mobilité s’interfaçant entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité, la plateforme de gestion interdisant, par ladite tokenisation irréversible, une visibilité des données d’utilisateurs par la plateforme des acteurs de mobilité.
Les utilisateurs sont inscrits à la plateforme d’utilisateurs et n’ont pas besoin de s’inscrire dans des plateformes d’acteurs de mobilité directement. En effet, la plateforme de gestion de service de mobilité effectue l’identification de la solution de transport parmi les plateformes d’acteurs de mobilité disponibles.
La solution proposée permet donc de mettre en relation de manière sécurisée des utilisateurs, particuliers ou via une entreprise (par exemple une société évènementielle), qui souhaitent se déplacer, avec des acteurs de mobilité, sans dévoiler directement l’identité des utilisateurs aux acteurs de mobilité (au moins tant que l’accord entre l’utilisateur et l’acteur de mobilité pour la prestation n’est pas définitivement établie).
Selon un mode de réalisation, la plateforme d’utilisateurs comprend des données de plusieurs utilisateurs et l’au moins une plateforme de mobilité comprend des données de plusieurs acteurs de mobilité ayant chacun au moins un premier paramètre de mobilité. Des premiers paramètres de mobilité comprennent par exemple le trajet à parcourir, les horaires prévus du déplacement, le nombre de passagers qu’il est possible de transporter, l’assistance à un événement, etc. Les données des acteurs de mobilité peuvent comprendre un premier paramètre de mobilité ou plusieurs premiers paramètres de mobilité.
Ainsi, dans l’une des applications possibles de la mise en relation au sens de la présente divulgation, la plateforme d’acteurs de mobilité peut comprendre (stocker par exemple) des données de plusieurs acteurs de mobilité comprenant, pour chaque acteur de mobilité, des données d’identité et au moins un premier paramètre de mobilité. La plateforme d’utilisateurs peut comprendre (stocker par exemple) des données de plusieurs utilisateurs comprenant, pour chaque utilisateur, des données d’identité. Le procédé peut alors comporter :
- sur réception d’une requête de mobilité d’un utilisateur comprenant au moins un deuxième paramètre de mobilité en provenance de la plateforme d’utilisateurs, identifier, parmi lesdits plusieurs acteurs de mobilité, au moins un acteur de mobilité ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité de la requête de mobilité, selon un critère de similarité donné,
- établir un jeton de l’utilisateur en fonction de données d’identité de l’utilisateur, et transmettre le jeton d’utilisateur avec l’au moins un deuxième paramètre de mobilité audit au moins un acteur de mobilité identifié ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité ;
- sur réception d’au moins une première réponse d’acceptation d’un acteur de mobilité identifié indiquant qu’il souhaite établir une connexion avec l’utilisateur selon l’au moins un premier paramètre de mobilité, établir, en fonction de données d’identité de l’acteur de mobilité identifié, un jeton de l’acteur de mobilité identifié, et transmettre à l’utilisateur le jeton de l’acteur de mobilité identifié avec l’au moins un premier paramètre de mobilité.
Les données d’identité précitées peuvent comporter, par exemple pour l’utilisateur, ses données personnelles (nom, adresse, numéro de téléphone, adresse numérique ou compte de réseau social, etc.), ainsi que des données de préférence (par exemple privilégier plutôt les voyages en train qu’en avion, etc.).
Dans une réalisation, le procédé peut comporter en outre, après réception d’une première réponse d’acception de l’acteur de mobilité, adresser à l’utilisateur une requête de vérification destinée à vérifier s’il veut établir une connexion avec l’acteur de mobilité identifié.
Des deuxièmes paramètres de mobilité peuvent comprendre par exemple le trajet à parcourir souhaité, l’heure de départ, le nombre de personnes qui souhaitent se déplacer vers un événement. La requête de mobilité peut comprendre un ou plusieurs deuxièmes paramètres de mobilité.
Le critère de similarité précité peut être par exemple une correspondance exacte entre les premiers et deuxièmes paramètres, ou alternativement une correspondance la plus proche entre les deuxièmes paramètres et les premiers paramètres proposés (par exemple quant à une destination précise de départ ou d’arrivée, ou encore un horaire de départ ou d’arrivée).
Typiquement, dans ce cas, l’opération d’adresser à l’utilisateur une requête de vérification comporte l’envoi à l’utilisateur d’une requête d’acceptation d’une connexion avec l’acteur de mobilité identifié et la réception d’une deuxième réponse d’acceptation de l’utilisateur souhaitant établir une connexion avec l’acteur de mobilité identifié.
Dans une réalisation, plusieurs acteurs de mobilité sont identifiés selon un critère de priorité et une requête de vérification est adressée à l’utilisateur pour vérifier s’il veut établir une connexion avec lesdits acteur de mobilité identifié suivant cette priorité.
Ainsi, un recrutement desdits plusieurs acteurs de mobilité est effectué par inscription de nouveaux acteurs de mobilité ou suppression d’anciens acteurs de mobilité.
La mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité est effectuée par exemple à travers des API respectives sécurisées.
Dans une réalisation, le procédé peut comporter en outre présenter une interface homme machine pour saisir une note d’évaluation, au moins pour l’utilisateur, d’une qualité d’un voyage réalisé avec l’acteur de mobilité identifié.
Dans une réalisation complémentaire ou alternative, le procédé peut comporter en outre présenter une interface homme machine à disposition d’un utilisateur pour organiser un paiement de l’utilisateur à l’acteur de mobilité identifié, pour un voyage effectué ensemble.
Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes lorsque ce programme est exécuté par un processeur.
La présente divulgation vise aussi un dispositif de gestion d’un service de mobilité. Ce dispositif peut comporter un serveur avec une interface de communication avec un réseau étendu et un circuit de traitement pour la mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, par échange de jetons, dans lequel au moins le jeton d’un utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible.
La présente divulgation vise aussi un système de gestion d’un service de mobilité comportant un dispositif tel que défini ci-dessus, une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, le dispositif étant interconnecté auxdites plateformes pour agir en tant que plateforme de gestion d’un service de mobilité pour la mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité.
D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
Fig. 1
illustre un mode de réalisation dans lequel une plateforme d’utilisateurs et des plateformes des acteurs de mobilité sont connectées à une plateforme de gestion.
Figs. 2 à 5
, , , illustrent un schéma fonctionnel d’un procédé de gestion d’un service de mobilité selon la présente divulgation.
Fig. 6
illustre un mode de réalisation dans lequel un acteur intermédiaire met en œuvre un procédé de gestion d’un service de mobilité selon la présente divulgation.
Fig. 7
illustre un mode de réalisation dans lequel des messages sont échangés entre la plateforme de gestion, l’utilisateur et l’acteur de mobilité identifié pour établir des interconnexions.
Fig. 8
illustre un mode de réalisation dans lequel des messages sont échangés entre la plateforme de gestion, l’utilisateur et l’acteur de mobilité identifié pour les mettre en relation.
Fig. 9
illustre la tokenisation irréversible des données de l’utilisateur et de l’acteur de mobilité identifié.
Il est maintenant fait référence à la , sur laquelle une plateforme d’utilisateurs 2 (par exemple une société organisatrice d’événements tel qu’un club de rugby) est en connexion avec des terminaux respectifs d’utilisateurs A1, …, An (base de membres). Des plateformes d’acteurs de mobilité 4a, 4b, …, 4n (par exemple des sociétés de covoiturage, des compagnies de train, de transporteurs privés, etc.) peuvent aussi être en relation avec des terminaux ou des serveurs dédiés chacun à un acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn (base de clients et prospects). Dans certain cas, les utilisateurs A1, …, An de la plateforme d’utilisateurs 2 peuvent correspondre à des acteurs de mobilité en relation avec une plateforme d’acteurs de mobilité telle qu’une plateforme utilisée par une société de covoiturage.
Les plateformes des acteurs de mobilité 4a, 4b, …, 4n comprennent, pour chaque acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, des données d’identité et au moins un premier paramètre de mobilité défini plus loin.
La plateforme d’utilisateurs 2 comprend des données d’identité des utilisateurs A1, …, An défini plus loin.
Une plateforme de gestion 6 d'un service de mobilité est connectée, de manière préférée à travers un réseau privé 8, auxdites plateforme des utilisateurs 2 et plateformes des acteurs de mobilité 4a, 4b, …, 4n. La plateforme de gestion 6 peut comporter, ou être mise en œuvre par un dispositif de gestion d’un service de mobilité. Ce dispositif de gestion peur comporter un serveur.
Dans un mode de réalisation des particuliers X1, …, Xn peuvent aussi se connecter à une interface 10 du serveur 6 à travers un réseau étendu 12 tel que l’internet.
Sur la , un utilisateur A2 de la société organisatrice d’événements 2 souhaite se déplacer en covoiturage avec d’autres personnes, pas forcément pour assister au même évènement (par exemple aller voir ensemble le même match de rugby) mais simplement pour se rendre dans la même ville au même moment. L’acteur de mobilité C1 (ou plusieurs acteurs de mobilité C1, Bp, X1 comme détaillé ci-dessous) est identifié, parmi plusieurs acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, comme pertinent pour le déplacement en covoiturage, comme décrit ci-dessous.
La solution de la présente description peut par exemple trouver application dans le cadre d’une organisation d’une manifestation sportive, par exemple les jeux olympiques où une société organisatrice, par exemple le comité olympique, veut favoriser le déplacement vers et depuis ses évènements pour un plus grand nombre de billets vendus.
Pour chaque réservation d’une épreuve, une demande de covoiturage peut apparaitre sur une page de la billetterie en ligne. Les utilisateurs rentrent leurs informations (alias et choix conducteur / passager, les informations de l’évènement étant déjà connues) et un covoiturage leur est proposé. Cette proposition peut être revue, fournie juste avant l’évènement, ou autres.
La présente divulgation est particulièrement avantageuse pour cette application. En effet, la solution de mobilité recherchée étant liée à l’événement que l’utilisateur a prévue, l’utilisateur n’est pas contraint à fournir un grand nombre d’informations.
La présente divulgation s’applique à toute société évènementielle :
- évènements sportifs de tout type (toutes les fédérations de sport) ;
- évènements culturels de tout type (musées, opéras, théâtres, fondations, médiathèques, associations, etc.),
- évènements ponctuels.
Les Figures 2 à 5 montrent un schéma fonctionnel d’un procédé de gestion d’un service de mobilité selon la présente divulgation.
Dans une première étape 500, la plateforme de gestion 6 reçoit, par au moins une des plateformes des acteurs de mobilité 4a, 4b, …, 4n, un message d’inscription des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn qui souhaitent s’inscrire auprès la plateforme de gestion 6.
Dans l’étape 500, la plateforme de gestion 6 reçoit en outre, par la plateforme d’utilisateurs 2, un message d’inscription de l’utilisateur A2.
Les messages d’inscription comprennent, pour l’utilisateur A2, au moins les données d’identité de l’utilisateur (par exemple ses données personnelles).
Pour un acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, les messages d’inscription peuvent comprendre des données d’identité des acteurs (des données personnelles par exemple s’il s’agit de personnes physiques proposant par exemple du covoiturage). Ces messages d’inscription des acteurs de mobilité peuvent comprendre aussi au moins un premier paramètre de mobilité. En particulier, les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn ont chacun associé au moins un premier paramètre de mobilité, comme par exemple : le trajet à parcourir, les horaires prévus du déplacement, le nombre de passagers qu’il est possible de transporter, l’évènement à participer, qui est utilisé dans un mode de réalisation particulièrement avantageux, etc.
Dans une étape 502, la plateforme de gestion 6 effectue une négociation pour la connexion avec les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn et l’utilisateur A2. La négociation, décrite plus en détail ci-dessous en référence à la , est une étape dans laquelle la plateforme de gestion 6 évalue l’acceptation (ou le refus d’acceptation) des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn et de l’utilisateur A2 qui ont fait la sollicitation d'inscription et enregistre leurs données d’identité dans une base de données sécurisée.
La plateforme de gestion 6 peut par exemple décider, dans l'étape 502, de ne pas accepter certains acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn en raison de conditions d’acceptation prédéfinies liée à une qualité du service offert pas les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, par exemple un niveau de fiabilité ou ponctualité du service de déplacement ou une vétusté des moyens de transports utilisés.
La plateforme de gestion 6 effectue, dans une étape 504 et de manière concurrente à l’étape 500, une étape de recrutement éventuel de nouveaux acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, L’étape de recrutement 504 comprend la réception de messages d’inscription de nouveaux acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn qui souhaitent s’inscrire sur la plateforme de gestion 6 et j’ajout de ces nouveaux acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, dans une étape de curation systémique 506, dans la base de données sécurisée. L’étape de curation systémique 506 est donc effectuée par la plateforme de gestion 6 pour mettre à jour la liste des acteurs se mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn avec les inscriptions de nouveaux acteurs de mobilité ou suppression d’anciens acteurs de mobilité dans la base de données sécurisée tenue à jour par la plateforme de gestion 6.
Après l’étape de recrutement 504 la plateforme de gestion 6 effectue l’étape de négociation 502.
Ensuite, dans une étape 508, la plateforme de gestion 6 obtient un accord pour la connexion avec au moins un des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn et l’utilisateur A2.
Dans une étape 510, la plateforme de gestion 6 établit les interconnexions entre la plateforme des utilisateurs 2 et les plateformes des acteurs de mobilité 4a, 4b, …, 4n. Dans un mode de réalisation, les interconnexions entre les plateformes est sont mises en œuvre à travers des API (pour « Application Program interface ») sécurisées entre les plateformes.
La illustre les étapes visant à recevoir les sollicitations (messages d’inscriptions) de l’utilisateur, ainsi que celles des acteurs de mobilité, avec notamment un filtrage possible des acteurs de mobilité, afin d’établir les canaux de connexion de la plateforme de gestion 6 avec l’utilisateur, d’une part, et avec les acteurs de mobilité, d’autre part.
Les Figures 3 à 5 suivantes illustrent les étapes visant à mettre en relation l’utilisateur A2 avec un acteur de mobilité, notamment l’acteur de mobilité identifié C1 mentionné ci-dessus.
En référence à la , la plateforme de gestion 6 reçoit, à l’étape 512, une requête de mobilité de l’utilisateur A2. Après, à l’étape de vérification 514, la plateforme de gestion 6 vérifie si l’utilisateur A2 est connu (car, par exemple, il a utilisé le service précédemment et ses données sont présentes dans la base de données sécurisée tenue à jour par la plateforme de gestion 6).
Dans le cas négatif, une étape de profilage 516 de l’utilisateur A2 est effectuée pour collecter les données de l’utilisateur A2 et les enregistrer dans la base de données sécurisée. Après, le procède poursuit à l’étape d’identification 518 décrite ci-dessous.
Dans le cas positif, une étape d’identification 518 est effectuée dans laquelle la plateforme de gestion 6 identifie l’acteur de mobilité C1 pertinent pour la mise en relation avec l’utilisateur A2, comme détaillé ci-dessous.
L’étape d’identification 518 comprend contacter l’ensemble des acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn qui sont pertinents selon un critère de similarité donné, pour rechercher et qualifier les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn intéressants. Dans la présente description, le terme « contacter » se réfère à l'envoi de données sous la forme d’un message de requête, attendant le plus souvent une réponse du destinataire du message, comme précisé ci-dessous avec référence au Figures 7 à 9.
En particulier, comme mentionné ci-dessus, les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn ont chacun défini précédemment de premiers paramètres de mobilité.
Les utilisateurs A1, …, An ont aussi chacun défini respectivement de deuxièmes paramètres de mobilité qui leurs sont propres, par exemple via des interfaces homme-machine connectées à des terminaux respectivement à disposition des utilisateurs. Des données de ces « deuxièmes paramètres » peuvent être par exemple : le trajet à parcourir souhaité, l’heure de départ, le nombre de personnes qui souhaitent se déplacer, l’évènement à participer, etc.
Ces deuxièmes paramètres de mobilité sont contenus dans la requête de mobilité.
Dans l’étape d’identification 518 l’acteur de mobilité C1 est identifié comme pertinent car ses premiers paramètres de mobilité sont identifiés comme similaires aux deuxièmes paramètres de mobilité de l’utilisateur A2.
Ainsi, dans une telle réalisation, la plateforme de gestion 6 dispose de ces premiers et deuxièmes paramètres provenant des terminaux des utilisateurs et des acteurs de mobilité et peut déterminer les premiers paramètres d’un acteur de mobilité qui sont les plus proches des deuxièmes paramètres d’un utilisateur. Le critère de similarité utilisé pour déterminer cette proximité des paramètres peut être basé sur des règles prédéfinies telles que les villes de départ et de destination doivent être identiques, mais les adresses de destination notamment peuvent différer, ou encore l’heure prévue d’arrivée peut être différente mais rester inférieure à une heure prévue d’arrivée de l’utilisateur (par exemple pour assister à un évènement qui commence à une heure donnée).
Dans une alternative de réalisation de la solution, plusieurs acteurs de mobilité Bp, C1, X1 (voir ) peuvent être identifiés comme pertinents selon un critère de priorité. Dans cette alternative, ces plusieurs acteurs de mobilité identifiés sont présentés à l’utilisateur A2 dans une liste ordonnée de plusieurs candidats, pour une sélection multiple. L’utilisateur A2 est donc interrogé pour vérifier s’il veut établir une connexion avec les acteurs de mobilité Bp, C1, X1 identifiés suivant cette priorité. Dans cette réalisation encore, l’ordre de priorité peut être fixé selon le critère précité de similarité (les premières données les plus proches étant en tête de liste).
La plateforme de gestion 6, à l’étape 520, contacte l’acteur de mobilité identifié C1. Dans une étape suivante 522, la plateforme de gestion 6 vérifie l’accord de l’acteur de mobilité identifié C1 pour cet utilisateur A2.
Le procédé continue alors comme illustré sur la et la plateforme de gestion 6, dans une étape 524, propose l’acteur de mobilité identifié C1 à l’utilisateur A2, par exemple par une notification sur son terminal.
Ensuite, dans une étape 526, la plateforme de gestion 6 vérifie une réception de l’accord de l’utilisateur A2 pour la mise en relation avec l’acteur de mobilité C1 choisi.
Dans le cas positif, la plateforme de gestion 6, à l’étape 528, met en relation l’utilisateur A2 avec l’acteur de mobilité identifié C1 en échangeant entre eux des jetons d’utilisateur et d’acteur de mobilité, comme détaillé en référence aux Figures 8 et 9.
Après, l’utilisateur A2 et l’acteur de mobilité identifié C1 effectuent un voyage ensemble.
Si aucun accord intervient entre l’utilisateur A2 et l’acteur de mobilité identifié C1, les étapes 518 à 528 sont répétées pour d’autres acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, sélectionnés selon l’ordre de priorité mentionné ci-dessus.
Le procédé peut se poursuivre comme illustré sur la avec une étape 530 de réception d'un message en provenance du terminal d'utilisateur, ce message étant indicatif d'aléas éventuels pendant le voyage (retards, embouteillages, pannes, etc.). Les aléas éventuels sont saisis par l'utilisateur sur son terminal Dans une étape 532, il est proposé à l’utilisateur A2 de noter éventuellement l’efficacité de la gestion des aléas, par l’acteur de mobilité identifié C1, jusqu’à la fin du parcours (par exemple au titre d’une évaluation à chaud).
Quand le voyage est terminé, le procédé selon la présente divulgation comprend en outre une étape de paiement 534 du voyage effectué et, dans certains modes de réalisation, ensuite, une étape d’évaluation 536 du voyage.
L’étape de paiement 534 peut aussi être mise en œuvre avant que le voyage soit effectué, par exemple en versant de l'argent vers la plateforme de gestion 6, puis la plateforme de gestion 6 effectue un paiement vers l'acteur de mobilité C1 une fois le voyage effectué.
En particulier, comme mentionné ci-dessus, l’étape de paiement 534 peut être effectuée à travers l’animation d’une interface homme-machine, sur le terminal au moins d’utilisateur, pour organiser un paiement de l’utilisateur A2 à l’acteur de mobilité identifié C1, pour le voyage effectué ensemble.
L’utilisateur A2 envoie un message de paiement à la plateforme des utilisateurs 2 qui transfert ce message vers la plateforme de gestion 6. La plateforme de gestion 6 effectue le paiement et envoie ensuite une confirmation du paiement à la plateforme des utilisateurs 2. La plateforme des utilisateur 2 transfert cette confirmation vers l’utilisateur A2.
De manière symétrique, l’acteur de mobilité identifié C1 envoie un message d’attente de paiement à la plateforme des acteurs de mobilité 4b qui transfert ce message vers la plateforme de gestion 6. La plateforme de gestion 6 effectue le paiement et envoie ensuite une confirmation du paiement effectué à la plateforme des acteurs de mobilité 4b. La plateforme des acteurs de mobilité 4b transfert cette confirmation vers l’acteur de mobilité identifié C1.
Eventuellement, des messages d’inscription peuvent en outre être échangés entre la plateforme de gestion 6 et les plateformes d’utilisateurs 2 et d’acteurs de mobilité 4b pour des services de souscriptions supplémentaires.
L’étape d’évaluation 536 peut être effectuée à travers l’animation d’une interface homme machine, sur le terminal à disposition de l’utilisateur A2 et sur un terminal de l’acteur de mobilité identifié C1, pour saisir une note d’évaluation (à froid typiquement) d’une qualité de voyage réalisé avec l’acteur de mobilité identifié.
Selon un mode de réalisation, une application s’exécute sur le terminal de l’utilisateur A2 pour présenter une interface homme machine afin que l’utilisateur A2 puisse saisir un score ou un commentaire d’évaluation et envoyer, via son terminal, un message d’évaluation du voyage à la plateforme des utilisateurs 2. La plateforme 2 transfert ce message vers la plateforme de gestion 6, qui termine les échanges avec la plateforme des utilisateurs 2 et met à jour la plateforme des acteurs de mobilité 4b qui, à son tour, met à jour l’acteur de mobilité identifié C1 avec les données de cette évaluation saisies par l’utilisateur A2 (par exemple un score d’évaluation noté sur cinq étoiles).
De manière symétrique, l’acteur de mobilité identifié C1 peut envoyer un message d’évaluation du voyage à la plateforme des acteurs de mobilité 4b qui le transfert vers la plateforme de gestion 6. La plateforme de gestion 6 termine les échanges avec la plateforme des acteurs de mobilité 4b et met à jour la plateforme des utilisateurs 2 qui, à son tour, met à jour l’utilisateur A2 avec cette évaluation.
Des informations d’évaluations contenues dans les messages d’évaluation du voyage sont mémorisées dans une mémoire.
La illustre le cas d’un acteur intermédiaire 14, par exemple d’une ville ou collectivité locale, qui souhaite exécuter un procédé de gestion d’un service de mobilité selon la présente description sous sa propre marque 14, en utilisant sa propre interface 10’ personnalisé par la plateforme de gestion 6.
Les bénéfices du procédé de gestion d’un service de mobilité selon la présente divulgation sont multiples :
- pour les sociétés évènementielles, pouvoir proposer activement à leur clientèle une solution de covoiturage. Elles pourraient donc proposer une solution qui renforce leur image auprès de leur clientèle ;
- pour les utilisateurs, bénéficier de la facilité de covoiturer avec des personnes ayant les mêmes centres d’intérêt qu’eux, avec une notion de praticité car dans ce cas l’aller et le retour sont proposés. Bien entendu, la confidentialité des données des utilisateurs (privacy) est protégée, via le système de jetons précité.
Sur la est illustrée une représentation schématique des messages échangés, pendant l'étape de négociation 502 mentionnée ci-dessus, pour établir de multiples interconnexions qui sont faites commercialement sur la base de négociations partenariales et techniquement via les API.
Une première flèche 100 indique l’établissement d’une connexion entre l’utilisateur A2 et la plateforme de gestion 6, une deuxième flèche 102 indique l’établissement d’une connexion entre un premier acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn (notamment l’acteur C1) et la plateforme de gestion 6 et une troisième flèche 104 indique l’établissement d’une connexion entre la plateforme de gestion 6 et un deuxième acteur de mobilité B1, …, Bn, C1, …, Cn, …, T1, …,Tn (notamment l’acteur T1). Aucune connexion directe entre l’utilisateur A2 et les acteurs de mobilité B1, …, Bn, C1, …, Cn, …, T1, …, Tn, ni entre les acteurs de mobilité T1 n’est effectuée.
Sur la est illustrée une représentation schématique des messages échangés entre la plateforme de gestion 6 et l’utilisateur A2 et entre la plateforme de gestion 6 et l’acteur de mobilité identifié C1 pour les mettre en relation pendant les étapes allant de l’étape 512 jusqu’à l’étape 528 mentionnées ci-dessus.
Une flèche 106 représente l’envoi d’une requête de mobilité de l’utilisateur A2, qui souhaite se déplacer selon les contenues des deuxièmes paramètres de mobilité, à la plateforme des utilisateurs 2, cette requête de mobilité étant transférée vers la plateforme de gestion 6 (flèche 106’). Les flèches 106 et 106’ correspondent ensemble à l’étape 512 de réception de la requête de mobilité mentionné ci-dessous.
Après la réception de la requête de mobilité, la plateforme de gestion 6 effectue l’étape d’identification 518 mentionnée ci-dessus.
A l’issue de ces premières connexions 100, 102, 104, 106, la plateforme de gestion 6 peut exécuter une tokenisation 18 visant à créer un jeton (ou « token » en anglais) d’utilisateur et un jeton d’acteur de mobilité identifié. Ces jetons sont générés pour une transaction donnée (par exemple à chaque nouvelle requête d’un utilisateur et à chaque réponse positive à cette requête émise par un acteur de mobilité) et sont sauvegardés dans la base de données sécurisée que peut utiliser la plateforme de gestion 6 pour gérer cette transaction.
La tokenisation 18, décrite en détail en référence à la ci-dessous, consiste à établir un jeton au moins pour chaque nouvelle entité se déclarant auprès de la plateforme de gestion 6. Ces jetons peuvent alors être utilisés lors de la transmission de cette requête de mobilité de l’utilisateur A2 (avec le jeton d’utilisateur) à l’acteur de mobilité identifié C1 et réciproquement lors d’une proposition de l’acteur de mobilité identifié C1 (avec le jeton d’acteur de mobilité) faite à l’utilisateur A2 en réponse à sa requête.
Pour la mise en œuvre de l’étape 18 de la commentée ici, les jetons respectifs d’utilisateur et d’acteur de mobilité sont établis à partir des données d’identité de l’utilisateur A2 et des données d’identité de l’acteur de mobilité identifié C1.
Typiquement, le jeton d’utilisateur représente une identité propre à l’utilisateur A2 (son nom, son adresse, une donnée de contact numérique telle que par exemple le numéro IMSI du téléphone de l’utilisateur et/ou son compte de réseau social et/ou une adresse email). Le jeton d’utilisateur peut être par exemple une signature numérique de ces données (par exemple un hash ou un cryptage avec une clé de sécurité) que seule la plateforme de gestion 6 peut utiliser afin de retrouver toutes les données initiales de l’utilisateur A2. Ainsi, la tokenisation est « irréversible » en ce sens que seule la plateforme de gestion 6 peut accéder aux données de l’utilisateur A2 à partir de son jeton.
Le jeton d’acteur de mobilité identifié C1 peut comporter des données d’identité (nom, adresse physique et numérique) de l’acteur C1, personne physique ou société de transport. Ces données sont acquises à l’issue des étapes d’inscription 500 et de négociation 502 de la .
Dans un mode de réalisation alternatif de l’invention, la tokenisation 18 peut être effectuée avant-même la réception de la requête de mobilité, par exemple lors de l’étape de négociation 502 ou, en référence à la , si l’utilisateur A2 n’est pas connu à l’étape 514, lors de l’étape de profilage 516, qui peut être accompagné de la création du jeton propre à l’utilisateur A2 et du jeton d’acteur de mobilité de tous les acteurs de mobilité qui se sont inscrits lors de l’étape l’inscription 500, avec enregistrement des jetons dans la base de données sécurisée.
Dans ce mode de réalisation, dans l’étape de négociation 502 (ou de profilage 516), des souhaits habituels de l’utilisateur A2 peuvent être collectés parmi les données d’identité précitées afin d’affiner son profil. En effet, ces données d’identité peuvent comporter typiquement des données personnelles comme le nom, l’adresse de l’utilisateur, etc., ainsi que d’autres données de préférences d’utilisateur, comme par exemple la préférence de privilégier autant que possible les voyages en train plutôt qu’en avion, ou autre. Par exemple, une page web peut être proposée à l’utilisateur A2 pour cliquer sur ses options préférées. En outre, il peut être collecté des données d’identité sur des contraintes du transport (personne en fauteuil roulant, présence d’enfants, etc.), ou autres. Ces données d’identité sont utilisées pour établir le jeton d’utilisateur.
Dans ce mode de réalisation, la plateforme de gestion 6 dispose alors soit du jeton d’utilisateur soit du jeton d’acteur de mobilité de tous les acteurs de mobilité qui se sont inscrits lors de l’étape l’inscription 500.
Ces données de jeton peuvent permettre à la plateforme de gestion 6 de choisir efficacement l’acteur de mobilité C1 répondant le mieux aux souhaits habituels de l’utilisateur A2, à l’étape d’identification 518 de la . La plateforme 6 peut par exemple réaliser un premier tri des acteurs de mobilité en fonction de ces données de jeton et ensuite sélectionner finalement l’un au moins des acteurs de mobilité identifié C1 sur la base de la demande spécifique de l’utilisateur A2 (destination particulière et/ou horaire de voyage et/ou mode de transport, souhaités, etc., selon les deuxièmes paramètres de la requête de mobilité).
Alternativement à une tokenisation préalable 18 avant toute transmission de requête d’un utilisateur (avec stockage en base de données sécurisée), la tokenisation peut être réalisée au fil de l’eau (au moment de transmettre la requête d’utilisateur et/ou au moment de transmettre la proposition de l’acteur de mobilité identifié C1 en réponse à une telle requête).
Ainsi, on comprendra que le terme « tokenisation » désigne aussi bien :
- l’affectation d’un jeton unique à un utilisateur donné ou à un acteur de mobilité donné (pour une ou plusieurs transactions subséquentes),
- que l’affectation d’un jeton unique par transaction, par exemple à un utilisateur donné, un jeton étant établi pour cet utilisateur à chacun de ses projets de voyage par exemple.
En se référant à nouveau à la , une flèche 108 indique l’envoie, par la plateforme de gestion 6 vers la plateforme des acteurs de mobilité 4b, d’une proposition, pour l’acteur de mobilité identifié C1, de connexion avec l’utilisateur A2, cette proposition étant transférée vers l’acteur de mobilité identifié C1 (flèche 108’). La plateforme des acteurs de mobilité 4b obtient un accord (flèche 110) de l’acteur de mobilité identifié C1 et envoie (flèche 110’) à la plateforme de gestion 6 une réponse d’acceptation de l’acteur de mobilité identifié C1 souhaitant établir une connexion avec l’utilisateur A2. Les flèches 108, 108’, 110 et 110’ correspondent ensemble aux étapes 520 et 522 de contact de l’acteur de mobilité identifié C1 et de réception de son accord mentionnés ci-dessus.
Une flèche 112 indique l’envoi, par la plateforme de gestion 6 vers la plateforme des utilisateurs 2, d’une proposition, pour l’utilisateur A2, de connexion avec l’acteur de mobilité identifié C1, cette proposition étant transférée vers l’utilisateur A2 (flèche 112’). La plateforme des utilisateurs 2 obtient un accord (flèche 114) de l’utilisateur A2 et envoie (flèche 114’) à la plateforme de gestion 6 une réponse d’acceptation de l’utilisateur A2 souhaitant établir une connexion avec l’acteur de mobilité identifié C. Les flèches 112, 112’, 114 et 114’ correspondent ensemble aux étapes 524 et 526 de proposition de l’acteur de mobilité identifié C1 à l’utilisateur A2 et d’obtention de son accord mentionnées ci-dessus.
Après la réception des accords (flèches 110 et 110’, 114 et 114’), la plateforme de gestion 6 met en connexion l’utilisateur A2 avec l’acteur de mobilité identifié C1 (étape 528) en échangeant entre eux le jeton d’utilisateur et le jeton d’acteur de mobilité, comme détaillée ci-dessous en référence à la . L’utilisateur A2 et l’acteur de mobilité identifié C1 effectuent alors le voyage ensemble, après échange des informations mutuelles à travers les jetons.
Dans un exemple, une société souhaite organiser le déplacement de ses salariés vers un évènement privé. Elle s’adresse donc à une plateforme d’organisation de transports en commun, définit la date et l’heure des voyages aller et retour, et le nombre de personnes à transporter. La plateforme d’organisation de transports en commun adresse la requête, via le système selon la présente description, à diverses sociétés de transports en commun en fournissant les détails du service demandé.
Ici interviendrait la valeur ajoutée de la plateforme de gestion 6 en tant que tiers de confiance, qui fournirait à la plateforme d’organisation de transports en commun un service d’orchestrateur, son expérience sur un historique de demandes et de qualité de services avec diverses sociétés de transport, et renverrait les diverses possibilités de mobilité à la société demandeuse. Cette société peut donc faire son choix, parmi un certain nombre de sociétés, en s’appuyant sur des données fiables de qualité de service, mises à jour dans la base de données précitée.
La tokenisation 18 de la est illustrée en détail sur la , à partir des données de l’utilisateur A2 pour le jeton d’utilisateur et des données de l’acteur de mobilité identifié C1 pour le jeton d’acteur de mobilité, pour une mise en relation entre l’utilisateur A2 et l’acteur de mobilité identifié C1 par échange de jetons.
Des données d’identité d’utilisateur 700 de l’utilisateur A2 sont connues par la plateforme de gestion 6, par exemple récupérées lors de l’étape d’inscription 500 ou de profilage 516 mentionnées ci-dessus.
Les données d’identité d’utilisateur 700 sont alors transformées, lors d’une première tokenisation 701 avec un premier code secret unique, en données d’identité d’utilisateur sécurisées 702 (pour former un jeton d’utilisateur). Les données d’identité sécurisées d’utilisateur 702 (ou « jeton d’utilisateur ») sont associées ensuite aux deuxièmes paramètres de mobilité 702a contenus dans la requête de mobilité pour former la proposition à l’acteur de mobilité identifié C1 (flèche 108).
Ainsi, on comprendra que si la tokenisation 18 est faite avant-même la réception de la requête de mobilité, le jeton d’utilisateur peut être mémorisé dans la base de données sécurisées (par exemple, lors de l’étape de négociation 502) et peut être récupéré par la plateforme de gestion 6 pour être associé, après la réception de la requête de mobilité, aux deuxièmes paramètres de mobilité 702a, afin d’être envoyés ensemble (flèche 108) à l’acteur de mobilité identifié C1.
La plateforme de gestion 6 connait aussi les données d’identité des acteurs de mobilité 704 et notamment celles de l’acteur de mobilité identifié C1, récupérées lors de l’étape d’inscription 500 (ou de recrutement 504) mentionnée ci-dessus.
Les données d’identité d’acteurs de mobilité 704 sont alors transformées, lors d’une deuxième tokenisation 705 avec un deuxième code secret unique, en données d’identité d’acteur de mobilité sécurisées 706 (jeton d’acteur de mobilité). Les données sécurisées d’identité d’acteur de mobilité 706 (ou « jeton d’acteur de mobilité ») sont associées ensuite aux premiers paramètres de mobilité 706a pour être partagées avec l’utilisateur A2 (flèche 112). Les premier et deuxième codes précités peuvent être différents ou identiques.
Ainsi, le jeton d’acteur de mobilité peut être mémorisé dans la base de données sécurisées (par exemple, lors de l’étape de négociation 502) et il est récupéré par la plateforme de gestion 6 pour être associé aux premiers paramètres de mobilité 706a, pour être envoyés ensemble (flèche 112) à l’utilisateur A2.
Quand la plateforme des acteurs de mobilité 4b envoie la réponse d’acceptation de l’acteur de mobilité identifié C1 (flèche 110’) à la plateforme de gestion 6, elle (la plateforme des acteurs de mobilité 4b) renvoie aussi le jeton d’utilisateur reçu lors de la proposition de connexion à la plateforme de gestion 6, de sorte que la plateforme de gestion 6 peut utiliser ce jeton afin d’identifier l’utilisateur A2 vers lequel cette réponse d’acceptation de l’acteur de mobilité identifié C1 doit être transférée.
La plateforme de gestion 6, après réception de la réponse d’acceptation de l’acteur de mobilité identifié C1 (‘flèche 110’), envoie à l’utilisateur A2 le jeton d’acteur de mobilité avec les premiers paramètres de mobilité 706a (flèche 112), et attend la réponse d’acceptation de l’utilisateur A2 (flèche 114’).
Seule la plateforme de gestion 6 dispose des clés de réversibilité afin d’accéder à nouveau en clair aux données d’identité de l’utilisateur et de l’acteur de mobilité. Ainsi, les échanges de données d’identité entre l’utilisateur A2 et l’acteur de mobilité identifié C1 ne sont pas accessibles respectivement à l’acteur de mobilité identifié C1 et à l’utilisateur A2.
Il s’agit alors d’une « tokenisation irréversible » en ce qu’elle permet à l’utilisateur A2 et à l’acteur de mobilité identifié C1 de se mettre en relation, tout en interdisant l’accès aux données d’utilisateurs A2 par l’acteur de mobilité identifié C1 (et éventuellement en interdisant aussi l’accès par l’utilisateur A2 aux données l’acteur de mobilité identifié C1). La tokenisation empêche ainsi l’acteur de mobilité identifié C1 de voir les données de l’utilisateur A2 et de les reconstruire, néanmoins sans l’aide de donnée tierces.
Les bénéfices de la solution de la présente solution sont multiples :
- pour la société demandeuse, la confiance dans la plateforme à laquelle elle s’adresse pour organiser le transport de ses salariés, mais aussi dans la dimension vertueuse des déplacements ;
- pour les salariés, la satisfaction d’être pris en charge avec une solution complète et « verte ».
- pour les plateformes organisatrices de transports en commun, l’assurance d’être en contact, pour les transactions, avec une plateforme de gestion 6 de confiance.
La présente solution est pleinement multimodale :
- elle simplifie la vie du grand public, mais aussi des sociétés organisatrices d’évènements, récurrents ou ponctuels ;
- elle permet la mise en relation de plateformes fédératrices B2B2C et B2B2B avec les personnes physiques ou morales, dans un climat de confiance, établi avec le système de jetons ;
- elle permet à la plateforme de gestion 6 de se positionner comme référent de confiance dans une chaîne de mise en relation de différents acteurs et clients de solutions de mobilité vertueuse.
La présente solution est évolutive : la plateforme de gestion 6 engrange toutes les transactions qui ont eu lieu et « apprend » l’historique des transactions (succès, aléas, évaluations, …) pour affiner ses modèles et constamment améliorer ses propositions aux différents acteurs mais aussi pour mieux mener la gestion des aléas.
L’objet de la présente description offre de nombreux avantages, en proposant typiquement une plateforme fédératrice s’interfaçant entre des entités B2B2C et B2B2B (la « plateforme de gestion d’un service de mobilité » telle que définie précédemment), laquelle gère alors l’interconnexion la plus pertinente entre les utilisateurs et les acteurs de mobilité, grâce à une gestion de jetons qui permet le rapprochement de profils, contextes, souhaits et contraintes, tout en préservant la confidentialité des données de l’ensemble des utilisateurs.
La plateforme peut préserver éventuellement la confidentialité des données des acteurs de mobilité également, notamment dans des mécanismes d’enchères entre acteurs de mobilité proposant une même prestation.
Cette plateforme fédératrice peut ainsi se présenter comme un tiers de confiance pour l’ensemble des acteurs, tant pour le recrutement, la mise en relation, la vérification des identités, que pour le paiement du service.
Le serveur de la plateforme de gestion 6 comporte un circuit de traitement de données pour la mise en œuvre d’un procédé de gestion d’un service de mobilité (recrutement, profiling, mise en relation, gestion des trajets, etc.) comme détaillé ci-dessus.
Le serveur est apte à exécuter le procédé présenté ci-avant. Typiquement, le serveur peut stocker notamment les données de code d’instructions d'un programme informatique au sens de la présente divulgation.
Le procédé de gestion d’un service de mobilité selon la présente divulgation assure la tokenisation des informations traitées afin qu’elles restent confidentielles et sécurisées.

Claims (11)

  1. Procédé de gestion d’un service de mobilité, comportant une mise en relation entre une plateforme d’utilisateurs (2) et au moins une plateforme d’acteurs de mobilité (4a, 4b, …, 4n), par échange de jetons d’utilisateur et d’acteur de mobilité, dans lequel au moins le jeton d’utilisateur est établi à partir de données de l’utilisateur par tokenisation irréversible.
  2. Procédé selon la revendication 1, dans lequel la mise en relation est mise en œuvre par une plateforme de gestion d’un service de mobilité (6) s’interfaçant entre la plateforme d’utilisateurs (2) et l’au moins une plateforme d’acteurs de mobilité (4a, 4b, …, 4n), la plateforme de gestion (6) interdisant, par ladite tokenisation irréversible, une visibilité des données d’utilisateurs pour la plateforme des acteurs de mobilité.
  3. Procédé de gestion d’un service de mobilité selon la revendication 1 ou 2, dans lequel l’au moins une plateforme d’acteurs de mobilité (4a, 4b, …, 4n) comprend des données de plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) comprenant, pour chaque acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn), de données d’identité et au moins un premier paramètre de mobilité et la plateforme d’utilisateurs (2) comprend des données de plusieurs utilisateurs (A1, A2, … , An) comprenant, pour chaque utilisateur, de données d’identité, le procédé comportant :
    - sur réception d’une requête de mobilité d’un utilisateur (A2) comprenant au moins un deuxième paramètre de mobilité, en provenance de la plateforme d’utilisateurs (2), identifier, parmi lesdits plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn), au moins un acteur de mobilité (C1) ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité de la requête de mobilité, selon un critère de similarité donné,
    - établir un jeton de l’utilisateur en fonction de données d’identité de l’utilisateur (A2), et transmettre le jeton d’utilisateur avec l’au moins un deuxième paramètre de mobilité audit au moins un acteur de mobilité identifié (C1) ayant l’au moins un premier paramètre de mobilité similaire à l’au moins un deuxième paramètre de mobilité ;
    - sur réception d’au moins une première réponse d’acceptation d’un acteur de mobilité identifié (C1) indiquant qu’il souhaite établir une connexion avec l’utilisateur (A2) selon l’au moins un premier paramètre de mobilité, établir, en fonction de données d’identité de l’acteur de mobilité identifié (C1), un jeton de l’acteur de mobilité identifié, et transmettre à l’utilisateur (A2) le jeton de l’acteur de mobilité identifié (C1) avec l’au moins un premier paramètre de mobilité.
  4. Procédé de gestion d’un service de mobilité selon la revendication 3, comportant en outre, après réception de la première réponse d’acceptation de l’acteur de mobilité identifié (C1), adresser à l’utilisateur (A2) une requête de vérification destinée à vérifier s’il veut établir une connexion avec l’acteur de mobilité identifiée (C1).
  5. Procédé de gestion d’un service de mobilité selon la revendication 4, dans lequel adresser à l’utilisateur (A2) une requête de vérification comporte :
    - envoyer à l’utilisateur (A2) une requête d’acceptation d’une connexion avec l’acteur de mobilité identifié (C1);
    - recevoir une deuxième réponse d’acceptation de l’utilisateur (A2) souhaitant établir une connexion avec l’acteur de mobilité identifié (C1).
  6. Procédé de gestion d’un service de mobilité selon l'une des revendications de 3 à 5, dans lequel plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) sont identifiés selon un critère de priorité et une requête de vérification est adressée à l’utilisateur (A2) pour vérifier s’il veut établir une connexion avec lesdits acteurs de mobilité identifié suivant cette priorité.
  7. Procédé de gestion d’un service de mobilité selon l'une des revendications de 3 à 6, dans lequel un recrutement desdits plusieurs acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) est effectué par inscription de nouveaux acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn) ou suppression d’anciens acteurs de mobilité (B1, …, Bn, C1, …, Cn, …, T1, …, Tn).
  8. Procédé de gestion d’un service de mobilité selon l’une des revendications précédentes, dans lequel la mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité est effectuée à travers des API respectives sécurisées.
  9. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes lorsque ce programme est exécuté par un processeur.
  10. Dispositif de gestion d’un service de mobilité comportant un serveur avec une interface de communication avec un réseau étendu pour la mise en relation entre une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, le serveur comportant un circuit de traitement pour la mise en œuvre du procédé selon l’une des revendications 1 à 8.
  11. Système de gestion d’un service de mobilité comportant un dispositif selon la revendication 10, une plateforme d’utilisateurs et au moins une plateforme d’acteurs de mobilité, le dispositif étant interconnecté auxdites plateformes pour agir en tant que plateforme de gestion d’un service de mobilité pour la mise en relation entre la plateforme d’utilisateurs et l’au moins une plateforme d’acteurs de mobilité.
PCT/EP2024/084243 2023-12-05 2024-12-02 Procédé de gestion d'un service de mobilité Pending WO2025119809A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2313551A FR3156224A1 (fr) 2023-12-05 2023-12-05 Procédé de gestion d’un service de mobilité
FRFR2313551 2023-12-05

Publications (1)

Publication Number Publication Date
WO2025119809A1 true WO2025119809A1 (fr) 2025-06-12

Family

ID=90458436

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/084243 Pending WO2025119809A1 (fr) 2023-12-05 2024-12-02 Procédé de gestion d'un service de mobilité

Country Status (2)

Country Link
FR (1) FR3156224A1 (fr)
WO (1) WO2025119809A1 (fr)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PALANISAMY ANANDHAKUMAR ET AL: "Decentralized Social Media Applications as a Service: a Car-Sharing Perspective", 2020 IEEE SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS (ISCC), IEEE, 7 July 2020 (2020-07-07), pages 1 - 7, XP033840312, DOI: 10.1109/ISCC50000.2020.9219617 *

Also Published As

Publication number Publication date
FR3156224A1 (fr) 2025-06-06

Similar Documents

Publication Publication Date Title
EP1327345B1 (fr) Procede de controle d'acces a des adresses de sites internet
EP1153376B1 (fr) Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
US20090216600A1 (en) Systems and methods for arranging a transport transaction
CN110414270B (zh) 一种基于区块链的个人数据保护系统及方法
EP3903069B1 (fr) Procédé et système de planification d'un trajet
EP1519288A1 (fr) Systeme et procede de covoiturage et dispositif de communication pour la mise en oeuvre du procede
KR20210105060A (ko) 맞춤검색이 가능한 부동산 거래 플랫폼 서버 및 그 부동산 거래방법
Hossan et al. Securing ride-sharing service using IPFS and hyperledger based on private blockchain
Anthony Jnr A decentralized prototype framework for peer-to-peer based electric car sharing services towards sustainable road transportation
EP2537286B1 (fr) Procédé d'authentification biométrique, système d'authentification et programme correspondant
JP2024177445A (ja) 着信者主導による通信方法及び通信システム及び電子決済システム
CN112732736B (zh) 信用更新方法及装置
WO2014086796A2 (fr) Gestion securisee d'une transaction de prestation de service
Gupta et al. A survey of peer-to-peer ride sharing services using blockchain
FR3156224A1 (fr) Procédé de gestion d’un service de mobilité
Stach Saving time, money and the environment-vHike a dynamic ride-sharing service for mobile devices
Tubis et al. Non-Technical Aspects of Safety in Scooter-Sharing System in Wroclaw
Tonin Uber: Disruptive innovation and regulation challenges
BE1019350A3 (fr) Usage d'une carte d'identite electronique en tant que carte d'affiliation.
Jahnavi et al. ShareRoute: Mobile Application for PickUp & DropOff Services
FR3153908A1 (fr) Procédé d’enregistrement de fichiers informatiques sur un serveur lié à une chaîne de blocs
FR3143144A1 (fr) Procédé de vente de jetons non-fongibles sur une chaîne de blocs
FR3113754A1 (fr) Système de gestion de contenus multimédias publiés via un réseau social, paramétré pour adapter la durée de diffusion d’un fichier à partager en fonction d’appréciations
FR3060172A1 (fr) Procede de transaction relative a un vehicule .
FR3106231A1 (fr) Procédé et système pour afficher sur une carte numérique, la position géographique de véhicules disponibles à la réservation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24817334

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE