FR3050051A1

FR3050051A1 - Gestion de reservation de salles de reunion dans un batiment

Info

Publication number: FR3050051A1
Application number: FR1653075A
Authority: FR
Inventors: Fabrice Lucas
Original assignee: Orange Applications For Business
Current assignee: Orange Applications For Business
Priority date: 2016-04-07
Filing date: 2016-04-07
Publication date: 2017-10-13

Abstract

L'invention concerne la 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 (BDD). Chaque salle comporte au moins un capteur de présence (CAP) pour détecter si un utilisateur est effectivement présent dans la salle de réunion (SR). Le capteur de présence transmet un signal comportant l'identifiant de salle et des données de présence à un serveur (SER) via un réseau de communication. L'identifiant de chaque salle de réunion (S1, S2, S3, S4) 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 (ST1), et - Salle disponible (ST3). Le serveur est connecté à la base de données et agencé pour gérer la base de données, pour mettre en œuvre les étapes : - Sur réception d'une requête de réservation d'une salle, et après vérification que ladite salle (S3) 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 (ST3).

Description

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 signal comportant des données de présence dans eette 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.

Toutefois, il peut advenir qu’un futur occupant de la salle ne puisse pas oeeuper 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).

Avantageusement, le serveur est connecté à la base de données et agencé pour gérer la base de données, et met alors en œuvre 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 saUe 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.

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 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,

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 œuvre 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 à celui d’une salle réservée mais inoccupée.

Appliquer une temporisation sur une durée prédéterminée, et ο 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 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 : 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.

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, - 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 saUes 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 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 donnée identifiant un utilisateur réservant la salle.

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 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 * 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 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 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 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 pour la mise en œuvre 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 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 réunion et reliés à un serveur connecté à une base de données pour la mise en œuvre 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 à 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 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, la figure 2 illustre des étapes d'un procédé selon un exemple de réalisation de l'invention. 11 est présenté ci-après une application de gestion de réservation de salles de réunion, voire de bureaux de passage. 11 s’agit d’une mise en œuvre simple de réservation, facilitée par 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 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 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 équipement conneeté 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é STI, ST2, ST3.

Dans l'exemple représenté : - l'état STI 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).

Ces différents statuts sont stockés dans la mémoire d'une base de données BDD, en correspondance d'un identifiant de saUe SI, S2, S3, S4...

Cette base de données est reliée (ou intégrée) à un serveur SER eomportant typiquement une interface INR de connexion à un réseau RES pour recevoir des requêtes de réservation d'équipements connectés TER d'utilisateurs. Le serveur SER eomporte en outre un eireuit de traitement intégrant par exemple un proeesseur PROC et une mémoire MEM stoekant des instructions d'un programme informatique pour la mise en œuvre du proeédé, ainsi que des données fixes (identifiants des saUes par exemple) et éventuellement des données temporaires (de calcul ou autre). Dans un exemple de réalisation, la mémoire MEM peut 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 eette dernière (BDD). Le circuit de traitement du serveur SER intègre en outre une horloge CLK pour la temporisation à appliquer après ehaque réservation. Par ailleurs, le serveur SER eomporte en outre une interface INC de réeeption des signaux issus des eapteurs CAP installés dans chaque salle de réunion SR. Dans une réaUsation, les eapteurs CAP peuvent être des capteurs infrarouges, comme indiqué ei-avant. Néanmoins, d'autres variantes sont possibles. Par exemple, des moyens de commande MC tels qu’une mise en serviee de ehauffage ou de climatisation dans 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 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, Putilisateur d’un équipement connecté TER souhaitant réserver une salle commande l’exécution d’une application sur son téléphone mobile pour demander une salle de réunion hhre à l’étape EL Cette demande est transmise au serveur SER pour interroger à l’étape E2 la hase de données afin de lister les salles de réunion dont le statut est celui d’une salle libre : STS. La liste des salles disponibles avec leur identifiant S3, S4 est établie à l’étape ES et transmise à l’équipement TER, en retour à sa demande. Cette liste peut éventuellement comporter en outre les autres salles avec les statuts « salle occupée STI » 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. L'utilisateur peut utiliser une interface de saisie de son équipement (écran tactile ou autre) pour choisir l'une des salles (SS 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 SS, ainsi, éventuellement, qu’un identifiant de Tutilisateur UTI 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 SS afin d'affecter à cette salle SS, dans la base de données BDD, le statut d'une saUe 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. Cette durée peut être fonction d’un identifiant de Tutilisateur 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 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, 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 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 réservée STI à l’étape ElO.

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 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 ElO correspond à une simplification de représentation illustrant le fait que le serveur vérifie d’abord si le statut de la saUe S3 n’est pas celui d’une saUe 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 ; eUe s’étend à d’autres variantes.

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 ElO garde le statut d’une salle réservée et occupée pendant la durée annoncée dans la requête. Néanmoins, dans une autre forme de réalisation, aueune information de durée de réservation n’est néeessaire 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 STI a été attribué à la salle S3. Ainsi, le statut d’une salle réservée STI peut 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é de la figure 2 peuvent être aussi simplifiées, par exemple par la suppression de l’étape ElO 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. 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 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.

Claims

Revendications

1. 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 œuvre 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 saUe de réunion est associé dans la base de données à un statut décrivant la disponibilité de la saUe 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 œuvre 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 ο 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 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 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 saUes 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 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.
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 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 : * 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 saUe, - 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 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 saUe 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 saUe.
8. Programme informatique caractérisé en ce qu’il comporte des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 7, lorsque ce programme est exécuté par un processeur.
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 œuvre 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 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.