Brevet FR3050051A1 — publié le 20171013

Gestion de réservation de salles de réunion dans un bâtiment La présente invention concerne la gestion de réservation de salles de réunion dans un ou plusieurs bâtiments. On entend ici « par salles de réunion » aussi bien des locaux tels que des salles à plusieurs utilisateurs, que des bureaux de passage, ou encore des salles de loisir privatisées (courts de tennis ou de squash par exemple), à réserver. La réservation d'une salle de réunion, qui n'est pas suivie finalement d'une occupation de la salle ensuite, peut générer bien entendu des problèmes d'organisation de gestion du parc des salles, mais aussi des problèmes environnementaux comme notamment le préchauffage automatique d'une salle, puis son chauffage et/ou son éclairage, inutilement, pendant la période de réservation de la salle. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé de gestion de réservation de salles de réunion dans un ou plusieurs bâtiments, dans lequel chaque salle de réunion est affectée d'un identifiant de salle dans une base de données. En particulier, chaque salle comporte au moins un capteur de présence pour détecter si un utilisateur est effectivement présent dans la salle de réunion. Un tel capteur (par exemple un capteur de présence à rayonnement infrarouge, ou autre) transmet alors un signal comportant l'identifiant de la salle dans laquelle il opère, ainsi que des données de présence (le cas échéant) à un serveur via un réseau de communication. L'identifiant de chaque salle de réunion peut être associé dans la base de données précitée à un statut décrivant la disponibilité de la salle, parmi au moins deux statuts : Salle réservée, et Salle disponible. Ainsi, les salles peuvent alors être équipées de capteurs de présence pour vérifier si une salle en particulier, présumée réservée, est effectivement occupée ou non. Un capteur qui ne détecte pas de présence dans une salle présumée réservée peut ne pas remonter au serveur de 3050051 2 signal comportant des données de présence dans cette salle. L'action que peut initier ensuite le serveur gérant la base de données pourrait alors être de faire passer simplement le statut de cette salle dans la base de données à celui d'une salle inoccupée. 5 Toutefois, il peut advenir qu'un futur occupant de la salle ne puisse pas occuper immédiatement la salle (du fait d'un retard, ou simplement d'une durée de trajet à prendre en compte entre la position courante de l'utilisateur au moment où il communique sa réservation et le lieu de la salle de réunion). 10 Avantageusement, le serveur est connecté à la base de données et agencé pour gérer la base de données, et met alors en oeuvre les étapes : Sur réception d'une requête de réservation d'une salle, et après vérification que ladite salle est associée à un statut d'une salle disponible, changer le statut de la salle, Appliquer une temporisation sur une durée prédéterminée, et si aucun signal 15 comportant des données de présence avec l'identifiant de la salle n'est reçu pendant la durée prédéterminée, affecter à la salle le statut d'une salle disponible. Ainsi, l'invention prévoit en particulier d'associer une temporisation à la détection de présence dans une salle. Une telle réalisation permet de rendre plus robuste la gestion des 20 réservations de salles, notamment en cas de retard des futurs occupants. Dans une forme de réalisation, l'identifiant de chaque salle de réunion est associé dans la base de données à un statut décrivant la disponibilité de la salle parmi au moins trois statuts : Salle réservée et occupée selon les données reçues du capteur de présence, 25 Salle réservée mais inoccupée selon les données reçues du capteur de présence, et Salle disponible. Le serveur peut mettre alors en oeuvre en particulier les étapes : Sur réception d'une requête de réservation d'une salle, et après vérification que ladite salle est associée à un statut d'une salle disponible, changer le statut de la salle 30 à celui d'une salle réservée mais inoccupée, Appliquer une temporisation sur une durée prédéterminée, et 3050051 3 o sur réception pendant cette durée prédéterminée d'un signal de présence reçu avec l'identifiant de ladite salle et comportant des données de présence, affecter à la salle le statut d'une salle réservée et occupée, o si aucun signal comportant des données de présence avec l'identifiant de la 5 salle n'est reçu pendant la durée prédéterminée, affecter à la salle le statut d'une salle disponible. Ainsi, cette réalisation offre une plus grande souplesse d'utilisation, profitant pleinement de l'association entre la détection de présence et la temporisation, pour créer un nouveau statut : 10 celui d'une salle réservée mais inoccupée. Un utilisateur capable de constater ce statut pour une salle donnée, via une interface homme/machine sur un équipement connecté à sa disposition, peut attendre le délai de temporisation pour réserver ensuite cette salle (ou encore émettre une option pour la réservation de cette salle avant-même la fin du délai de temporisation) s'il souhaite cette salle en particulier. 15 Comme indiqué ci-dessus, dans une réalisation, la requête de réservation peut être reçue d'un équipement d'un utilisateur communiquant avec le serveur, le procédé comportant alors en outre les étapes dans lesquelles : - l'équipement envoie au serveur une demande de réservation de salle, 20 - le serveur, sur réception de la demande de réservation de salle, détermine par consultation de la base les salles dont le statut est celui d'une salle disponible, et transmet à l'équipement au moins des données des salles disponibles incluant des identifiants des salles disponibles, - sur réception sur l'équipement des données des salles disponibles, l'équipement exécute une application d'interface homme/machine pour demander à l'utilisateur le choix d'une des 25 salles disponibles, - sur réception du choix de l'utilisateur, l'équipement transmet au serveur la requête précitée de réservation de salle, comportant alors l'identifiant de la salle choisie par l'utilisateur. Dans une forme de réalisation, la requête de réservation de salle comporte en outre une 30 donnée identifiant un utilisateur réservant la salle. 3050051 4 Cette forme de réalisation permet de compter les occurrences de réservations de salle avec un statut de salle réservée mais inoccupée après la période de temporisation, pour chaque utilisateur donné, afin de de tenir par exemple une base de statistiques et/ou de générer des alertes relatives à des comportements d'utilisateurs indélicats (réservant souvent des salles 5 sans les occuper, typiquement). Cette forme de réalisation permet en outre, en complément ou en variante, au serveur de : - déterminer une durée moyenne pour chaque utilisateur entre : * un moment de réception de requête de réservation d'une salle par cet utilisateur, et 10 * un moment de réception d'un signal comportant des données de présence avec l'identifiant de cette salle, - et de fixer la durée prédéterminée de temporisation à appliquer pour une réservation de salle par cet utilisateur en fonction de la durée moyenne précitée. Une telle réalisation permet alors d' adapter finement la durée choisie pour la temporisation 15 aux habitudes de chaque utilisateur et de tenir compte par exemple d'une précocité d'un utilisateur dans la réservation d'une salle par rapport au moment où il occupe effectivement la salle. Dans une réalisation alternative ou complémentaire, la requête de réservation étant reçue 20 d'un équipement d'un utilisateur communiquant avec le serveur, cette requête de réservation de salle comporte en outre une donnée de géolocalisation courante de l'équipement, et la période de temporisation est déterminée par estimation d'une durée de trajet entre la géolocalisation courante de l'équipement et une géolocalisation prédéterminée de la salle. Une telle réalisation permet de prendre en compte les temps de trajet des utilisateurs pour se 25 rendre dans la salle de réunion réservée, afin d' affiner la durée de temporisation en fonction de ce paramètre. On peut en outre prendre en compte les habitudes des utilisateurs par rapport à la précocité de leur réservation comme indiqué ci-dessus. La présente invention vise aussi un programme informatique comportant des instructions 30 pour la mise en oeuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur. La figure 2, décrite en détails plus loin, illustre un ordinogramme d'un algorithme possible d'un tel programme informatique, avec des instructions de code 3050051 5 distribuées entre un équipement connecté d'un utilisateur et un serveur du type ci-avant, relié à la base de données précitée. L'invention vise aussi un système comportant des capteurs agencés dans des salles de 5 réunion et reliés à un serveur connecté à une base de données pour la mise en oeuvre du procédé ci-avant. L'invention vise aussi un serveur d'un tel système, comportant en particulier une interface d'entrée pour recevoir des signaux de présence issus de capteurs de présence, une connexion 10 à une base de données et un circuit de traitement (incluant typiquement un processeur et une mémoire de stockage des instructions du code du programme informatique précité) pour opérer les étapes du procédé ci-avant. D'autres avantages et caractéristiques de l'invention apparaitront à l'examen de la 15 description détaillée d'exemples de réalisation donnés ci-après et à l'examen des dessins annexés, sur lesquels : la figure 1 illustre un système au sens de la présente invention, avec en particulier des capteurs CAP installés dans les salles de réunion SR et aptes à remonter des données de présence à un serveur SER au sens de l'invention, 20 la figure 2 illustre des étapes d'un procédé selon un exemple de réalisation de l'invention. Il est présenté ci-après une application de gestion de réservation de salles de réunion, voire de bureaux de passage. Il s'agit d'une mise en oeuvre simple de réservation, facilitée par 25 l'installation de capteurs CAP (figure 1), par exemple des capteurs infrarouges, capables de détecter un mouvement, et donc de détecter une présence (ou non) d'une personne dans un espace préalablement réservé. Dans les espaces de travail ouverts, un utilisateur, tel qu'un employé d'une société louant par 30 exemple des locaux avec des salles ou bureaux à réserver, peut être amené à réserver une salle de travail ou un bureau juste avant de se rendre à son lieu de travail ou bien depuis l'accueil du site. Il est intéressant de lui proposer une solution simple pour réserver en 3050051 6 avance un espace, sans avoir recours à des badges ou autres moyens nécessitant l'installation d'équipements lourds pour chaque salle. Ainsi, en référence à la figure 1, une application logicielle peut être installée sur un 5 équipement connecté d'un utilisateur, tel qu'un terminal mobile TER, de type smartphone par exemple, pour visualiser sur une interface homme-machine, telle qu'un écran du terminal, les différentes salles de réunion d'un ou plusieurs bâtiments et leur état de disponibilité ST1, ST2, ST3. 10 Dans l'exemple représenté : - l'état ST1 correspond au statut d'une salle réservée et occupée, - l'état ST2 correspond au statut d'une salle réservée mais inoccupée, et - l'état ST3 correspond au statut d'une salle libre (non réservée). 15 Ces différents statuts sont stockés dans la mémoire d'une base de données BDD, en correspondance d'un identifiant de salle Si, S2, S3, S4... Cette base de données est reliée (ou intégrée) à un serveur SER comportant typiquement une interface INR de connexion à un réseau RES pour recevoir des requêtes de réservation 20 d'équipements connectés TER d'utilisateurs. Le serveur SER comporte en outre un circuit de traitement intégrant par exemple un processeur PROC et une mémoire MEM stockant des instructions d'un programme informatique pour la mise en oeuvre du procédé, ainsi que des données fixes (identifiants des salles par exemple) et éventuellement des données temporaires (de calcul ou autre). Dans un exemple de réalisation, la mémoire MEM peut 25 d'ailleurs stocker les données de la base BDD. Plus généralement, le serveur SER est connecté à la base de données BDD pour la gestion de cette dernière (BDD). Le circuit de traitement du serveur SER intègre en outre une horloge CLK pour la temporisation à appliquer après chaque réservation. Par ailleurs, le serveur SER comporte en outre une interface INC de réception des signaux issus des capteurs CAP installés dans chaque salle de 30 réunion SR. Dans une réalisation, les capteurs CAP peuvent être des capteurs infrarouges, comme indiqué ci-avant. Néanmoins, d'autres variantes sont possibles. Par exemple, des moyens de commande MC tels qu'une mise en service de chauffage ou de climatisation dans 3050051 7 la salle, ou encore un interrupteur de lumière, peuvent être connectés au serveur SER pour lui communiquer un signal indiquant un changement d'état (lumière éteinte devenant allumée, ou mise en service du chauffage) caractérisant la présence d'une personne dans la salle. La connexion entre les capteurs CAP plus généralement et le serveur SER peut s'effectuer via le 5 même réseau RES de connexion aux terminaux TER (réseau cellulaire par exemple, ou local LAN) ou encore via un réseau différent (type LoRa ® ou autre), ou encore un réseau filaire. En référence maintenant à la figure 2, l'utilisateur d'un équipement connecté TER souhaitant réserver une salle commande l'exécution d'une application sur son téléphone mobile pour 10 demander une salle de réunion libre à l'étape El. Cette demande est transmise au serveur SER pour interroger à l'étape E2 la base de données afin de lister les salles de réunion dont le statut est celui d'une salle libre : ST3. La liste des salles disponibles avec leur identifiant S3, S4 est établie à l'étape E3 et transmise à l'équipement TER, en retour à sa demande Cette liste peut éventuellement comporter en outre les autres salles avec les statuts « salle 15 occupée ST1 » et « salle réservée mais inoccupée ST2 » pour parvenir à l'affichage sur écran présenté sur la figure 1 avec des logos propres à chaque statut de salle. Sur réception de cette liste, l'équipement TER exécute l'application pour animer l'interface homme-machine et présenter ainsi à l'utilisateur la liste des salles disponibles à l'étape E4. 20 L'utilisateur peut utiliser une interface de saisie de son équipement (écran tactile ou autre) pour choisir l'une des salles (S3 dans l'exemple représenté) à l'étape E5. L'équipement TER envoie ensuite au serveur SER une requête REQ à l'étape E6 comportant l'identifiant de la salle choisie S3, ainsi, éventuellement, qu'un identifiant de l'utilisateur UTI 25 et/ou des données de géolocalisation courantes de l'équipement TER. À l'étape E7, le serveur SER reçoit la requête REQ et y lit en particulier l'identifiant de salle S3 afin d'affecter à cette salle S3, dans la base de données BDD, le statut d'une salle réservée mais inoccupée ST2. A l'étape E8, le serveur déclenche ensuite une temporisation d'une durée prédéterminée 30 Cette durée peut être fonction d'un identifiant de l'utilisateur UTI ayant des habitudes de réservation un certain délai avant son occupation effective de la salle. Dans ce cas, ce délai peut être pris en compte pour la détermination de la durée de la temporisation. En 3050051 8 complément ou en variante, la durée de temporisation peut être fonction d'une géolocalisation courante de l'équipement TER. Dans ce cas, le serveur peut estimer une durée de trajet jusqu'à la salle réservée. On peut citer à titre d'exemple le cas d'un grand bâtiment dans lequel l'utilisateur se déplace à pieds depuis un accueil où il réserve une salle, 5 jusqu'à la salle réservée. Pendant la durée de la temporisation (flèche KO en sortie du test E8), tant que le capteur CAP de la salle S3 ne communique pas de signal comportant des données de présence effective dans la salle S3 (flèche KO en sortie du test E9), le statut de la salle S3 est 10 maintenu à celui d'une salle réservée mais inoccupée ST2. Si, au contraire, le capteur CAP de la salle S3 communique un signal comportant effectivement des données de présence dans la salle S3 (flèche OK en sortie du test E9), le serveur interprète ce signal comme correspondant à une situation dans laquelle l'utilisateur, ayant réservé la salle, s'y est bien rendu pour l'occuper. Ainsi, le serveur fait passer le statut de la salle S3 à celui d'une salle 15 réservée ST1 à l'étape E10. En revanche, si pendant toute la durée de la temporisation (flèche OK en sortie du test E8), le serveur n'a reçu aucun signal du capteur CAP qui comporterait des données de présence effective dans la salle S3, le serveur affecte à cette salle S3 le statut d'une salle libre ST3 20 dans la base de données BDD, à l'étape El 1. Le serveur peut en outre à l'étape E12 stocker une occurrence pour l'utilisateur d'identifiant UTI ayant réservé une salle sans l'occuper ensuite (dans l'option où l'identifiant UTI est transmis dans la requête REQ). Sur la figure 2, la flèche en trait fort issue de l'étape El0 correspond à une simplification de représentation illustrant le fait que le serveur vérifie d'abord si le statut de la salle S3 n'est pas celui d'une 25 salle réservée et occupée avant de le faire passer à celui d'une salle libre. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes. 30 Ainsi par exemple, la réservation de la salle, émise au moyen de la requête REQ ci-avant, peut spécifier une durée de réservation de cette salle. Dans ce cas, la salle S3, après l'étape El0 garde le statut d'une salle réservée et occupée pendant la durée annoncée dans la requête. 3050051 9 Néanmoins, dans une autre forme de réalisation, aucune information de durée de réservation n'est nécessaire dans la requête. Dans ce mode de réalisation simplifié, le serveur peut amorcer à nouveau la temporisation de l'étape E8, une fois que le statut d'une salle réservée et occupée ST1 a été attribué à la salle S3. Ainsi, le statut d'une salle réservée ST1 peut 5 toujours être mis en jeu si le capteur de la salle ne renvoie pas de signal comportant des données d'une présence effective après une durée de temporisation. D'ailleurs, dans une réalisation simplifiée, la base de données peut ne comporter que deux statuts : celui d'une salle réservée et celui d'une salle libre. En outre, les étapes du procédé 10 de la figure 2 peuvent être aussi simplifiées, par exemple par la suppression de l'étape El0 visant à affecter à la salle le statut d'une salle réservée (ou « réservée et occupée » si ce statut est retenu). En effet, cette variante consiste à tenir compte du cas d'un utilisateur qui entre par erreur dans la salle alors qu'il ne l'avait pas réservée auparavant. 15 Néanmoins, l'indication du statut d'une salle « réservée mais inoccupée » sur une interface d'équipement TER reste avantageuse et permet d'informer un utilisateur qu'une salle S2 (comme illustré sur la figure 1) qui parait libre, est pré-réservée en réalité. Par ailleurs, on a illustré sur la figure 1 un exemple de réalisation dans lequel on prévoit des 20 logos distincts pour les différents types de statuts de salle. Dans une variante, on peut utiliser des codes couleurs différents sur l'écran d'interface du terminal TER, par exemple rouge pour une salle réservée et occupée, orange pour une salle réservée mais inoccupée, et vert pour une salle libre. REVENDICATIONS1. Procédé de gestion de réservation de salles de réunion dans un ou plusieurs bâtiments, chaque salle de réunion étant affectée d'un identifiant de salle dans une base de données, caractérisé en ce que chaque salle comporte au moins un capteur de présence pour détecter si un utilisateur est effectivement présent dans la salle de réunion, le capteur de présence transmettant un signal comportant l'identifiant de salle et des données de présence à un serveur via un réseau de communication, en ce que l'identifiant de chaque salle de réunion est associé dans la base de données à un statut décrivant la disponibilité de la salle, parmi au moins deux statuts : Salle réservée, et Salle disponible, et en ce que le serveur est connecté à la base de données et agencé pour gérer la base de données, et met en oeuvre les étapes : Sur réception d'une requête de réservation d'une salle, et après vérification que ladite salle est associée à un statut d'une salle disponible, changer le statut de la salle, Appliquer une temporisation sur une durée prédéterminée, et si aucun signal comportant des données de présence avec l'identifiant de la salle n'est reçu pendant la durée prédéterminée, affecter à la salle le statut d'une salle disponible. 2. Procédé selon la revendication 1, caractérisé en ce que l'identifiant de chaque salle de réunion est associé dans la base de données à un statut décrivant la disponibilité de la salle parmi au moins trois statuts : Salle réservée et occupée selon les données reçues du capteur de présence, Salle réservée mais inoccupée selon les données reçues du capteur de présence, et Salle disponible, et en ce que le serveur met en oeuvre les étapes : Sur réception d'une requête de réservation d'une salle, et après vérification que ladite salle est associée à un statut d'une salle disponible, changer le statut de la salle à celui d'une salle réservée mais inoccupée, Appliquer une temporisation sur une durée prédéterminée, et 3050051 11 o sur réception pendant cette durée prédéterminée d'un signal de présence reçu avec l'identifiant de ladite salle et comportant des données de présence, affecter à la salle le statut d'une salle réservée et occupée, o si aucun signal comportant des données de présence avec l'identifiant de la 5 salle n'est reçu pendant la durée prédéterminée, affecter à la salle le statut d'une salle disponible. 3. Procédé selon l'une des revendications précédentes, caractérisé en ce que la requête de réservation est reçue d'un équipement d'un utilisateur communiquant avec le serveur, et en 10 ce que le procédé comporte en outre les étapes dans lesquelles : - l'équipement envoie au serveur une demande de réservation de salle, - le serveur, sur réception de la demande de réservation de salle, détermine par consultation de la base les salles dont le statut est celui d'une salle disponible, et transmet à l'équipement au moins des données des salles disponibles incluant des identifiants des salles disponibles, 15 - sur réception sur l'équipement des données des salles disponibles, l'équipement exécute une application d'interface homme/machine pour demander à l'utilisateur le choix d'une des salles disponibles, - sur réception du choix de l'utilisateur, l'équipement transmet au serveur ladite requête de réservation de salle, comportant l'identifiant de la salle choisie par l'utilisateur. 20 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la requête de réservation de salle comporte en outre une donnée identifiant un utilisateur réservant la salle. 5. Procédé selon la revendication 4, caractérisé en ce que les occurrences de réservations de 25 salle avec un statut de salle réservée mais inoccupée après la période de temporisation sont comptées pour chaque utilisateur. 6. Procédé selon l'une des revendications 4 et 5, caractérisé en ce que le serveur : - détermine une durée moyenne pour chaque utilisateur entre : 30 * un moment de réception de requête de réservation d'une salle par cet utilisateur, et * un moment de réception d'un signal comportant des données de présence avec l'identifiant de cette salle, 3050051 12 - et fixe la durée prédéterminée de temporisation à appliquer pour une réservation de salle par cet utilisateur en fonction de ladite durée moyenne. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que la requête de 5 réservation est reçue d'un équipement d'un utilisateur communiquant avec le serveur, en ce que la requête de réservation de salle comporte en outre une donnée de géolocalisation courante de l'équipement, et en ce que la période de temporisation est déterminée par estimation d'une durée de trajet entre la géolocalisation courante de l'équipement et une géolocalisation prédéterminée de la salle. 10 8. Programme informatique caractérisé en ce qu'il comporte des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7, lorsque ce programme est exécuté par un processeur. 15 9. Système comportant des capteurs agencés dans des salles de réunion et reliés à un serveur connecté à une base de données pour la mise en oeuvre du procédé selon l'une des revendications 1 à 7. 10. Serveur d'un système selon la revendication 9, comportant une interface d'entrée pour 20 recevoir des signaux de présence issus de capteurs de présence, une connexion à une base de données et un circuit de traitement pour opérer les étapes du procédé selon l'une des revendications 1 à 7.