Brevet FR3076651A1 — publié le 20190712

PROCEDE DE MISE A JOUR D'UN INDICATEUR DE DISPONIBILITE D'UN VEHICULE POUR SA RESERVATION DOMAINE L'invention concerne un procédé de mise a jour d'un indicateur de disponibilité d'un véhicule pour sa réservation. Le domaine de l'invention concerne notamment les méthodes pour réserver, rendre disponible un véhicule afin de le restituer dans un parc de véhicules disponibles à la réservation. Le domaine de l'invention concerne plus particulièrement les procédés mis en oeuvre à partir d'un téléphone intelligent ou d'un équipement électronique portable utilisé pour libérer ou accéder à un véhicule non couvert par un réseau de données. ETAT DE L'ART Il existe des procédés pour réserver et mettre à disposition un véhicule, notamment automobile. Dans ces méthodes, généralement un véhicule personnel ou d'une flotte professionnelle est mis à disposition au sein d'un parc de véhicules. On connait des solutions permettant de réserver et d'activer l'ouverture du véhicule au moyen d'un terminal mobile. Le document US2015/0137943 décrit une telle solution. Le terminal mobile est dans ce cas utilisé pour interroger un serveur distant afin de vérifier la disponibilité des véhicules, d'en sélectionner un et de requérir les autorisations d'accès au véhicule. Dans cette solution, le véhicule a lui-même des moyens d'accès à un réseau et peut remonter des informations vers un serveur distant notamment sur sa disponibilité. Le serveur peut alors transmettre des informations directement au véhicule. Il existe des solutions dans lesquelles le véhicule et le terminal s'échangent des informations, par exemple, un statut du véhicule ou bien même des informations de publicité. 2 Le document US2011/0034128 décrit une telle solution. Le véhicule et le terminal d'un usager d'un service échangent des informations notamment sur une fin d'utilisation du véhicule. Dans ce cas, le terminal est capable, par exemple, d'éteindre un véhicule. Les données peuvent, en 5 outre, être remontées à un serveur distant afin d'être enregistrées. Or, il existe un problème lorsque le véhicule est garé, par exemple, dans un lieu non couvert par un réseau de données. Cela peut se produire dans des parkings souterrains ou dans des garages clos. Dans ce dernier cas, après une utilisation d'un véhicule, ce dernier 10 ne peut pas communiquer à un serveur distant son état, par exemple un état de disponibilité. RESUME DE L'INVENTION L'invention vise à pallier les inconvénients précités. 15 La solution proposée par l'invention est un procédé de mise à jour d'une base de données pour la restitution d'un véhicule comportant les étapes suivantes : - Génération d'un indicateur de disponibilité du véhicule à partir d'un calculateur du véhicule ; 20 Transmission automatique d'un ensemble d'information comportant ledit indicateur de disponibilité à au moins un équipement utilisateur d'un premier utilisateur via une liaison sans fil de courte portée ; Enregistrement de l'ensemble d'information dans une mémoire de 25 l'équipement jusqu'à une détection ultérieure d'un accès à un réseau de données ; Transmission automatique de l'ensemble d'information comportant ledit indicateur de disponibilité à un serveur distant depuis l'équipement utilisateur via une liaison sans fil permettant un accès 30 à un réseau de données ; Mise à jour d'une base de données modifiant un statut de disponibilité véhicule au sein d'un parc de véhicules par un calculateur du serveur distant. 3 L'équipement utilisateur est ici utilisé comme une passerelle informatique. Cet équipement est un vecteur de transport, notamment de l'indicateur de disponibilité, qui est naturellement plus rapide à retrouver un réseau de données pour communiquer avec le serveur distant vu qu'il est 5 porté par un utilisateur. Les données peuvent ainsi être remontées au serveur distant afin d'être enregistrées, même lorsque le véhicule est garé dans un lieu non couvert par un réseau de données. D'autres caractéristiques avantageuses de l'invention sont listées 10 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 : - la génération de l'indicateur de disponibilité est 15 avantageusement généré consécutivement à: une commande numérique générée suite à l'arrêt du véhicule ou de son système de gestion électrique et/ou ; une commande numérique générée suite à la fermeture d'une portière et/ou; une commande numérique générée suite à la réception d'un message à partir d'une interface de communication sans fil provenant 20 d'un terminal utilisateur comportant une donnée de fin d'utilisation. - Avantageusement, la transmission automatique de l'ensemble d'information est réalisée après une première tentative échouée de transmission et un premier enregistrement de ladite information dans une mémoire du premier équipement. 25 - La liaison de courte portée est préférentiellement une liaison Bluetooth. - L'ensemble d'information comprend avantageusement : un identifiant du véhicule ; une adresse IP ou une URL ; un secret partagé avec un serveur distant ; un jeton comportant un horodatage. 30 - Le procédé peut comprendre, en outre, les étapes suivantes : comparaison des jetons et des identifiants reçus d'une pluralité de messages reçus provenant d'une pluralité d'équipements ; suppression des indicateurs de disponibilité en doublon provenant d'un même véhicule. 4 - La mise à jour de la base de données du serveur distant peut comprendre en outre les étapes suivantes: enregistrement d'une nouvelle localisation de stationnement du véhicule ; enregistrement de données d'usage comportant l'une au moins des données suivantes : 5 o Temps d'utilisation ; O Kilomètres parcourus ; o Déclenchement d'évènements (airbag, alerte révision, etc.). - Le procédé peut comprendre une étape de modification du statut de disponibilité du véhicule pour sa réservation par un second utilisateur 10 comportant : identification du second utilisateur enregistré dans une base de données d'un service d'accès à un parc de véhicules ; génération d'un indicateur de libre accès d'un véhicule ; première transmission par un serveur à destination d'au moins un second utilisateur d'un ensemble d'information comportant l'indicateur de libre accès ; seconde transmission 15 automatique de l'ensemble d'information comportant ledit indicateur de libre accès à au moins un véhicule via une liaison sans fil de courte portée ; enregistrement de l'ensemble d'information reçu par le véhicule dans une mémoire dudit véhicule ; activation d'un déverrouillage de l'accès au véhicule. 20 - L'indicateur de libre accès est avantageusement associé à l'identifiant d'un second utilisateur, le second ensemble d'information transmis au véhicule comportant en outre un identifiant utilisateur. - Le procédé peut comprendre en outre l'étape suivante : réception par le serveur d'une demande d'accès à un véhicule par le second 25 utilisateur préalablement à la génération d'un indicateur de libre accès. - Avantageusement, le procédé comprend consécutivement à l'identification du second utilisateur une comparaison entre au moins une position du véhicule et une position dudit second utilisateur afin d'activer la génération d'un indicateur de libre accès pour le second utilisateur à 30 transmettre au véhicule. - Avantageusement, le procédé comprend consécutivement à la demande d'accès, une sélection d'un véhicule à partir du second équipement parmi une liste de véhicules générée par ledit serveur. - Avantageusement, le procédé comprend les étapes suivantes : 5 Détection d'un accès à un réseau de données via une liaison sans fil , Transmission automatique par l'équipement du véhicule de données véhicule et de données d'association avec le nouvel 5 utilisateur vers le serveur distant permettant un accès à un réseau de données ; Mise à jour d'une base de données modifiant un statut de disponibilité véhicule au sein d'un parc de véhicules par un calculateur du serveur distant. 10 Un autre aspect de l'invention concerne un système comportant au moins un terminal mobile et un serveur pour la mise en oeuvre de l'une quelconque des étapes du procédé défini précédemment. 15 BREVE DESCRIPTION DES FIGURES D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description détaillée qui suit, en référence aux figures annexées, qui illustrent : 20 - figure 1 : une représentation d'un cas d'usage de l'invention lorsqu'un véhicule d'un parc susceptible d'être réservé en ligne n'est pas couvert par un réseau de données ; figure 2: un exemple de réalisation d'une mise en oeuvre des étapes de l'invention afin de modifier un statut de disponibilité de 25 véhicule. DESCRIPTION Accès au service 30 Dans la suite de la description, on appellera "un service" : l'ensemble des fonctionnalités proposé et assuré par le serveur SERV et par au moins un équipement EQi connecté au serveur SERV par l'intermédiaire d'un réseau de données. Le service peut comprendre par exemple, les fonctionnalités suivantes : 6 - la réservation d'un véhicule parmi une liste de véhicules disponibles. - la localisation d'un véhicule par exemple sur une carte numérique affichée sur l'équipement utilisateur EQ; ; 5 - la mise à disponibilité d'un véhicule réservé après une période d'utilisation ; - le déverrouillage à distance d'un véhicule après une réservation validée ; - le verrouillage à distance d'un véhicule après une fin 10 d'utilisation d'un véhicule du parc ; Etc. La figure 1 représente quatre entités dont un premier équipement EQ1 d'un utilisateur U1, un second équipement EQ2 d'un second utilisateur U2, un serveur distant, noté SERV, et un équipement EC)cAR disposé dans un 15 véhicule CAR. Le véhicule CAR est un véhicule d'un parc de véhicules dédiés à la location pour des utilisateurs abonnés à un service. Authentification au service, enregistrement 20 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 à un ensemble de véhicules d'un parc. Selon un mode de réalisation, l'enregistrement d'un utilisateur est 25 réalisé auprès d'un service web d'un serveur distant associé au service. L'enregistrement comporte l'enregistrement d'un identifiant utilisateur Ui et une adresse réseau @EQi 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 30 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 35 données associe un véhicule CAR à un utilisateur U1 lorsque ce dernier 7 utilise un véhicule CAR. Selon un mode de réalisation, le serveur SERV comporte une fonction permettant de réaliser les associations. Dans le cadre de l'invention, un équipement utilisateur est utilisé par le véhicule comme un relai pour transmettre des données à un serveur 5 distant SERV. Les échanges entre l'équipement du véhicule EQcAR et un équipement utilisateur EQ1, peuvent donc comprendre des données d'authentification. Au lancement du programme, l'équipement EQ1 et l'équipement EQc,AR tentent d'établir une connexion courte portée LaDi afin d'échanger un 10 message M1 pour qu'il soit transmis via un réseau de données NET à un serveur distant SERV. Le message M1 peut alors, par exemple, comprendre une donnée permettant de délivrer à l'utilisateur U1 certains droits temporaires afin qu'il puisse échanger des données avec le serveur distant SERV, notamment pour activer une mise à jour de la base de données qui 15 est gérée par le serveur SERV. Le serveur SERV peut alors être couplé ou non à un autre serveur d'authentification, par exemple pour permettre de reconnaitre l'utilisateur U1 et de lui associer des droits prédéfinis. Par exemple, un serveur d'authentification peut, par exemple, gérer des droits utilisateurs relatifs à un 20 ensemble des utilisateurs d'un service de location d'un parc de véhicules et de services associés permettant d'activer la mise en disponibilité d'un véhicule dans le parc à la place du véhicule. Equipements, serveur 25 Selon un premier mode de réalisation, les équipements EQ1, EQ2 sont des équipements électroniques mobiles comportant une interface de communication, par exemple GSM, GPRS 3G, UMTS, 4G, LTE ou Wifi, pour établir une liaison de communication sans fil avec un équipement de communication d'un réseau de données, tels que le réseau internet. 30 L'équipement de communication peut être, par exemple, un commutateur, un routeur, un serveur d'un réseau, une station de base d'un réseau de terminaux mobiles comme un enodeB ou un nodeB pour les réseau LTE, UMTS. Les équipements EQ1, EQ2 sont préférentiellement des 35 téléphones intelligents ou des tablettes numériques. Selon un mode de 8 réalisation, les équipements comprennent, par exemple, un code exécutable d'une application téléchargeable permettant de réaliser les fonctions des procédés de l'invention. Le serveur SERV réalise certaines étapes du procédé de 5 l'invention pouvant correspondantes également à des fonctions d'un logiciel. Il peut être un unique équipement tel qu'un ordinateur comportant des ressources permettant de réaliser les fonctions d'un serveur. Selon une alternative de l'invention, les fonctions du serveur SERV peuvent être assurées par une pluralité de serveurs, c'est-à-dire d'ordinateurs. À titre 10 d'exemple, un serveur d'authentification, permettant notamment de gérer les droits utilisateurs et un serveur stockant les informations du parc de véhicules peuvent être configurés pour réaliser le procédé de l'invention. Selon un autre exemple, les données des utilisateurs et les données des véhicules sont stockées dans un nuage, autrement appelé 15 « cloud » et comportant une pluralité de ressources mémoires synchronisées entre elles et accessibles depuis le réseau de données NET. Cadre de l'invention Le véhicule CAR est dans le cadre de l'invention un véhicule d'un 20 parc de véhicules disponibles à la réservation via un service auquel des utilisateurs sont abonnés. Un système de réservation permet à partir d'un équipement EQi de réserver un véhicule disponible en générant une requête auprès d'un serveur SERV. La requête est alors transmise via un réseau de données NET, 25 représenté dans la figure 1, par exemple Internet. Un intérêt d'un tel réseau est de permettre à des utilisateurs de facilement réserver leur véhicule depuis presque n'importe où. Le serveur SERV peut alors gérer des informations de disponibilité de véhicules afin d'informer les abonnés au service de la localité des véhicules et de leur disponibilité. Après une 30 utilisation d'un véhicule, les informations de disponibilité sont alors mises à jour par l'émission de messages du véhicule CAR vers le serveur SERV. Le serveur SERV est, dans cet exemple, accessible à partir du réseau NET. L'invention se place dans un contexte dans lequel un véhicule CAR du parc est stationné dans une zone non couverte P1 par un réseau de 35 données NET, tel qu'un parking fermé, un sous-sol ou encore tout autre lieu 9 ne présentant pas une exposition suffisante pour permettre le passage de communications sans fil avec un point d'accès PAi au réseau de données. Le réseau NET s'appuie sur une infrastructure permettant d'acheminer des communications sans fil provenant de terminaux mobiles 5 vers des équipements réseaux et réciproquement. Le point d'accès Pm au réseau NET peut être, par exemple, une borne relais, une station de base, un point d'accès domestique WIFI ou tout autre équipement réseau susceptible de fournir une interface de communication avec un réseau de données, comme par exemple internet. 10 La figure 1 représente un cas de figure dans lequel le véhicule CAR a été utilisé par un premier utilisateur U1. Ce dernier gare par exemple le véhicule CAR dans un parking fermé P1 après l'avoir utilisé. Le véhicule CAR devient donc à nouveau disponible pour d'autres utilisateurs. Or dans 15 ce cas de figure, le parking P1 ne permet pas au véhicule CAR de recevoir ou d'émettre des données au sein du réseau de données NET via le point d'accès PAi. L'isolement du véhicule CAR vis-à-vis du réseau est matérialisé sur la figure 1 par un symbole NO_COUV. De ce fait, lorsque le véhicule CAR tente d'établir une connexion à 20 partir d'un équipement embarqué EQcAR avec le réseau de données NET, l'échec de l'établissement de la communication ne permet pas de transférer des données au serveur distant SERV. En conséquence, le véhicule CAR ne peut déclarer sa disponibilité auprès d'un service automatisé de gestion d'un parc de véhicules. 25 Communication entre le véhicule et l'utilisateur L'invention permet l'établissement d'une communication entre l'équipement EQ1 du premier utilisateur U1 et l'équipement EQcAR du véhicule CAR afin de clore la phase d'utilisation du véhicule CAR. Selon un 30 mode de réalisation, la communication est une communication de courte portée, noté I-CP1, par exemple de type Bluetooth. Tout autre type de protocole de courte portée peut être utilisé. Selon différentes modes de réalisation, l'activation de la communication de courte portée Lcpi peut être initiée : - 10 - par l'équipement EQ1 consécutivement à une action de l'utilisateur U1, une transmission d'une information de fin de réservation étant alors émise à destination de l'équipement EC)cAR du véhicule CAR. Cette initiation peut être enclenchée 5 automatiquement par l'équipement utilisateur EQ1. Dans ce cas, l'équipement EQ1 comporte une fonction déclenchant automatiquement la liaison Bluetooth afin d'envoyer un message au véhicule CAR. Automatiquement par l'équipement embarqué EQcAR du 10 véhicule CAR suite à une détection d'une information de fin de réservation. L'information de fin de réservation peut être, par exemple, générée par l'équipement EQ1 ou par une action de l'utilisateur U1 sur une commande du tableau de bord du véhicule CAR. 15 Selon un exemple de réalisation, la liaison de courte portée LCP1 est une liaison Bluetooth. Généralement, la portée d'une telle liaison Bluetooth peut être avantageusement d'une quinzaine de mètres. Un intérêt est de permettre un transfert depuis l'équipement du véhicule CAR d'une 20 information de fin d'utilisation éventuellement à un utilisateur Ui du service qui serait susceptible d'être à proximité du véhicule CAR. Cela peut avoir un intérêt lorsque le premier utilisateur U1 quitte précipitamment le lieu du véhicule sans recevoir du véhicule une donnée de disponibilité à mettre à jour auprès du serveur SERV. 25 Selon un mode de réalisation, lorsque l'équipement EQcAR du véhicule CAR détecte un échec de la connexion avec un réseau de données et donc avec le serveur distant SERV et qu'il détecte qu'il est stationné ou à l'arrêt ou qu'il reçoit une information de fin d'utilisation provenant du véhicule 30 CAR, il engage automatiquement une procédure de connexion sur la liaison de courte portée avec l'équipement EQ1 de l'utilisateur U1 ou avec tout autre équipement d'un abonné au service susceptible d'être situé à proximité. Selon un autre mode de réalisation, lorsque l'utilisateur U1 indique un état de fin de réservation afin de libérer le véhicule CAR, il génère une 35 commande à partir de son équipement EQ1. La commande active alors automatiquement la liaison sans fil de courte portée Lcpi afin d'échanger le nouveau statut de disponibilité du véhicule CAR. Une fois cette connexion établie, le statut du véhicule CAR est 5 sélectionné parmi les statuts suivants : {DISPONIBLE; NON_DISPONIBLE}, dans le cas présent comme « DISPONIBLE ». Après une utilisation par un utilisateur U1, le véhicule bascule son statut en « DISPONIBLE » sous réserve qu'un autre champ ne soit pas pris en compte dans la détermination du statut du véhicule CAR. 10 L'activation de la liaison courte portée Lcpi permet de transférer un message M1 comportant une information de disponibilité à l'équipement EQ1 ou à un autre équipement d'un utilisateur du service de réservation de véhicules. L'information de disponibilité est alors enregistrée dans l'équipement EQ1 de l'utilisateur U.i. 15 L'utilisateur U1 quitte alors le lieu du stationnement du véhicule CAR, par exemple en sortant d'un parking P1. Il est alors sous la couverture réseau du point d'accès PAi. L'équipement EQ1 peut donc accéder au réseau de données NET et donc au serveur SERV. L'invention permet, 20 lorsque l'équipement EQ1 détecte le réseau NET, de transférer l'information de disponibilité au serveur SERV automatiquement afin que le serveur puisse mettre à jour une base de données des véhicules disponibles. Le véhicule CAR peut alors être réservé par un autre utilisateur, par exemple U2 sur la figure I. 25 La figure 1 représente un cas d'un second utilisateur U2 pénétrant dans le parking P1 et souhaitant réserver un véhicule CAR du parc au moyen du service proposé par le serveur SERV et d'une application cliente de l'équipement EQ2. Selon un mode de réalisation de l'invention, le serveur SERV 30 génère alors un message M2 comportant une information de libre accès IDAccEs au véhicule CAR qui est transmise à l'équipement EQ2 dans l'objectif qu'il puisse être transmis au véhicule CAR si l'utilisateur U2 s'approche suffisamment près du véhicule CAR, c'est-à-dire dans la portée de la liaison courte portée Lcpi du véhicule CAR. Cette fonctionnalité permet au véhicule CAR d'activer automatiquement son accès en recevant un message M2 du - 12 - serveur SERV par l'intermédiaire d'un utilisateur abonné U2 au service. Selon les cas de figure, l'utilisateur U2 peut avoir préalablement réservé le véhicule CAR ou avoir simplement permis, grâce à son équipement EQ2, de transmettre le message M2 au véhicule CAR. 5 Dans un cas où le véhicule CAR serait couvert par un réseau de données NET, le procédé de remise d'un véhicule dans le parc des véhicules disponibles s'effectue par l'émission d'un premier message du véhicule vers le serveur SERV pour indiquer la fin d'une précédente utilisation et par la réception d'un second message de remise en disponibilité du véhicule afin 10 qu'un tiers utilisateur puisse réserver le véhicule. Dans le cadre de l'invention, on rappelle que le véhicule CAR, ne pouvant transmettre directement l'information faute d'être couvert par le réseau NET, utilise la liaison courte portée 1-0p1 avec au moins un équipement utilisateur EQi afin de transmettre le premier message M1 et de recevoir le second message M2- 15 Procédé La figure 2 représente un synoptique des principales étapes d'un mode de réalisation de l'invention. La figure 2 représente quatre entités déjà représentées à la figure 20 1, à savoir l'équipement EQcp,R du véhicule CAR, l'équipement EQ1 d'un premier utilisateur U1 quittant le véhicule CAR après son utilisation, le serveur SERV hébergeant notamment au moins une fonction du service de réservation de véhicules et un équipement EQ2 d'un utilisateur U2 susceptible d'évoluer à proximité du véhicule CAR ou souhaitant réserver ce 25 dernier. Dans sa première phase, le procédé permet de générer un indicateur de disponibilité IDDIspo permettant d'indiquer au serveur SERV qu'un véhicule CAR est disponible à nouveau dans le parc de véhicules 30 disponibles après une utilisation par un utilisateur U1. Selon un mode de réalisation, le procédé de l'invention comprend une première étape GENIDDIspo visant à générer un indicateur de disponibilité IDDispo du véhicule CAR. Ce dernier indicateur IDDispo est généré après une détection d'une information de fin d'utilisation du véhicule 35 soit reçue par l'équipement EQoAR du véhicule CAR. Selon un mode de - 13 - réalisation, la génération de l'indicateur IDDIspo est réalisée au moyen d'un calculateur de l'équipement électronique du véhicule EQcAR. Selon un mode de réalisation, le procédé comprend une étape de transmission TRANSi_Mi d'un message M1 depuis le serveur SERV vers 5 l'équipement EQ1 via une liaison courte portée. L'équipement EQcAR comprend donc une interface de communication sans fil permettant d'établir des liaisons de courtes portées avec un équipement tiers. Selon un mode de réalisation, lorsque cette transmission échoue, le véhicule CAR engage une transmission broadcast ou plusieurs 10 transmissions points à points avec une pluralité d'équipements utilisateurs Ui susceptibles d'être à proximité du véhicule CAR. Ce cas de figure peut avoir lieu lorsque le premier utilisateur U1 n'active pas sa liaison Bluetooth ou lorsqu'un évènement empêche la liaison courte portée 1-cp1 d'être opérationnelle. 15 Alternativement dès qu'il détecte qu'il ne peut être couvert par le réseau NET, le véhicule CAR peut diffuser par défaut un message M1 au moyen d'une liaison courte portée avec un ou plusieurs équipements détectés à proximité du véhicule CAR que ce soit l'équipement EQ1 ou un autre EQi. Dans ce cas de figure, l'invention permet d'utiliser temporairement 20 un équipement EQi d'un utilisateur Ui comme relais pour transmettre le message M1. Les ressources de l'équipements EQi sont alors utilisées, tel que sa mémoire, son calculateur et son interface pour transmettre le message M1. Ce dernier message M1 sera alors réémis à destination du serveur SERV lorsque l'équipement EQi sera couvert par le réseau NET. 25 Selon un mode de réalisation, lorsque le véhicule CAR n'a pas réussi à transférer le message M1 à un équipement EQ1 ou EQi, une reconnexion périodique automatique est réalisée de manière favoriser les tentatives positives d'envoi du message M1 à destination du serveur SERV. Selon un mode de réalisation, le véhicule CAR réémet le message 30 M1 jusqu'à ce qu'un acquittement émis par le serveur SERV soit reçu par l'équipement EQcAR du véhicule CAR. Dans ce mode de réalisation, la seconde phase du procédé permet d'utiliser un parc d'équipements EQi d'utilisateur Ui susceptibles d'être à proximité du véhicule CAR pour réémettre un acquittement ou un message M2 comportant une donnée - 14 - permettant de libérer l'accès au véhicule CAR, notée indicateur de libre accès I DACCES - Selon un mode de réalisation, l'équipement EQcAR émet une commande de verrouillage LCK_VEHI du véhicule CAR lorsque le message 5 M1 est émis. Cette solution permet de sécuriser l'accès au véhicule CAR même dans le cas où le premier utilisateur U1 n'active pas la liaison courte portée Lcpi afin de recevoir le message M1 comportant l'indicateur de disponibilité IDDIspo. Dans ce cas, le véhicule CAR reste en statut d'indisponibilité avec un verrouillage actif des portes en attendant un lo message retour M2 provenant du serveur SERV, par exemple lorsqu'une nouvelle réservation de véhicule est activée. Selon un mode de réalisation, le procédé de l'invention comporte une étape d'enregistrement du message M1 dans une mémoire de 15 l'équipement EQ1 (ou EQi) lorsque la liaison courte portée l-cp1 est activée par l'équipement EQ1 et l'équipement EQcAR. Les données du message sont enregistrées sur une mémoire de l'équipement en attendant que l'équipement EQ1 puisse émettre vers un point d'accès Pm du réseau NET. Outre l'indicateur de disponibilité IDDisPo, les données comprises 20 dans le message M1 peuvent comprendre par exemple : Un identifiant du véhicule Id_CAR; Une adresse IP ou une URL, notamment du serveur SERV hébergeant le service de mise à jour de la base de données des véhicules disponibles afin que le message M1 soit 25 correctement relayé; Un secret partagé KEY avec un serveur distant d'authentification ou le serveur SERV; Un jeton comportant un horodatage, c'est-à-dire une date, par exemple la date à laquelle le message M1 a été généré. 30 Un intérêt de la transmission de l'identifiant Id_CAR est de limiter les erreurs notamment pour qualifier l'association entre un utilisateur Ui et un équipement de véhicule EQcAR. Le serveur SERV sera alors en mesure de vérifier que le véhicule CAR était bien associé à l'utilisateur U1. Il pourra - 15 - également discriminer des différents messages provenant d'un même lieu dans lequel différents véhicules du parc sont stationnés. Un avantage de la transmission de l'identifiant du serveur comme son adresse IP ou son URL dans le message M1 est de fournir à 5 l'équipement EQ1, qui joue le rôle d'un relai, une adresse du serveur SERV à laquelle transmettre le message M1. Cela peut avoir un intérêt dans le cas d'une architecture distribuée dans laquelle les différents services sont supportés par différents serveur SERV. A titre d'exemple, les services associés aux utilisateurs peuvent être assurés par un premier serveur 10 SERVI et les services associés aux véhicules sont assurés par un second serveur SERV2. Dans ce dernier cas, les serveurs SERVI et SERV2 sont synchronisés pour assurer une mise à jour des informations de disponibilité des véhicules. Un avantage du partage d'un secret entre le véhicule CAR et le 15 serveur distant SERV est de sécuriser la transmission de données entre les deux équipements EQ1 et EQcAR et également entre EQ1 et le serveur SERV. Les transmissions peuvent alors être chiffrées. Un système de clefs symétriques peut être mis en place afin de chiffrer les transmissions entre les différents équipements. Alternativement, selon un autre exemple, un système 20 de clefs asymétriques peut être utilisé entre d'une part le serveur et d'autre part chaque équipement utilisateur EQi. Un avantage de la transmission d'un jeton d'horodatage est de traiter, côté serveur SERV, une pluralité de réception de messages M1 provenant de différents équipements EQi. Dans le cas d'une diffusion par 25 l'équipement du véhicule EC2cAR d'une information de disponibilité IDDIspo du véhicule CAR à une pluralité d'équipements utilisateur EQi, le serveur SERV, recevant possiblement différents messages M1, est en mesure de gérer les doublons. Un exemple de gestion des doublons est de : 30 enregistrer les différents messages M1 reçus générer automatiquement un message M2 comportant un indicateur de libre accès IDAccEs du véhicule CAR vers ledit véhicule CAR, par exemple via une pluralité d'équipements EQi susceptibles EQi d'évoluer à proximité du véhicule CAR, 35 dès réception du premier message M1 ; - 16 - - suppression des messages M1 suivants le premier message M1 reçu et provenant d'autres équipements EQi. Selon un mode de réalisation, le serveur SERV comporte une fonction rapprochant la provenance géographique des messages M1 afin de 5 corroborer l'information avant de la traiter. Selon différents exemples de réalisation, la date d'horodatage peut être la date de génération des messages M1 par l'équipement EQcAR, la date de réception ou d'émission du message M1 par l'équipement EQ1. Afin de mettre en oeuvre la gestion des doublons, un calculateur 10 du serveur SERV est en mesure de regrouper les différents messages M1 provenant du véhicule CAR dont l'identifiant est analysé. Le calculateur compare les dates des messages M1 provenant des différents équipements EQi ayant relayé le message M1. Un exemple de réalisation comprend la suppression des messages en doublons provenant du véhicule CAR dans 15 une fenêtre de temps prédéfinie. Le procédé comporte une étape notée DET_BALI correspondant à la détection d'une balise ou d'un point d'accès PAi à un réseau. Cette étape est réalisée par un équipement utilisateur EQi. Il peut s'agir de l'équipement utilisateur EQ1 qui vient d'utiliser le véhicule CAR ou d'un autre utilisateur Ui 20 situé à proximité du véhicule CAR et ayant reçu un message M1 provenant du véhicule CAR. L'enregistrement du message M1 dans une mémoire de l'équipement EQ1 ou EQi est donc réalisé au moins jusqu'à la détection d'un point d'accès PAi au réseau NET. 25 Selon un mode de réalisation, lorsqu'un équipement EQi reçoit un message M1, un calculateur de l'équipement peut activer automatiquement une demande d'accès au réseau NET, par exemple en augmentant la fréquence des demandes d'accès vis-à-vis d'une valeur par défaut préconfigurée. 30 Le procédé comporte alors une étape TRANS2_M1 des données sauvegardées en mémoire de l'équipement EQi vers le serveur SERV via une liaison longue portée LCP1, par exemple de type GSM, GPRS, EDGE, 3G, UMTS, HSDPA, HSPA+, 4G, LTE, LTE-Advanced ou 5G, IMT-2020, LTE-B ou encore WIFI. - 17 - Le message M1 est alors émis à destination du serveur SERV distant. Une étape d'enregistrement ENIDDispo de l'indicateur IDDispo est engagée à réception du message par le serveur SERV. Selon une variante de réalisation, l'équipement EQ1 est en mesure 5 d'envoyer au serveur SERV dans tous les cas de figure, qu'il ait reçu le message M1 ou non, un message indiquant que le véhicule CAR est à nouveau disponible puisque l'utilisateur U1 ne l'utilise plus. Selon un mode de réalisation, le serveur SERV peut donc mettre à jour sa base de données afin que le véhicule puisse être réservé à nouveau. En revanche, il est impossible 10 pour le serveur SERV d'activer l'ouverture ou le déverrouillage du véhicule CAR pour une prochaine réservation. Le procédé de l'invention comporte donc une seconde phase permettant de libérer l'accès au véhicule pour une future réservation. Un intérêt d'utiliser le message M1 via un équipement utilisateur 15 EQ1 est de ne pas changer le traitement déjà existant au niveau du serveur SERV. Le traitement consiste à mettre à jour la base de données lorsque le véhicule CAR émet un message de fin d'utilisation. Cette modification pourrait avoir lieu uniquement sur la base d'une réception d'un message généré par l'équipement utilisateur EQ1. Il y a donc un avantage mettre en 20 oeuvre ce mode de relais lorsque le véhicule est aveugle vis-à-vis du réseau de données. Selon un mode de réalisation, l'information de disponibilité du véhicule CAR provenant du message M1 permet de valider la mise en disponibilité du véhicule CAR vis-à-vis d'une même information de 25 disponibilité qui aurait été uniquement générée depuis l'équipement EQi au serveur SERV. Selon un mode de réalisation, le procédé de l'invention comporte une étape de génération et de transmission d'un message M2 visant à rendre 30 libérer l'accès au véhicule CAR, par exemple en déverrouillant son accès pour une prochaine réservation. Avantageusement, cette étape succède, par exemple, à une demande de réservation du véhicule CAR par un utilisateur U2 au moyen du service. La réservation étant validée par le serveur SERV, ce dernier réémet alors au moins un message M2 sur l'équipement EQ2 d'un 35 utilisateur U2. Cette étape est notée TRANS3_ M2. -18- Différents cas de figure peuvent être envisagés dans le cadre de l'invention. Le véhicule CAR n'étant pas accessible directement via le réseau NET, le serveur SERV a la capacité d'engager différents modes afin de libérer le véhicule CAR pour une prochaine utilisation. 5 Selon une première variante, le serveur SERV émet systématiquement à chaque utilisateur Ui à proximité de la localisation connue du véhicule CAR un message M2 susceptible d'être réémis par l'équipement EQi d'un utilisateur Ui au véhicule CAR. Cette possibilité permet de rendre accessible le véhicule CAR à n'importe quel utilisateur du 10 service rentrant dans la zone PI non couverte par le réseau NET et souhaitant le réserver. Elle permet surtout de s'assurer que le véhicule CAR puisse se déverrouiller en augmentant les chances de réception d'un message M2 avec une pluralité d'utilisateurs pénétrant dans le parking Pl. Un autre intérêt est de rendre le véhicule CAR facilement 15 accessible même dans le cas où l'utilisateur choisirait son véhicule à louer une fois dans la zone Pl, c'est-à-dire lorsqu'il ne serait plus en connexion avec le serveur SERV. Ayant reçu le message M2 avant d'entrer dans le parking Pi, l'utilisateur Ui serait en mesure d'accéder au véhicule CAR. A cette fin, le serveur SERV exploite une donnée de localisation des 20 utilisateurs Ui abonnés au service lorsque l'équipement EQ2 autorise le partage de la localisation. Selon une seconde variante, le serveur SERV émet un message M2 uniquement sur demande d'un utilisateur M2 souhaitant réserver le véhicule CAR. Cette mise en oeuvre sécurise l'accès au véhicule CAR en 25 limitant les autorisations d'accès qu'une fois la demande de réservation effectuée. Selon une troisième variante, le serveur SERV émet un message M2 à une pluralité d'utilisateurs du service uniquement lorsqu'au moins une demande de réservation du véhicule CAR a été validée. Ainsi, cela permet 30 de s'assurer que le véhicule CAR puisse être ouvert ou déverrouiller, par exemple, lorsque l'utilisateur ayant réservé le véhicule n'a pas de connexion courte portée 1-cp1 active ou ne fonctionnant pas. Il peut alors s'appuyer sur un réseau d'utilisateur du service permettant de déverrouiller l'accès au véhicule pour lui. - 19 - Le procédé comporte alors une étape d'enregistrement ENR_M2 du message M2 dans une mémoire d'un équipement EQ2 ou plusieurs équipements EQi. Le message M2 enregistré est ensuite réémis vers le véhicule CAR quand cela est possible. Le procédé comprend donc une étape 5 de transmission TRANS4_M2 du message M2 lorsqu'au moins un équipement EQ2 ou EQi ayant reçu le message M2 sera à proximité du véhicule CAR. Afin de transmettre le message M2, l'équipement EQ2 ou EQi activera alors, par exemple, sa liaison Bluetooth afin de détecter un véhicule en écoute. L'équipement comporte un calculateur et une interface afin de tenter d'établir 10 une connexion avec un véhicule du parc. Si un véhicule CAR répond à la requête de l'équipement EQi, selon un mode de réalisation, l'équipement EQi vérifie que l'identifiant du véhicule correspond bien à l'identifiant contenu dans le message M2. Un avantage est de sécuriser la transmission courte portée et l'accès aux 15 données échangées via cette liaison. Selon un autre mode de réalisation, l'équipement EQi émet le message M2 à tout type de véhicule tentant d'établir une connexion avec l'équipement EQi. Un avantage de ce mode de réalisation est de ne pas modifier le traitement effectué sur l'équipement EQi. Les modifications de 20 traitements sont uniquement mises en oeuvre au niveau de l'équipement du véhicule EQcAR. Lorsque le véhicule CAR réceptionne un message M2 provenant d'un équipement utilisateur EQi. Le procédé comprend une étape de modification du statut de disponibilité du véhicule CAR. Le véhicule CAR 25 déverrouille son accès et active potentiellement les commandes permettant d'être opérationnel afin de rouler lorsqu'un utilisateur démarre le moteur du véhicule CAR. Lorsque le véhicule CAR est réservé par un utilisateur U2 et que ce dernier se dirige dans une zone en vue du point d'accès PAi au réseau, 30 l'équipement du véhicule EC2cAR transmet un message M3 au serveur SERV afin de mettre à jour ses données véhicules et les données d'association avec le nouvel utilisateur U2. Cette étape est notée TRANS5_M3 sur la figure 2. Le serveur SERV met à jour les données, cette étape est notée VALID STATU sur la figure 2. 35 - 20 - Programme d'ordinateur L'invention concerne également un produit programme d'ordinateur comportant des instructions pour la mise en oeuvre des 5 différentes phases du procédé de l'invention. Selon différents modes de réalisation, des étapes peuvent être réalisées par un programme d'ordinateur d'un équipement ou de plusieurs équipements EQ1, EQ2, EQcAR. Avantageusement, le programme d'ordinateur peut être installé sur un téléphone intelligent ou une tablette numérique ayant une interface de 10 communication sans fil. Selon un mode de réalisation, le programme d'ordinateur comporte différents exécutables enregistrés sur différents équipements, tels qu'au moins un équipement d'un véhicule et au moins un équipement utilisateur, les différents exécutables pouvant mettre en oeuvre le procédé de 15 l'invention. L'invention concerne également un terminal mobile comportant une interface, par exemple tactile. L'interface comporte un écran pour l'affichage de champs de saisie permettant de définir des paramètres relatifs à la description du véhicule et pour l'affichage par exemple d'une carte 20 numérique interactive. Selon un mode de réalisation, l'équipement mobile comporte un composant permettant d'obtenir une information de géolocalisation qui peut être récupérée par le logiciel. Ainsi, les requêtes émises par un équipement utilisateur EQi ou un équipement du véhicule EQcAR peuvent comprendre 25 des données saisies ou définies par l'utilisateur U1 et des données provenant d'un autre composant ou d'un autre logiciel tel qu'une donnée de localisation du véhicule ou de l'utilisateur. Selon un mode de réalisation, les utilisateurs sont préinscrits à partir du logiciel et sont connus du fait qu'un identifiant est enregistré dans 30 une base de données distante. Selon un mode de réalisation, une base de données associe un véhicule CAR à un utilisateur U1 lorsque ce dernier utilise un véhicule CAR. L'invention concerne également un support d'enregistrement non transitoire comportant les données, qui, une fois installées dans un - 21 - ordinateur ou un équipement de type terminal mobile, permettent d'exécuter le procédé de l'invention. Selon un autre aspect, l'invention concerne un système de mise à 5 jour d'un statut de véhicule CAR, du type automobile, dans une base de données d'un serveur distant SERV. Le système comprend au moins un équipement utilisateur EQi et un équipement de véhicule EQoAR et le serveur de données décrits précédemment au travers de la description du procédé. Le véhicule est un véhicule comportant un équipement ayant au 10 moins un calculateur et une mémoire pour mettre en oeuvre les étapes du procédé. L'équipement REVENDICATIONS1. Le procédé de mise à jour d'une base de données pour la restitution d'un véhicule (CAR) comportant les étapes suivantes : - Génération (GEN_IDDIsPo) d'un indicateur de disponibilité (IDDIspo) du véhicule (CAR) à partir d'un calculateur du véhicule (CAR) ; - Transmission (TRANSi_Mi) automatique d'un ensemble d'information (M1) comportant ledit indicateur de disponibilité (IDDIspo) à au moins un équipement utilisateur (EQ1) d'un premier utilisateur (U1) via une liaison sans fil de courte portée (Lcpi) ; - Enregistrement (ENR_M1) de l'ensemble d'information (M1) dans une mémoire de l'équipement (EQ1) jusqu'à une détection ultérieure d'un accès à un réseau de données (NET) ; - Transmission (TRANS2_M1) automatique de l'ensemble d'information (M1) comportant ledit indicateur de disponibilité (IDDIspo) à un serveur distant (SERV) depuis l'équipement utilisateur (EQ1) via une liaison sans fil (LLpi) permettant un accès à un réseau de données (NET) ; - Mise à jour (MODIF_DISPO_CAR) d'une base de données (BD) modifiant un statut de disponibilité véhicule (CAR) au sein d'un parc de véhicules (ECAR) par un calculateur (K2) du serveur distant (SERV). 2. Le procédé selon la revendication 1, caractérisé en ce que la génération de l'indicateur de disponibilité (GEN_IDDispo) est généré consécutivement à: - Une commande numérique générée suite à l'arrêt du véhicule ou de son système de gestion électrique et/ou ; - Une commande numérique générée suite à la fermeture d'une portière et/ou ; - Une commande numérique générée suite à la réception d'un message à partir d'une interface de communication sans fil provenant d'un terminal utilisateur (EQ1) comportant une donnée de fin d'utilisation. -23 - 3. Le procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce que la transmission (TRANS2_M1) automatique de l'ensemble d'information (M1) est réalisée après une première 5 tentative échouée de transmission et un premier enregistrement de ladite information dans une mémoire du premier équipement (EQ1). 4. Le procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la liaison de courte portée est une liaison 10 Bluetooth. 5. Le procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'ensemble d'information (M1) comprend : - Un identifiant du véhicule (Id_CAR) ; 15 - Une adresse IP ou une URL ; - Un secret partagé (KEY) avec un serveur distant (SERV) ; - Un jeton comportant un horodatage. 6. Le procédé selon la revendication 5, caractérisé en ce qu'il comprend, 20 en outre, les étapes suivantes : - Comparaison des jetons et des identifiants reçus d'une pluralité de messages reçus provenant d'une pluralité d'équipements (EQi) ; - Suppression des indicateurs de disponibilité en doublon provenant d'un même véhicule (CAR). 25 7. Le procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la mise à jour de la base de données (BD) du serveur distant (SERV) comprend en outre les étapes suivantes : - Enregistrement d'une nouvelle localisation de stationnement du 30 véhicule (CAR) ; - Enregistrement de données d'usage comportant l'une au moins des données suivantes : o Temps d'utilisation ; o Kilomètres parcourus ; 35 o Déclenchement d'évènements (airbag, alerte révision, etc.). -24- 8. Le procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend une étape de modification du statut de disponibilité du véhicule (CAR) pour sa réservation par un second 5 utilisateur (U2) comportant : - Identification du second utilisateur (U2) enregistré dans une base de données d'un service d'accès à un parc de véhicules (>:CAR); - Génération d'un indicateur de libre accès (IDAccEs) d'un véhicule (CAR) ; 10 - Première transmission par un serveur (SERV) à destination d'au moins un second utilisateur (U2) d'un ensemble d'information (M2) comportant l'indicateur de libre accès (IDAccEs) ; - Seconde transmission automatique de l'ensemble d'information (M2) comportant ledit indicateur de libre accès (IDAccEs) à au moins 15 un véhicule (CAR) via une liaison sans fil de courte portée (Lcpi) ; - Enregistrement de l'ensemble d'information (M2) reçu par le véhicule (CAR) dans une mémoire dudit véhicule (CAR) ; - Activation d'un déverrouillage de l'accès au véhicule (CAR). 20 9. Le procédé selon la revendication 8, caractérisé en ce que l'indicateur de libre accès (IDAccEs) est associé à l'identifiant d'un second utilisateur (U2), le second ensemble d'information (M2) transmis au véhicule comportant en outre un identifiant utilisateur (Id_U2). 25 10. Le procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend en outre l'étape suivante : - Réception par le serveur (SERV) d'une demande d'accès à un véhicule (CAR) par le second utilisateur (U2) préalablement à la génération d'un indicateur de libre accès (IDAccEs). 30 11. Le procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend consécutivement à l'identification du second utilisateur (U2) - Comparaison entre au moins une position (POScAR) du véhicule 35 (CAR) et une position (POSu2) dudit second utilisateur (U2) afin -25 - d'activer la génération d'un indicateur de libre accès (IDAccEs) pour le second utilisateur à transmettre au véhicule (CAR). 12.Le procédé selon l'une quelconque des revendications 10 à 11, 5 caractérisé en ce qu'il comprend consécutivement à la demande d'accès, une sélection d'un véhicule (CAR) à partir du second équipement (EQ2) parmi une liste de véhicules (CAR) générée par ledit serveur (SERV). 10 13.Le procédé selon l'une quelconque des revendications 10 à 12, caractérisé en ce qu'il comprend les étapes suivantes : - Détection d'un accès à un réseau de données (NET) via une liaison sans fil (I_Lpi) ; - Transmission (TRANS3_M3) automatique par l'équipement du 15 véhicule (EQcAR) de données véhicule et de données d'association avec le nouvel utilisateur (U2) vers le serveur distant (SERV) permettant un accès à un réseau de données (NET) ; - Mise à jour (VALID_STATU) d'une base de données (BD) modifiant un statut de disponibilité véhicule (IDDIspo) au sein d'un 20 parc de véhicules (ECAR) par un calculateur du serveur distant (SERV). 14.Système comportant au moins un terminal mobile (EQ1, EQ2) et un serveur (SERV) pour la mise en oeuvre de l'une quelconque des 25 Étapes du procédé des revendications 1 à 13.