FR3091392A1 - Procédé et système de gestion d’une flotte de véhicules partagés - Google Patents

Procédé et système de gestion d’une flotte de véhicules partagés Download PDF

Info

Publication number
FR3091392A1
FR3091392A1 FR1874382A FR1874382A FR3091392A1 FR 3091392 A1 FR3091392 A1 FR 3091392A1 FR 1874382 A FR1874382 A FR 1874382A FR 1874382 A FR1874382 A FR 1874382A FR 3091392 A1 FR3091392 A1 FR 3091392A1
Authority
FR
France
Prior art keywords
car
vehicle
serv
fleet
vehicles
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.)
Granted
Application number
FR1874382A
Other languages
English (en)
Other versions
FR3091392B1 (fr
Inventor
François Colon
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.)
Vulog SAS
Original Assignee
Vulog SAS
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 Vulog SAS filed Critical Vulog SAS
Priority to FR1874382A priority Critical patent/FR3091392B1/fr
Priority to US17/418,968 priority patent/US20220114501A1/en
Priority to PCT/FR2019/053295 priority patent/WO2020136353A1/fr
Priority to EP19850733.7A priority patent/EP3903256A1/fr
Publication of FR3091392A1 publication Critical patent/FR3091392A1/fr
Application granted granted Critical
Publication of FR3091392B1 publication Critical patent/FR3091392B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0645Rental transactions; Leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40Business processes related to the transportation industry

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • Game Theory and Decision Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Educational Administration (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)
  • Automation & Control Theory (AREA)

Abstract

L’invention concerne un procédé de gestion d’une flotte de véhicules partagés (CAR1-CAR7) par une pluralité d’utilisateurs (U1-U4), ledit procédé comportant les étapes suivantes :a) calcul, par un serveur informatique (SERV), d’un premier nombre de requêtes de réservation de véhicules de la flotte dans une zone géographique prédéterminée (GEO), b) détermination, par le serveur informatique (SERV), des positions géographiques des véhicules de la flotte (CAR1-CAR7) et calcul d’un second nombre de véhicules de la flotte disponibles (CAR3-CAR6) dans la zone géographique (GEO),c) comparaison, par le serveur informatique (SERV), du premier nombre et du second nombre,d) si le second nombre est inférieur au premier nombre, alors identification, par le serveur informatique (SERV), des véhicules de la flotte (CAR3-CAR5) : - qui sont indisponibles et en cours de fonctionnement ; - et dont la position géographique est située dans la zone géographique (GEO) ou à une distance prédéterminée de ladite zone géographique, e) génération, par le serveur informatique (SERV), d’une requête incitative incluant l’emplacement de la zone géographique (GEO),f) transmission automatique de cette requête incitative, depuis le serveur informatique (SERV) via une liaison sans fil, aux véhicules identifiés de la flotte (CAR3-CAR5) ou à au moins un équipement mobile des utilisateurs desdits véhicules identifiés. Figure à publier avec l’abrégé : Fig. 1

Description

Description
Titre de l'invention : Procédé et système de gestion d’une flotte de véhicules partagés
[0001] Domaine technique,
[0002] L’invention concerne un procédé et un système de gestion d’une flotte de véhicules partagés.
[0003] Le domaine de l’invention concerne notamment les méthodes pour libérer un véhicule partagé dans une zone géographique déterminée.
[0004] Etat de la technique,
[0005] Un service de partage de véhicule (en anglais « car-sharing ») ou véhicules en libreservice est un système dans lequel une société, une agence publique, une coopérative, une association, ou un groupe d'individus, met à la disposition de « clients » ou membres du service un ou plusieurs véhicules (ci-après « flotte de véhicules »). Plutôt que de disposer d'un véhicule personnel, l'utilisateur du service dispose d'un véhicule qu'il ne paye que pour la durée de son besoin. En d’autres termes, lorsqu’un utilisateur utilise un véhicule partagé, il est facturé d’un certain montant. Le montant facturé dépendant généralement du nombre de kilomètres parcourus et/ou du temps d’utilisation du véhicule et/ou du modèle ou type de véhicule. Le reste du temps, le véhicule est destiné à être utilisé par d'autres membres.
[0006] Il peut arriver qu’à une période donnée (par exemple chaque vendredi entre 18h et 20h) et dans une zone géographie particulière (par exemple à la sortie d’une gare de trains), la demande de réservation des véhicules soit très forte. A ce jour, aucune solution efficace n'incite un utilisateur à libérer son véhicule dans cette zone géographique et durant cette période donnée.
[0007] Le document US 2015/0206206 (PUENTE) décrit un procédé et un système d’échange de véhicules entre conducteurs. Un serveur peut enregistrer les requêtes de souhait de location d’un premier utilisateur et avertir un autre utilisateur enregistré que le premier utilisateur souhaite échanger ou louer son véhicule. Le système propose d’assister l’échange par la définition d’un lieu et d’une heure d’échange. La requête d’échange peut comprendre des données tarifaires ou de durée. Un inconvénient de ce système est que chaque utilisateur doit fixer un point de rendez-vous accepté d’un commun accord. Le système décrit ne propose pas de service à des gens souhaitant pouvoir disposer simplement un véhicule selon où ils se trouvent, sans avoir nécessairement à négocier avec d’autres utilisateurs.
[0008] Un objectif de l’invention est de remédier aux inconvénients précités. Un autre objectif de l’invention est de proposer une méthode permettant d’inciter efficacement des utilisateurs à libérer leur véhicule pour satisfaire les besoins d’autres utilisateurs de la communauté. Un autre objectif de l’invention est de proposer une solution pour mettre rapidement des véhicules à la disposition d’utilisateurs selon où ils se trouvent, sans avoir à négocier directement avec d’autres utilisateurs.
[0009] Présentation de l’invention.
[0010] La solution proposée par l’invention est un procédé de gestion d’une flotte de véhicules partagés par une pluralité d’utilisateurs, ledit procédé comportant les étapes suivantes :
a) calcul, par un serveur informatique, d’un premier nombre de requêtes de réservation de véhicules de la flotte dans une zone géographique prédéterminée,
b) détermination, par le serveur informatique, des positions géographiques des véhicules de la flotte et calcul d’un second nombre de véhicules de la flotte disponibles dans la zone géographique,
c) comparaison, par le serveur informatique, du premier nombre et du second nombre,
d) si le second nombre est inférieur au premier nombre, alors identification, par le serveur informatique, des véhicules de la flotte : - qui sont indisponibles et en cours d’utilisation ; - et dont la position géographique est située dans la zone géographique ou à une distance prédéterminée de ladite zone géographique,
e) génération, par le serveur informatique, d’une requête incitative incluant l’emplacement de la zone géographique,
f) transmission automatique de cette requête incitative, depuis le serveur informatique via une liaison sans fil, aux véhicules identifiés de la flotte ou à au moins un équipement des utilisateurs desdits véhicules identifiés.
[0011] Grâce à ce procédé, un grand nombre d’utilisateurs peuvent être incités à libérer leur véhicule partagé dans une zone géographique où la demande d’utilisation est forte. Le serveur informatique ne cible que les utilisateurs qui sont potentiellement les plus à même de libérer leur véhicule dans la zone concernée, ce qui permet d’accroître significativement l’efficacité du service. De plus, ces utilisateurs ciblés reçoivent automatiquement les requêtes incitatives depuis le serveur informatique, et non plus depuis d’autres utilisateurs en demande, à l’inverse de ce que préconise US 2015/0206206, ce qui permet d’éviter toute négociation entre utilisateurs. En outre, le serveur informatique évalue automatiquement et de manière autonome le taux de demandes d’utilisation et ne génère les requêtes incitatives que si la demande est supérieure à l’offre. Le serveur gère ainsi de manière autonome l’offre et la demande, optimisant de fait la pertinence du service.
[0012] D’autres caractéristiques avantageuses de l’invention sont listées ci-dessous. Chacune de ces caractéristiques peut être considérée seule ou en combinaison avec les caractéristiques remarquables définies ci-dessus, et faire l’objet, le cas échéant, d’une ou plusieurs demandes de brevet divisionnaires :
- Selon un mode de réalisation, à l’étape a), le calcul du premier nombre est opéré en prenant en compte le nombre de requêtes de réservation estimées, lequel nombre est basé sur un historique des requêtes de réservation effectives sur une période temporelle antérieure.
- Selon un mode de réalisation, à l’étape a), le calcul du premier nombre est opéré en prenant en compte le nombre de requêtes de réservation effectives à un instant donné. - Selon un mode de réalisation, l’étape e) comprend une sous-étape consistant à associée un coupon électronique de réduction de facturation à la requête incitative, lequel coupon a une validité limitée dans le temps.
- Selon un mode de réalisation, en outre les étapes suivantes :
g) génération et transmission d’un indicateur de disponibilité au serveur informatique, depuis un véhicule de la flotte rendu disponible ou depuis un équipement mobile de l’utilisateur dudit véhicule, via une liaison sans fil,
h) détermination, par le serveur informatique, de la position géographique dudit véhicule et d’un montant à facturer suite à l’utilisation dudit véhicule,
i) application, par le serveur informatique, de la réduction de facturation audit montant à facturer aux conditions suivantes : - la position géographique du véhicule correspond à l’emplacement de la zone géographique ; - et la requête incitative générée à l’étape e) a été transmise au véhicule ou à l’équipement mobile de l’utilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité de l’étape g) ; - et le coupon de réduction est valide.
- Selon un mode de réalisation, l’étape f) comprend une sous étape consistant à enregistrer, dans une zone mémoire du serveur, des identifiants des véhicules de la flotte auxquels a été transmise la requête incitative générée à l’étape e).
- Selon un mode de réalisation: l’étape g) comprend une sous étape consistant à associer un identifiant du véhicule à l’indicateur de disponibilité ; - à l’étape i), le serveur informatique compare l’identifiant associé à l’indicateur de disponibilité avec les identifiants enregistrés dans sa zone mémoire, pour déterminer si la requête incitative générée à l’étape e) a été transmise au véhicule ou à l’équipement mobile de l’utilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité de l’étape g).
- Selon un mode de réalisation, le procédé comprend en outre les étapes suivantes : g) génération et transmission d’un indicateur de disponibilité au serveur informatique, depuis un véhicule de la flotte rendu disponible ou depuis un équipement mobile de l’utilisateur dudit véhicule, via une liaison sans fil, le coupon de réduction étant associé audit indicateur de disponibilité si ledit coupon est valide,
h) détermination, par le serveur informatique, de la position géographique dudit véhicule et d’un montant à facturer suite à l’utilisation dudit véhicule,
i) application, par le serveur informatique, de la réduction de facturation audit montant à facturer, si la position géographique dudit véhicule correspond à l’emplacement de la zone géographique.
- Selon un mode de réalisation alternatif, le procédé comprend en outre les étapes suivantes :
g) génération et transmission d’un indicateur de disponibilité au serveur informatique, depuis un véhicule de la flotte rendu disponible ou depuis un équipement mobile de l’utilisateur dudit véhicule, via une liaison sans fil, le coupon de réduction étant associé audit indicateur de disponibilité,
h) détermination, par le serveur informatique, de la position géographique dudit véhicule et d’un montant à facturer suite à l’utilisation dudit véhicule,
i) application, par le serveur informatique, de la réduction de facturation audit montant à facturer, si la position géographique dudit véhicule correspond à l’emplacement de la zone géographique, et si le coupon de réduction est valide.
- Selon un mode de réalisation, l’étape e) comprend une sous étape consistant à inclure dans la requête incitative un ou plusieurs itinéraires d'acheminement vers l’emplacement de la zone géographique.
[0013] Un autre aspect de l’invention concerne un système de gestion d’une flotte de véhicules partagés par une pluralité d’utilisateurs, ledit système comportant un serveur informatique adapté pour communiquer, via des liaisons sans fil, avec les véhicules de la flotte, lequel serveur comporte au moins une unité de traitement, et au moins une mémoire comprenant une ou plusieurs applications informatiques dont les instructions, lorsqu’elles sont exécutées par ladite unité de traitement, permettent audit serveur : a) de calculer un premier nombre de requêtes de réservation de véhicules de la flotte dans une zone géographique prédéterminée,
b) de déterminer les positions géographiques des véhicules de la flotte et de calculer un second nombre de véhicules de la flotte disponibles dans la zone géographique,
c) de comparer le premier nombre et le second nombre,
d) si le second nombre est inférieur au premier nombre, alors identifier des véhicules de la flotte : - qui sont indisponibles et en cours de fonctionnement ; - et dont la position géographique est située dans la zone géographique ou à une distance prédéterminée de ladite zone géographique,
e) de générer une requête incitative incluant l’emplacement de la zone géographique, f) de transmettre automatiquement de cette requête incitative, via une liaison sans fil, aux véhicules identifiés de la flotte ou à au moins un équipement mobile des utilisateurs desdits véhicules identifiés.
[0014] D escription des figures.
D’autres avantages et caractéristiques de l’invention apparaîtront mieux à la lecture de la description d’un mode de réalisation préféré qui va suivre, en référence aux dessins annexés, réalisés à titre d’exemples indicatifs et non limitatifs et sur lesquels :
[fig.l] illustre un exemple de réalisation d’un système pour la mise en œuvre de l’invention,
[fig.2] est un exemple de réalisation des étapes d’un procédé conforme à l’invention.
[0015] Description des modes de réalisation,
[0016] Le procédé et le système objets de l’invention engendrent des manipulations d’éléments physiques, notamment des signaux (électriques ou magnétiques) et des données numériques, capables d'être stockés, transférés, combinés, comparés, ..., et permettant d’aboutir à un résultat souhaité.
[0017] L’invention met en œuvre une ou plusieurs applications informatiques exécutées par des équipements ou serveurs informatiques. Par souci de clarté, il faut comprendre au sens de l’invention que « un équipement ou serveur fait quelque chose » signifie « l'application informatique exécutée par une unité de traitement de Γéquipement ou du serveur fait quelque chose ». Tout comme « l'application informatique fait quelque chose » signifie « l'application informatique exécutée par Γunité de traitement de Γ équipement ou du serveur fait quelque chose ».
[0018] Encore par souci de clarté, la présente invention est susceptible de faire référence à un ou plusieurs « processus informatiques logiques ». Ces derniers correspondent aux actions ou résultats obtenus par l’exécution d’instructions de différentes applications informatiques. Aussi, il faut également comprendre au sens de l’invention que « un processus informatique logique est adapté pour faire quelque chose » signifie « les instructions d’une application informatique exécutées par une unité de traitement font quelque chose ».
[0019] Encore par souci de clarté, les précisions suivantes sont apportées à certains termes utilisés dans la description et les revendications :
- « Ressource informatique » peut être compris de façon non limitative comme : composant, matériel, logiciel, fichier, connexion à un réseau informatique, quantité de mémoire RAM, espace de disque dur, bande passante, vitesse de processeur, nombre de CPU, etc.
- « Serveur informatique » peut être compris de façon non limitative comme : dispositif informatique (matériel ou logiciel) comportant des ressources informatiques pour réaliser les fonctions d’un serveur et qui offre des services, ordinateur, pluralité d’ordinateurs, serveur virtuel sur internet, serveur virtuel sur Cloud, serveur virtuel sur une plate-forme, serveur virtuel sur une infrastructure locale, réseaux de serveurs, cluster, nœud, ferme de serveurs, ferme de nœuds, etc.
- « Service » peut être compris de façon non limitative comme l'ensemble des fonctionnalités proposé et assuré par un serveur et par au moins un équipement connecté audit serveur SERV par l’intermédiaire d’un réseau. Le service peut comprendre par exemple, les fonctionnalités suivantes : la réservation d’un véhicule partagé parmi une liste de véhicules disponibles, la localisation d’un véhicule partagé par exemple sur une carte numérique affichée sur un équipement utilisateur, la mise à disponibilité d’un véhicule partagé après une période d’utilisation, le déverrouillage à distance d’un véhicule partagé après une réservation validée, le verrouillage à distance d’un véhicule partagé après une fin d’utilisation d’un véhicule, etc.
- « Requête » désigne un ordre d'exécution pouvant suivre un protocole de communication et comprenant des paramètres en entrée (question, informations, ...) et éventuellement des paramètres en retour (réponse, information, ...), pouvant se présenter dans un format lié au protocole employé.
- « Unité de traitement » peut être compris de façon non limitative comme : processeur, microprocesseurs, CPU (pour Central Processing Unit).
- « Matériel informatique » représente une ou plusieurs pièces détachées d’un équipement informatique et peut être compris de façon non limitative comme hardware.
- « Application informatique » peut être comprise comme : logiciel, programme informatique, software, etc.
- « Réseau » peut être compris de façon non limitative comme : bus informatique, réseau personnel (PAN), réseau local (LAN, WLAN,..), réseau étendu (WAN), réseau internet, réseau intranet, réseau extranet. Le réseau informatique est un ensemble d'équipements informatiques reliés entre eux pour échanger, de manière sécurisée ou non, des informations et/ou des données selon un protocole de communication (ISDN, Ethernet, ATM, IP, CLNP, TCP, HTTP, ...).
- « Base de données » peut être comprise de façon non limitative comme un ensemble structuré et organisé de données enregistrées sur des supports accessibles par des équipements informatiques et pouvant être interrogées, lues et mises à jour. Des données peuvent y être insérées, récupérées, modifiées et/ou détruites. La gestion et l'accès à la base de données peuvent être assurés par un ensemble d’applications informatiques qui constituent un système de gestion de base de données (SGBD).
- « Véhicule partagé » ou véhicules en libre-service (en anglais « car sharing ») est un véhicule mis à la disposition de « clients » ou membres. Lorsqu’un utilisateur utilise un véhicule partagé, il est facturé d’un certain montant dépendant généralement du nombre de kilomètres parcourus et/ou du temps d’utilisation du véhicule et/ou du modèle ou type de véhicule. Le véhicule peut être une voiture, une voiture autonome, une moto, un vélo, une trottinette, un bateau, etc.
- « Flotte » ou « parc » peut être compris comme une pluralité de véhicules partagés appartenant à une société, une agence publique, une coopérative, une association, un groupe d'individus.
- Tel qu’utilisé ici, sauf indication contraire, l’utilisation des adjectifs ordinaux « premier», «deuxième», «troisième», etc., pour décrire un objet indique simplement que différentes occurrences d’objets similaires sont mentionnées et n’implique pas que les objets ainsi décrits doivent être dans une séquence donnée, que ce soit dans le temps, dans l'espace, dans un classement ou de toute autre manière.
[0020] Sur la figure 1, le système pour la mise du procédé objet de l’invention comprend un serveur informatique SERV, une flotte de véhicules partagés CARrCAR7, et des utilisateurs Ui-U4. La zone géographique GEO servant à exemplifier l’invention est ici une gare de trains. De manière plus générale, la zone géographique GEO peut consister en une position géographique spécifique (par exemple défini par une adresse ou des coordonnées GPS) ou une région géographique plus étendue incluant plusieurs points géographiques, par exemple le quartier d’une ville ( prédéfini dans une base de données et correspondant à une région définie par un code postal ou par une région délimitée par des rues et définissant des quartiers connus) ou une zone définissant un cercle ayant pour centre une position géographique spécifique (ex : le centre de la gare) et un rayon ou un diamètre prédéfini (ex : rayon de 200 m).
[0021] Les utilisateurs U1-U4 disposent chacun d’au moins un équipement mobile EQ1-EQ4 qui sont des équipements électroniques comportant une interface de communication, par exemple GSM, 3G, 4G ou Wifi, pour établir une liaison de communication sans fil avec le serveur SERV au travers d’un réseau NET. Ce dernier est par exemple un réseau internet, s’appuyant sur une infrastructure permettant d’acheminer des communications sans fil provenant des équipements EQrEQ4. Les équipements EQrEQ4 sont préférentiellement des téléphones intelligents (Smartphones), des tablettes numériques, des ordinateurs portables, etc. Ils comprennent les ressources informatiques, par exemple un code exécutable d’une application informatique téléchargeable, permettant de réaliser des fonctions du procédé de l’invention. Selon un mode de réalisation, chaque utilisateur Ui est enregistré auprès d’un serveur de gestion de droits qui peut être ou non le serveur distant SERV. Les utilisateurs Ui accèdent à un service correspondant à l’accès aux véhicules CAR1-CAR7. L’enregistrement d’un utilisateur peut être réalisé auprès d’un service web d’un serveur distant associé au service.
L’enregistrement comporte par exemple l’enregistrement d’un identifiant utilisateur Ui et une adresse réseau de l’équipement utilisateur EQi, il peut s’agir d’un port, d’une adresse IP, d’une adresse MAC ou toute autre adresse ou combinaisons d’éléments constituants des adresses permettant d’identifier un équipement utilisateur EQi. Selon un mode de réalisation, les utilisateurs Ui sont préinscrits à partir d’un logiciel et sont connus du fait qu’un identifiant est enregistré dans une base de données distante. Selon un mode de réalisation, une base de données associe un véhicule CAR; à un utilisateur Uj lorsque ce dernier utilise le véhicule CAR;. Selon un mode de réalisation, le serveur SERV comporte une fonction permettant de réaliser les associations.
[0022] Chaque véhicule CARrCAR7 est associé à un numéro d’identification unique. Chaque véhicule CARrCAR7 dispose avantageusement d’au moins un équipement CEQi- CEQ7 comportant une interface de communication, par exemple GSM, 3G, 4G ou Wifi, pour établir une liaison de communication sans fil avec le serveur SERV au travers d’un réseau NET. Les équipements CEQr CEQ7 sont préférentiellement des ordinateurs embarqués comprenant les ressources informatiques permettant de réaliser des fonctions du procédé de l’invention. A un instant donné, les véhicules CARrCAR7 peuvent être :
- avec un statut dit « Disponible » : le véhicule est stationné (garé) et non réservé,
- avec un statut dit « Indisponible » : soit le véhicule est stationné mais déjà réservé par un utilisateur (statut « Indisponible-Réservé »), soit le véhicule est en cours de fonctionnement (statut « Indisponible-en fonctionnement »). On considérera dans ce dernier cas qu’un utilisateur (non représenté sur la figure 1) est installé dans le véhicule et dispose d’un équipement électronique mobile similaire aux équipements EQ1-EQ4. [0023] Le serveur SERV met régulièrement à jour, préférentiellement en temps réel, une base de données des véhicules de la flotte. Cette base de données regroupe notamment : l’identifiant de chaque véhicule CAR;, leur statut (« Disponible » ou « Indisponible-Réservé » ou « Indisponible-en fonctionnement »), et leur position géographique. D’autres informations et/ou données peuvent être regroupées dans la base de données, le cas échéant. La base de données peut être enregistrée dans une zone mémoire du serveur SERV ou être distante dudit serveur et connectée à ce dernier.
[0024] L’information sur le statut d’un véhicule CAR; est transmise au server SERV en temps réel ou a des intervalles de temps prédéfinis (par exemple toutes les 5 minutes). Cette information peut être transmise au serveur SERV :
- par l’équipement embarqué CEQ; du véhicule CAR; suite à une détection d’un évènement. Cet évènement est par exemple généré par une action de l’utilisateur sur une commande spécifique aménagé sur le tableau de bord du véhicule CAR;. Cette commande peut être actionnée lorsque l’utilisateur a stationné son véhicule et libéré le véhicule. Le statut passe alors de « Indisponible-en fonctionnement » à « Disponible »,
- par l’équipement EQj de l’utilisateur Uj du véhicule CAR;, consécutivement à une action dudit l’utilisateur sur son équipement. L’utilisateur peut par exemple actionner une touche dédiée affichée sur un écran tactile de son équipement, après avoir stationné et libéré son véhicule. Le statut passe alors de « Indisponible-en fonctionnement » à « Disponible ».
Lorsque le serveur SERV reçoit une requête de réservation de la part d’un utilisateur et qu’il peut faire droit à cette requête (c’est-à-dire qu’un véhicule est disponible à la réservation), ledit serveur fait passer le statut d’un véhicule de « Disponible » à « Indisponible-Réservé ». Cette requête de réservation peut par exemple être générée via un équipement EQj ou via une application informatique auquel l’utilisateur Uj est abonné.
[0025] La position géographique peut être obtenue par satellite (système GPS ou Galileo) ou par un système de triangulation (par exemple, un système utilisant les cellules d’un réseau 4G) ou par une combinaison des deux systèmes de localisation. L’équipement CEQi d’un véhicule CAR; comporte avantageusement un composant, par exemple un composant GPS, permettant d’obtenir une information de géo-localisation qui peut être récupérée par le serveur SERV. Le serveur SERV peur récupérer automatiquement cette information en interrogeant en temps réel ou a intervalles de temps régulier (par exemple toutes les 5 minutes), les équipements CEQi des véhicules. Les équipements des véhicules peuvent également transmettre automatiquement cette information au serveur SERV (sans répondre à une requête d’interrogation), en temps réel ou a intervalles de temps régulier (par exemple toutes les 5 minutes). Selon une alternative, la position géographique d’un véhicule CAR; peut correspondre à une position définie à partir d’une interface de saisie d’un équipement EQj d’un utilisateur Uj utilisant le véhicule CAR;. Par exemple, l’utilisateur Uj peut évaluer une position à partir d’une carte interactive affichée sur une interface graphique de son équipement EQj. Cette position est ensuite transmise au serveur SERV.
[0026] Dans l’exemple de la figure 1, les véhicules CARi et CAR2 sont stationnés à proximité de la gare GEO (par exemple dans un parking dédié) et sont libres (statut « Disponible »). Les véhicule CAR3-CAR6 sont en fonctionnement (statut « Indisponible-en fonctionnement ») et le véhicule CAR7 est stationné mais déjà réservé par un utilisateur (statut « Indisponible-Réservé »). Les utilisateurs UrU4 sont dans la gare de trains GEO, ou à proximité de celle-ci, et souhaitent faire une réservation de véhicule dans cette zone. Pour ce faire, ils transmettent au serveur SERV une requête de réservation, qui est par exemple générée depuis leur équipement EQi EQ4 ou via une application informatique auquel les utilisateurs sont abonnés.
[0027] Les utilisateurs UrU4 indiquent la zone géographique où ils souhaitent récupérer leur véhicule. La localisation de cette zone géographique peut être par défaut la position géographique des utilisateurs UrU4 au moment où ils transmettent leur requête de réservation. Cette position peut être obtenue par satellite (système GPS ou Galileo) ou par un système de triangulation (par exemple, un système utilisant les cellules d’un réseau 4G) ou par une combinaison des deux systèmes de localisation. Chaque équipement EQrEQ4 comporte avantageusement un composant, par exemple un composant GPS, permettant d’obtenir une information de géo-localisation qui est automatiquement incluse dans la requête de réservation. Dans une variante de réalisation, lors de la génération de la requête de réservation, l’utilisateur renseigne la zone géographique où il souhaite récupérer son véhicule. Cette zone peut par exemple être renseignée depuis d’une carte interactive affichée sur une interface graphique de son équipement. La position de cette zone géographique est ensuite jointe à la requête de réservation et transmise au serveur SERV.
[0028] Dans le cadre de la présente invention, le serveur SERV analyse les requêtes de réservation des utilisateurs U1-U4 et constate que ces derniers souhaitent récupérer leur véhicule dans la même zone géographique, ici la gare de train GEO. De manière générale, le serveur SERV peut définir que plusieurs utilisateurs souhaitent récupérer leur véhicule dans une même zone géographique lorsque les positions renseignées par chaque utilisateur sont concentrées dans un cercle de diamètre prédéfini, par exemple un cercle dont diamètre est compris entre 50 m et 1 km. Dans l’exemple de la figure 1, la zone géographique GEO de la gare peut être définie par un cercle dont le centre correspond au point central de ladite gare et dont le diamètre est de 400 m. Le serveur SERV peut ainsi calculer un premier nombre de requêtes de réservation dans la zone géographique GEO. Ici, le premier nombre de requête est égal à 4, soit le nombre des utilisateurs U1-U4.
[0029] Le serveur SERV interroge alors la base de données pour déterminer les véhicules de la flotte dont la position géographique est incluse dans la zone géographique GEO et qui sont libres (statut « Disponible »). Dans l’exemple de la figure 1, le serveur SERV calcule que seuls les véhicules CARi et CAR2 sont disponibles dans la zone GEO. Le nombre de véhicules disponibles dans la zone géographique GEO, dénommé second nombre, est ici égal à 2.
[0030] Le serveur SERV va comparer le premier nombre (demande) et le second nombre (offre). Si le second nombre est supérieur ou égal au premier nombre (offre supérieure ou égale à la demande), alors le serveur SERV va gérer les réservations de manière classique et affecter un véhicule à chacun des utilisateurs U1-U4.
[0031] Si le second nombre est inférieur au premier nombre (offre inférieure à la demande), le serveur SERV va mettre en œuvre un processus informatique logique conduisant à inciter d’autres utilisateurs à libérer leur véhicule dans la zone GEO géographique. Tel est le cas dans l’exemple de la figure 1, où il y seulement 2 véhicules disponibles, CAR 1 et CAR2, alors que 4 requêtes de réservation ont été reçues par le serveur SERV. Ce dernier identifie des véhicules qui sont indisponibles et en cours d’utilisation (statut « Indisponible-en fonctionnement »), et dont la position géographique est située dans la zone géographique GEO et/ou à une distance prédéterminée de ladite zone géographique.
[0032] Le serveur SERV interroge la base de donnée est sélectionne les véhicules CAR3 CAR6 qui sont indisponibles et en cours de fonctionnement (statut « Indisponible-en fonctionnement »). Le véhicule CAR7 n’est pas sélectionné car son statut est « Indisponible-Réservé ».
[0033] Le serveur SERV sélectionne parmi les véhicules sélectionnés CAR3-CAR6, ceux dont la position géographique est située dans la zone géographique GEO ou à une distance prédéterminée de ladite zone. Par exemple, le serveur SERV peut identifier les véhicules situés dans un rayon de 10 km de la zone géographique GEO. Plus particulièrement sur la figure 1, le serveur SERV défini une zone élargie GEO’ incluse dans un cercle dont le centre correspond au point central de la gare et dont le diamètre est de 20 km. Tous les véhicules inclus dans cette zone élargie GEO’ sont retenus par le serveur SERV. Sur la figure 1, les véhicules CAR3-CAR5 sont sélectionnés. Le véhicule CAR6étant en dehors de la zone élargie GEO’, il n’est pas retenu par le serveur SERV. Pour ce véhicule CAR6, le processus est masqué, l'utilisateur dudit véhicule n’étant pas informé par le serveur SERV. Selon une alternative, la zone élargie GEO’ est définie non pas en terme de distance spatiale, mais en terme de distance temporelle. Par exemple, le serveur SERV retient les véhicules qui sont susceptibles de mettre moins de 10 minutes (ou un autre temps déterminé) pour rejoindre la zone géographique GEO. Grâce à cette sélection, le serveur SERV ne cible que les utilisateurs et véhicules qui ont le plus de chances d’être libérés dans la zone géographiques GEO, ce qui permet d’accroître le niveau de l’offre.
[0034] Le serveur SERV génère, une requête incitative incluant l’emplacement (ou coordonnées géographiques) de la zone géographique GEO. Un ou plusieurs itinéraires d'acheminement vers l’emplacement de la zone géographique GEO peuvent être inclus dans cette requête. Dans un exemple, les itinéraires d'acheminement prennent en compte le trafic routier de manière à proposer le chemin le plus rapide pour arriver à la zone géographique GEO. Ces itinéraires sont calculés en prenant comme point de départ la position géographique des véhicules CAR3-CAR5. Les itinéraires peuvent donc être différents d’un véhicule à un autre.
[0035] Les requêtes sont dites « incitatives » en ce sens qu’elles incitent les utilisateurs des véhicules CAR3-CAR5 à libérer leur véhicule dans la zone géographique GEO. Pour ce faire, les requêtes peuvent inclure des données permettant d’afficher un message du type « en libérant votre véhicule dans la zone GEO, vous rendez service à d’autres utilisateurs de la communauté ». Pour inciter davantage les utilisateurs, les requêtes incluent avantageusement une donnée de réduction de facturation, qui s’apparente à un coupon de réduction électronique. En d’autres termes, et comme expliqué plus avant dans la description, l’incitation est financière : une réduction est appliquée sur le montant facturé si l’utilisateur libère effectivement son véhicule dans la zone géo graphique GEO. Le besoin en véhicules dans la zone géographique GEO est généralement limité dans le temps, par exemple un vendredi entre 18h et 20h. En dehors de cette période, la demande de réservation peut ne souffrir d’aucun pic. Aussi, on prévoit avantageusement que le coupon réduction a une validité limitée dans le temps, par exemple le vendredi 31 décembre 2018 entre 18h et 20h. Au-delà de cette heure et de cette date, plus aucune réduction de facturation ne sera accordée.
[0036] Le serveur SERV transmet ces requêtes aux véhicules CAR3-CAR5 sélectionnés, au travers du réseau NET. Ces requêtes sont dans ce cas directement reçues par les équipements embarqués CEQ3-CEQ5 desdits véhicules. A réception de ces requêtes, les équipements CEQ3-CEQ5 peuvent afficher sur une interface graphique aménagée dans les véhicules CAR3-CAR5, l’emplacement de la zone géographique GEO (par exemple localisé sur la carte), éventuellement accompagné d’un ou plusieurs itinéraires d'acheminement et d’un message incitatif du type « en libérant votre véhicule dans la zone GEO, vous rendez service à d’autres utilisateurs de la communauté » ou « en libérant votre véhicule dans la zone GEO, vous bénéficierez d’une réduction de X €sur votre facture ». Ce message incitatif mentionne également la durée de validité de l’offre de réduction, par exemple « offre valable le vendredi 31 décembre 2018 de 18h à 20h ». Dans une variante de réalisation, le serveur SERV transmet les requêtes aux équipements mobile (ex : Smartphones) des utilisateurs des véhicules CAR3-CAR5. Cette transmission est réalisée au travers du réseau NET. A réception de ces requêtes, les équipements peuvent afficher sur leur interface graphique, l’emplacement de la zone géographique GEO, éventuellement accompagné d’un ou plusieurs itinéraires d'acheminement et d’un message incitatif du type « en libérant votre véhicule dans la zone GEO, vous rendez service à d’autres utilisateurs de la communauté » ou « en libérant votre véhicule dans la zone GEO, vous bénéficierez d’une réduction de X €sur votre facture. Offre valable le vendredi 31 décembre 2018 de 18h à 20h ». Dans une autre variante de réalisation, le serveur SERV transmet les requêtes non seulement aux équipements embarqués CEQ3-CEQ5 des véhicules CAR3-CAR5 mais également aux équipements des utilisateurs desdits véhicules. Quel que soit le mode de réalisation, les utilisateurs sont automatiquement avertis par le serveur SERV, et de manière centralisée.
[0037] Prenons l’exemple où l’utilisateur du véhicule CAR3 répond favorablement à la requête incitative, en ce sens qu’il libère son véhicule dans la zone géographique GEO. Un indicateur de disponibilité du véhicule CAR3 est alors transmis au serveur SERV, permettant d’indiquer à ce dernier que le véhicule CAR3 est disponible à nouveau. Comme expliqué précédemment, l’indicateur de disponibilité peut être généré et transmis depuis l’équipement embarqué CEQ3 du véhicule CAR3 suite à la détection d’un évènement. Cet évènement est par exemple généré par une action de l’utilisateur sur une commande spécifique aménagé sur le tableau de bord du véhicule CAR3 lorsqu’il a stationné et libéré ledit véhicule. L’indicateur de disponibilité peut également être généré et transmis depuis l’équipement mobile (ex : Smartphones) de l’utilisateur du véhicule CAR3, consécutivement à une action dudit l’utilisateur sur son équipement. L’utilisateur peut par exemple actionner une touche dédiée affichée sur un écran tactile de l’équipement, après avoir stationné et libéré son véhicule.
[0038] Le serveur SERV détermine la position géographique du véhicule CAR3 Comme indiqué précédemment, cette position géographique peut être obtenue par satellite, par triangulation ou par une combinaison des deux systèmes de localisation. La position géographique peut encore être générée par l’équipement mobile de l’utilisateur et transmise en même temps que l’indicateur de disponibilité. Le serveur SERV détermine également le montant à facturer suite à l’utilisation du véhicule CAR3.
[0039] Le serveur SERV compare la position géographique du véhicule CAR3 et la position de la zone géographique GEO. Si la position géographique du véhicule CAR3 correspond à l’emplacement de la zone géographique GEO, alors le serveur SERV applique la réduction de facturation au montant à facturer. Par exemple, si le montant initial à facturer est de 20€ et que la réduction est de 5€, alors le serveur SERV ne facturera que 15€ à l’utilisateur du véhicule CAR3. A l’inverse, si la position géographique du véhicule CAR3 ne correspond pas à l’emplacement de la zone géographique GEO, alors le serveur SERV n’appliquera pas la réduction de facturation au montant à facturer : 20€ seront facturés à l’utilisateur. Comme mentionné précédemment, la réduction de facturation n’est accordée que si la donnée de facturation est encore valide, c’est-à-dire que rutilisateur a bien libéré son véhicule dans la zone géographique GEO pendant la période de validité de l’offre de réduction (vendredi 31 décembre 2018 de 18h à 20h).
[0040] La réduction n’est en outre accordée qu’aux utilisateurs ayant volontairement fait la démarche de satisfaire les besoins d’autres utilisateurs. Il ne paraît pas justifier d’accorder une réduction aux utilisateurs ayant libéré leur véhicule de manière hasardeuse dans la zone géographique GEO. Aussi la réduction n’est accordée que si la requête incitative a été transmise au véhicule CAR3 ou à l’équipement mobile de rutilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité.
[0041] Plusieurs méthodes permettent au serveur SERV de savoir si la requête incitative a été transmise à un véhicule ou à l’équipement mobile de rutilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité. Selon un mode de réalisation, le serveur SERV enregistre, dans une zone mémoire, les identifiants des véhicules CAR3-CAR5 auxquels a été transmise la requête incitative. Lorsque l’indicateur de disponibilité est transmis au serveur SERV, l’équipement CEQ3 du véhicule CAR3 rendu disponible ou l’équipement mobile de l’utilisateur dudit véhicule, intègre ou joint à cet indicateur, l’identifiant dudit véhicule. A réception de l’indicateur de disponibilité, il suffit alors au serveur SERV de comparer l’identifiant associé à l’indicateur de disponibilité avec les identifiants enregistrés dans sa zone mémoire. Si l’identifiant correspond à un identifiant enregistré, alors le serveur SERV peut déterminer si la requête incitative a été transmise au véhicule CAR3 ou à l’équipement de l’utilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité, ledit serveur appliquant alors la réduction. Dans le cas contraire, le serveur SERV n’applique pas la réduction.
[0042] Selon un autre mode de réalisation, si le coupon de réduction est valide (i.e. qu’il n’est pas périmé), il est associé à l’indicateur de disponibilité. Cette association est opérée par l’équipement CEQ3 du véhicule CAR3 rendu disponible, ou par l’équipement mobile de l’utilisateur dudit véhicule. Pour savoir s’il doit appliquer la réduction, le serveur SERV doit simplement vérifier que la position géographique du véhicule CAR3 correspond à l’emplacement de la zone géographique GEO. En effet, dans la mesure où le coupon de réduction est associé à l’indicateur de disponibilité, le serveur SERV en déduit automatiquement que la requête incitative a été transmise au véhicule CAR3 ou à l’équipement mobile de l’utilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité et que le coupon de réduction est valide. Comparé au mode de réalisation décrit précédemment, ce mode de réalisation est particulièrement avantageux car il le nombre de calculs effectués par le serveur SERV est réduit, ce qui permet de consommé moins d’énergie et de solliciter moins de ressources informatiques.
[0043] Selon un autre mode de réalisation, le coupon de réduction est systématiquement associé à l’indicateur de disponibilité, que ledit coupon soit valide ou périmé. Pour savoir s’il doit appliquer la réduction, le serveur SERV doit donc vérifier, outre la position géographique du véhicule CAR3, la validité du coupon de réduction.
[0044] Dans les modes de réalisation décrits aux paragraphes précédents, le serveur SERV calcule le premier nombre de requêtes de réservation effectives, à un instant donnée, et définie sa stratégie en fonction des véhicules effectivement disponibles à un instant donné. Le but de cette stratégie étant que l’offre de véhicules arrive à compenser la demande de réservation, dans une zone géographique spécifique.
[0045] Selon un autre mode de réalisation, le serveur SERV est configuré pour anticiper un potentiel déséquilibre entre les offres de véhicules et les demandes de réservation, dans une zone géographique donnée. Pour ce faire, le serveur SERV calcul le premier nombre de requêtes de réservation en prenant en compte le nombre de requêtes de réservation estimées, basé sur un historique des requêtes de réservation effectives sur une période temporelle antérieure. En s’appuyant sur un apprentissage machine (machine leaming en anglais, qui est une branche de l’intelligence artificielle), le serveur SERV peut avoir la capacité d’anticiper des situations potentiellement problématiques, en ce sens où, dans des zones géographiques données, les offres de véhicules pourraient être inférieures aux demandes de réservation. En analysant l’évolution des requêtes de réservation reçues, le serveur SERV peut anticiper qu’à une période donnée et dans une zone géographie particulière, la demande de réservation de véhicules est systématiquement très forte. Par exemple, le serveur SERV peut déceler que chaque vendredi de l’année, entre 18h et 20h, à la sortie d’une gare de trains spécifique, il y a en moyenne 15 demandes de réservation.
[0046] En se basant sur l’exemple de la figure 1, prenons l’hypothèse où deux véhicules CARi et CAR2 sont stationnés à proximité de la gare GEO et sont libres (statut « Disponible »). Si à 18h, seulement deux utilisateurs Ui-U2 transmettent une requête de réservation au serveur SERV, celui-ci va constater que le premier nombre de requêtes de réservation effectives (=2) correspond au second nombre de véhicules disponibles (=2). Si le calcul du premier nombre est opéré en ne prenant en compte que le nombre de requêtes de réservation effectives à 18h, alors le serveur SERV ne va mettre en œuvre le processus informatique logique permettant de générer et transmettre les requêtes incitatives. Cela peut être problématique, car ce processus logique ne sera mis en œuvre qu’à la réception d’une nouvelle requête en réservation (ex : à 18hl0). Il faut un certain temps avant que des utilisateurs avertis libèrent leur véhicule à proximité de la gare GEO (ex : pas avant 18h20). Les utilisateurs ayant requis une réservation devront donc patienter un certain laps de temps avant de récupérer un véhicule disponible.
[0047] Au contraire, si le serveur SERV prend en compte l’historique des requêtes de réservation, il va anticiper qu’environ 15 demandes de réservation vont être requises. Le premier nombre calculé par le serveur SERV va donc être égal à 15 et non pas à 2, ce premier nombre étant supérieur au second nombre de véhicules disponibles (=2). Dès 18h, et préférentiellement avant cette heure (ex : dès 17h50), le serveur SERV va pouvoir mettre en œuvre le processus logique permettant de générer et transmettre les requêtes incitatives. Les utilisateurs avertis vont ainsi pouvoir atteindre la gare GEO plus rapidement et libérer leur véhicule en avance, de sorte que les utilisateurs ayant requis une réservation patienteront moins longtemps.
[0048] Selon un autre mode de réalisation, le serveur SERV va calculer le premier nombre de requêtes de réservation en prenant en compte : le nombre de requêtes de réservation effectives à un instant donné, et le nombre de requêtes de réservation estimées, basé sur l’historique des requêtes de réservation effectives sur une période temporelle antérieure. Par exemple, le serveur SERV commence par considérer uniquement un nombre estimé qui est basé sur l’historique des requêtes de réservation (ex : 15 requêtes estimées). Puis, dès que le nombre de requêtes de réservation effectives dépasse ce nombre estimé (ex : à partir de 16 requêtes effectives), le serveur SERV ne considère que ce nombre effectif. Cette technique permet d’optimiser la réduction du temps d’attente des utilisateurs ayant requis une réservation, au début de la période de forte demandes, puis de gérer en temps réel le rééquilibrage entre l’offre et la demande lorsque le nombre de demande de réservation effectives dépasse le nombre de demandes estimées.
[0049] L’invention concerne également un produit programme d’ordinateur comportant des instructions pour la mise en œuvre des différentes étapes du procédé de l’invention. Les étapes peuvent être réalisées par un programme d’ordinateur enregistré dans la mémoire du serveur SERV et dont les instructions sont exécutées par l’unité de traitement dudit serveur. Selon différents modes de réalisation, des étapes du procédé peuvent être réalisées par un ou plusieurs équipements EQ;, CEQj.
[0050] La figure 2 représente un synoptique des principales étapes d’un procédé selon l’invention. La figure 2 schématise cinq entités déjà représentées à la figure 1, à savoir les équipements mobiles EQ1-EQ4 des utilisateurs U1-U4, le serveur SERV et l’équipement CEQ d’un véhicule CAR. Selon un mode préféré de réalisation :
- Les étapes notées GEN_REQ_RESA schématise la génération des requêtes de réservation depuis les équipements mobiles EQ1-EQ4 des utilisateurs UrU4.
- Ces requêtes de réservation sont transmises au serveur SERV qui calcule alors le premier nombre de requêtes de réservation dans la zone géographique prédéterminée. Cette étape de calcul est notée CAL_NB1.
- Dans une étape POS_GEO, le serveur SERV détermine les positions géographiques des véhicules de la flotte et sélectionne ceux qui sont localisés dans la zone géographique concernée.
- A l’étape CAL_NB2, le serveur SERV calcule un second nombre, qui correspond au nombre de véhicules localisés dans la zone géographique concernée et ayant un statut « Disponible ».
L’ordre des étapes POS_GEO et CAL_NB2 peut être inversé : le serveur SERV recherche d’abord les véhicules ayant un statut « Disponible » puis sélectionne parmi ces véhicules ceux qui sont localisés dans la zone géographique concernée.
- A l’étape COMP_NB, le serveur SERV compare le premier nombre et le second nombre.
- Si le second nombre est inférieur au premier nombre, alors, dans une étape IDEN_VEHI, le serveur SERV identifie les véhicules qui ont un statut « Indisponible-en fonctionnement », et dont la position géographique est située dans la zone géographique concernée ou à une distance prédéterminée de celle-ci.
- A l’étape GEN_REQ_INCI, le serveur SERV génère une requête incitative incluant l’emplacement de la zone géographique concernée. Le coupon de réduction de facturation (étape REDU) et/ou un ou plusieurs itinéraires d'acheminement vers l’emplacement de la zone géographique concernée (étape ITIN), peuvent être associés à la requête incitative. Cette requête (et le cas échéant le coupon de réduction et/ou les itinéraires) est automatiquement transmise aux véhicules identifiés à l’étape IDEN_VEHI.
- Dans une étape ENR_ID_VEHI, le serveur SERV peut enregistrer dans une zone mémoire, les identifiants des véhicules identifiés à l’étape IDEN_VEHI et auxquels la requête incitative a été transmise.
- L’étape ACCEPT_REQ_INCI illustre la réception de la requête incitative par l’équipement CEQ d’un véhicule identifié à l’étape IDEN_VEHI.
- A l’étape GEN_INDI, l’équipement CEQ du véhicule génère un indicateur de disponibilité, l’utilisateur ayant libéré ledit véhicule dans la zone géographique concernée. Un identifiant du véhicule peut être associé à l’indicateur de disponibilité (étape ID_VEHI). Le coupon de réduction peut également être associé à cet indicateur (étape REDU_VEHI). Cet indicateur (et le cas échéant l’identifiant du véhicule et/ou le coupon de réduction) est transmis au serveur SERV.
- A l’étape POS_GEO_VEHI, le serveur SERV détermine la position géographique du véhicule ayant transmis l’indicateur de disponibilité.
- A l’étape EACT, le serveur SERV détermine le montant à facturer, avec application de la réduction (étape APPLI_REDU) si les conditions d’application de la réduction sont réunies.
Les étapes ACCEPT_REQ_INCI, GENJNDI, ID_VEHI, REDU_VEHI peuvent être réalisées par un équipement mobile des utilisateurs des véhicules identifiés à l’étape IDEN_VEHI.
[0051] L’agencement des différents éléments et/ou moyens et/ou étapes de l’invention, dans les modes de réalisation décrits ci-dessus, ne doit pas être compris comme exigeant un tel agencement dans toutes les implémentations. Notamment, une ou plusieurs caractéristiques exposées seulement dans un mode de réalisation peuvent être combinées avec une ou plusieurs autres caractéristiques exposées seulement dans un autre mode de réalisation. En particulier, le coupon de réduction peut être utilisé ultérieurement par un utilisateur, afin d’obtenir une réduction de facturation sur une autre course. En complément ou en substitution du coupon de réduction, le serveur SERV peut joindre à la requête incitative, un bon électronique offrant aux utilisateurs un service supplémentaire, par exemple l’accès sans frais supplémentaire, à un modèle de véhicule haut de gamme.

Claims (1)

  1. Revendications [Revendication 1] Procédé de gestion d’une flotte de véhicules partagés (CARrCAR7) par une pluralité d’utilisateurs (Ui-U4), ledit procédé comportant les étapes suivantes : a) calcul, par un serveur informatique (SERV), d’un premier nombre de requêtes de réservation de véhicules de la flotte dans une zone géographique prédéterminée (GEO), b) détermination, par le serveur informatique (SERV), des positions géographiques des véhicules de la flotte (CAR1-CAR7) et calcul d’un second nombre de véhicules de la flotte disponibles (CAR3-CAR6) dans la zone géographique (GEO), c) comparaison, par le serveur informatique (SERV), du premier nombre et du second nombre, d) si le second nombre est inférieur au premier nombre, alors identification, par le serveur informatique (SERV), des véhicules de la flotte (CAR3-CAR5) : - qui sont indisponibles et en cours de fonctionnement ; - et dont la position géographique est située dans la zone géographique (GEO) ou à une distance prédéterminée de ladite zone géographique, e) génération, par le serveur informatique (SERV), d’une requête incitative incluant l’emplacement de la zone géographique (GEO), f) transmission automatique de cette requête incitative, depuis le serveur informatique (SERV) via une liaison sans fil, aux véhicules identifiés de la flotte (CAR3-CAR5) ou à au moins un équipement mobile des utilisateurs desdits véhicules identifiés. [Revendication 2] Procédé selon la revendication 1, dans lequel à l’étape a), le calcul du premier nombre est opéré en prenant en compte le nombre de requêtes de réservation estimées, lequel nombre est basé sur un historique des requêtes de réservation effectives sur une période temporelle antérieure. [Revendication 3] Procédé selon l’une des revendications 1 ou 2, dans lequel à l’étape a), le calcul du premier nombre est opéré en prenant en compte le nombre de requêtes de réservation effectives à un instant donné. [Revendication 4] Procédé selon l’une des revendications 1 à 3, dans lequel l’étape e) comprend une sous-étape consistant à associée un coupon électronique de réduction de facturation à la requête incitative, lequel coupon a une validité limitée dans le temps. [Revendication 5] Procédé selon la revendication 4, comprenant en outre les étapes
    suivantes : g) génération et transmission d’un indicateur de disponibilité au serveur informatique (SERV), depuis un véhicule de la flotte (CAR3) rendu disponible ou depuis un équipement mobile de l’utilisateur dudit véhicule, via une liaison sans fil, h) détermination, par le serveur informatique (SERV), de la position géographique dudit véhicule (CAR3) et d’un montant à facturer suite à l’utilisation dudit véhicule, i) application, par le serveur informatique (SERV), de la réduction de facturation audit montant à facturer aux conditions suivantes : - la position géographique du véhicule (CAR3) correspond à l’emplacement de la zone géographique (GEO), et - la requête incitative générée à l’étape e) a été transmise au véhicule (CAR3) ou à l’équipement mobile de l’utilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité de l’étape g), et - le coupon de réduction est valide. [Revendication 6] Procédé selon l’une des revendications 1 à 5, dans lequel l’étape f) comprend une sous étape consistant à enregistrer, dans une zone mémoire du serveur (SERV), des identifiants des véhicules de la flotte auxquels a été transmise la requête incitative générée à l’étape e). [Revendication 7] Procédé selon la revendication 6 prise en combinaison avec la revendication 5, dans lequel : - l’étape g) comprend une sous étape consistant à associer un identifiant du véhicule à l’indicateur de disponibilité, - à l’étape i), le serveur informatique (SERV) compare l’identifiant associé à l’indicateur de disponibilité avec les identifiants enregistrés dans sa zone mémoire, pour déterminer si la requête incitative générée à l’étape e) a été transmise au véhicule (CAR3) ou à l’équipement mobile de l’utilisateur dudit véhicule, préalablement à la génération de l’indicateur de disponibilité de l’étape g). [Revendication 8] Procédé selon la revendication 4, dans lequel le procédé comprend en outre les étapes suivantes : g) génération et transmission d’un indicateur de disponibilité au serveur informatique (SERV), depuis un véhicule de la flotte (CAR3) rendu disponible ou depuis un équipement mobile de l’utilisateur dudit véhicule, via une liaison sans fil, le coupon de réduction étant associé audit indicateur de disponibilité si ledit coupon est valide, h) détermination, par le serveur informatique (SERV), de la position
    géographique dudit véhicule (CAR3) et d’un montant à facturer suite à l’utilisation dudit véhicule, i) application, par le serveur informatique (SERV), de la réduction de facturation audit montant à facturer, si la position géographique dudit véhicule (CAR3) correspond à l’emplacement de la zone géographique (GEO). [Revendication 9] Procédé selon la revendication 4, dans lequel le procédé comprend en outre les étapes suivantes : g) génération et transmission d’un indicateur de disponibilité au serveur informatique (SERV), depuis un véhicule de la flotte (CAR3) rendu disponible ou depuis un équipement mobile de l’utilisateur dudit véhicule, via une liaison sans fil, le coupon de réduction étant associé audit indicateur de disponibilité, h) détermination, par le serveur informatique (SERV), de la position géographique dudit véhicule (CAR3) et d’un montant à facturer suite à l’utilisation dudit véhicule, i) application, par le serveur informatique (SERV), de la réduction de facturation audit montant à facturer, si la position géographique dudit véhicule (CAR3) correspond à l’emplacement de la zone géographique (GEO), et si le coupon de réduction est valide. [Revendication 10] Procédé selon l’une des revendications 1 à 9, dans lequel l’étape e) comprend une sous étape consistant à inclure dans la requête incitative un ou plusieurs itinéraires d'acheminement vers l’emplacement de la zone géographique (GEO). [Revendication 11] Système de gestion d’une flotte de véhicules partagés (CARrCAR7) par une pluralité d’utilisateurs (Ui-U4), ledit système comportant un serveur informatique (SERV) adapté pour communiquer, via des liaisons sans fil, avec les véhicules (CARrCAR7) de la flotte, lequel serveur comporte au moins une unité de traitement, et au moins une mémoire comprenant une ou plusieurs applications informatiques dont les instructions, lorsqu’elles sont exécutées par ladite unité de traitement, permettent audit serveur : a) de calculer un premier nombre de requêtes de réservation de véhicules de la flotte dans une zone géographique prédéterminée (GEO), b) de déterminer les positions géographiques des véhicules de la flotte (CARi-CAR7) et de calculer un second nombre de véhicules de la flotte disponibles (CAR3-CAR6) dans la zone géographique (GEO), c) de comparer le premier nombre et le second nombre,
    d) si le second nombre est inférieur au premier nombre, alors identifier des véhicules de la flotte (CAR3-CAR5) : - qui sont indisponibles et en cours de fonctionnement ; - et dont la position géographique est située dans la zone géographique (GEO) ou à une distance prédéterminée de ladite zone géographique,
    e) de générer une requête incitative incluant l’emplacement de la zone géographique (GEO),
    f) de transmettre automatiquement de cette requête incitative, via une liaison sans fil, aux véhicules identifiés de la flotte (CAR3-CAR5) ou à au moins un équipement mobile des utilisateurs desdits véhicules identifiés.
FR1874382A 2018-12-28 2018-12-28 Procédé et système de gestion d’une flotte de véhicules partagés Active FR3091392B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1874382A FR3091392B1 (fr) 2018-12-28 2018-12-28 Procédé et système de gestion d’une flotte de véhicules partagés
US17/418,968 US20220114501A1 (en) 2018-12-28 2019-12-24 Method and system for transmitting a prompt request
PCT/FR2019/053295 WO2020136353A1 (fr) 2018-12-28 2019-12-24 Procédé et système de transmission d'une requête incitative
EP19850733.7A EP3903256A1 (fr) 2018-12-28 2019-12-24 Procédé et système de transmission d'une requête incitative

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1874382A FR3091392B1 (fr) 2018-12-28 2018-12-28 Procédé et système de gestion d’une flotte de véhicules partagés

Publications (2)

Publication Number Publication Date
FR3091392A1 true FR3091392A1 (fr) 2020-07-03
FR3091392B1 FR3091392B1 (fr) 2021-01-29

Family

ID=67107621

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1874382A Active FR3091392B1 (fr) 2018-12-28 2018-12-28 Procédé et système de gestion d’une flotte de véhicules partagés

Country Status (4)

Country Link
US (1) US20220114501A1 (fr)
EP (1) EP3903256A1 (fr)
FR (1) FR3091392B1 (fr)
WO (1) WO2020136353A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016029168A1 (fr) 2014-08-21 2016-02-25 Uber Technologies, Inc. Organisation d'un service de transport pour un utilisateur d'après le temps d'arrivée estimé de l'utilisateur
US10721327B2 (en) 2017-08-11 2020-07-21 Uber Technologies, Inc. Dynamic scheduling system for planned service requests
US20210248520A1 (en) * 2020-02-12 2021-08-12 Uber Technologies, Inc. Timing optimization for transiting users of an on-demand transport service
US11669786B2 (en) 2020-02-14 2023-06-06 Uber Technologies, Inc. On-demand transport services
DE102022207417A1 (de) 2022-07-20 2024-01-25 Volkswagen Aktiengesellschaft Verfahren und Steuereinrichtung zum Betreiben einer Mietwagenflotte sowie Mietwagenflotte

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150206206A1 (en) 2014-01-23 2015-07-23 Cox Enterprises, Inc. Systems and methods for flexible vehicle sharing
US20150348178A1 (en) * 2014-05-30 2015-12-03 Verizon Patent And Licensing Inc. Method and System for Renting and Sub-Renting Vehicles
US20160203435A1 (en) * 2013-09-05 2016-07-14 Toyota Motor Europe Nv/Sa Systems and methods for managing a vehicle fleet
EP3121769A1 (fr) * 2014-03-19 2017-01-25 Nissan Motor Co., Ltd. Programme et dispositif de gestion de véhicule partagé

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3258430A4 (fr) * 2015-02-13 2018-07-11 Beijing Didi Infinity Technology and Development Co., Ltd. Procédé et système de planification de capacité de transport
US20170193625A1 (en) * 2015-12-21 2017-07-06 Lyft, Inc. Driver supply control

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160203435A1 (en) * 2013-09-05 2016-07-14 Toyota Motor Europe Nv/Sa Systems and methods for managing a vehicle fleet
US20150206206A1 (en) 2014-01-23 2015-07-23 Cox Enterprises, Inc. Systems and methods for flexible vehicle sharing
EP3121769A1 (fr) * 2014-03-19 2017-01-25 Nissan Motor Co., Ltd. Programme et dispositif de gestion de véhicule partagé
US20150348178A1 (en) * 2014-05-30 2015-12-03 Verizon Patent And Licensing Inc. Method and System for Renting and Sub-Renting Vehicles

Also Published As

Publication number Publication date
WO2020136353A1 (fr) 2020-07-02
EP3903256A1 (fr) 2021-11-03
US20220114501A1 (en) 2022-04-14
FR3091392B1 (fr) 2021-01-29

Similar Documents

Publication Publication Date Title
FR3091392A1 (fr) Procédé et système de gestion d’une flotte de véhicules partagés
EP3903069B1 (fr) Procédé et système de planification d'un trajet
US10371542B2 (en) System and methods for performing multivariate optimizations based on location data
CA2658482C (fr) Systeme et procede de gestion interoperables de services multiples geolocalisables
EP3987502B1 (fr) Procédé et système de gestion de places de stationnement
US20170132541A1 (en) Systems and methods for crowd-sourcing parking space
JP2004178385A (ja) カーシェアリング支援システム、カーシェアリング支援方法およびコンピュータプログラム
EP2150930A2 (fr) Procédé et système permettant de mettre un véhicule public individuel à la disposition d'un utilisateur
EP2537286B1 (fr) Procédé d'authentification biométrique, système d'authentification et programme correspondant
FR3047102A1 (fr) Procede de detection de passagers, de gestion et d'optimisation de leurs transports partages
WO2019086796A1 (fr) Procede de mise a disposition d'un vehicule et de sa restitution dans un parc de vehicules disponibles a la reservation, procede de reservation d'un vehicule, systeme
EP4085402A1 (fr) Procede et systeme pour activer l'acces a un vehicule stationne dans un lieu non couvert par un reseau de donnees
EP1998532A1 (fr) Système d'agrégation de services pour une plateforme de télécommunication
WO2021144535A1 (fr) Procede et systeme pour incorporer des positions geographiques de vehicules disponibles a la reservation dans une carte numerique
BE1027166B1 (fr) Procédé permettant de transporter une pluralité d'usagers et de marchandises
WO2023001914A1 (fr) Procede et systeme pour controler le deplacement de vehicules autonomes appartenant a une flotte de vehicules partages
EP4374305A1 (fr) Procédé et système pour modifier la durée de mise en veille et/ou la fréquence de réactivation et/ou la durée de réveil d'un équipement informatique embarqué dans un véhicule appartenant à une flotte de véhicules partagés
FR2942897A1 (fr) Procede et systeme de gestion d'une flotte de vehicule
FR3125621A1 (fr) Procédé et système pour commander l’activation de bornes de recharges de véhicules électriques
FR3047334A1 (fr) Systeme et procede de traitement et partage des donnees sur une region geographique preconfiguree et determinee
FR3104369A1 (fr) Procédé de communication de données d’un véhicule connecté
FR2924508A1 (fr) Procede et systeme pour mettre a la disposition d'un utilisateur un vehicule public individuel
FR3023404A1 (fr) Systeme innovant de gestion dynamique du stationnement
FR3010219A1 (fr) Procede, dispositif et installation pour la validation d'un titre dematerialise

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200703

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6