FR 3098943 A1 20210122 FR 1907951 A 20190715 Description Titre de l'invention : Système, procédé et dispositif pour répondre de manière différentielle aux requêtes de données [0001] La spécification concerne de façon générale la gestion de requêtes de données et spé- cifiquement un système, un procédé et un dispositif pour répondre de manière différentielle aux requêtes de données selon l'origine des requêtes. [0002] Dans une variété de contextes, un dispositif informatique (p. ex. un serveur) reçoit des requêtes pour des données et génère des réponses à ces requêtes (c.-à-d. qu'il génère et/ou récupère les données pour les renvoyer au demandeur). Dans certains scénarios, le contenu de la réponse varie sur la hase des caractéristiques du demandeur. Par exemple, dans l'industrie du voyage, une entité agente de voyage peut soumettre une requête pour des offres de produits de voyage (p. ex. des vols) à un dispositif informatique ou à un réseau de dispositifs implémentant la logique de construction d'offre d'une compagnie aérienne. Un tel système peut ensuite, afin de générer une réponse à la requête, traiter un ensemble de règles définissant le contenu de la réponse (p. ex. les informations relatives à la programmation et aux tarifs des vols mentionnés ci-dessus) spécifique à chacune d'un nombre d'entités agentes de voyages individuelles. [0003] L'approche ci-dessus requiert cependant que les règles spécifiques à chacune des entités demandeuses soient déployées au niveau du gestionnaire de requêtes (p. ex. un système de distribution mondiale (GDS). Des nombres croissants de demandeurs augmentent le coût computationnel et la complexité d'implémentation de ces règles. Par ailleurs, certains systèmes utilisent une entité intermédiaire entre les demandeurs et les gestionnaires de requête, telle qu'un système agrégateur connectant un demandeur à de multiples gestionnaires de requête. La présence de ces entités intermédiaires complique par ailleurs l'identification précise des demandeurs au niveau des gestionnaires de requête. [0004] Un premier aspect de la spécification fournit un procédé de réponses différentielles aux requêtes de données dans un serveur gestionnaire de requête, le procédé comprenant : le stockage, dans une mémoire du serveur gestionnaire de requêtes : d'un ensemble de définitions de réponses prédéfinies, chaque définition de réponse ayant un identifiant de demandeur virtuel attribué distinct ; et (ii) pour chaque identifiant de demandeur virtuel, un critère de sélection ; la réception d'une requête de données associée à un d'une pluralité de demandeurs, la requête de données incluant (i) des paramètres de requête et (ii) un ensemble d'attributs du demandeur ; la comparaison de l'ensemble des attributs du demandeur avec les critères de sélection ; basée 2 sur la comparaison, l'attribution d'un des identifiants de demandeur virtuel sélectionné à la requête de données ; la récupération d'une des définitions de réponse correspondant à l'identifiant de demandeur virtuel sélectionné; l'obtention des données de réponse en fonction des paramètres de requête et de la définition de réponse active ; et la transmission, en réponse à la requête de données des données de réponse. [0005] Dans certains exemples, l'ensemble des définitions de réponse inclut une définition de réponse par défaut correspondant à un des identifiants de demandeur virtuel par défaut ; et l'attribution de l'identifiant de demandeur virtuel sélectionné inclut, lorsque l'ensemble des attributs du demandeur ne satisfait aucun des critères de sélection, l'attribution d'un identifiant de demandeur virtuel par défaut à la requête. [0006] Dans certains exemples, le procédé comprend par ailleurs le stockage, dans la mémoire, d'un dépôt de données sources, dans lequel l'obtention des données de réponse comprend la génération des données de réponse à partir des données sources conformément à la définition de réponse et aux paramètres de requête. [0007] Dans certains exemples, l'obtention des données de réponse comprend : l'envoi d'une interrogation du serveur gestionnaire de réponse à un serveur auxiliaire identifié dans la définition de réponse, l'interrogation incluant l'identifiant de demandeur virtuel et les paramètres du demandeur; et la réception des données de réponse du serveur auxiliaire en réponse à l'interrogation. Dans certains exemples, l'interrogation peut par ailleurs inclure l'ensemble des attributs du demandeur. [0008] Dans certains exemples, la réception de la requête de données comprend la réception de la requête de données directement de l'un de la pluralité des demandeurs. [0009] Dans certains exemples, la réception de la requête de données comprend la réception de la requête de données provenant d'un agrégateur associé à un sous-ensemble de la pluralité des demandeurs. Dans certains exemples, le procédé peut par ailleurs comprendre, préalablement à la réception de la requête de données : l'établissement d'un lien de communication avec l'agrégateur en utilisant un seul ensemble d'éléments d'authentification d'agrégateur. [0010] Dans certains exemples, les paramètres de requête définissent une requête pour une offre de produits de voyage et les données de réponse définissent au moins un produit de voyage offert. Aussi, dans certains exemples, l'ensemble des attributs du demandeur inclut un type de demandeur et chaque critère de sélection inclut au moins un type de demandeur virtuel. Dans certains exemples, la requête de données est une requête pour des offres de produits de voyage formatées selon la nouvelle norme de capacité de distribution (NDC). [0011] Un deuxième aspect de la spécification fournit un serveur gestionnaire de requête comprenant : une mémoire stockant : (i) un ensemble prédéfini de définitions de réponses, chaque définition de réponse ayant un identifiant de demandeur virtuel 3 attribué distinct ; et (ii) pour chaque identifiant de demandeur virtuel, un critère de sélection ; une interface de communication ; un processeur connecté à la mémoire et à l'interface de communication, le processeur étant configuré pour : recevoir une requête de données associée à un d'une pluralité de demandeurs via l'interface de communication, la requête de données incluant (i) des paramètres de requête et (ii) un ensemble d'attributs du demandeur ; comparer l'ensemble des attributs du demandeur avec les critères de sélection ; sur la hase de la comparaison, attribuer un des identifiants de demandeur virtuel sélectionné à la requête de données ; récupérer une des définitions de réponse correspondant à l'identifiant de demandeur virtuel sélectionné ; obtenir des données de réponse en fonction des paramètres de requête et de la définition de réponse active ; et transmettre, en réponse à la requête de données, les données de réponse via l'interface de communication. [0012] Dans certains exemples, l'ensemble des définitions de réponse inclut une définition de réponse par défaut correspondant à un des identifiants de demandeurs virtuels par défaut ; et le processeur est configuré, dans le but d'attribuer l'identifiant de demandeur virtuel sélectionné, pour attribuer l'identifiant de demandeur virtuel par défaut à la requête lorsque l'ensemble des attributs du demandeur ne satisfait aucun des critères de sélection. [0013] Dans certains exemples, la mémoire comprend par ailleurs le stockage, d'un dépôt de données sources ; et le processeur est configuré, afin d'obtenir des données de réponse, pour générer des données de réponse à partir des données sources conformément à la définition de réponse et aux paramètres de requête. [0014] Dans certains exemples, le processeur est configuré, afin d'obtenir des données de réponse pour : envoyer une interrogation du serveur gestionnaire de réponse à un serveur auxiliaire identifié dans la définition de réponse, l'interrogation incluant l'identifiant du demandeur virtuel et les paramètres du demandeur ; et recevoir les données de réponse du serveur auxiliaire en réponse à l'interrogation. Dans certains exemples, l'interrogation peut par ailleurs inclure l'ensemble des attributs du demandeur. [0015] Dans certains exemples, le processeur est configuré pour recevoir la requête de données directement de l'un de la pluralité des demandeurs. [0016] Dans certains exemples, le processeur est configuré pour recevoir la requête de données d'un agrégateur associé à un sous-ensemble de la pluralité des demandeurs. Dans certains exemples, le procédé peut par ailleurs être configuré, préalablement à la réception de la requête de données, pour établir un lien de communication avec l'agrégateur en utilisant un seul ensemble d'éléments d'authentification d'agrégateur. [0017] Dans certains exemples, les paramètres de requête définissent une requête pour une offre de produits de voyage et les données de réponse définissent au moins un produit de voyage offert. Aussi, dans certains exemples, l'ensemble des attributs du demandeur inclut un type de demandeur et chaque critère de sélection inclut au moins un type de demandeur virtuel. Dans certains exemples, la requête de données est une requête pour des offres de produits de voyage formatées selon la nouvelle norme de capacité de distribution (NDC). [0018] Selon un troisième aspect, un produit-programme d'ordinateur est fourni. Le produit- programme d'ordinateur comprend des instructions qui, lorsqu'elles sont exécutées par un ordinateur, amènent l'ordinateur à mettre en oeuvre le procédé selon le premier aspect et les exemples qui y sont associés. [0019] Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles : [0020] [fig.1] illustre un système pour répondre de manière différentielle à des requêtes de données. [0021] [fig.2] illustre certains composants internes du serveur gestionnaire de requête de la FIG. 1 ; [0022] [fig.3] illustre un procédé pour répondre de manière différentielle aux requêtes de données ; [0023] [fig.4] illustre un procédé pour la mise en oeuvre du bloc 305 du procédé de la FIG. 3 [0024] [fig.5] illustre des critères de sélection exemplaires utilisés aux blocs 310 et 315 du procédé de la FIG. 3 ; [0025] [fig.6] illustre des définitions de réponse exemplaires utilisées aux blocs 330 et 335 du procédé de la FIG. 3 ; et [0026] [fig.7] illustre un exemple de la mise en oeuvre du bloc 340 du procédé de la FIG. 3. [0027] La FIG. 1 illustre un système 100 pour répondre de manière différentielle aux requêtes de données. Le système 100 inclut un serveur un gestionnaire de requêtes 104 (aussi appelé simplement le serveur 104 dans la présente) qui reçoit les requêtes de données, via un réseau 106, associé aux dispositifs informatiques des demandeurs dont des exemples 108-1. 108-2, et 108-3 sont montrés. On comprendra que des nombres plus importants ou plus petits de dispositifs informatiques de demandeurs 108 (également appelés simplement demandeurs 108 dans la présente) peuvent être fournis dans d'autres modes de réalisation. Les requêtes de données peuvent être transmises directement d'un demandeur 108 au serveur 104 via le réseau 106 comme c'est le cas pour le demandeur 108-1. D'autres demandeurs, tels que les demandeurs 108-2 et 108-3, peuvent transmettre des requêtes de données à un serveur agrégateur 112 (aussi appelé simplement un agrégateur 112) qui relaye les requêtes de données au serveur 104 comme illustré par les lignes pointillées dans la FIG. 1. En d'autres termes, certaines requêtes de données bien qu'associées aux demandeurs 108 qui sont à l'origine des requêtes de données ne sont pas reçues au serveur 104 des demandeurs 108 eux-mêmes. [0028] Le serveur 104 stocke un dépôt de données sources 116 à partir duquel des réponses aux requêtes de données sont générées. Le système 100 peut aussi inclure un ou plusieurs serveurs auxiliaires utilisés dans la génération de réponses aux requêtes de données. Un serveur auxiliaire exemplaire 120 qui stocke un dépôt auxiliaire de données sources 124 est montré dans la FIG. 1. Le serveur 104 et/ou le serveur auxiliaire 120 peuvent chacun générer une portion de la réponse à une requête de données basée sur les contenus de l'un ou des deux dépôts 116 et 124. [0029] La génération de réponse par le serveur 104 (avec ou sans l'implication du serveur auxiliaire 120) est dite différentielle parce que les réponses générées par le serveur 104 dépendent à la fois des paramètres de requête dans les requêtes de données et des attributs du demandeur 108 lui-même. C'est-à-dire que si deux demandeurs différents 108 transmettent des requêtes de données avec les mêmes paramètres de requête, les réponses fournies à chaque demandeur ne sont pas nécessairement les mêmes. Comme cela sera décrit de façon plus détaillée ci-dessous, le serveur 104 implémente diverses fonctionnalités pour permettre cette génération de réponse différentielle tout en atténuant l'augmentation des exigences en matière de stockage et la complexité computationnelle qui surviendraient dans les systèmes antérieurs permettant la génération de réponse différentielle. [0030] La fonctionnalité du système 100 et particulièrement du serveur 104, sera décrite ci- dessous en association avec un déploiement exemplaire du système 100 pour répondre à des requêtes pour des produits de voyage. Cependant, comme il en ressortira pour les hommes de métier, le système 100 peut aussi être déployé dans une variété d'autres contextes en faisant usage de la fonctionnalité décrite dans la présente pour permettre efficacement la génération de réponses différentielles. [0031] Plus spécifiquement, dans les exemples exposés ci-dessous, le serveur 104 est géré par ou pour le compte d'un fournisseur de produits de voyage tels que des vols et des services auxiliaires. C'est-à-dire que le serveur 104 est géré par ou pour le compte d'une compagnie aérienne. Les données sources 116 incluent donc des données définissant des programmations de vols, des tarifs, des services auxiliaires disponibles (p. ex. l'enregistrement de bagages, la sélection de siège, et autres services de ce genre). Le serveur auxiliaire 120 peut aussi être géré par ou pour le compte d'une compagnie aérienne et dans certains exemples peut être intégré au serveur gestionnaire de requête 104 (p. ex. comme une application supplémentaire exécutée par le serveur 104). [0032] Les dispositifs informatiques de demandeurs 108 sont des dispositifs informatiques ou des ensembles de dispositifs informatiques (p. ex. liés par des réseaux internes ou 6 autres) gérés par des entités qui vendent et/ou font la promotion des produits de voyage mentionnés ci-dessus aux clients (p. ex. des particuliers cherchant des vols). C'est-à-dire que les entités gérant les demandeurs 108 sont des intermédiaires entre la compagnie aérienne et les clients. Les demandeurs 108, en réponse aux interrogations des clients susmentionnés, envoient les requêtes de données au serveur 104. Les requêtes de données peuvent aussi être appelées requêtes d'offre ou requête de shopping et spécifient typiquement certains paramètres de requête, tels qu'un lieu d'origine et de destination pour un vol, des dates de départ (et le cas échéant de retour) et autres paramètres de cc genre. Le serveur 104 génère des réponses incluant une ou plusieurs offres (p. ex. des vols et/ou des serveurs auxiliaires) qui satisfont les paramètres de requête ainsi que toute autre condition supplémentaire spécifique au demandeur, définie au serveur 104. [0033] Les gestionnaires des dispositifs demandeurs 108 sont typiquement connus sous l'appellation d'agents de voyage et peuvent être catégorisés de diverses manières en fonction de leurs relations avec les clients et les compagnies aériennes. Par exemple, le demandeur 108-1 peut être désigné comme un agent de voyage de métarecherche. Le demandeur 108-1 peut être configure pour demander les offres pour le compte de clients (p. ex. qui peuvent interagir avec le demandeur 108-1 via des navigateurs sur le web) et pour présenter les offres reçues du serveur 104 aux clients. Cependant, le demandeur 108-1 typiquement ne finalise pas les réservations, il dirige plutôt le client vers un site web géré par la compagnie aérienne pour la réservation. [0034] Le demandeur 108-2 peut être, par exemple, une compagnie de gestion de voyages (TMC) qui gère l'approvisionnement de produits de voyage pour le compte d'une ou de plusieurs organisations. En d'autres termes, le demandeur 108-2 est un agent de voyage d'entreprise ou d'organisation. Le demandeur 108-3 peut par exemple être une agence de voyages en ligne (OTA) accessible au client via Internet pour demander des offres de produits de voyage du serveur 104 et pour acheter ces produits de voyage. [0035] L'agrégateur 112 tel qu'il est illustré dans la FIG. 1 peut servir d'intermédiaire entre certains demandeurs 108 (p. ex. les demandeurs 108-2 et 108-3) et le serveur 104. Bien que non illustré dans la FIG. 1, par souci de simplicité d'illustration, l'agrégateur 112 se connecte typiquement à de multiples serveurs 104 (p. ex. gérés par des compagnies aériennes différentes ou d'autres fournisseurs). Ainsi l'agrégateur 112 peut recevoir une demande d'un demandeur 108 et générer de multiples requêtes à chacun d'une pluralité de serveurs distincts 104. L'agrégateur 112 peut ensuite, lors de la réception des réponses de chaque serveur 104, renvoyer les réponses collectées au demandeur pertinent 108. [0036] Comme il en ressortira pour les hommes de métier, la génération de réponses aux requêtes de données est effectuée par la même entité (la compagnie aérienne dans 7 l'exemple illustré) qui fournit les produits définis dans les réponses. L'entité répondant est donc la sources maîtresse des données de réponse. Cet arrangement contraste avec les systèmes antérieurs dans lesquels les réponses sont générées par des entités intermédiaires. Par exemple, dans certains systèmes antérieurs une pluralité de systèmes de distribution mondiale (GDSs), p. ex. chacun étant implémenté par des serveurs ou plus typiquement par un réseau de serveurs, reçoit des requêtes de données dès demandeurs 108. Chaque GDS obtient également, soit directement des fournisseurs (p. ex. des compagnies aériennes) ou plus typiquement d'éditeurs tiers des informations de tarifs et de programmation (c.-à-d. au moins une portion des données sources dans les dépôts 116 et 124). Ces informations définissent des règles spécifiant quels demandeurs 108 ont accès à quels vols et/ou à quels tarifs. Par exemple, certains demandeurs 108 peuvent avoir négocié des accords de prix avec un ou plusieurs fournisseurs. Ces accords peuvent donner au demandeur un accès à des prix réduits. [0037] Chaque GDS attribue généralement une authentification et/ou des éléments d'authentification de connexion à chaque demandeur 108 desservi par le GDS. À la réception d'une requête d'un demandeur 108, un GDS donné traite les règles mentionnées ci-dessus en fonction de l'identité du demandeur 108 pour générer une réponse. Le GDS répond donc aussi de manière différentielle aux requêtes de données des demandeurs 108 qu'il dessert. C'est-à-dire, que deux demandeurs 108 demandant des vols aux mêmes dates entre les mêmes points de départ et d'arrivée peuvent recevoir des offres différentes basées sur les accords ci-dessus tels qu'ils sont implémentés au serveur GDS via les données de tarification et de programmation. [0038] Ainsi que noté ci-dessus, dans le système 100, le serveur 104 ne se limite pas à fournir des informations de tarifs et de programmation à un ensemble de GDSs ou à des éditeurs tiers. Plutôt, le serveur 104, tel qu'il est envisagé par la nouvelle norme de capacité de distribution (NDC), est directement responsable de la réception des requêtes de données et de la génération des réponses aux requêtes. Le fait de transposer la responsabilité pour la génération de réponses au fournisseur (c.-à-d. à l'opérateur du serveur 104), telle qu'elle est envisagée par la nonne NDC, introduit certaines difficultés techniques pour le serveur 104 que le modèle antérieur basé sur le GDS ne résout pas de façon adéquate. [0039] Le serveur 104, en qualité d'hébergeur des données sources 116 (et par association les données sources 124), doit répondre aux requêtes de tous les demandeurs 108 alors qu'un quelconque GDS individuel dans les systèmes antérieurs ne répond qu'aux requêtes d'un sous-ensemble de demandeurs 108. En d'autres termes, le nombre de demandeurs 108 pour lesquels le serveur 104 doit générer des réponses aux requêtes de données peut être substantiellement plus important que le nombre de demandeurs 108 avec lesquels un quelconque GDS individuel interagit. Le fait de maintenir des 8 éléments d'authentification distincts pour chaque demandeur 108 et/ou des ensembles de règles de génération de réponse pour chaque demandeur 108 peut avoir un coût prohibitif en termes de besoins de stockage et de charge computationnelle au serveur 104, en plus d'être chronophage et coûteux à déployer. Les difficultés ci-dessus peuvent augmenter substantiellement à l'échelle des systèmes dans lesquels la même infrastructure informatique sert de multiples lignes aériennes ou autres fournisseurs de produits de voyage (p. ex. l'infrastructure peut être gérée par un fournisseur de technologies de l'information pour le compte de nombreuses lignes aériennes). En d'autres termes, la même infrastructure sous-jacente peut implémenter une pluralité de serveurs distincts 104, chacun étant dans l'obligation de prendre en charge un grand nombre d'éléments d'authentification de demandeurs distincts. Pour un ensemble donné de lignes aériennes, chacune interagissant avec un nombre important de demandeurs, le nombre d'éléments d'authentification requis peut atteindre un coût prohibitif pour la gestion par l'infrastructure sous-jacente. [0040] De plus, même si des règles de type GDS spécifiques à chaque demandeur 108 devaient être implémentées au serveur 104, les demandeurs 108 qui soumettraient des requêtes à l'agrégateur 112 représenteraient néanmoins un autre défi pour le serveur 104. Les règles au serveur 104 peuvent correspondre à l'agrégateur 112, empêchant le serveur 104 de répondre de manière différentielle aux requêtes des demandeurs 108-2 et 108-3. Autrement, des règles spécifiques aux demandeurs 108-2 et 108-3 peuvent être implémentées au serveur 104, mais l'agrégateur 112 peut devoir utiliser une pluralité d'identifiants et/ou d'éléments d'authentification de connexion distincts pour communiquer avec le serveur 104 pour le compte des divers demandeurs 108. [0041] Au-delà des défis techniques exposés ci-dessus, le déploiement de règles pour dif- férencier les réponses aux requêtes pour les fournisseurs de produits peut en lui-même être chronophage et donc représenter une tâche coûteuse. La compagnie aérienne ou autre entité fournisseuse responsable de l'approvisionnement de ces règles peut devoir gérer un nombre important de règles (p. ex. en fonction du nombre de de- mandeurs 108). Dans les systèmes antérieurs, l'introduction de règles supplémentaires peut avoir un effet en cascade sur les règles existantes, nécessitant que l'entité fournisseuse reconfigure une portion importante des règles afin d'implémenter une logique de distribution de produits supplémentaires, plutôt que de simplement retenir la logique existante tout en déployant la logique supplémentaire. [0042] Par conséquent, comme cela sera exposé de façon plus détaillée ci-dessous, le serveur 104 implémente une génération de réponse de manière à conserver au moins une certaine capacité à différencier les demandeurs 108, sans la charge technique d'approvisionnement en éléments d'authentification de connexion et/ou de règles de 9 génération de réponse pour chacun des demandeurs 108. [0043] Dans ce but, le serveur 104 conserve, en plus des données sources 116, un ensemble de définitions de réponse 128. Chaque définition de réponse dans l'ensemble de définitions 128 définit divers paramètres de configuration pour usage dans la génération d'une réponse à une requête entrante d'un demandeur 108 (ou associée à celui-ci). Chaque définition de réponse a un identifiant de demandeur virtuel distinct. Dc plus, le serveur 104 maintient des critères de sélection 132, utilisés pour attribuer un des identifiants dc demandeur virtuel susmentionnés à une requête entrante. C'est-à-dire qu'à la réception d'une requête de données, le serveur 104 utilise les critères dc sélection 132 pour attribuer un identifiant de demandeur virtuel à la requête et récupère la définition de réponse correspondante pour usage dans la génération dc réponse. En découplant les définitions de réponse 128 des demandeurs individuels 108, le serveur 104 peut donc implémenter un nombre plus petit de définitions de réponse que le nombre de demandeurs 108. Cependant, comme cela sera exposé ci-dessous, le serveur 104 peut néanmoins implémenter une logique spécifique au demandeur durant la génération de réponse. [0044] Faisant maintenant référence à la Fig. 2, avant d'exposer la fonctionnalité du système 100 de façon plus détaillée, certains composants du serveur 104 vont maintenant être décrits de façon plus détaillée. Comme le montre la FIG. 2, le serveur 104 inclut au moins un processeur 200, tel qu'une unité centrale de traitement (CPU) ou autre élément similaire. Le processeur 200 est interconnecté à une mémoire 204 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire [RAM], mémoires à lecture seule [ROM], mémoires programmables à lecture seule effaçables électriquement [EEPROM], mémoires flash, stockage informatique magnétique, et autres de ce genre). Le processeur 200 et la mémoire 204 sont généralement compris d'un ou de plusieurs circuits intégrés (ICs). [0045] Le processeur 200 est aussi interconnecté à une interface de communication 208 qui permet au serveur 104 de communiquer avec les autres dispositifs informatiques du système 100 (c.-à-d. l'agrégateur 112, le serveur auxiliaire 120 et les demandeurs tels que le demandeur 108-1), le sous-système du fournisseur 104 et le sous-système client 120) via le réseau 106. L'interface de communication 208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d'interface de réseau [NICs] des unités de radio, et autres similaires) pour communiquer via le réseau 106. Les composants spécifiques de l'interface de communication 208 sont sélectionnés en fonction de la nature du réseau 106. Le serveur 104 peut aussi inclure des dispositifs d'entrée et de sortie connectés au processeur 200, tels que des claviers, des souris, des écrans, et autres de ce genre (non illustrés). [0046] Les composants du serveur 104 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le serveur 104 inclut une pluralité de processeurs qui peuvent soit partager la mémoire 204 et l'interface de communications 208 ou qui ont chacun des interfaces de communications et des mémoires associées distinctes. [0047] La mémoire 204 stocke les données sources 116, les définitions de réponse 128 et les critères de sélection 132 mentionnés ci-dessus par rapport à la FIG. 1. La mémoire 204 stocke aussi une pluralité d'instructions de programmation lisibles par ordinateur, exécutables par le processeur 200 sous forme d'applications variées, incluant une application de génération de réponse différentielle 212 (également appelée simplement dans la présente l'application 212). Les hommes de métier comprendront que le processeur 200 exécute les instructions de l'application 212 (et toute autre application pertinente) afin de mettre en oeuvre des actions diverses définies par les instructions contenues dans celle-ci. Dans la description ci-dessous, le processeur 200 et plus généralement le serveur 104 sont censés être configurés pour mettre en oeuvre ces actions. On comprendra qu'ils sont configurés ainsi via l'exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204. [0048] L'exécution de l'application 212, comme cela sera exposé ci-dessous, configure le serveur 104 pour recevoir une requête de données, telle qu'une requête pour des offres de produits de voyage comme noté ci-dessus. L'exécution de l'application 212 configure par ailleurs le serveur 104 pour comparer un ensemble d'attributs de demandeur de la requête avec les critères de sélection 132 et sur la base de la comparaison, pour attribuer un des identifiants de demandeur virtuel à la requête. Par ailleurs, le serveur 104 est configuré, via l'exécution de l'application 212, pour récupérer une définition de réponse active de l'ensemble de définitions de réponse 128 et pour générer une réponse à la requête conformément à la définition de réponse active. Les définitions de réponse peuvent elles-mêmes nécessiter l'exécution d'applications supplémentaires telles que, à titre d'exemple, des applications génératrices de composants de réponse 216 et 220 montrées dans la FIG. 2. Les applications 216 et 220 peuvent être responsables d'une grande variété d'actions de génération de réponse, telles qu'une sélection de services auxiliaires, une sélection de prix, et autres actions de ce genre. Ces applications peuvent aussi résider en dehors du serveur 104, par exemple dans le serveur auxiliaire 120. [0049] Faisant maintenant référence à la FIG. 3, certains aspects d'exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la FIG. 3 illustre un procédé 300 de réponse différentielle aux requêtes de données. Le procédé 300 sera décrit conjointement à sa mise en oeuvre dans le système 100. En particulier, les blocs 11 du procédé 300 sont mis en oeuvre au serveur 104 via l'exécution de l'application 212 (et en option les applications 216 et 220) par le processeur 200. [0050] Au bloc 305, le serveur 104 reçoit une requête de données associée un demandeur 108. Faisant référence à la FIG. 4, une mise en oeuvre exemplaire du bloc 305 est illustrée, dans laquelle une requête 400 est transmise du demandeur 108-2, via le réseau 106, à l'agrégateur 112. L'agrégateur 112 transmet ensuite la requête au serveur 104 et, comme noté ci-dessus, peut aussi transmettre la requête à une pluralité d'autres serveurs 104 (p. ex. gérés par d'autres lignes aériennes). Le format de la requête 400 n'est pas particulièrement limité. Par exemple, l'agrégateur 112 peut implémenter un quelconque format pertinent pour recevoir des requêtes de ses clients demandeurs 108. Dans certains exemples, le serveur 104 est configure pour recevoir des requêtes formatées selon la norme NDC et pour générer des réponses également formatées selon la norme NDC L'agrégateur 112 peut donc être configuré pour convertir la requête 400 en une requête NDC avant d'envoyer la requête 400 au serveur 104. [0051] La requête 400, telle qu'elle est montrée dans la FIG. 4, inclut des paramètres de requête incluant, dans le présent exemple, des lieux d'origine et de destination. Les paramètres de requêtes peuvent aussi inclure des dates de voyage, une indication que des vols directs ou à segments multiples sont préférés et ainsi de suite. En d'autres termes, les paramètres de requête ont défini les caractéristiques désirées des données de réponse (c.-à-d. des produits de voyage recherchés par la requête 400 dans le présent exemple). La requête 400 inclut aussi un ensemble d'attributs de demandeur. Par contraste avec les paramètres de requête, l'ensemble d'attributs du demandeur définit les caractéristiques du demandeur 108 qui a initié la requête. Par exemple, ainsi que montré dans la FIG 4, l'ensemble d'attributs du demandeur de la requête 400 inclut un identifiant de demandeur (108-2) et un type de demandeur indiquant que le demandeur 108-2 est un TMC. Divers autres attributs de demandeur peuvent aussi être inclus. Par exemple, les attributs de demandeur peuvent inclure un identifiant de marché indiquant une région géographique dans laquelle opère le demandeur 108-2. Divers autres attributs de demandeur seront aussi évidents pour les hommes de métier. [0052] Dans certains exemples, lorsque la requête 400 est acheminée vers le serveur 104, via l'agrégateur 112, la requête 400 peut être modifiée à l'agrégateur 112. Par exemple, l'agrégateur 112 peut insérer son propre identifiant dans la requête de sorte que l'ensemble d'attributs du demandeur inclut à la fois l'identifiant du demandeur 108-2 lui-même et identifiant de l'agrégateur 112. [0053] De retour à la FIG. 3, au bloc 310 le serveur 104 compare l'ensemble des attributs du demandeur de la requête reçue au bloc 305 (c.-à-d. la requête 400 dans l'exemple illustré dans la FIG. 4) avec les critères de sélection 132. Les critères de sélection 132, 12 de façon générale, définissent une ou plusieurs conditions pour chaque identifiant de demandeur virtuel utilisé par le serveur 104. Lorsque les attributs du demandeur de la requête satisfont les conditions correspondant à un identifiant de demandeur virtuel, cet identifiant de demandeur virtuel est attribué à la requête. [0054] Prêtant attention à la FIG. 5, une illustration schématique des critères de sélection 132 est montrée. Spécifiquement, les critères de sélection sont montrés pour deux identifiants de demandeur virtuel 500-1 et 500-2. Les critères de sélection tels qu'illustrés dans la FIG. 5 évaluent seulement le type de demandeur de la requête 400. C'est-à-dire que lorsque le type de demandeur est «TMC », l'identifiant de demandeur virtuel 500-1 est attribué à la requête. Lorsque d'autre part le type de demandeur est « META » (p. ex. pour les demandeurs de métarecherche tels que le demandeur 108-1 montré dans la FIG. 1), l'identifiant de demandeur virtuel 500-2 est attribué à la requête. Les identifiants de demandeur virtuel 500 peuvent prendre des formes variées. Dans le présent exemple, les identifiants de demandeur virtuel sont des pscudo-codes de ville (PCCs) qui peuvent aussi être désignés comme IDs d'entreprise, utilisés par divers fournisseurs de produits de voyage pour identifier des entités telles que des agents de voyage. [0055] Au bloc 315, le serveur 104 détermine si de quelconques critères de sélection 132 sont satisfaits par l'ensemble des attributs du demandeur. Lorsque la détermination est négative, un identifiant de demandeur virtuel par défaut (p. ex. 500-D qui sera exposé de façon plus détaillée ci-dessous) est attribué à la requête au bloc 320. Cependant, lorsque la détermination au bloc 315 est affirmative, un identifiant de demandeur virtuel, correspondant à un critère de sélection satisfait, quel qu'il soit, est attribué à la requête par le serveur 104 au bloc 325. Faisant à nouveau référence à la FIG. 5, dans le présent exemple la mise en oeuvre du procédé 300, la requête 400 (dont une copie est montrée dans la FIG. 5) contient le type de demandeur « TMC» et l'identifiant de demandeur virtuel 500-1 est donc attribué à la requête 400 au bloc 325. La requête 400 peut être modifiée pour un usage interne au serveur 104 afin d'inclure l'identifiant de demandeur virtuel attribué. Par exemple, le serveur 104 peut générer une requête actualisée 504 telle que montrée dans la FIG. 5 qui inclut le contenu de la requête d'origine 400 ainsi que l'identifiant de demandeur virtuel 500-1. [0056] Suite à l'attribution d'un identifiant de demandeur virtuel à la requête au bloc 325 (ou l'attribution d'un identifiant de demandeur virtuel par défaut au bloc 320) le serveur 104 continue au bloc 330. Au bloc 330, le serveur 104 récupère une des définitions de réponse de l'ensemble des définitions de réponse 128. La définition de réponse récupérée au bloc 330, désignée comme étant la définition de réponse active, correspond à l'identifiant de demandeur virtuel attribué au bloc 320 ou 325. C'est-à-dire que le serveur 104 conserve une définition de réponse pour chaque 13 identifiant de demandeur virtuel et l'identifiant de demandeur virtuel, attribué au bloc 320 ou 325, dicte quelle définition de réponse est récupérée au bloc 330. [0057] Prêtant attention à la FIG. 6, une illustration schématique de trois définitions de réponse exemplaire est montrée. Les trois définitions de réponse sont une définition de réponse 600-1 correspondant à identifiant de demandeur virtuel 500-1, une définition de réponse 600-2 correspondant à identifiant de demandeur virtuel 500-2, et une définition de réponse 600-3 correspondant un identifiant de demandeur virtuel par défaut 500-D. Par conséquent, dans le présent exemple de la mise en oeuvre du bloc 330, le serveur 104 récupère la définition de réponse 600-1 de l'ensemble des définitions de réponse 128. [0058] De retour à la FIG. 3, au bloc 335 le serveur 104 obtient des données de réponse pour la requête 400 (ou, dans le présent exemple, la forme interne 504 de la requête 400) conformément à la définition de réponse active. Faisant référence à nouveau à la FIG. 6, chaque définition de réponse 600 spécifie des règles, des paramètres de configuration ou autres instructions pour usage dans la génération ou autrement l'obtention de données de réponse. Dans le présent exemple, chaque définition de réponse inclut des informations de configuration pour une ou plusieurs de la génération de données tarifaires, de la sélection de services auxiliaires et des informations de paiement requises. Comme il en ressortira pour les hommes de métier, la nature des définitions de réponse peut largement varier en fonction de la nature des requêtes de données. On comprendra aussi que les définitions de réponse n'ont pas besoin de spécifier des paramètres de configuration et autres spécifications pour la génération de réponse, mais peuvent aussi spécifier des processus de gestion ultérieurs, p. ex. lorsqu'un produit de voyage dans les données de réponse est sélectionné pour un achat par un demandeur 108. C'est-à-dire que l'attribution des identifiants de demandeur virtuel et la récupération des définitions de réponse comme décrites ci-dessus peuvent déterminer non seulement la génération de données de réponse pour la requête initiale, mais aussi une ou plusieurs étapes de traitement pour des requêtes subséquentes associées à la requête du bloc 305. [0059] Comme on peut le voir dans la FIG. 6, chaque définition de réponse peut entraîner la génération de certaines portions des données de réponse selon un mécanisme différent. Par exemple, la définition de réponse 600-1 amène le serveur 104 à demander des informations tarifaires au serveur auxiliaire 120 où le dépôt 124 peut spécifier des prix réduits pour les demandeurs TMC. Par contre, les définitions de réponse 600-2 et 600-3 amènent le serveur 104 à générer ou à récupérer des informations tarifaires via l'exécution de l'application 216. Comme autre exemple, la définition de réponse 600-1 impose un mode de paiement différent des définitions de réponse 600-2 et 600-3. Spécifiquement, la définition de réponse 600-1 indique que le paiement pour un produit de 14 voyage sélectionné pour achat par le demandeur pertinent 108 (parmi les produits de voyage offerts dans la réponse) est réalisé via un rapport du serveur 104 à un serveur de facturation et de facilité de paiement (BSP) (non illustré) qui sert d'intermédiaires pour les paiements entre des entités agentes de voyages et des entités fournisseuses (p. ex. des compagnies aériennes). Pendant ce temps, les définitions de réponse 600-2 et 600-3 requièrent un paiement par carte de crédit au moment de l'achat. Toujours par ailleurs, la définition de réponse 600-3 ne configure pas le serveur 104 pour sélectionner des services auxiliaires au cours de la génération de réponse alors que les définitions de réponse 600-1 et 600-2 provoquent la sélection de services auxiliaires via l'exécution de l'application 220. [0060] Par conséquent, dans la présente mise en oeuvre exemplaire du bloc 335, le serveur 104 transmet une requête au serveur auxiliaire 120 pour des informations tarifaires et exécute l'application 220 pour sélectionner (p. ex. dans les données sources 116) des services auxiliaires. La requête au serveur auxiliaire 120 peut inclure à la fois l'identifiant de demandeur virtuel 500-1 et toute autre portion pertinente de l'ensemble d'attributs du demandeur mentionné ci-dessus. C'est-à-dire que bien que les identifiants de demandeur virtuel déterminent quelle définition de réponse est exécutée pour générer des données de réponse, des composants individuels du serveur 104 peuvent faire usage d'informations spécifiques au demandeur pour affiner davantage la génération de données de réponse. [0061] De retour à la FIG. 3, au bloc 340, en réponse à la génération de données de réponse, le serveur 104 transmet les données de réponse à remettre au demandeur 108. Dans le présent exemple, en faisant référence à la FIG. 7, le serveur 104 transmet une réponse 700 à l'agrégateur 112 pour une remise subséquente au demandeur 108-2. La réponse 700 peut, par exemple, être transmise à l'agrégateur sous forme d'un message formaté NDC et l'agrégateur 112 peut convertir la réponse 700 en un quelconque format approprié avant de fournir la réponse au demandeur 108-2. [0062] Comme il sera maintenant apparent, le système 100 (et particulièrement le serveur 104) permet la génération de réponses aux requêtes de données sans nécessiter la configuration des définitions de réponse pour chaque demandeur 108. Au lieu de cela, les définitions de réponse n'ont besoin d'être configurées que pour chaque identifiant de demandeur virtuel 500. Un identifiant de demandeur virtuel donné permet à un nombre quelconque de demandeurs d'être mappés sur une seule définition de réponse réduisant ainsi potentiellement de beaucoup le volume de configuration de génération de réponses requis au serveur 104. De tels groupements de demandeurs 108 en un plus petit nombre d'identifiants de demandeur virtuel permettent à l'opérateur du serveur 104 d'équilibrer la granularité de la génération de réponse par rapport au stockage et à la charge computationnelle. Par ailleurs, l'usage d'attributs de demandeur ainsi que l'identifiant de demandeur virtuel dans la génération de réponse permettent à la génération de réponse d'être façonnée sur mesure pour des demandeurs spécifiques 108 lorsque c'est souhaitable. [0063] Comme il en ressortira aussi de la discussion ci-dessus, le système 100 permet la mo- dification de la génération de réponse différentielle, p. ex. en déployant des identifiants supplémentaires de demandeurs virtuels et des définitions de réponses correspondantes tout en atténuant ou en éliminant le besoin dc reconfigurer des définitions de réponses existantes. Par exemple, une compagnie aérienne a la possibilité d'implémenter une définition de réponse supplémentaire ainsi qu'un identifiant de demandeur virtuel correspondant et n'a besoin que d'actualiser les critères dc sélection 132 pour redirigcr les requêtes désirées vers le nouvel identifiant dc demandeur virtuel. Les définitions de réponse antérieures n'ont pas besoin d'être modifiées. [0064] Les hommes de métier apprécieront que dans certains modes de réalisation, la fonc- tionnalité des applications 212, 216 et 220 et/ou du serveur auxiliaire 120 puisse être implémentée en utilisant du matériel préprogrammé ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications [ASTCs], des mémoires à lecture seule programmables et effaçables électriquement [EEPROMs, etc.] ou d'autres composants associés. [0065] Le champ d'application des revendications ne saurait être limité aux modes de réa- lisation exposés ci-dessus dans les exemples, mais doit recevoir l'interprétation la plus large conformément à la description dans sa globalité. 16 [Revendication I] [Revendication 2] [Revendication 3] [Revendication 4] REVENDICATIONSUn procédé de réponse différentielle à des requêtes de données dans un serveur gestionnaire de requête, le procédé comprenant : le stockage, dans une mémoire du serveur gestionnaire dc requêtes : [i] d'un ensemble de définitions de réponses prédéfinies, chaque définition dc réponse ayant un identifiant de demandeur virtuel attribué distinct ; et [ii] pour chaque identifiant de demandeur virtuel, un critère de sélection la réception d'une requête de données associée à un d'une pluralité de demandeurs, la requête de données incluant [i] des paramètres de requête et un ensemble d'attributs du demandeur ; la comparaison de l'ensemble d'attributs du demandeur avec les critères de sélection ; sur la base de la comparaison, l'attribution d'un des identifiants de demandeur virtuel sélectionné à la requête de données ; la récupération d'une des définitions de réponse active correspondant à l'identifiant de demandeur virtuel sélectionné ; l'obtention des données de réponse en fonction des paramètres de la requête et de la définition de réponse active ; la transmission, en réponse à la requête de données des données de réponse. Le procédé de la revendication 1, dans lequel l'ensemble des définitions de réponse inclut une définition de réponse par défaut correspondant à un des identifiants de demandeurs virtuels par défaut ; et dans lequel l'attribution de l'identifiant de demandeur virtuel sélectionné inclut, lorsque l'ensemble des attributs du demandeur ne satisfait aucun des critères de sélection, l'attribution d'un identifiant de demandeur virtuel par défaut à la requête. Le procédé de la revendication 1 ou 2, comprenant par ailleurs le stockage, dans la mémoire, d'un dépôt de données sources ; dans lequel l'obtention des données de réponse comprend la génération des données de réponse à partir des données sources conformément à la définition de réponse et aux paramètres de requête. Le procédé de la revendication 1 ou 2, dans lequel l'obtention des données de réponse comprend : l'envoi d'une interrogation du serveur gestionnaire de réponse à un 17 [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] serveur auxiliaire identifié dans la définition de réponse, l'interrogation incluant l'identifiant de demandeur virtuel et les paramètres du demandeur ; et la réception des données de réponse du serveur auxiliaire en réponse à l' interrogation. Le procédé de l'une quelconque des revendications 1 à 4, dans lequel la réception de la requête de données comprend la réception de la requête de données directement de l'un de la pluralité des demandeurs. Le procédé de l'une quelconque des revendications 1 à 4, dans lequel la réception de la requête de données comprend la réception de la requête de données d'un agrégateur associé à un sous-ensemble de la pluralité des demandeurs. Le procédé de la revendication 6, comprenant par ailleurs, préalablement à la réception de la requête de données : l'établissement d'un lien de communication avec l'agrégateur en utilisant un seul ensemble d'éléments d'authentification d'agrégateur. Un serveur gestionnaire de requêtes comprenant : une mémoire stockant : [i] un ensemble de définitions de réponses pré-définies, chaque définition de réponse ayant un identifiant de demandeur virtuel attribué distinct ; et [ii] pour chaque identifiant de demandeur virtuel, un critère de sélection ; une interface de communication ; et un processeur connecté à la mémoire et à l'interface de communication, le processeur étant configuré pour : recevoir une requête de données associée à un d'une pluralité de demandeurs via l'interface de communication, la requête de données incluant [i] des paramètres de requête et [ii] un ensemble d'attributs du demandeur ; comparer l'ensemble d'attributs du demandeur avec les critères de sélection ; sur la base de la comparaison, attribuer un des identifiants de demandeur virtuel sélectionné à la requête de données ; récupérer une des définitions de réponse correspondant à l'identifiant de demandeur virtuel sélectionné ; obtenir des données de réponse en fonction des paramètres de requête et de la définition de réponse active ; et transmettre, en réponse à la requête de données, les données de réponse via l'interface de communication. 18 [Revendication 9] Le serveur gestionnaire de requête de la revendication 8 étant configure par ailleurs pour mettre en oeuvre le procédé de l'une quelconque des revendications 2 à 7. [Revendication 10] Un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé selon l'une quelconque des revendications 1 à 7 lorsque ledit programme fonctionne sur un ordinateur.