Brevet FR3102283A1 — publié le 20210423

Un dispositif, un système et un procédé pour fournir des objets de fournisseur à partir d'une antémémoire sont fournis. Les objets de fournisseur reçus représentent les éléments fournis par les systèmes de fournisseur. Les objets de fournisseur sont catégorisés en fonction de leurs caractéristiques de réutilisabilité et/ou de contexte et sont stockés tels que catégorisés. Une requête est reçue pour un ou plusieurs éléments fournis par ledit ou plusieurs systèmes de fournisseur. Un objet de fournisseur stocké et catégorisé est déterminé pour répondre aux critères associés à la requête, incluant une ou plusieurs caractéristiques de réutilisabilité et de contexte respectives de l'objet de fournisseur. En réponse à la détermination selon laquelle l’objet de fournisseur, qui satisfait les critères, est estimé être actuellement valide, une réponse correspondant à l'objet de fournisseur est fournie. DISPOSITIF, SYSTÈME ET PROCÉDÉ POUR FOURNIR DES OBJETS DE FOURNISSEUR À PARTIR D’UNE ANTÉMÉMOIRE Domaine La spécification porte généralement sur les bases de données, et plus particulièrement sur un dispositif, un système et un procédé permettant de fournir des objets de fournisseur à partir d’une antémémoire. Contexte La fourniture de divers produits incluant par exemple des marchandises et des services liés au voyage (p. ex. des vols, des réservations d'hôtel, et autres similaires) requiert typiquement que diverses entités discrètes échangent des données définissant divers aspects des produits. Des exemples de ces entités, dans le contexte des produits liés au voyage, incluent des compagnies aériennes, des agences de voyages, des utilisateurs finaux, des systèmes de réservation et autres similaires. Bien que ces entités puissent être configurées pour échanger des données selon un format normalisé, (p. ex. selon la norme de nouvelle capacité de distribution (NDC) basée sur le langage de balisage extensible XML dans le contexte des produits liés au voyage), elles peuvent néanmoins employer des mécanismes différents pour initier l'échange de données. Résumé Un aspect de la présente spécification fournit un procédé comprenant : la réception, sur un ou plusieurs serveurs, des objets de fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseur ; la catégorisation, sur ledit ou plusieurs serveurs, des objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte ; le stockage, sur ledit ou plusieurs serveurs, sur une ou plusieurs mémoires, des objets de fournisseur tels que catégorisés ; la réception, sur un ou plusieurs serveurs, depuis un dispositif demandeur, d’une requête pour ledit ou plusieurs éléments fournis par un ou plusieurs systèmes de fournisseur ; la détermination sur ledit ou plusieurs serveurs qu'un objet de fournisseur, stocké sur ladite ou plusieurs mémoires, réponde aux critères associés à la requête, y compris une ou plusieurs caractéristiques de réutilisabilité et de contexte respectives de l'objet de fournisseur ; et en réponse à la détermination que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide, la fourniture par un ou plusieurs serveurs, au dispositif demandeur, d’une réponse correspondant à l'objet de fournisseur. Dans certains modes de réalisation, la catégorisation des objets de fournisseur par la réutilisabilité comprend : la catégorisation des objets de fournisseur par une ou plusieurs des caractéristiques respectives et des combinaisons respectives d'un ou de plusieurs éléments respectifs représentés par les objets de fournisseur ; et la détermination que la réutilisabilité respective de l'objet de fournisseur réponde aux critères associés à la requête comprend : la détermination que l'objet de fournisseur représente une ou plusieurs des mêmes caractéristiques et une même combinaison dudit ou de plusieurs éléments demandés par la requête. Dans certains mode de réalisation, la catégorisation des objets de fournisseur par les caractéristiques de contexte comprend : la catégorisation des objets de fournisseur par un ou plusieurs contextes respectifs dans lequel un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client et une catégorie d'éléments respectifs représentés par les objets de fournisseur ; et la détermination que le contexte respectif de l'objet de fournisseur remplisse les critères associés à la requête comprend : la détermination que l'objet de fournisseur représente un ou plusieurs d'un même contexte respectif de la requête, une même personnalisation, un même emplacement géographique, un même type de client et une même catégorie dudit ou de plusieurs éléments demandés par la requête. Dans certains modes de réalisation, la détermination que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide comprend : la détermination qu'un horaire actuel ne dépasse pas une ou plusieurs d'une heure d'expiration estimée et une valeur TTL (Time-To-Live) estimée de l'objet de fournisseur. Dans certains modes de réalisation, le procédé comprend en outre : l'utilisation, sur ledit ou plusieurs serveurs, d'un modèle d'apprentissage automatique déterminant la réutilisabilité et d'un modèle d'apprentissage automatique déterminant le contexte pour catégoriser respectivement les objets de fournisseur par les caractéristiques de réutilisabilité et le contexte. Dans certains modes de réalisation, le procédé comprend en outre : l'utilisation, sur ledit ou plusieurs serveurs, d'un modèle d'apprentissage automatique d'estimation de la validité pour déterminer que l'objet de fournisseur est estimé être actuellement valide. Un autre aspect de la présente spécification fournit un serveur comprenant : une ou plusieurs mémoires ; une interface de communication ; et un contrôleur configuré pour : recevoir, via l'interface de communication, des objets de fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseur ; classer les objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte ; stocker, au niveau de ladite ou de plusieurs mémoires, les objets de fournisseur tels qu'ils ont été catégorisés ; recevoir, via l'interface de communication, depuis un dispositif demandeur, une requête pour un ou plusieurs éléments fournis par ledit ou plusieurs systèmes de fournisseur ; déterminer qu'un objet de fournisseur, stocké dans ladite ou plusieurs mémoires, réponde aux critères associés à la requête, y compris une ou plusieurs caractéristiques de réutilisabilité et de contexte respectives de l'objet de fournisseur ; et en réponse à la détermination que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide, fournir au dispositif demandeur, via l'interface de communication, une réponse correspondant à l'objet de fournisseur. Dans certains mode de réalisation, le contrôleur est en outre configuré pour catégoriser les objets de fournisseur par réutilisabilité en : catégorisant les objets de fournisseur par une ou plusieurs des caractéristiques respectives et des combinaisons respectives d'un ou de plusieurs éléments respectifs représentés par les objets de fournisseur ; et en déterminant que la réutilisabilité respective de l'objet de fournisseur satisfait les critères associés à la requête comprend : la détermination que l'objet de fournisseur représente une ou plusieurs des mêmes caractéristiques et une même combinaison dudit ou de plusieurs éléments requis par la requête. Dans certains modes de représentation, le contrôleur est en outre configuré pour catégoriser les objets de fournisseur par caractéristiques de contexte en : catégorisant les objets de fournisseur par un ou plusieurs d'un contexte respectif dans lequel un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client et une catégorie d'éléments respectifs représentés par les objets de fournisseur ; et en déterminant que le contexte respectif de l'objet de fournisseur remplisse les critères associés à la requête comprend : la détermination que l'objet de fournisseur représente un ou plusieurs d'un même contexte respectif de la requête, une même personnalisation, un même emplacement géographique, un même type de client et une même catégorie dudit ou de plusieurs éléments demandés par la requête. Dans certains modes de réalisation, le contrôleur est en outre configuré pour déterminer si l'objet de fournisseur, qui satisfait les critères, est estimé être actuellement valide en : déterminant qu'un horaire actuel ne dépasse pas une ou plusieurs d'une heure d'expiration estimée et une valeur TTL (Time-To-Live) estimée de l'objet de fournisseur. Dans certains modes de réalisation, le contrôleur est en outre configuré pour : utiliser un modèle d'apprentissage automatique déterminant la réutilisabilité et un modèle d'apprentissage automatique déterminant le contexte pour catégoriser respectivement les objets de fournisseur en fonction des caractéristiques de réutilisabilité et de contexte. Dans certains modes de réalisation, le contrôleur est en outre configuré pour : utiliser un modèle d'apprentissage automatique d'estimation de validité pour déterminer que l'objet de fournisseur est estimé être actuellement valide. Un autre aspect de la présente spécification fournit un support durable lisible par ordinateur stockant un programme d'ordinateur, dans lequel l'exécution du programme d'ordinateur est pour : recevoir, sur un ou plusieurs serveurs, des objets de fournisseurs représentant des éléments fournis par un ou plusieurs systèmes de fournisseurs ; catégoriser, sur ledit ou plusieurs serveurs, les objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte ; stocker, sur ledit ou plusieurs serveurs, sur une ou plusieurs mémoires, les objets de fournisseurs tels que catégorisés ; recevoir, sur un ou plusieurs serveurs, depuis un dispositif demandeur, une requête pour un ou plusieurs éléments fournis par un ou plusieurs systèmes de fournisseurs ; déterminer sur un ou plusieurs serveurs qu'un objet de fournisseur, stocké sur une ou plusieurs mémoires, réponde aux critères associés à la requête, comprenant une ou plusieurs caractéristiques de réutilisabilité et de contexte respectives de l'objet de fournisseur ; et en réponse à la détermination que l'objet de fournisseur, qui satisfait les critères, soit actuellement jugé valide, fournir par un ou plusieurs serveurs, au dispositif demandeur, une réponse correspondant à l'objet de fournisseur. Dans certains modes de réalisation du support durable lisible par ordinateur, la catégorisation des objets de fournisseurs par réutilisabilité comprend : la catégorisation des objets de fournisseurs par une ou plusieurs des caractéristiques respectives et des combinaisons respectives d'un ou de plusieurs éléments respectifs représentés par les objets de fournisseur ; et la détermination que la réutilisabilité respective de l'objet de fournisseur réponde aux critères associés à la requête comprend : la détermination que l'objet de fournisseur représente une ou plusieurs des mêmes caractéristiques et une même combinaison dudit ou de plusieurs éléments requis par la requête. Dans certains modes de réalisation du support durable non-lisible par ordinateur, la catégorisation des objets de fournisseur par les caractéristiques du contexte comprend : la catégorisation des objets de fournisseur par un ou plusieurs d'un contexte respectif dans lequel un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client et une catégorie d'éléments respectifs représentés par les objets de fournisseur ; et la détermination que le contexte respectif de l'objet de fournisseur remplisse les critères associés à la requête comprend : la détermination que l'objet de fournisseur représente un ou plusieurs d'un même contexte respectif de la requête, une même personnalisation, un même emplacement géographique, un même type de client et une même catégorie dudit ou de plusieurs éléments demandés par la requête. Un autre aspect de la présente spécification fournit un produit-programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon l’un quelconque des aspects du procédé et des modes de réalisation exposés ci-dessus lorsque ledit programme fonctionne sur un ordinateur. Pour une meilleure compréhension des divers exemples décrits dans la présente et pour montrer plus clairement comment ils peuvent être mis en œuvre, des références seront faites, à titre d'exemples uniquement, aux dessins en annexe dans lesquels : illustre un système pour fournir des objets de fournisseur à partir d’une antémémoire, selon des exemples non limitatifs. illustre un exemple de structure d'un ou de plusieurs serveurs pour stocker et fournir des objets de fournisseur, selon des exemples non limitatifs. illustre un procédé pour fournir des objets de fournisseur à partir d'une antémémoire, selon des exemples non limitatifs. illustre le système de la FIG. 1 des modules de formation d'apprentissage automatique pour fournir des objets de fournisseur à partir d'une antémémoire, selon des exemples non limitatifs. illustre le système de la FIG. 1 catégorisant les objets de fournisseur pour le stockage dans une antémémoire, selon des exemples non limitatifs. illustre le système de la FIG. 1 fournissant un objet de fournisseur à un dispositif demandeur basé sur une validité actuelle de l'objet de fournisseur, selon des exemples non limitatifs. illustre des exemples d’objets de fournisseur tels que catégorisés, selon des exemples non limitatifs. Description détaillée La FIG. 1 représente un système 100 pour fournir des objets de fournisseur à partir d'une antémémoire. Les objets de fournisseur, dans les exemples exposés dans la présente, peuvent comprendre des objets de données et/ou des enregistrements de données qui correspondent à des produits et/ou des éléments, tels que des marchandises et des services liés au voyage (p. ex. des vols, des réservations d'hôtel, des locations de véhicules, et autres similaires), fournis par un système de fournisseur. Plus spécifiquement, les produits et/ou les éléments exposés dans les exemples ci-dessous peuvent être des billets d'avion et des services associés (p. ex. des services d'enregistrement de bagages, une alimentation pendant le vol, des distractions, et autres similaires). Cependant, les systèmes et les procédés exposés ci-dessous peuvent aussi être appliqués à divers autres types d’objets de données et/ou d'éléments. La livraison des éléments mentionnés ci-dessus est typiquement contrôlée par une entité fournisseuse, telle qu'une compagnie aérienne dans le cas des éléments mentionnés en lien avec les exemples fournis dans la présente. Le système 100 inclut un ou plusieurs systèmes de fournisseurs 104 (p. ex. un ou plusieurs serveurs ou d’autres dispositifs informatiques appropriés) qui dans cet exemple sont gérés par une ou plusieurs entités fournisseuses. Le système 100 peut inclure une pluralité de systèmes de fournisseurs 104, chacun étant géré par une entité fournisseuse respective (p. ex. d'autres compagnies aériennes), bien qu'un seul système de fournisseur 104 soit montré à titre d'exemple. Les objets de fournisseur peuvent être dans un quelconque format approprié incluant, mais sans s'y limiter, des recommandations Edifact dans le contexte d'un échange de données basé sur le système de distribution globale (GDS), des enregistrements d'offres dans le contexte des échanges de données basés sur la nouvelle norme de capacité de distribution (NDC) et/ou tout autre format approprié. En effet, les objets de fournisseur peuvent comprendre des objets de données et/ou des enregistrements de données, stockant par exemple une recommandation Edifact ou une offre NDC et/ou toutes autres données pertinentes représentant au moins un élément fourni par le système de fournisseur 104. Chaque objet de fournisseur définit un élément, ou une combinaison d'éléments qui peuvent être offerts pour achat (p. ex. par les utilisateurs finaux des éléments) incluant, mais sans se limiter à un ou plusieurs de vols, voyages en train, séjours d'hôtel, accès au salon de l'aéroport, surclassement de siège, service d'enregistrement de bagages, alimentation pendant le vol, distractions et autres similaires. Dans les exemples exposés ci-dessous, chaque objet de fournisseur peut définir un vol géré par l'entité fournisseuse et/ou des services auxiliaires associés au vol. Chaque objet de fournisseur contient donc divers champs. Certains champs définissent des attributs d'éléments, tels que des identifiants d'objets de produits (p. ex. des identifiants de services, des identifiants d'éléments, des identifiants de produits, et autres similaires), des lieux, des dates et des horaires correspondant aux produits (p. ex. des horaires de vol et d'autres données d'itinéraire). Le type de champs et/ou de données d'un objet de fournisseur peut dépendre d'un type d'objet de fournisseur. Par exemple, les objets de fournisseur correspondant à des vols peuvent inclure des identifiants de vol, alors que les objets de fournisseur correspondant à d'autres éléments liés au voyage tels qu'une offre de voyage en train, un hôtel, l'accès au salon de l'aéroport et/ou une offre pour un surclassement en siège premium, peuvent inclure des informations liées au voyage en train, à l'hôtel, au salon, au siège premium, etc. Comme cela sera décrit ci-dessous, le système 100 comprend par ailleurs un réseau 116 et un serveur d'intermédiation 120. Le réseau 116 comprend une quelconque combinaison de réseaux de zone locale et étendue, incluant l'Internet, de sorte que les composants du système 100 peuvent communiquer. Le serveur d'intermédiation 120 sert généralement d'intermédiaire entre le dispositif client 112 et le système de fournisseur 104, de sorte par exemple que le dispositif client 112 puisse demander des produits au système de fournisseur 104 et/ou à plus d'un seul système de fournisseur 104, via le serveur d'intermédiation 120. Tel que décrit, le système 100 comprend par ailleurs un serveur d'antémémoire 121 qui antémémorise et/ou stocke des objets de fournisseur reçus de sources diverses dans le système 100 incluant, mais sans s'y limiter, le système de fournisseur 104. Comme cela sera expliqué ci-dessous, le serveur d'antémémoire 121 fournit par ailleurs des réponses qui incluent des objets de fournisseurs stockés dans une antémémoire à un dispositif demandeur, tel que le dispositif client 112, par exemple, via le serveur d'intermédiation 120. Alors que les serveurs 120, 121 peuvent être deux dispositifs distincts, la fonctionnalité des serveurs 120, 121 peut être combinée en un serveur 125 et/ou implémentée dans un environnement dématérialisé (cloud) en utilisant une pluralité de serveurs et/ou un ou plusieurs serveurs. Tel qu'illustré, le serveur d'antémémoire 121 maintient une antémémoire et/ou une mémoire 126 qui peuvent être implémentées comme une ou plusieurs mémoires. La mémoire 126 contient des objets de fournisseur tels qu'ils sont reçus au serveur d'antémémoire 121 de diverses sources d'objets de fournisseur dans le système 100. Le serveur d’antémémoire 121 peut mettre en œuvre des modèles d'apprentissage automatique pour catégoriser les objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte, et stocker les objets de fournisseur dans la mémoire 126 tels que catégorisés ; le serveur d’antémémoire 121 peut également déterminer si un objet de fournisseur stocké et catégorisé est actuellement valide, comme décrit en détail ci-après. Dans le présent exemple, le dispositif client 112 peut être opéré par une entité d'agent de voyages et, par conséquent, générer et transmettre des requêtes d'objets de fournisseur (p. ex. représentant des produits pouvant être achetés) au système de fournisseur 104, via le serveur d'intermédiation 120, au nom des utilisateurs finaux (p. ex. des voyageurs). Le système 100 peut inclure une pluralité de dispositifs clients 112, bien qu'un seul dispositif client 112 soit montré dans la FIG. 1 à titre d'illustration. Formulé d'une autre manière, le serveur d'intermédiation 120 sert d'intermédiaire entre le dispositif client 112 et le système de fournisseur 104 et reçoit des requêtes provenant du dispositif client 112. Comme il sera expliqué de façon plus détaillée ci-dessous, dans certains exemples, avant que le serveur d'intermédiation 120 ne demande un objet de fournisseur au système de fournisseur 104, ce qui correspond à au moins un élément fourni par le système de fournisseur 104, le serveur d'intermédiation 120 peut demander l'objet de fournisseur au serveur d’antémémoire 121 qui détermine si un objet de fournisseur, enregistré dans la mémoire 126, satisfait les critères associés à cette requête, incluant une ou plusieurs caractéristiques respectives de réutilisation et de contexte de l’objet de fournisseur. En outre, lorsqu'il est déterminé qu’un objet de fournisseur stocké dans la mémoire 126 satisfait les critères, le serveur d’antémémoire 121 peut estimer si l'objet de fournisseur est estimé être actuellement valide. Lorsque l'objet de fournisseur est estimé être actuellement valide, le serveur d’antémémoire 121 fournit l'objet de fournisseur au serveur d'intermédiation 120 qui transmet l'objet de fournisseur au dispositif client 112 en réponse à la requête. Par conséquent, les objets de fournisseur déjà reçus, stockés et catégorisés peuvent être utilisés, par le serveur d'intermédiation 120, pour répondre à la requête, plutôt que de demander un objet de fournisseur qui satisfait les critères du système de fournisseur 104. Un tel exemple peut réduire le temps de réponse à la requête par rapport à la requête d’un objet de fournisseur qui satisfait les critères du système de fournisseur 104. En outre, un tel exemple peut réduire davantage l'utilisation de la bande passante entre le serveur d'intermédiation 120 et le système 104 du fournisseur, ainsi que réduire les ressources de traitement du système de fournisseur 104, par exemple en générant un autre objet de fournisseur qui répond à des critères similaires utilisés pour générer précédemment un objet de fournisseur (p. ex, l'objet de fournisseur enregistré dans la mémoire 126 servant à répondre à la requête). Dans d'autres exemples encore, le serveur d'intermédiation 120 peut d'abord demander des objets de fournisseur qui satisfont les critères d'une requête du système de fournisseur 104. Lorsque le système de fournisseur 104 ne répond pas dans une période de temps seuil donnée (qui peut être une période de temps fixe et/ou une période de temps dynamique basée sur les temps de réponse historiques pour le système de fournisseur 104 au moment où les objets de fournisseur sont demandés), le serveur d'intermédiation 120 peut communiquer avec le serveur d’antémémoire 121 pour fournir au dispositif client 112 un objet de fournisseur qui satisfait les critères de la requête. Dans de tels exemples, le système de fournisseur 104 peut être en panne et/ou occupé et, par conséquent, de tels exemples peuvent réduire de nouveau le temps de réponse à une requête par rapport à l'attente de la réponse du système de fournisseur 104. En général, la requête et/ou la commande d'éléments représentés par les objets de fournisseur survient dans le système 100 via un échange de messages, par exemple entre le serveur d'intermédiation 120 et le système de fournisseur 104. Ces messages peuvent par conséquent être associés à des objets de fournisseur et peuvent inclure des messages pour un ou plusieurs de : une requête d'objets de fournisseur ; une requête pour d'autres informations associées aux objets de fournisseur ; la fourniture des objets de fournisseur ; la commande d'éléments représentés par les objets de fournisseur, et autres similaires. En outre, le serveur d'intermédiation 120 peut fournir des objets de fournisseur au dispositif client 112 tels que reçus du système de fournisseur 104 et/ou le serveur d'intermédiation 120 peut modifier les objets de fournisseur dans un autre format. Tel qu'illustré, le système 100 comprend par ailleurs un dispositif du pôle d'événements 127 qui peut recevoir des messages associés aux objets de fournisseur, à partir du système de fournisseur 104. Le dispositif du pôle d'événements 127 peut comprendre un substitut pour au moins le serveur d'intermédiation 120 de sorte que les messages reçus par au moins le serveur d'intermédiation 120 sont reçus au dispositif du pôle d'événement 127. Par exemple, lorsque le système de fournisseur 104 transmet un message et/ou une réponse au serveur d'intermédiation 120 qui inclut un objet de fournisseur, le message et/ou la réponse peuvent d'abord être reçus au dispositif du pôle d'événements 127 et ensuite être transmis au serveur d'intermédiation 120. Formulé différemment, lorsque les objets de fournisseurs sont demandés à un système de fournisseur, les objets de fournisseur peuvent être poussés vers le dispositif du pôle d'événements 127 pour les rendre accessibles à d'autres composants du système 100, autres qu'une instance actuelle du serveur d'intermédiation 120, comme cela sera décrit ci-dessous de façon plus détaillée. En effet, le dispositif du pôle d'événements 127 peut être configuré pour recevoir des messages et/ou des réponses qui incluent des objets de fournisseur de tous les systèmes de fournisseurs 104 du système 100. Un tel « trafic » peut être « en temps réel » et inclure des messages générés en raison des objets de fournisseur demandés par le dispositif client 112. Cependant, dans d'autres exemples, un tel trafic peut ne pas être « en temps réel »; dans ces exemples, un composant du système 100, tel qu'un générateur de trafic qui peut être un composant du serveur d'intermédiation 120 et/ou un composant séparé, et autres similaires, peut automatiquement et/ou périodiquement demander des objets de fournisseur d'un ou de plusieurs systèmes de fournisseurs 104 via des messages, par exemple pour avoir un enregistrement d'offres pour des vols vers des destinations données à des dates particulières ; ces requêtes peuvent être transmises et/ou déclenchées par le serveur d'intermédiation 120. Le serveur d’antémémoire 121 reçoit généralement du dispositif du pôle d'événements 127 des objets de fournisseur générés par le système de fournisseur 104 pour le stockage dans la mémoire 126. Par exemple, le dispositif du pôle d'événements 127 peut pousser des messages et/ou des objets de fournisseur vers le serveur d’antémémoire 121 et/ou le serveur d’antémémoire 121 peut demander des messages et/ou des objets de fournisseur au dispositif du pôle d'événements 127. Comme illustré, le système 100 comprend en outre un système de formation de modèles d'apprentissage automatique 129 qui peut recevoir des messages du dispositif du pôle d'événements 127, et générer des classificateurs d'apprentissage automatique pour les modèles d'apprentissage automatique implémentés dans le serveur d'antémémoire 121. Avant d’exposer la fonctionnalité du système 100 de façon plus détaillée, certains composants du serveur d’antémémoire 121 vont maintenant être décrits de façon plus détaillée en faisant référence à la FIG.2. Alors que le serveur d’antémémoire 121 est décrit comme un dispositif autonome et/ou séparé du serveur d'intermédiation 120, dans d'autres exemples, la fonctionnalité du serveur d’antémémoire 121 peut être répartie entre d'autres composants du système 100 et/ou la fonctionnalité du serveur d’antémémoire 121 peut être au moins partiellement combinée avec le serveur d'intermédiation 120. Comme le montre la FIG. 2, le serveur d’antémémoire 121 inclut au moins un processeur 220, tel qu’une unité de traitement centrale (CPU), et autres similaires. Le contrôleur 220 est interconnecté à une mémoire 222 stockant une application 223, la mémoire 222 étant implémentée comme un support durable, 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 similaires). Le contrôleur 220 et la mémoire 222 sont généralement composés d’un ou de plusieurs circuits intégrés (ICs). Le contrôleur 220 est aussi interconnecté à une interface de communication 228 qui permet au serveur d’antémémoire 121 de communiquer avec les autres composants du système 100 (c.-à-d. le serveur d’intermédiation 120, le dispositif du pôle d'événements 127, et autres similaires) via le réseau 116. L’interface de communication 228 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 116. Les composants spécifiques de l’interface de communication 228 sont sélectionnés sur la base de la nature du réseau 116. Le serveur d'antémémoire 121 peut aussi inclure des dispositifs d’entrée et de sortie connectés au contrôleur 220, tel que des claviers, des souris, des écrans, et autres similaires (non illustrés). Les composants du serveur d'antémémoire 121 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 d'antémémoire 121 inclut une pluralité de processeurs qui peuvent soit partager la mémoire 222 et l’interface de communication 228, ou qui ont chacun des interfaces de communication et des mémoires associées distinctes. Telle qu’illustrée, la mémoire 222 peut inclure la mémoire 126 (et/ou une portion de celle-ci). Cependant, dans d'autres exemples, la mémoire 126 peut être externe au serveur d’antémémoire 121 et être accessible au contrôleur 220, par exemple via l’interface de communication 228. En effet, la mémoire 126 peut être distribuée entre tous les composants appropriés du système 100. La mémoire 222 stocke aussi une pluralité d’instructions de programmation lisibles par ordinateur, exécutables par le contrôleur 220 sous forme d’applications variées, incluant l'application 223. Les hommes de métier comprendront que le contrôleur 220 exécute les instructions de l’application 223 (et toute autre application pertinente) afin de mettre en œuvre des actions diverses définies par les instructions contenues dans celle-ci. Dans la description ci-dessous, le contrôleur 220, et de façon plus générale le serveur d'antémémoire 121, sont censés être configurés pour mettre en œuvre ces actions. On comprendra qu’ils sont configurés ainsi via l’exécution (par le contrôleur 220) des instructions des applications stockées dans la mémoire 222. L'exécution de l'application 223, comme nous le verrons plus loin, configure le serveur d’antémémoire 121 pour : recevoir des objets de fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseur 104 ; catégoriser les objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte ; stocker, sur une ou plusieurs mémoires 126, les objets de fournisseur tels que catégorisés ; recevoir, d'un dispositif demandeur (p. ex, le dispositif client 112), une requête pour un ou plusieurs articles fournis par un ou plusieurs systèmes de fournisseur 104 ; déterminer qu'un objet de fournisseur, stocké dans une ou plusieurs mémoires 126, réponde aux critères associés à la requête, y compris une ou plusieurs caractéristiques respectives de réutilisation et de contexte de l'objet de fournisseur ; et en réponse à la détermination que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide, fournir au dispositif demandeur une réponse correspondant à l'objet de fournisseur. Alors que l'application 223 peut être implémentée par programmation, dans d'autres exemples, l'application 223 peut être implémentée en utilisant des modèles d'apprentissage automatique. Dans d'autres exemples encore, l'application 223 peut combiner une implémentation programmatique avec une implémentation en utilisant des modèles d'apprentissage automatique. En effet, comme illustré, la mémoire 222 stocke en outre des modèles d'apprentissage automatique ("MLMs") 235 qui peuvent être utilisés, par le contrôleur 220, pour catégoriser les objets de fournisseur par une ou plusieurs caractéristiques de réutilisation et de contexte, et déterminer si un objet de fournisseur est actuellement valide. Les modèles d'apprentissage automatique 235 peuvent inclure des modèles et/ou des algorithmes basés sur des réseaux neuraux et/ou d'apprentissage profond et/ou d’apprentissage automatique, et autres similaires, incluant mais sans s'y limiter : un modèle de régression linéaire généralisée ; un modèle de forêt aléatoire ; un modèle de machine vectorielle de support ; un modèle de régression de stimulation de gradient (gradient boosting) ; un modèle d'arbre décisionnel ; un modèle additif généralisé ; des modèles de programmation évolutionnaire ; des modèles d'inférence bayésienne, des modèles d'apprentissage de renforcement, et autres similaires. Cependant, un quelconque modèle d'apprentissage automatique approprié et/ou modèle d'apprentissage profond et/ou modèle de réseau neural entre dans le champ d'application des présents exemples. Alors que la structure du système de fournisseur 104, du dispositif client 112, du serveur d'intermédiation 120, du concentrateur d'événements 127 et du système d'apprentissage automatique 129 n'est pas décrite en détail, le système de fournisseur 104, le dispositif client 112, le serveur d'intermédiation 120, le dispositif du pôle d'événements 127 et le système d'apprentissage automatique 129 peuvent avoir une structure similaire dans le serveur d’antémémoire 121 mais adaptée aux fonctionnalités respectives du système de fournisseur 104, au dispositif client 112, au serveur d'intermédiation 120, au dispositif du pôle d'événements 127 et au système d'apprentissage automatique 129. L'attention est maintenant dirigée vers la FIG. 3 qui illustre un organigramme représentant un procédé 300 pour fournir des objets de fournisseur à partir d’une antémémoire. Les opérations du procédé 300 de la FIG. 3 correspondent à des instructions lisibles par machine qui sont exécutées par le serveur d’antémémoire 121, et en particulier le contrôleur 220. Dans l'exemple illustré, les instructions représentées par les blocs de la FIG. 3 sont mémorisés dans la mémoire 222 par exemple, comme l'application 223 (et/ou les modèles d'apprentissage automatique 235). Le procédé 300 de la FIG. est une manière possible de configurer le contrôleur 220 et/ou le serveur d'antémémoire 121 et/ou le système 100. Par ailleurs, la discussion qui suit sur le procédé 300 de la FIG. 3 conduira à une compréhension plus avancée du système 100 et de ses divers composants. Le procédé 300 de la FIG. 3 n'a pas besoin d'être mis en œuvre dans la séquence exacte qui est illustrée, et de même les divers blocs peuvent être mis en œuvre parallèlement plutôt qu'en séquence. Par conséquent, les éléments du procédé 300 sont désignés dans la présente comme étant des « blocs » plutôt que des « étapes ». Le procédé 300 de la FIG. 3 peut également être implémenté dans des variations du système 100 de la FIG. 1. En particulier, alors que le procédé 300 est décrit comme étant implémenté par le serveur d'antémémoire 121, la fonctionnalité du serveur d’antémémoire 121 peut être combinée en un seul dispositif informatique qui implémente le procédé 300. Autrement, la fonctionnalité du serveur d’antémémoire 121 peut être distribuée entre une pluralité de serveurs et/ou de dispositifs informatiques qui implémentent le procédé 300 ; par exemple un dispositif informatique différent peut être utilisé pour implémenter chaque modèle d’apprentissage informatique 235. A ce titre, les blocs du procédé 300 peuvent être implémentés par un ou plusieurs serveurs et/ou dispositifs informatiques. Dans un bloc 302, le contrôleur 220 et/ou un ou plusieurs serveurs reçoivent des objets de fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseur 104. Dans certains exemples, les objets de fournisseur peuvent être reçus sous forme de messages (p. ex. un format de langage de balisage extensible [XML]) associés aux objets du fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseur 104. Dans certains exemples, les messages peuvent avoir plus d'un format. Les messages peuvent être associés à des objets de fournisseur qui peuvent comprendre des offres NDC ou des recommandations Edifact (p. ex. conformes à un format GDS) et autres similaires, et/ou être dans un quelconque format approprié ; le format des messages peut donc dépendre de la capacité des systèmes de fournisseurs 104 et/ou des sources des messages, et/ou du fait que les systèmes de fournisseurs 104 et/ou les sources des messages fonctionnent selon un format d'échange de données basé sur la NDC ou le GDS et/ou un autre type de format d'échange de données. Par ailleurs, les messages peuvent être reçus du dispositif du pôle d'événements 127 ; en effet, le contrôleur 220 et/ou ledit ou plusieurs serveurs peuvent recevoir tous les messages reçus au niveau du dispositif du pôle d'événements 127. Cependant, les messages peuvent être reçus à partir d'une quelconque source appropriée de messages dans le système 100. Dans un bloc 304, le contrôleur 220 et/ou un ou plusieurs serveurs catégorisent les objets du fournisseur selon une ou plusieurs caractéristiques de réutilisabilité et de contexte. Dans les exemples où la catégorisation des objets du fournisseur par réutilisabilité se produit, une telle catégorisation peut inclure, sans s'y limiter : la catégorisation des objets du fournisseur par une ou plusieurs des caractéristiques respectives ; et des combinaisons respectives d'un ou de plusieurs éléments respectifs représentés par les objets du fournisseur (p. ex. les éléments respectifs comprenant des produits fournis par les systèmes du fournisseur 104 ; cependant les éléments respectifs représentés par les objets du fournisseur peuvent correspondre aux critères inclus dans une requête du dispositif client 112 telle que décrite de façon plus détaillée. Dans les exemples où la catégorisation par les caractéristiques de contexte des objets de fournisseur se produit, cette catégorisation peut inclure, mais sans s’y limiter : la catégorisation des objets de fournisseur par un ou plusieurs éléments d'un contexte respectif dans lequel un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client et une catégorie d'éléments respectifs représentés par les objets de fournisseur. Par exemple, un objet de fournisseur peut être personnalisé en fonction d'un emplacement géographique à partir duquel une requête ayant donné lieu à un objet de fournisseur a été reçue et/ou selon que l'objet de fournisseur est destiné à des clients ayant une carte de fidélité aérienne et/ou à des clients ayant un statut de fidélité aérienne particulier, et autres similaires (p. ex. un type de client) et/ou si un objet de fournisseur est public ou privé (p. ex. pour quiconque, ou pour certains clients). Par exemple, le contrôleur 220 et/ou un ou plusieurs serveurs peuvent catégoriser les objets de fournisseur à l'aide des modèles d'apprentissage automatique 235. Dans un exemple, un modèle d'apprentissage automatique donné 235 peut comprendre un modèle d'apprentissage automatique déterminant la réutilisabilité pour catégoriser un objet de fournisseur en fonction de la réutilisabilité, ce qui peut inclure, sans s'y limiter : la catégorisation de l'objet de fournisseur par une ou plusieurs caractéristiques respectives de l'objet de fournisseur et des combinaisons respectives d'un ou de plusieurs éléments représentés par l'objet de fournisseur. Par exemple, les caractéristiques utilisées pour catégoriser l'objet de fournisseur peuvent être des caractéristiques de l'objet de fournisseur lui-même, tel qu'un vol pour un jour donné, tel que représenté par l'objet de fournisseur, le fait que l'objet de fournisseur soit pour une classe particulière de sièges sur le vol (p. ex. économie, premium, affaires, première, et autres similaires), un code de type de passger (c-à-d. si l’offre concerne un adulte, un enfant, etc.), un nombre de bagages inclus pour le vol et autres similaires, si l’offre est publique (elle peut être ouverte à tous) ou privée (elle peut être ouverte uniquement à une seule personne donnée et/ou à des personnes), et autres similaires. Ainsi, par exemple, l'objet de fournisseur pour un vol donné un jour donné, pour une classe donnée et un nombre donné de bagages peut être catégorisé comme réutilisable pour les demandes de vol du jour donné, pour la classe donnée et le nombre donné de bagages ; cependant, l'objet de fournisseur ne peut être réutilisable pour les demandes de vol du jour donné, pour la classe donnée mais pour un autre nombre de bagages. Dans un autre exemple, un modèle d'apprentissage automatique donné 235 peut comprendre un modèle d'apprentissage automatique déterminant le contexte pour catégoriser un objet de fournisseur en fonction des caractéristiques du contexte, qui peut inclure, mais sans s'y limiter : la catégorisation de l'objet de fournisseur par un ou plusieurs des contextes respectifs dans lesquels un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client,et une catégorie d’éléments respectifs représentés par l'objet de fournisseur. En particulier, les objets de fournisseur fournis par un système de fournisseur 104 peuvent être personnalisés en fonction de certains types de caractéristiques d'une requête pour l'objet de fournisseur, telle que les caractéristiques de contexte énumérées ci-dessus. Par exemple, un prix donné d'un objet de fournisseur et/ou des éléments offerts par un objet de fournisseur, et autres similaires, peut être personnalisé en fonction des caractéristiques de contexte d'une requête pour l'objet de fournisseur (p. ex. une requête qui est émise à partir de l'Angleterre pour un vol donné peut résulter en un objet de fournisseur qui est différent d'une requête pour le même vol qui émise à partir de la France) ; en d'autres termes, un système de fournisseur 104 peut mettre en œuvre un ensemble de règles et/ou une logique de contexte lorsqu'il fournit un objet de fournisseur en réponse à une requête ; la catégorisation d'un objet de fournisseur en fonction des caractéristiques du contexte peut inclure la catégorisation de l'objet de fournisseur d'une manière qui simule (et similaire) l'ensemble des règles et/ou la logique de contexte mis en œuvre par le système de fournisseur 104. Cette catégorisation peut autrement être désignée comme une segmentation du fait qu'un système de fournisseur 104 puisse fournir des objets de fournisseur d'une manière segmentée et/ou contextuelle. Par conséquent, le bloc 304 peut inclure l'utilisation d'un modèle d'apprentissage automatique déterminant la réutilisabilité 235 et d'un modèle d'apprentissage automatique déterminant le contexte 235 pour catégoriser respectivement les objets de fournisseur selon les caractéristiques de réutilisabilité et de contexte. Dans un bloc 306, le contrôleur 220 et/ou un ou plusieurs serveurs stockent, dans une ou plusieurs mémoires 126, les objects du fournisseur tels que catégorisés. Dans un bloc 308, le contrôleur 220 et/ou un ou plusieurs serveurs reçoivent, d'un dispositif demandeur, une requête (p. ex. un message) pour un ou plusieurs éléments fournis par ledit ou plusieurs systèmes du fournisseur 104. Par exemple, une requête peut inclure des critères (p. ex. pour un vol, telle qu’une origine, une destination, une date, et autres similaires) qui peuvent être utilisés pour rechercher les objets de fournisseur stockés dans la mémoire 126. Ces critères peuvent correspondre, au moins en partie, à une ou plusieurs catégories de caractéristiques de réutilisabilité et de contexte en fonction desquelles les objets de fournisseur sont stockés dans la mémoire 126. Une requête pour un ou plusieurs éléments fournis par un ou plusieurs systèmes de fournisseur 104 peut généralement être générée par le dispositif client 112 (p. ex. un dispositif demandeur peut comprendre le dispositif client 112) et reçue par le serveur d'intermédiation 120, qui peut demander le ou les éléments fournis par un ou plusieurs systèmes de fournisseur 104 du serveur d’antémémoire 120. Ainsi, au bloc 308, un dispositif de requête à partir duquel une requête est reçue (p. ex. au niveau du serveur d’antémémoire 121) peut comprendre le dispositif client 112 et/ou le serveur d'intermédiation 120. Dans un bloc 310, le contrôleur 220 et/ou un ou plusieurs serveurs déterminent si un objet de fournisseur, stocké dans une ou plusieurs mémoires 126, satisfait les critères associés à la requête, y compris une ou plusieurs caractéristiques de réutilisation et de contexte respectives de l'objet de fournisseur. Par exemple, la détermination que la réutilisabilité respective de l'objet de fournisseur réponde aux critères associés à la requête peut comprendre : la détermination que l'objet de fournisseur représente une ou plusieurs des mêmes caractéristiques et une même combinaison dudit ou de plusieurs des éléments demandés dans la requête. De même, déterminer que le contexte respectif de l'objet de fournisseur réponde aux critères associés à la requête peut comprendre de : déterminer que l'objet de fournisseur représente un ou plusieurs d'un même contexte respectif de la requête, une même personnalisation, un même emplacement géographique, un même type de client et une même catégorie du ou des éléments demandés dans la requête. Lorsqu'un objet de fournisseur, stocké dans une ou plusieurs mémoires 126, satisfait les critères associés à la requête (p. ex. une décision « OUI » au bloc 310), dans un bloc 312, le contrôleur 220 et/ou un ou plusieurs serveurs déterminent si l'objet de fournisseur qui satisfait les critères est actuellement estimé valide. Par exemple, un modèle d'apprentissage automatique 235 donné peut comprendre un modèle d'apprentissage automatique d'estimation de validité pour déterminer une criticité et/ou une validité d'un objet de fournisseur qui peut inclure, mais sans s'y limiter, la détermination de la validité actuelle de l'objet de fournisseur. Par exemple, un objet de fournisseur peut inclure un champ de durée de vie (TTL) qui indique généralement une durée qu’un fournisseur désigne comme étant la durée de validité de l’objet de fournisseur (p. ex. une durée, telle que 30 minutes, durant laquelle un prix proposé pour un vol peut être valide). Toutefois, les objets de fournisseur peuvent être valides plus longtemps que la durée de vie du champ TTL ; par exemple, un vol associé à l'objet de fournisseur peut avoir lieu six mois après la date à laquelle l'objet de fournisseur a été généré, et un prix proposé ne peut pas changer et/ou expirer pour une période de temps donnée qui est plus longue que la durée du champ TTL (p. ex. quatre mois), et/ou la période donnée peut être basée sur les chargements (p. ex. des vols) et/ou la saisonnalité. Par conséquent, dans ces exemples, le modèle d'apprentissage automatique 235 peut déterminer la criticité et/ou une validité d'un objet de fournisseur en déterminant qu'une heure actuelle ne dépasse pas une ou plusieurs d'un temps heure d'expiration estimée et une valeur TTL estimée (ou non estimée) d'un objet de fournisseur. En fait, les termes " criticité " et " validité " peuvent être utilisés de façon interchangeable. Par conséquent, le procédé 300 peut en outre comprendre l'utilisation, au niveau du contrôleur 220 et/ou d'un ou plusieurs serveurs, d'un modèle d'apprentissage automatique d'estimation de validité 235 pour déterminer que l'objet de fournisseur (stocké dans une ou plusieurs mémoires 126) est estimé être actuellement valide. Lorsque l'on estime que l'objet de fournisseur qui satisfait les critères est actuellement valide (p. ex. une décision « OUI » au bloc 312), au bloc 314, le contrôleur 220 et/ou un ou plusieurs serveurs fournissent, au dispositif demandeur, une réponse correspondant à l'objet de fournisseur (p. ex. stockée dans une ou plusieurs mémoires 126). Lorsque le responsable du traitement 220 et/ou un ou plusieurs serveurs déterminent, dans le bloc 310, qu'aucun objet de fournisseur ne satisfait les critères associés à la requête (p. ex. une décision « NON » dans le bloc 310) et/ou lorsque le responsable du traitement 220 et/ou un ou plusieurs serveurs déterminent, dans le bloc 312, que l'objet de fournisseur qui satisfait les critères n'est actuellement pas valide (p. ex. une décision « NON » dans le bloc 312), dans un bloc 316 le contrôleur 220 et/ou un ou plusieurs serveurs peuvent demander et recevoir du système de fournisseur 104 un objet de fournisseur qui répond à ces critères. Contrairement au reste du procédé 300, le bloc 316 peut être implémenté par le serveur d'intermédiation 120 et non par le serveur d’antémémoire 121. Lorsqu'un objet de fournisseur répondant aux critères est reçu du système de fournisseur 104 (p. ex. au lieu d'être récupéré dans une ou plusieurs mémoires 126), dans un autre exemple du bloc 314, le contrôleur 220 et/ou un ou plusieurs serveurs fournissent au dispositif demandeur une réponse correspondant à l'objet de fournisseur reçu du système de fournisseur 104 ; dans ces exemples du bloc 314, le serveur d'intermédiation peut fournir cette réponse. En outre, l'objet de fournisseur qui satisfait les critères peut être reçu via le dispositif du pôle d'événements 127 qui fournit l'objet de fournisseur au serveur d’antémémoire 121 pour un stockage dans une ou plusieurs mémoires 126. Alternativement, le bloc 316 peut être mis en œuvre, avant le bloc 310 et, lorsqu'aucune réponse n'est reçue du système 104 du fournisseur dans une période de temps seuil, le bloc 310 peut être mis en œuvre. En effet, tout critère approprié permettant au serveur d'intermédiation 120 de déterminer s'il faut demander un objet de fournisseur au serveur d’antémémoire 121 ou au système de fournisseur 104, entre dans le cadre de la présente spécification. Par exemple, le serveur d'intermédiation 120 peut inclure des règles et/ou des instructions mises en œuvre par un contrôleur de celui-ci, pour déterminer quand demander un objet de fournisseur au serveur d’antémémoire 121 ou au système de fournisseur 104. Par exemple, une requête provenant du dispositif client 112 peut être hautement personnalisée et/ou personnalisée pour un utilisateur donné (p. ex. un client) et le serveur d'intermédiation 120 peut mettre en œuvre des règles qui forcent une requête pour un objet de fournisseur hautement personnalisé et/ou personnalisé (p. ex. en fonction des données de la requête) à être demandée au système de fournisseur 104. De même, une requête du dispositif client 112 peut concerner un objet de fournisseur de haute qualité (p. ex. telle que déterminée à l'aide de règles prédéfinies, qui peuvent inclure, par exemple, l'indication qu'un temps de réponse plus long est acceptable) et le serveur d'intermédiation 120 peut mettre en œuvre des règles qui forcent la requête d'un objet de fournisseur de haute qualité au système de fournisseur 104 à être demandée. Toutefois, tout autre critère de contournement du serveur d’antémémoire 121 entre dans le champ d'application de la présente spécification. Lorsqu'aucun objet de fournisseur ne satisfait les critères de la requête et/ou qu'aucun objet de fournisseur valide ne satisfait les critères de la requête, la réponse retournée au bloc 314 peut être une réponse nulle. Bien que certains aspects du procédé 300 aient été généralement décrits en ce qui concerne un objet de fournisseur fourni en réponse à une requête, il est entendu que le procédé 300 peut être utilisé pour fournir plusieurs objets de fournisseur en réponse à une requête. Par exemple, le serveur d’antémémoire 121 peut : déterminer (p. ex. au bloc 310 et au bloc 312) qu'une pluralité d'objets de fournisseur, stockés dans une ou plusieurs mémoires 126, réponde aux critères associés à la requête, y compris une ou plusieurs caractéristiques respectives de réutilisabilité et de contexte de l'objet de fournisseur ; et en réponse à la détermination que la pluralité des objets de fournisseur, qui satisfont les critères, soit estimée être actuellement valide, fournir au dispositif demandeur une réponse correspondant à la pluralité des objets de fournisseur. Dans d'autres exemples encore, un ou plusieurs serveurs peuvent implémenter le bloc 316 en parallèle avec le bloc 310, le bloc 312 et le bloc 314, de sorte que la pluralité d'objets de fournisseur fournis au dispositif demandeur inclut des objets de fournisseur provenant de ladite ou de plusieurs mémoires 126 et des objets de fournisseur reçus du système du fournisseur 104. Le reste du procédé 300 peut être adapté en conséquence. Un exemple du procédé 300 est décrit ci-après, comprenant un exemple de formation de modèles d’apprentissage automatique 235. L'attention est d'abord dirigée vers la FIG. 4, qui illustre le système 100, mais sans le réseau 116. Plutôt FIG. 4 montre des liens de communication entre les composants du système 100 qui sont représentés entre ceux-ci par des flèches à deux bouts ; ces liens de communication peuvent inclure le réseau 116. Sinon, FIG. 4 est similaire à la FIG. 1, avec des composants similaires ayant des nombres similaires. En particulier, la FIG. 4 illustre un exemple de formation des modèles d'apprentissage automatique 235 tels qu'implémentés sur le serveur d’antémémoire 121. La FIG. 4, le concentrateur d'événements 127 reçoit les messages 401 du système 104 du fournisseur comme décrit ci-dessus. Les messages 401, tels qu'ils sont représentés, comprennent des objets fournisseur et autres similaires. Le concentrateur d'événements 127 fournit les messages 401 au système de formation au modèle d'apprentissage automatique 129 qui génère les classificateurs 436 pour les modèles d'apprentissage automatique 235 et fournit les classificateurs 436 aux modèles d'apprentissage automatique 235 correspondants implémentés sur le serveur d’antémémoire 121. Par exemple, tel qu'illustré, le serveur d’antémémoire 121 implémente un modèle d'apprentissage automatique déterminant la réutilisabilité 235-1, un modèle d'apprentissage automatique déterminant le contexte 235-2, et un modèle d'apprentissage automatique estimant la validité 235-3. Ainsi, le système de formation au modèle d'apprentissage automatique 129 génère des classificateurs appropriés 436 pour chacun de ces modèles d'apprentissage automatique 235 implémentés sur le serveur d’antémémoire 121. Comme illustré, le dispositif du pôle d'événements 127 peut par ailleurs fournir les objets de fournisseur 402 des messages 401 au serveur d'antémémoire 121. Alors que les objets de fournisseur 402 sont illustrés comme étant différents des messages 401, les objets de fournisseur 402 peuvent être reçus auprès du serveur d'antémémoire 121 sous la forme de messages 401. L'attention se porte maintenant à la FIG. 5 et la FIG. 6 qui illustre un exemple du procédé 300. L'attention est d'abord dirigée vers la FIG. 5, qui est essentiellement similaire à la FIG. 4 mais sans le système de formation des modèles d'apprentissage automatique 129, avec des composants similaires ayant des nombres similaires. La FIG. 5 représente le serveur d’antémémoire 121 recevant (p. ex. au bloc 302) deux objets de fournisseur 402-1, 402-2. Comme illustré, le serveur d’antémémoire 121 implémente les modèles d'apprentissage automatique 235-1, 235-2 pour catégoriser (p. ex. au bloc 304 du procédé 300) les objets de fournisseur 402-1, 402-2 selon les caractéristiques de réutilisabilité et de contexte. Tel qu'illustré, le modèle d'apprentissage automatique 235-1 catégorie l'objet de fournisseur 402-1 selon une catégorie « A » de réutilisabilité, et catégorise l'objet de fournisseur 402-2 selon une catégorie « B » de réutilisabilité. De même, le modèle d'apprentissage automatique 235-2 catégorise l'objet de fournisseur 402-1 selon une catégorie « A » de caractéristiques de contexte, et catégorise l'objet de fournisseur 402-2 selon une catégorie « B » de caractéristiques de contexte. Bien qu'un tel exemple soit simpliste, il est entendu que les modèles d'apprentissage automatique 235-1, 235-2 peuvent catégoriser les objets de fournisseur 402-1, 402-2 selon toute catégorie appropriée de caractéristiques de réutilisabilité et/ou de contexte et/ou toute autre catégorie appropriée (p. ex. comme indiqué par les classificateurs d'apprentissage automatique 436). Un objet de fournisseur 402 peut être catégorisé dans plus d'une catégorie ; des exemples plus détaillés d'objets de fournisseur, tels que catégorisés, sont décrits ci-dessous en ce qui concerne la FIG. 7. Par exemple, le serveur d’antémémoire 121 peut catégoriser les objets de fournisseur 402-1, 402-1 par réutilisabilité en catégorisant les objets de fournisseur 402-1, 402-1 par une ou plusieurs des caractéristiques respectives et des combinaisons respectives d'un ou de plusieurs éléments respectifs représentés par les objets de fournisseur 402-1, 402-1. De même, le serveur d’antémémoire en 121 peut catégoriser les objets de fournisseur 402-1, 402-1 par caractéristiques de contexte en catégorisant les objets de fournisseur par un ou plusieurs d'un contexte respectif dans lequel un objet de fournisseur respectif 402-1, 402-1 a été demandé, une personnalisation, un emplacement géographique, un type de client, et une catégorie des éléments respectifs représentés par les objets de fournisseur 402-1 et 402-1. En effet, comme décrit ci-dessus, la catégorisation des objets de fournisseur 402-1, 402-1 selon les caractéristiques du contexte peut inclure la catégorisation de l'objet de fournisseur d'une manière qui simule (et similaire) un ensemble de règles/ou une logique de contexte mis en œuvre par le système de fournisseur 104. Telle qu’également décrite ci-dessus, cette catégorisation peut autrement être désignée comme une segmentation car un système de fournisseur 104 peut fournir des objets de fournisseur d'une manière segmentée et/ou contextuelle. De plus, alors que les objets de fournisseur 402-1 et 402-2 sont catégorisés en fonction de leurs caractéristiques à la fois de réutilisabilité et de contexte, dans d'autres exemples, les objets de fournisseur 402-1 et 402-2 peuvent être catégorisés en fonction d'une ou de plusieurs caractéristiques de réutilisabilité et de contexte. Tel qu’illustré, le serveur d’antémémoire 121 stocke (p. ex. au bloc 306 du procédé 300), dans la mémoire 126, les d’objets de fournisseur 402-1, 402-2 tels que catégorisés. Tel qu'illustré, l'article 402-1 de l’objet de fournisseur est stocké en association avec les indicateurs d'une catégorie « A » de réutilisabilité et d'une catégorie « A » de caractéristiques de contexte. De même, l'objet de fournisseur 402-2 est stocké en association avec des indicateurs d'une catégorie « B » de réutilisabilité et une catégorie « B » de caractéristiques de contexte. Alors que seuls deux objets de fournisseur 402-1, 402-2 sont illustrés comme étant stockés et catégorisés dans la mémoire 126, tout nombre approprié des objets de fournisseur 402 peut être stocké dans la mémoire 126, tel que catégorisé par les modèles d'apprentissage automatique 235-1, 235-2. L'attention se porte maintenant à la FIG. 6, qui est essentiellement similaire à la FIG. 5, avec des composants similaires ayant des nombres similaires. En particulier, la FIG. 6 illustre le serveur d’antémémoire recevant (p. ex. au bloc 308 du procédé 300), du serveur d'intermédiation 120, une requête 601 pour un ou plusieurs éléments fournis par un ou plusieurs systèmes de fournisseur 104, tel qu’un vol, et autres similaires. Par exemple, telle qu’illustrée, la requête a été générée par le dispositif client 112 et transmise au serveur d'intermédiation 120 qui fournit la requête 601 au serveur d’antémémoire 121. La requête 601 peut inclure des critères (p. ex. pour le vol, telle qu’une origine, une destination, une date, et autres similaires) qui peuvent être utilisés pour rechercher les objets de fournisseur 402 stockés dans la mémoire 126. Ces critères peuvent correspondre, au moins en partie, à une ou plusieurs catégories de caractéristiques de réutilisabilité et de contexte selon lesquelles les objets de fournisseur 402 sont stockés dans la mémoire 126. En particulier, plutôt que de demander un objet de fournisseur qui représente l'élément du système de fournisseur 104, le serveur d'intermédiation 120 peut d'abord utiliser la requête 601 pour demander l'élément au serveur d'antémémoire 121 qui détermine si un ou plusieurs objets de fournisseur 402, stockés dans la mémoire 126, satisfont les critères associés à la requête 601, par exemple une ou plusieurs des caractéristiques respectives de réutilisabilité et de contexte de l'objet de fournisseur 402. Tel qu'illustré, le serveur d'antémémoire 121 détermine (p. ex. au bloc 310 du procédé 300) que l'objet de fournisseur 402-1 satisfait les critères associés à la requête 601. Par exemple, le serveur d’antémémoire 121 peut déterminer que la réutilisabilité de l'objet de fournisseur 402-1 réponde aux critères associés à la requête 601 en déterminant que l'objet de fournisseur 402-1 représente une ou plusieurs des mêmes caractéristiques et une même combinaison d'un ou de plusieurs éléments demandés par la requête 601. Toutefois, tel qu'illustré, le serveur d’antémémoire 121 peut déterminer que la réutilisabilité de l'objet de fournisseur 402-2 ne répond pas aux critères associés à la requête 601 en déterminant que l'objet de fournisseur 402-2 ne représente pas une ou plusieurs des mêmes caractéristiques et une même combinaison d'un ou de plusieurs éléments demandés par la requête 601. Bien que les présents exemples soient décrits en ce qui concerne la réutilisabilité d'un objet de fournisseur répondant aux critères associés à la requête 601, dans d'autres exemples, la réutilisabilité de plus d'un objet de fournisseur peut répondre aux critères associés à la requête 601. De même, le serveur d’antémémoire 121 peut déterminer que le contexte respectif de l'objet de fournisseur 402-1 réponde aux critères associés à la requête 601 en déterminant que l'objet de fournisseur 402-1 représente un ou plusieurs d'un même contexte respectif (et/ou similaire) de la requête 601, y compris, mais sans s'y limiter, une personnalisation identique (et/ou similaire), un même emplacement géographique (et/ou similaire), un même type de client (et/ou similaire) et une même catégorie (et/ou similaire) associée à la requête 601 et/ou dudit ou de plusieurs éléments demandés par la requête 601. Le serveur d’antémémoire 121 estime (p. ex. au bloc 312 du procédé 300) la validité de l'objet de fournisseur 402-1 en utilisant le modèle d'apprentissage automatique 235-3 (p.ex. et les classificateurs d'apprentissage automatique 435-3). Tel qu'illustré, l'objet de fournisseur 402-1 est déterminé être valide (p. ex. « OUI » l’objet de fournisseur 402-1 est valide) En réponse à la détermination que l'objet de fournisseur 402-1 réponde aux critères associés à la requête 601 et que l'objet de fournisseur 402-1 soit valide, le serveur d’antémémoire 121 fournit (p. ex. au bloc 314 du procédé 300) l'objet de fournisseur 402-1 au serveur d'intermédiation 120 qui fournit l'objet de fournisseur 402-1 au dispositif client 112, par exemple en transmettant l'objet de fournisseur 402-1 comme message 401. L'objet de fournisseur 402-1 (p. ex. le message 401 qui inclut l'objet de fournisseur 402-1) peut également être reçu au niveau du dispositif du pôle d'événements 127 et fourni au système de formation de modèles d'apprentissage automatique 129 pour une utilisation dans la formation des modèles d'apprentissage automatique 235, telle que décrite ci-dessus. Bien que tel qu'illustré, un seul objet de fournisseur 402-1 valide qui satisfait les critères de la requête 601 soit fourni au dispositif client 112, plusieurs objets de fournisseur 402 valides qui satisfont les critères de la requête 601 peuvent être fournis au dispositif client 112, comprenant, mais sans s'y limiter, des dizaines à des centaines d'objets de fournisseur 402. Dans les exemples où aucun objet de fournisseur 402 valide qui satisfait les critères de la requête 601 n'est stocké dans la mémoire 126, le serveur d'intermédiation 120 peut demander (p. ex. au bloc 316 du procédé 300) au système de fournisseur 104 des objets de fournisseur 402 qui satisfont les critères de la requête 601. Dans d'autres exemples encore, lorsqu'un objet de fournisseur 402 stocké dans la mémoire 126 satisfait les critères de la requête 601 mais est déterminé invalide, le serveur d'intermédiation 120 peut demander au système de fournisseur 104 des objets de fournisseur 402 qui satisfont les critères de la requête 601, par exemple pour récupérer une version plus récente de l'objet de fournisseur 402 stocké dans la mémoire 126 qui satisfait les critères de la requête 601. Dans ces exemples, le serveur d'antémémoire 121 peut fournir un indicateur d'un fournisseur d’objets 402 invalide qui satisfait les critères de la requête 601 qui peut inclure un identifiant d'un système de fournisseur 104 qui a initialement généré l'objet de fournisseur 402 maintenant invalide de sorte que le serveur d'intermédiation 120 peut récupérer une version plus récente de l'objet de fournisseur 402 invalide en fonction de l'identifiant du système de fournisseur 104. Dans d'autres exemples encore, le serveur d'intermédiation 120 peut d'abord demander les objets de fournisseur 402 qui satisfont les critères de la requête 601 auprès du système de fournisseur 104. Lorsque le système de fournisseur 104 ne répond pas dans un laps de temps seuil donné, le serveur d'intermédiation 120 peut demander les objets de fournisseur 402 au serveur d'antémémoire 121. En outre, le serveur d‘antémémoire 121 peut mettre à jour les objets de fournisseur 402 stockés dans la mémoire 126. Par exemple, les objets de fournisseur 402 stockés dans la mémoire 126 peuvent concerner des éléments spécifiques, tels qu'un vol spécifique, et autres similaires. Lorsqu'un autre objet de fournisseur 402 est reçu (p. ex. au bloc 302 du procédé 300) qui représente une version plus récente d'un objet de fournisseur 402 déjà stocké et catégorisé dans la mémoire 126, la nouvelle version d'un objet de fournisseur 402 peut être catégorisée et peut remplacer l'objet de fournisseur 402 déjà stocké et catégorisé dans la mémoire 126, comme décrit ci-dessus (p. ex. de sorte que les caractéristiques de réutilisabilité, de contexte et/ou la validité soient également actualisées). Les exemples illustrés dans la FIG. 5 et FIG. 6 en ce qui concerne la catégorisation des objets du fournisseur 402-1, 402-2 selon les catégories « A » et « B » sont relativement simplistes. Par conséquent, l'attention se porte sur la FIG. 7 qui représente des exemples d'objets de fournisseur 702 tels que catégorisés par les modèles d'apprentissage automatique 235-1, 235-2 et qui peuvent être stockés dans la mémoire 126. Alors que les objets de fournisseur 702 sont représentés sous forme de tableau, les objets de fournisseur 702 peuvent être enregistrés dans tout format approprié. Dans le tableau représenté, chaque ligne correspond à un objet de fournisseur particulier 702, tel que catégorisé, avec des colonnes correspondant à divers attributs et/ou caractéristiques des objets de fournisseur 702, comprenant, mais sans s'y limiter, les caractéristiques associées à la réutilisabilité et les caractéristiques de contexte. Tel qu'illustré, l'objet du fournisseur 702 correspond à une offre de vols, avec des colonnes définissant, pour les offres, un transporteur ("CXR") d'un vol, une origine ("ORI") d'un vol, une destination ("DES") d'un vol, un code de type de passager ("PTC") de l'offre (par ex. "ADT" ou adulte), si une offre est publique ("PUB") (par exemple ou privée), un "TTL" pour l'offre, un identifiant ("ID") de l'offre, un numéro de vol ("AF#") du vol, un coût ("COÛT") de l'offre, un nombre de bagages ("BAGS") de l'offre et une caractéristique du contexte ("Contexte") de l'offre. En particulier, le transporteur, l'origine, la destination, le TTL, l'identifiant, le numéro de vol, le coût, le code de type de passager, si une offre est publique, et le nombre de bagages peuvent être déterminés en utilisant le modèle 235-1 d'apprentissage automatique déterminant la réutilisabilité et peuvent inclure l'extraction de telles informations des objets de fournisseur 702 avant la catégorisation. Les caractéristiques de contexte peuvent être déterminées à l'aide du modèle d'apprentissage automatique déterminant le contexte 235-2. Comme illustré, par exemple, chacun des objets de fournisseur 702 est catégorisé selon qu'un objet de fournisseur 702 s'adresse à des clients de pays différents. Ainsi, par exemple, l'objet de fournisseur 702 de la première ligne peut être fourni en réponse à des requêtes de clients situés en France, en supposant que l'objet de fournisseur 702 de la première ligne réponde par ailleurs aux critères de telles requêtes. De même, l'objet de fournisseur 702 de la deuxième rangée peut être fourni en réponse à des requêtes de clients situés aux États-Unis, en supposant que l'objet de fournisseur 702 de la deuxième rangée réponde par ailleurs aux critères de telles requêtes. De même, l'objet de fournisseur 702 de la troisième rangée peut être fourni en réponse à des demandes de clients situés au Royaume-Uni, en supposant que l'objet de fournisseur 702 de la troisième rangée réponde par ailleurs aux critères de ces requêtes. Lorsque de nouveaux objets de fournisseur sont reçus qui correspondent à l'un des objets de fournisseur 702 tels que catégorisés, les objets de fournisseur 702 tels que catégorisés peuvent être remplacés. Par exemple, lorsqu'un objet de fournisseur le plus récent est reçu pour le vol numéro AF456 (par exemple, l'objet de fournisseur 702 de la deuxième ligne), par exemple avec un coût actualisé, l'objet de fournisseur 702 de la deuxième ligne peut être remplacé par l’objet de fournisseur le plus récent. Dans cette spécification, des éléments peuvent être décrits comme étant « configurés pour » mettre en œuvre une ou plusieurs fonctions ou comme étant « configurés pour » ces fonctions. En général, un élément qui est configuré pour effectuer ou mettre en œuvre une fonction est capable d'effectuer la fonction, ou est approprié pour mettre en œuvre la fonction, ou est adapté pour effectuer la fonction, ou est fonctionnel pour mettre en œuvre la fonction ou est capable de mettre en œuvre la fonction autrement. Il est compris que dans le but de cette spécification le langage « au moins un de X, Y et Z » et « un ou plusieurs de X, Y et Z » peut être interprété comme signifiant X seulement, Y, seulement, Z seulement ou toutes combinaisons de deux ou plusieurs éléments X, Y, Z (p. ex. XYZ, XY, YZ, XZ, et ainsi suite). Une logique similaire peut être appliquée pour deux ou plusieurs éléments dans toute occurrence de « au moins un... » et « un ou plusieurs… » langages. Les termes « environ », « substantiellement », « essentiellement », « approximativement », et autres similaires sont, par exemple, définis comme signifiant « proche de », comme le comprendront les hommes de métier. Dans certains exemples, les termes sont compris comme étant « dans un rayon de 10 % », dans d'autres exemples, « dans un rayon de 5 % », et encore dans d'autres exemples « dans un rayon de 1 % » et encore dans d'autres exemples « dans un rayon de 0,5 % ». Les hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité des dispositifs et/ou des procédés et/ou des processus décrit dans la présente peut ê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 (ASICs), des mémoires à lecture seule programmables et effaçables électriquement (EEPROMs, etc.) ou d’autres composants associés. Dans d'autres exemples, la fonctionnalité des dispositifs et/ou des procédés et/ou des processus décrits dans la présente peut être mise en œuvre en utilisant un appareil informatique qui a accès à une mémoire de code (non illustrée) qui stocke un code de programme lisible par ordinateur pour fonctionner dans l'appareil informatique. Le code de programme lisible par ordinateur pourrait être stocké sur un support de stockage lisible par ordinateur qui est fixe, tangible et lisible directement par ces composants, (p. ex. une disquette amovible, un CD-ROM, une RAM, un disque dur, un lecteur de clé USB). Par ailleurs on comprendra que le programme lisible par ordinateur peut être stocké sur un produit programme d'ordinateur comprenant un support utilisable par ordinateur. Par ailleurs, un dispositif de stockage durable peut comprendre le code de programme lisible par ordinateur. Il est par ailleurs apprécié que le code de programme lisible par ordinateur et/ou le support utilisable par ordinateur peut comprendre un code de programme durable lisible par ordinateur et/ou un support durable utilisable par ordinateur. Autrement, le code de programme lisible par ordinateur pourrait être stocké à distance, mais être transmissible à ces composants via un modem ou tout autre dispositif d'interface connecté à un réseau (incluant sans limitation, l'Internet) sur un support de transmission. Le support de transmission peut être soit un support inamovible (p. ex. des lignes de communication optiques et/ou numériques et/ou analogues ou un support amovible (p. ex. micro-ondes, infrarouge, optique à espace libre ou autres systèmes de transmission) ou une combinaison de ceux-ci. Les hommes de métier comprendront qu'il y a encore d'autres exemples et modifications possibles et que les exemples ci-dessus ne sont que des illustrations d'un ou de plusieurs exemples. Un procédé pour fournir des objets de fournisseur à partir d'une antémémoire comprenant : la réception, sur un ou plusieurs serveurs, des objets de fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseurs ; la catégorisation, sur ledit ou plusieurs serveurs, des objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte ; le stockage, par ledit ou plusieurs serveurs, dans une ou plusieurs mémoires, des objets de fournisseur tels que catégorisés ; la réception, sur ledit ou plusieurs serveurs, d'un dispositif demandeur, une requête pour un ou plusieurs éléments fournis par ledit ou plusieurs systèmes de fournisseur ; la détermination sur un ou plusieurs serveurs qu'un objet de fournisseur, stocké sur une ou plusieurs mémoires, réponde aux critères associés à la requête, y compris une ou plusieurs caractéristiques de réutilisabilité et de contexte respectives de l'objet de fournisseur ; et en réponse à la détermination que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide, en fournissant, par ledit ou plusieurs serveurs, au dispositif demandeur, une réponse correspondant à l'objet de fournisseur. Le procédé de revendication 1, dans lequel la catégorisation des objets de fournisseur par réutilisabilité comprend : la catégorisation des objets de fournisseur par une ou plusieurs des caractéristiques respectives et des combinaisons respectives dudit ou de plusieurs éléments respectifs représentés par les objets de fournisseur ; et la détermination que la réutilisabilité respective de l'objet de fournisseur réponde aux critères associés à la requête comprend : la détermination que l'objet de fournisseur représente une ou plusieurs des mêmes caractéristiques et une même combinaison dudit ou de plusieurs éléments demandés par la requête. Le procédé de revendication 1 ou de revendication 2, dans lequel la catégorisation des objets de fournisseur par les caractéristiques de contexte comprend : la catégorisation des objets de fournisseur par un ou plusieurs éléments d'un contexte respectif dans lequel un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client et une catégorie d'éléments respectifs représentés par les objets de fournisseur ; et la détermination que le contexte respectif de l'objet de fournisseur satisfait les critères associés à la requête comprend : la détermination que l'objet de fournisseur représente un ou plusieurs d'un même contexte respectif de la requête, une même personnalisation, un même emplacement géographique, un même type de client et une même catégorie dudit ou de plusieurs éléments demandés dans la requête. Le procédé de l'une quelconque des revendications 1 à 3, dans lequel il est déterminé que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide, comprend : la détermination qu'un horaire actuel ne dépasse pas une ou plusieurs d'une heure d'expiration estimée et d'une valeur TTL (Time-To-Live) estimée de l'objet de fournisseur. Le procédé de l'une quelconque des revendications 1 à 4, comprenant en outre :l'utilisation, sur ledit ou plusieurs serveurs, d'un modèle d'apprentissage automatique déterminant la réutilisabilité et d'un modèle d'apprentissage automatique déterminant le contexte pour catégoriser respectivement les objets de fournisseur en fonction des caractéristiques de réutilisabilité et du contexte. Le procédé de l'une quelconque des revendications 1 à 5, comprenant en outre :l'utilisation, sur ledit ou plusieurs serveurs, d'un modèle d'apprentissage automatique d'estimation de validité pour déterminer que l'objet de fournisseur soit estimé être actuellement valide. Un serveur pour fournir des objets de fournisseur à partir d'une antémémoire comprenant : une ou plusieurs mémoires ; une interface de communication ; et un contrôleur configuré pour : recevoir, via l'interface de communication, des objets de fournisseur représentant des éléments fournis par un ou plusieurs systèmes de fournisseur ; de catégoriser les objets de fournisseur par une ou plusieurs caractéristiques de réutilisabilité et de contexte ; de stocker, dans une ou plusieurs mémoires, les objets de fournisseur tels que catégorisés ; de recevoir, par l'intermédiaire de l'interface de communication, à partir d'un dispositif demandeur, une requête pour un ou plusieurs éléments fournis par un ou plusieurs systèmes de fournisseur ; de déterminer qu'un objet de fournisseur, stocké dans une ou plusieurs mémoires, satisfait les critères associés à la requête, comprenant une ou plusieurs caractéristiques de réutilisabilité et de contexte respectives de l'objet de fournisseur ; et en réponse à la détermination que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide, fournir, via l'interface de communication, au dispositif demandeur, une réponse correspondant à l'objet de fournisseur. Le serveur selon la revendication 7, dans lequel le contrôleur est en outre configuré pour catégoriser les objets de fournisseur par réutilisabilité en : catégorisant les objets de fournisseur en fonction d'une ou de plusieurs caractéristiques respectives et de combinaisons respectives d'un ou de plusieurs éléments respectifs représentés par les objets de fournisseur ; et en déterminant que la réutilisabilité respective de l'objet de fournisseur satisfait les critères associés à la requête comprend : la détermination que l'objet de fournisseur représente une ou plusieurs des mêmes caractéristiques et une même combinaison dudit ou de plusieurs éléments demandés par la requête. Le serveur de l'une quelconque des revendications 7 à 8, dans lequel le contrôleur est en outre configuré pour catégoriser les objets de fournisseur par caractéristiques de contexte en : catégorisant les objets de fournisseur par un ou plusieurs éléments d'un contexte respectif dans lequel un objet de fournisseur respectif a été demandé, une personnalisation, un emplacement géographique, un type de client et une catégorie d'éléments respectifs représentés par les objets de fournisseur ; et déterminant que le contexte respectif de l'objet de fournisseur réponde aux critères associés à la requête comprend : la détermination que l'objet de fournisseur représente un ou plusieurs d'un même contexte respectif de la requête, une même personnalisation, un même emplacement géographique, un même type de client et une même catégorie dudit ou des éléments demandés dans la requête. Le serveur de l'une quelconque des revendications 7 à 9, dans lequel le contrôleur est en outre configuré pour déterminer que l'objet de fournisseur, qui satisfait les critères, soit estimé être actuellement valide en : déterminant qu'un horaire actuel ne dépasse pas une ou plusieurs d'une heure d'expiration estimée et une valeur TTL (Time-To-Live) estimée de l’objet de fournisseur. Le serveur de l'une quelconque des revendications 7 à 10, dans lequel le contrôleur est en outre configuré pour : utiliser un modèle d'apprentissage automatique déterminant la réutilisabilité et un modèle d'apprentissage automatique déterminant le contexte pour catégoriser respectivement les objets de fournisseur en fonction des caractéristiques de réutilisabilité et de contexte. Le serveur de l'une quelconque des revendications 7 à 11, dans lequel le contrôleur est en outre configuré pour : utiliser un modèle d'apprentissage automatique d'estimation de la validité pour déterminer si l'objet de fournisseur est estimé être actuellement valide. Un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 6 lorsque ledit programme fonctionne sur un ordinateur.