FR 3092194 A1 20200731 FR 1900655 A 20190125 Description Titre de l'invention : Génération d'une liste d'éléments de données disponibles d'au moins un fournisseur de services [0001] La présente invention concerne un procédé implémenté par ordinateur, un système informatique et un produit-programme d'ordinateur pour générer une liste des éléments de données disponibles d'au moins un fournisseur de services en réponse à une requête générée par un utilisateur. Spécifiquement, la présente invention vise à solutionner une requête d'utilisateur relative à des réservations de chambres d'hôtel en interfaceant avec une base de données d'inventaire d'au moins un hôtel. [0002] Dans les systèmes de réservation d'hôtel, une caractéristique essentielle est de pouvoir solutionner une requête entrante d'un utilisateur dans les meilleurs délais. Unc requête d'utilisateur comprend typiquement des données fonctionnelles détaillant un plusieurs critères nécessaires pour solutionner la requête de l'utilisateur. Les données fonctionnelles peuvent comprendre des données relatives à l'utilisateur et des données relatives à un service. Les données relatives à un utilisateur sont, par exemple, le fait que l'utilisateur ne soit pas ou soit handicapé, auquel cas il faut lui attribuer une chambre appropriée à son handicap. Les données relatives à un utilisateur peuvent aussi inclure le nombre de personnes et leurs âges, par exemple des parents avec un nourrisson peuvent avoir besoin d'un type dc chambre différent que ces mêmes parents avec un adolescent. Les données relatives à un utilisateur peuvent aussi être liées au but de leur voyage, c.-à-d. affaires ou vacances. Les données relatives aux services sont typiquement relatives au type dc chambre (p. ex. située à un étage bas, à un étage élevé, une chambre tranquille, avec une vue sur l'océan, une vue sur la ville, une vue sur le jardin, une chambre fumeur, non-fumeur, une chambre simple, double, triple, un lit extra large, un lit large, une chambre luxueuse, une suite, etc. Les données relatives aux services incluent aussi généralement les dates d'arrivée et dc départ et peuvent par ailleurs inclure une requête pour plusieurs chambres. [0003] En sus des données fonctionnelles dans la requête de l'utilisateur, il y a d'autres com- plexités qui surviennent pour solutionner la requête d'un utilisateur. Une complexité importante introduite par le propriétaire de l'hôtel (de la chaîne d'hôtel) concerne les tarifs variés qui peuvent être applicables à une même chambre. Spécifiquement, les propriétaires d'hôtel, particulièrement les chaînes d'hôtels à grande échelle, ont des offres tarifaires différentes. Des exemples d'offres tarifaires sont les suivants : la meilleure offre tarifaire flexible (BFR) indiquant le tarif le plus bas disponible au public avec le moins de restrictions pour ce type de chambre au moment de la réservation ; l'offre au meilleur tarif garanti (BRG) signifiant que si vous trouvez un tarif 2 moins cher au cours d'une période définie après la réservation, la différence est compensée; une offre à prix bas signifiant le prix le plus bas disponible au public pour ce type de chambre au moment de la réservation, laquelle réservation est ensuite typiquement assujettie à des frais d'annulation ; une autre offre tarifaire qui n'est utilisée que lorsqu'une ou plusieurs autres offres tarifaires ne sont pas disponibles, etc. Les offres tarifaires peuvent aussi dépendre des données fonctionnelles dans la requête de l'utilisateur (p. ex., l'utilisateur peut inclure une requête pour voir uniquement des BI4Rs). [0004] Les prétendues règles commerciales qui sont implémentées par les chaînes d'hôtels représentent une autre complexité qui doit être prise en compte. En général ces règles sont implémentées au niveau des hébergements. Un hébergement est un appariement d'un type de chambre et d'un tarif de chambre. Les règles commerciales détaillent qu'une disponibilité d'un certain hébergement (ou groupe d'hébergements) dépend de la disponibilité d'un hébergement différent (ou d'un groupe d'hébergements différents). Dans un premier scénario, il est possible qu'une offre tarifaire soit seulement affichée comme étant disponible lorsqu'une offre tarifaire différente n'est plus disponible. Par exemple, un hôtel a 20 chambres de type de chambre A et fait une promotion sur 10 de ces chambres à une offre tarifaire réduite. L'offre tarifaire normale ne devient disponible que lorsque le nombre prédéfini de chambres du type de chambre A a été réservé. Dans un deuxième scénario, il est possible qu'un type de chambre devienne disponible uniquement lorsqu'un ou plusieurs autres types de chambres ne sont plus disponibles. Par exemple, lorsqu'une personne non handicapée demande une chambre simple, il se peut qu'on lui offre un type de chambre adaptée à une personne handicapée, car les chambres simples ne sont plus disponibles. [0005] En général, le solutionnement de la requête de l'utilisateur nécessite l'identification d'un ou de plusieurs hébergements qui satisfont la requête de l'utilisateur en tenant compteur des règles de dépendance. Cependant, un utilisateur s'attend normalement aussi à recevoir un tarif pour chaque chambre disponible. Ainsi, même après avoir identifié l'hébergement disponible, une autre complexité pour solutionner la requête de l'utilisateur est le calcul du prix actuel de l'hébergement. Afin de calculer un prix, les systèmes de réservation d'hôtel sont normalement assortis d'un moteur tarifaire dédié pour générer le prix. Afin de générer le prix, le moteur tarifaire a besoin d'interfacer avec d'autres systèmes dédiés (p. ex. un système de gestion de recettes). Les détails du moteur tarifaire ne sont pas importants pour la présente invention, mais on notera que cela nécessite généralement beaucoup de ressources et est donc, en général, plus chronophage pour solutionner une requête d'utilisateur. [0006] 111 faut par ailleurs signaler qu'actuellement, un procédé pour solutionner une requête de client est géré en fournissant un système informatique dédié qui inclut des ins- 3 tructions codées en dur pour chaque règle de dépendance possible. C'est pourquoi la révision d'une règle de dépendance spécifique signifie qu'il faut revoir les instructions codées en dur, ce qui s'avère très chronophage et conduit fréquemment à des erreurs (p. ex. oublier de changer le code pour un certain type de requêtes d'utilisateur, dans ce cas l'ancienne règle de dépendance obsolète est toujours appliquée). [0007] Au vu des complexités décrites ci-dessus, il n'est pas simple de solutionner des requêtes d'utilisateur dans les meilleurs délais. Ces exemples montrent le besoin pour des systèmes, des procédés et des produits-programmes d'ordinateur améliorés afin de solutionner les requêtes d'utilisateurs. [0008] Un objectif de la présente invention est de fournir un procédé implémenté par or- dinateur pour solutionner une requête d'un utilisateur en utilisant moins de ressources. [0009] Cet objectif est atteint selon l'invention avec un procédé implémenté par ordinateur pour générer une liste d'éléments de données disponibles d'au moins un fournisseur de services en réponse à la requête générée par un utilisateur, le procédé comprenant : a) la réception de ladite requête générée par l'utilisateur comprenant des données fonctionnelles qui incluent des données relatives à l'utilisateur et des données relatives aux services ; b) la récupération, en particulier à partir d'une première base de données, d'une liste d'éléments de données, laquelle liste est de préférence basée sur lesdites données fonctionnelles, une valeur de validité binaire indéfinie ayant été attribuée à chaque élément de données ; c) la récupération, à partir d'une base de données de règles, d'un ensemble de règles de dépendance pour la valeur de validité des éléments de données, lequel ensemble est de préférence basé sur lesdites données fonctionnelles ; d) la génération d'un graphe orienté en organisant ladite liste d'éléments de données selon les règles de dépendance récupérées, le graphe orienté comprenant une pluralité de noeuds reliés par des flèches d'un premier type, chaque noeud représentant un élément de données, chaque premier type de flèches s'étendant d'un noeud d'extrémité vers un noeud de tête et représentant que la valeur de validité dudit noeud d'extrémité est dépendante de la valeur de validité dudit noeud de tête ; e) d'appliquer un processus de filtration pour résoudre ledit graphe orienté, lequel le processus de filtration comprend un processus d'élimination de validité comprenant : val-i) de calculer, pour un premier sous-ensemble de noeuds comprenant au moins un noeud de tête, la valeur de validité étant conforme à une base de données de validité, la valeur de validité d'un élément de données étant égale à un lorsque ledit au moins un fournisseur de services comprend un service satisfaisant les données relatives au service dans ladite requête générée par un utilisateur ; val-ii) d'établir, après val-i), la valeur de validité de chaque noeud d'extrémité qui est dépendante d'un noeud de tête ayant une valeur de validité de zéro à zéro ou un ; val-iii) de répéter val-i) et val-ii) jusqu'à ce que chaque noeud dans ledit graphe orienté ait une valeur de validité établie ; et val-iv) de filtrer, après val-iii), le graphe orienté en conservant seulement les noeuds ayant une valeur de validité égale à un ; f) de calculer, par un moteur tarifaire, un prix pour chaque élément de données filtré ; et g) de générer ladite liste des éléments de données disponibles en extrayant les éléments de données filtrés avec leurs prix dudit graphe orienté. [0010] L'invention repose sur l'idée que la réduction du nombre d'éléments de données pour lesquels un prix doit être calculé réduira les ressources nécessaires pour solutionner la requête de l'utilisateur dans les meilleurs délais. Par conséquent, sur la base de la requête de l'utilisateur, en particulier sur les données fonctionnelles qui y sont intégrées et sur les règles de dépendance récupérées, les éléments de données sont organisés dans un graphe orienté ou chaque noeud représente un élément de données auquel une valeur de validité binaire indéfinie est attribuée. Le graphe orienté est ensuite filtré sur la hase de la valeur de validité pour réduire le nombre de noeuds pour lesquels un prix doit être calculé. En particulier, le processus d'élimination de validité commence en calculant la valeur de validité pour un premier sous-ensemble de noeuds en interfaccant avec une hase de données de validité et par la suite en propageant les valeurs de validité calculées à travers le graphe orienté sur la hase des règles de dépendance. Ce procédé est appliqué de façon itérative jusqu'à cc que chaque noeud dans ledit graphe orienté ait un ensemble de valeurs de validité, après quoi les noeuds invalides (c.-à-d. les noeuds ayant une valeur de validité de zéro) sont supprimés. [0011] Bien que le taux de suppression (c.-à-d. le nombre d'éléments de données supprimés par rapport au nombre d'éléments de données d'origine) dépende d'un plus grand nombre de facteurs, il a été constaté qu'une telle stratégie diminue en moyenne le nombre d'éléments de données pour lesquels un prix doit être calculé. Par conséquent, moins d'appels au moteur tarifaire ont besoin d'être faits afin de satisfaire la requête de l'utilisateur, économisant ainsi des ressources et/ou diminuant le temps nécessaire pour satisfaire la requête de l'utilisateur. [0012] Comme autre avantage, la provision d'une base de données de règles séparée comprenant toutes les règles de dépendance permet de réviser facilement une ou plusieurs règles. En particulier, lorsqu'une règle de dépendance doit être révisée il suffit maintenant de réviser seulement la règle dans la base de données puisque le graphe orienté est généré pour chaque requête d'utilisateur. Cela économise du temps lors de la révision des règles de dépendance en comparaison avec les règles de dépendance codées en dur et réduit aussi le risque d'erreur dans ces révisions. [0013] Dans un mode de réalisation de la présente invention, ledit graphe orienté comprend une ou plusieurs feuilles, une feuille étant un noeud de tête qui n'est pas un noeud d'extrémité, dans lequel, pour val-i) ledit premier sous-ensemble de noeuds est constitué de feuilles. [0014] Le fait d'assurer que le premier sous-ensemble de noeuds est constitué de feuilles bénéficie de façon optimale des règles de dépendance. Cela évite en particulier, de calculer une valeur de validité d'un noeud dépendant dans val-i) ce qui s'avère plus tard être invalide en raison de sa dépendance d'un noeud qui a été calculé (ou établi) plus tardivement. [0015] Dans un mode de réalisation de la présente invention, le procédé comprend par ailleurs le filtrage, entre f) et g), du graphe orienté en conservant seulement les noeuds ayant un prix au-dessus d'un seuil prédéfini. [0016] Dans ce mode de réalisation, des recettes possibles pour le fournisseur de services sont améliorées en supprimant les éléments de données rapportant peu. [0017] Dans un mode de réalisation de la présente invention, une valeur de visibilité binaire indéfinie est attribuée à chaque noeud, dans lequel c) comprend la récupération de la base de données de règles, d'un ensemble de règles de dépendance de valeur de visibilité, lequel ensemble est de préférence basé sur lesdites données fonctionnelles, dans lequel d) comprend par ailleurs : d-i) d'ajouter des flèches d'un deuxième type entre les noeuds selon les règles de dépendance de valeurs de visibilité récupérées, chaque deuxième type de flèche s'étendant d'un noeud d'extrémité à un noeud de tête et représentant que la visibilité dudit noeud d'extrémité est dépendante de la visibilité dudit noeud de tête, dans lequel c) comprend par ailleurs un processus d'élimination de visibilité comprenant : vis-i) d'établir la valeur de visibilité de chaque noeud qui a une valeur de validité de zéro à zéro ; vis-ii) d'établir, pour un deuxième sous-ensemble de noeuds comprenant au moins un noeud de tête, la valeur de visibilité conformément à une base de données de visibilité, la valeur de visibilité d'un élément de données étant égale à un lorsque le service associé audit éléments de données satisfait les données relatives à l'utilisateur dans ladite requête générée par un utilisateur. vis-iii) d'établir après vis-h), la valeur de visibilité de chaque noeud d'extrémité qui est dépendant d'un noeud de tête ayant une valeur de visibilité de zéro comme zéro ou un ; vis-iv) de répéter vis-ii) et vis-iii) jusqu'à ce que chaque noeud dans ledit graphe orienté ait une valeur de visibilité établie ; et vis-v) de filtrer, après vis-iv), le graphe orienté en conservant seulement les noeuds ayant une valeur de visibilité égale à un. [0018] Ce mode de réalisation inclut un deuxième processus d'élimination basé sur une valeur de visibilité. La valeur de visibilité indique si oui ou non un élément de données est visible pour l'utilisateur, préférablement basé sur les données fonctionnelles, en particulier les données relatives à l'utilisateur, qu'il contient. Bien que le taux de suppression (c.-à-d. le nombre d'éléments de données supprimés par rapport au nombre d'éléments de données d'origine) dépende d'un plus grand nombre de facteurs, il a été constaté que le fait d'inclure un deuxième processus d'élimination diminue, en moyenne, le nombre d'éléments de données pour lesquels un prix doit être calculé. Par conséquent, moins d'appels du moteur tarifaire ont besoin d'être faits afin de so- 6 lutionner la requête de l'utilisateur, économisant de ce fait des ressources et/ou diminuant le temps nécessaire pour solutionner la requête de l'utilisateur. [0019] Dans un mode de réalisation préféré de la présente invention, le deuxième sous- ensemble de noeuds est inclus le premier sous-ensemble de noeuds, dans lequel, de préférence, le premier sous-ensemble de noeuds inclut des noeuds avec une visibilité égale à zéro. [0020] Cela assure que les appels faits à la hase de données de visibilité sont faits au moins pour les mêmes éléments de données pour lesquels les appels à la hase de données de validité ont été faits, signifiant que les appels peuvent être exécutés simultanément pour économiser du temps et/ou des ressources. [0021] Dans un mode de réalisation de la présente invention, dans lequel une valeur de compteur de nombres entiers est attribuée à chaque noeud, le compteur de la valeur d'un noeud étant le nombre de noeuds d'extrémité qui dépendent dudit noeud via le premier type de flèches, dans lequel, pour le processus d'élimination de validité, les noeuds ayant les valeurs de compteur les plus élevées sont considérés en premier. [0022] Cc mode de réalisation optimise par ailleurs le processus de filtration en commençant avec les noeuds ayant le nombre le plus élevé de noeuds dépendants, car ceux-ci, particulièrement lorsqu'ils s'avèrent être invalides et éventuellement invisibles, suppriment le plus de noeuds dépendants. [0023] Dans un mode de réalisation de la présente invention, ledit graphe orienté comprend au moins un de : au moins un noeud de tête qui est dépendant de multiples noeuds de têtes ; et de multiples noeuds d'extrémité qui sont dépendants d'un seul noeud de tête. [0024] Dans un mode de réalisation de la présente invention, lesdites flèches représentent au moins une des relations de dépendance suivantes : «VRAI» indiquant que la valeur de validité du noeud d'extrémité est la même que la valeur de validité du noeud de tête; « FAUX» indiquant que la valeur de validité d'un noeud d'extrémité est l'opposé de la valeur de validité d'un noeud de tête ; «ET» indiquant que la valeur de validité d'un noeud d'extrémité est égale à un lorsque la valeur de validité de tous ses noeuds de tête est égale à un ; «OU» indiquant que la valeur de validité du noeud d'extrémité est égale à un lorsque la valeur de validité d'au moins un des noeuds de tête est égale à un. [0025] Dans un mode de réalisation de la présente invention, chaque premier type de flèche est VRAI et chaque deuxième type de flèche est FAUX. [0026] Sur la base des relations de dépendance ci-dessus et de multiples dépendances, chaque règle de dépendance concevable peut être implémentée uniquement avec un nombre limité d'opérateurs. [0027] Dans un mode de réalisation de la présente invention, chaque élément de données est un hébergement, ledit fournisseur de services étant au moins un hôtel, lesdites données relatives aux services comprenant au moins une date d'arrivée et une date de départ et 7 ladite hase de données de validité étant un inventaire dudit au moins un hôtel, dans lequel ladite hase de données de visibilité est une table de consultation dudit au moins un hôtel, dans lequel un noeud a une valeur de visibilité égale à un lorsque le type d'hébergement satisfait les données relatives à l'utilisateur dans ladite requête générée par l'utilisateur, dans lequel chaque hébergement comprend un type de chambre et un prix de chambre, un noeud ayant une valeur de validité égale à un lorsque ledit au moins un hôtel comprend une chambre correspondant au type d'hébergement qui est disponible entre ladite date d'arrivée et ladite date de départ. [0028] Dans cc mode de réalisation, le procédé est particulièrement adapté au système de ré- servation d'hôtel informatisé. [0029] Dans un mode de réalisation préféré de la présente invention, ladite requête générée par un utilisateur comprend un nombre entier naturel supérieur à zéro indiquant le nombre de chambres demandées, dans lequel un noeud a une valeur de validité égale à un lorsque ledit au moins un hôtel comprend le nombre de chambres demandées correspondant au type d'hébergement qui est disponible entre ladite date d'arrivée et ladite date de départ. [0030] Cette vérification évite d'avoir à faire appel au moteur tarifaire lorsque le nombre d'hébergements disponibles est déjà en dessous du nombre de la requête, cc qui accélère substantiellement le solutionnement de la requête. [0031] Cet objectif est aussi atteint par un système informatique comprenant des moyens configurés pour mettre en oeuvre les étapes du procédé telles que décrites ci-dessus. [0032] Cet objectif est par ailleurs atteint par un produit programme d'ordinateur comprenant des instructions stockées sur un support lisible par ordinateur qui, lorsque le programme est exécuté par un ordinateur, amène ordinateur à mettre en oeuvre les étapes du procédé telles que décrites ci-dessus. [0033] L'invention sera expliquée par ailleurs au moyen de la description qui suit et des figures annexées. [0034] [fig.1] montre un organigramme d'un procédé implémenté par ordinateur pour so- lutionner une requête d'utilisateur pour une réservation d'hôtel conformément à un mode de réalisation de la présente invention [0035] [fig.2] montre un système de réservation d'hôtel informatisé conforme à un mode de réalisation de la présente invention. [0036] [fig.3] montre un exemple de graphes orientés. [0037] [fig.4] montre un autre exemple de graphes orientés. [0038] [fig..5] montre un organigramme de la filtration de la Fig. 1. [0039] La présente invention sera décrite par rapport à des modes de réalisation particuliers et en faisant référence à certains dessins, mais l'invention ne s'y limite pas. Les dessins décrits sont seulement schématiques et ne sont pas limitatifs. Dans les dessins, la taille 8 de certains des éléments peut être exagérée et, à des fins illustratives, n'est pas dessinée à l'échelle. Les dimensions et les dimensions relatives ne correspondent pas nécessairement aux réductions actuelles pour la mise en pratique de l'invention. [0040] Par ailleurs, les termes : premier, deuxième, troisième et autres termes similaires dans la description sont utilisés pour faire la distinction entre des éléments similaires et pas nécessairement pour décrire un ordre séquentiel ou chronologique. Les termes sont interchangeables dans des circonstances appropriées et les modes de réalisation de l'invention peuvent fonctionner selon d'autres séquences que celles décrites ou illustrées dans les présentes. [0041] En outre, les termes «dessus », «bas « sur», «dessous » et autres de cc genre sont utilisés dans la description à titre descriptif. Les termes ainsi utilisés sont interchangeables dans des circonstances appropriées et les modes de réalisation de l'invention décrits dans les présentes peuvent fonctionner selon d'autres orientations que celles décrites ou illustrées dans les présentes. [0042] Par ailleurs, les divers modes de réalisation même s'ils sont décrits comme «préférés » doivent être interprétés comme des modes d'implémentation de l'invention exemplaires plutôt que limitatifs du champ d'application de l'invention. [0043] En général, les routines exécutées pour mettre en oeuvre les modes de réalisation de la présente invention, qu'elles soient implémentées comme des parties d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-ci, peuvent être désignées dans les présentes comme « code de programme informatique» ou simplement «code de programme ». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à des moments divers dans des dispositifs divers de mémoire et de stockage dans un ordinateur, et qui lorsqu'il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, amène cet ordinateur à mettre en oeuvre les opérations nécessaires pour exécuter les opérations et/ou éléments concrétisant les aspects variés des modes de réalisation de l'invention. Les instructions d'un programme informatique lisibles par ordinateur pour accomplir les opérations des modes de réalisation de l'invention peuvent être, par exemple : le langage d'assemblage ou, un code source ou un code objet, écrit en combinaison avec un ou plusieurs langages de programmation. [0044] Le code de programme mis en oeuvre dans toute application/module décrit(e) dans les présentes peut être distribué individuellement ou collectivement comme un produit programme d'ordinateur, sous une variété de formes. En particulier, le code de programme peut-être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur pour amener un processeur à mettre en oeuvre des aspects des modes de réalisation de l'invention. 9 [0045] Les supports de stockage de données lisibles par ordinateur qui sont intrinsèquement non transitoires, peuvent inclure des médias tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans toute méthode ou technologie de stockage de données, tels que des instructions de programme lisibles par ordinateur, des structures de donnée, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires : une mémoire vive à accès aléatoire (RAM), une mémoire morte à lecture seule (ROM), une mémoire à lecture seule programmable et effaçable (EPROM), une mémoire à lecture seule programmable et effaçable électriquement (EEPROM), une mémoire flash, ou autre technologie de support solide de mémoire, un disque compact portable doté d'une mémoire à lecture seule (CD-ROM), ou autre stockage optique, des cassettes magnétiques, une bande magnétique, un support de stockage magnétique ou tout autre support pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme étant des signaux transitoires en soi (p. ex., des ondes radio ou d'autres ondes électromagnétiques se propageant). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou un dispositif de stockage externe via un réseau. [0046] Les instructions de programme lisibles par ordinateur, stockées dans un support lisible par ordinateur, peuvent être utilisées pour amener un ordinateur, d'autres types d'appareils programmables de traitement ou d'autres dispositifs, à fonctionner d'une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies par un ou plusieurs processeurs sur un ordinateur à usage général, un ordinateur à usage spécial, ou tout autre appareil programmable de traitement de données pour produire une machine telle que les instructions qui sont exécutées par l'intermédiaire d'un ou de plusieurs processeurs provoquent une série de calculs devant être effectués pour implémenter les fonctions, actions et/ou opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ ou diagrammes blocs. [0047] Dans certains autres modes de réalisation, les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs peuvent être réarrangés, traités en série et/ou simultanément, conformément aux modes de réalisation de l'invention. En outre, un quelconque des organigrammes, diagrammes séquentiels, et/ou diagrammes blocs peut inclure plus ou moins de blocs que ceux qui sont illustrés conformément à des modes de réalisation de l' invention. [0048] Bien que la présente divulgation soit décrite en faisant référence à un système de ré- servation d'hôtel, on notera que l'invention n'est pas limitée à cette application particulière et doit être considérée comme étant applicable à toutes sortes de systèmes de données dédiés au solutionnement des requêtes d'utilisateur lorsque les éléments de données désirés sont liés les uns aux autres par des règles de dépendance. [0049] L'invention sera décrite de façon générale en faisant référence aux figures 1 et 2, où un procédé 100 et un système 200 sont illustrés pour solutionner une requête de réservation d'hôtel entrante. [0050] L'utilisateur final (p. ex. un agent de voyage, un client, etc.) génère une requête sur son terminal d'utilisateur 20 (p. ex. un ordinateur personnel, un dispositif mobile incluant un smartphone, un ordinateur portable, un PDA, etc.). Cette requête peut être générée automatiquement par un logiciel dédié (p. ex. le site Web d'une chaîne d'hôtel ou le site Web d'une agence de voyages) permettant à un utilisateur de saisir unc liste de paramètres prédéfinis (p. ex. la destination, les dates d'arrivée et de départ, le nombre de personnes, les préférences telles que le type de chambre, l'emplacement de la chambre, la disponibilité d'un parking, etc.). La requête générée par l'utilisateur comprend des données fonctionnelles qui incluent des données relatives à un utilisateur et des données relatives aux services. Les données relatives à un utilisateur sont par exemple, si l'utilisateur est handicapé ou non et peuvent aussi inclure le nombre de personnes et leurs âges. Les données relatives à un utilisateur peuvent aussi avoir un lien avec l'objet du voyage. Les données relatives aux services sont typiquement liées au type de chambre et incluent aussi les dates d'arrivée et de départ et peuvent par ailleurs inclure une demande est faite pour de multiples chambres. [0051] La requête générée par l'utilisateur est envoyée du terminal de l'utilisateur 20 vers le système informatique 200. Cet envoi peut survenir via plusieurs voies différentes, mais se fait généralement via l'Internet. La requête est reçue au 102 dans le module entrée-sortie (I/O) 202 qui est responsable de la gestion de toute correspondance entrante et sortante entre le système 200 et le terminal de l'utilisateur 20. [0052] Après avoir reçu la requête, les données fonctionnelles dans la requête sont envoyées à un module de récupération de données 204 dont la tâche est de traiter les données fonctionnelles au 104 de sorte qu'une liste d'hébergements et un ensemble de règles de dépendance de validité puissent être récupérées au 106 et 108 respectivement. Spécifiquement, le module d'analyse de données 204 peut traiter et/ou formater les données fonctionnelles ou un sous-ensemble de celles-ci sous forme de structure de donnée appropriée pour interfacer avec un inventaire de chambres d'hôtel externe 30 et avec une 11 hase de données de règles de dépendance 206. En outre, le module d'analyse de données 204 peut initier automatiquement un ou plusieurs appels à l'inventaire externe de chambres d'hôtel 30 et à la hase de données de règles de dépendance 206 afin de récupérer les données désirées. Dans certains modes de réalisation, en même temps que les règles de dépendance de validité, un ensemble de règles de dépendance de visibilité est aussi récupéré au 108. [0053] De façon générale, un hébergement peut être envisagé comme une paire consistant d'un type de chambre et d'un tarif de chambre. Des exemples de type de chambre incluent une chambre simple, double, triple, une chambre luxueuse, une suite, située à un étage inférieur, à un étage supérieur, une chambre tranquille, avec vue sur l'océan, sur la ville, sur le jardin, une chambre fumeur, non-fumeur, un lit extra large, un lit large, une chambre pour personne handicapée, etc. Des exemples de tarifs de chambre incluent le meilleur tarif flexible (BFR), le meilleur tarif garanti (BRG), un bas tarif, un autre tarif, etc. On notera que la même chambre d'hôtel physique peut être présente dans de multiples hébergements. Par exemple une chambre double peut être appariée avec quatre tarifs différents, dans ce cas la même chambre physique génère quatre hébergements différents. [0054] Les données récupérées (c.-à-d. la liste des hébergements, l'ensemble des règles de dépendance de validité et, en option, l'ensemble des règles de dépendance de visibilité) sont envoyées à un générateur de graphes 208 qui est responsable de l'organisation de la liste d'hébergements dans un graphe orienté sur la base des règles de dépendance au 110. Dans le générateur de graphes 208, un ou facultativement deux valeurs binaires seront attribuées à chaque hébergement, une première valeur indiquant la valeur de validité de l'hébergement et une deuxième valeur indiquant la visibilité de l'hébergement. Le fait que l'hôtel (la chaîne) ait ou non, une chambre du type de chambre indiquée disponible est lié à la valeur de validité. Le fait qu'un hébergement puisse être offert à un utilisateur est lié à la valeur de visibilité. Par exemple une chambre pour personne handicapée, bien que disponible, ne devrait pas en premier lieu être proposée à une personne non handicapée. De façon générale, les deux valeurs sont aussi liées l'une à l'autre, car la valeur de visibilité est toujours établie à zéro quand la valeur de validité est zéro comme ceci sera détaillé ci-dessous. Quelques exemples d'un graphe orienté seront décrits en faisant référence aux figures 3 et 4. [0055] La Figure 3 illustre une situation impliquant quatre hébergements, chacun ayant le même tarif de chambre et seule personne a fait une réservation. L'hébergement 1 (RS1) et l'hébergement 2 (RS2) représentent une chambre double, un hébergement 3 (RS3) représente une chambre simple et un hébergement 4 (RS4) représente une chambre pour personne handicapée. Puisque RS1 et RS2 sont identiques, ils sont indépendants l'un de l'autre. RS1 et RS2 sont dépendants de la visibilité de RS3, car une 12 chambre double sera offerte uniquement au cas où aucune chambre simple n'est disponible. En d'autres termes, puisque RS3 a une valeur de visibilité égale à 1 (c.-à-d. qu'elle est visible), alors RSI et RS2 ont une valeur de visibilité égale à 0 (c.-à-d. qu'elles sont invisibles). De cc fait, les flèches 301 et 302 indiquent une relation de visibilité «FAUX ». RS4 est dépendant de la visibilité de RSI, RS2 et RS3, car cet hébergement peut être offert à une personne non handicapée uniquement si RS1, RS2 et RS3 ne sont pas visibles, signifiant que la flèche 303 indique une relation de visibilité «FAUX ET ». En d'autres termes, lorsque RS1, RS2 et RS3 ont une valeur de visibilité égale à 0, alors RS4 a une valeur de visibilité égale à 1. [0056] Dans le graphe orienté de la figure 3, il peut maintenant se passer ce qui suit. En supposant que l'utilisateur indique qu'il voyage seul, alors RS3 sera visible basé sur la supposition qu'il est valide, sinon il sera invisible. Si RS3 est valide, alors seul RS3 sera délivré au 112 puisque RSI, RS2 et RS3 sont invisibles. Si RS3 est invalide, alors RS1 et RS2 seront rendus visibles. Le fait que RS1 et/ou RS2 seront maintenant délivrés ou non dépend seulement de la validité de RS1 et RS2. Si l'un ou l'autre est valide, alors celui-ci sera affiché. Si aucun n'est valide, seulement alors RS4 sera visible. RS4 sera alors affiché en fonction de sa validité. [0057] La Figure 4 illustre une situation comprenant six hébergements impliquant des chambres doubles, chacune étant assortie de trois offres tarifaires différentes. RS1, RS3 et RS5 indiquent une chambre double avec respectivement un tarif principal, un autre tarif et un BFR. De façon similaire, RS2, RS4 et RS6 indiquent une chambre double avec respectivement un tarif principal, un autre tarif et un BFR. En raison de la politique de l'hôtel, BFR est toujours invisible, sauf si tous les autres tarifs ne sont plus valides et sont donc invisibles. De ce fait, RS5 et RS6 dépendent de la visibilité des hébergements RS1 à RS4. En outre, si l'hébergement BFR (RS5 et RS6) n'est pas valide, cela signifie que les chambres physiques ont été réservées normalement, alors aucun des hébergements RS1 à RS4 ne peut être valide. De ce fait, la validité des hébergements RS1 à RS4 est directement dépendante de la validité de RS5 et RS6 comme indiqué par les flèches 406 à 409. L'autre tarif n'est valide qu'au cas où les deux tarifs principaux seraient invalides. De ce fait, les hébergements RS3 et RS4 dépendent de la validité de RS1 et RS2. En outre, l'utilisateur a indiqué une préférence pour une chambre tranquille. Dans ce cas, RS1 est une chambre tranquille, alors que RS2 ne l'est pas. Par conséquent, la visibilité de RS2 dépend de la visibilité de RS1. Pour résumer, la flèche 401 indique une relation de visibilité «FAUX ET », la flèche 402 indique une relation de validité «FAUX ET», les flèches 403 et 404 indiquent une relation de visibilité «FAUX», la flèche 405 indique une relation de validité «FAUX» et les flèches 406 à 409 indiquent une relation de validité « VRAI». [0058] Dans le graphe orienté de la figure 4, il peut maintenant se passer ce qui suit. RS5 ou 13 RS6 sont valides, ce qui rend automatiquement RS1 et RS3 ou RS2 et RS4 valides. RS1 sera affiché au 112. Si RS5 n'est pas valide, alors RS1 sera invisible et RS2 sera présenté à l'utilisateur. Si RS2 est aussi invalide, RS3 sera affiché. Lorsque les hébergements RS1 à RS3 sont invalides, RS4 sera affiché en supposant qu'il soit valide. Si RS4 n'est pas valide, RS5 et RS6 seront affichés. [0059] On notera que les exemples décrits ci-dessus en référence aux figures 3 et 4 sont ex- trêmement simplifiés. En pratique, le graphe orienté peut, selon l'hôtel (chaîne), comprendre aisément des douzaines voire des centaines de noeuds, chaque noeud représentant un hébergement. [0060] Le résultat final du générateur de graphes 208, au 110, est un graphe orienté comprenant une pluralité de noeuds (chaque noeud représentant un hébergement) qui sont connectés avec un premier type de flèches et un deuxième type de flèches indiquant respectivement la dépendance de validité et la dépendance de visibilité entre les noeuds de tête et les noeuds d'extrémité. Ce graphe est envoyé à un module de filtration 210 qui appliquera un processus de filtration pour résoudre ledit graphe orienté au 112, le processus de filtration sera décrit en faisant référence à la figure 5. [0061] Au 502, le graphe orienté est reçu par le module de filtrage 210. Un sous-ensemble de noeuds avec lequel le processus de filtration commencera est sélectionné au 504. De préférence, ce sous-ensemble consiste de noeuds feuilles, c.-à-d. de noeuds qui ne sont pas dépendants d'autres noeuds pour éviter d'avoir à calculer une valeur de visibilité au 506 qui aurait pu être déterminée à partir de son noeud de tête. Plus préférablement, ce sous-ensemble contient les noeuds feuilles ayant le nombre le plus élevé de noeuds dépendants. De façon avantageuse, ce sous-ensemble est choisi pour contenir aussi peu de noeuds que possible afin de minimiser le nombre de calculs de valeurs de visibilité. Pour ce sous-ensemble, une valeur de visibilité est calculée au 506 en interfaceant avec une table de consultation de types de chambre d'hôtel 50. Cette table 50 contient des informations concernant les types de chambres qui peuvent et ne peuvent pas être visibles pour certains profils d'utilisateurs. [0062] Une fois que la valeur de visibilité a été calculée pour le sous-ensemble, ces valeurs sont propagées à travers le graphe orienté conformément avec les règles de dépendance de visibilité au 508. Au cas où l'établissement de la valeur de visibilité de tous les noeuds dans le graphe orienté ne résulterait pas de la propagation, les étapes 504 à 508 sont répétées. En particulier, un nouveau sous-ensemble contenant des noeuds non définis est choisi et la table de consultation 50 est à nouveau utilisée pour établir la valeur de visibilité de ces noeuds dont les valeurs de visibilité sont ensuite propagées. Ultimement, chaque noeud dans le graphe orienté aura une valeur de visibilité établie. [0063] Une première suppression (ou élimination) est faite au 510. Spécifiquement, chaque noeud d'extrémité invisible qui n'est pas lui-même un noeud de tête est supprimé. Le 14 fait que le noeud ne puisse pas être un noeud de tête évite de supprimer des noeuds qui peuvent influencer le processus d'élimination de validité qui survient subséquemment. On notera qu'il est possible d'omettre l'étape 510. En outre, si la valeur de visibilité a été attribuée au 110, il est aussi possible d'omettre les étapes 504 à 510. [0064] Au 512 un nouveau sous-ensemble de noeuds est sélectionné pour commencer le processus d'élimination de validité. De préférence, ce sous-ensemble consiste de noeuds feuilles, c.-à-d. des noeuds qui ne sont pas dépendants d'autres noeuds pour éviter d'avoir à calculer une valeur de validité au 514 qui aurait pu être déterminée à partir de son noeud de tête. Plus préférablement, ce sous-ensemble contient les noeuds feuilles ayant le nombre le plus élevé de noeuds dépendants. De façon avantageuse, cc sous-ensemble est choisi pour contenir aussi peu de noeuds que possible afin de minimiser le nombre de calculs de valeur de validité. Dans un mode de réalisation, cc sous-ensemble est identique à celui qui a été sélectionné au 504. Pour ce sous-ensemble, une valeur de validité est calculée au 514 en intcrfaccant avec un moteur de disponibilité de chambres d'hôtel 40. Ce moteur 40 détermine si un hébergement est disponible ou non. D'autres détails sur le moteur de disponibilité de chambres d'hôtel 40 seront évités, car il s'agit d'un moteur très complexe qui interface avec une pluralité de systèmes externes différents pour générer des disponibilités actualisées. Cependant, on remarquera que les appels au moteur de disponibilité de chambres d'hôtel 40 nécessitent une quantité substantielle de ressources supérieure aux appels à la table de consultation de types de chambre d'hôtel 50 et qu'il est donc avantageux de minimiser le nombre d'appels si possible. C'est aussi pour cela que l'étape 510 est bénéfique, car elle peut réduire le nombre d'appels au moteur de disponibilité de chambres d'hôtel 40. [0065] Une fois que la valeur de validité a été calculée pour le sous-ensemble, ces valeurs sont propagées à travers le graphe orienté conformément aux règles de dépendance de validité au 516. Au cas où l'établissement de la valeur de validité de tous les noeuds dans le graphe orienté ne résulterait pas de la propagation, les étapes 512 à 516 sont répétées. En particulier, un nouveau sous-ensemble est choisi contenant des noeuds non établis et le moteur de disponibilité de chambres d'hôtel 40 est à nouveau sollicité pour calculer la valeur de validité de ces noeuds, lesquelles valeurs de validité sont ensuite propagées. Ultimement, chaque noeud dans le graphe orienté aura une valeur de validité établie. [0066] Aux 518, les valeurs de visibilité sont ajustées, lorsque c'est nécessaire, sur la base des valeurs de validité. Spécifiquement, les noeuds invalides sont fixés à une valeur de visibilité égale à zéro. Les valeurs de visibilité modifiées sont ensuite propagées au 520, les étapes 518 et 520 peuvent aussi être omises et seront omises au cas où aucune valeur de visibilité n'a été établie au 110. Une deuxième suppression est effectuée au 522 en conservant uniquement les noeuds ayant une valeur de validité, et faculta- tivement une valeur de visibilité, égale à un. [0067] Une fois que le graphe orienté a été filtré au 112, le module de récupération de prix 212 interface avec un moteur tarifaire externe 60 pour déterminer un prix pour chaque noeud non supprimé au 114. Comme indiqué ci-dessus, les détails du moteur tarifaire ne sont pas importants pour la présente invention, mais il ne faut pas oublier que cela nécessite généralement beaucoup de ressources et que c'est donc en général plus chronophage pour le solutionnement d'une requête d'utilisateur, et il est donc avantageux de minimiser le nombre d'appels si possible. [0068] Une fois que le prix a été récupéré pour chaque noeud restant, un filtre supplé- mentaire peut être appliqué au 116 par un module de filtration de prix de 214. Spécifiquement, il est vérifié si le prix d'un noeud dépasse un seuil prédéfini. Par exemple, le seuil peut être basé sur une offre de has tarif et nécessite que le prix soit au moins 15 % supérieur au prix de l'offre de bas tarif. Les noeuds ayant un prix trop has sont aussi supprimés. [0069] Les noeuds restants sont fournis au module TO 202 qui les met en liste et les affiche au 118 sur le terminal de l'utilisateur 20. [0070] Bien que des aspects de la présente divulgation aient été décrits en faisant référence à des modes de réalisation spécifiques, on notera que ces aspects peuvent être implémentés sous d'autres formes dans le champ d'application de l'invention. 16 [Revendication I]