Brevet FR3102280A1 — publié le 20210423

Un serveur : reçoit en provenance d’au moins un système de fournisseur, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le système de fournisseur(s) ; génère un objet d’intermédiation, correspondant audit au moins un objet de fournisseur, incluant un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation et les données d’objet d’intermédiation étant remplies avec au moins un sous-ensemble de données d’objet de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et tout identifiant d’objet de fournisseur dans une forme d’origine ; et fournit l’objet d’intermédiation, à la place dudit au moins un objet de fournisseur, à un dispositif client qui a demandé le au moins un élément, l’objet d’intermédiation fourni. L’identifiant d’objet d’intermédiation peut permettre au serveur de servir d’intermédiaire entre le dispositif client et le système(s) de fournisseur sans stocker l’objet de fournisseur et/ou un quelconque identifiant d’objet de fournisseur. Figure à publier avec l’abrégé : Fig. 3 DISPOSITIF, SYSTÈME ET PROCÉDÉ POUR UNE INTERMÉDIATION ENTRE UN SYSTÈME DE FOURNISSEUR QUI FOURNIT DES OBJETS DE FOURNISSEUR ET UN DISPOSITIF CLIENT DOMAINE La spécification concerne de façon générale l’intermédiation entre dispositifs, et spécifiquement un dispositif, un système et un procédé pour l’intermédiation entre un système de fournisseur qui fournit des objets de fournisseur, et un dispositif client. CONTEXTE Le provisionnement de divers produits incluant par exemple des biens et des services liés au voyage (p. ex. des vols, des réservations d’hôtel et ainsi de suite) requiert typiquement que des entités discrètes diverses échangent des données définissant des aspects divers des produits. Des exemples de ces entités, dans le contexte des produits liés au voyage, incluent les compagnies aériennes, les agences de voyages, les utilisateurs finaux, les systèmes de réservation et similaires. Bien que ces entités puissent être configurées pour échanger des données conformément à 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), ils peuvent néanmoins utiliser des mécanismes différents pour initier l’échange de données. Résumé : Un aspect de la spécification fournit un procédé pour l’intermédiation entre un système de fournisseur et un dispositif client, le procédé comprenant : la réception, à un serveur d’intermédiation, en provenance d’au moins un système de fournisseur, d’au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; la génération, au serveur d’intermédiation, d’un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation, les données d’objet d’intermédiation remplies avec au moins un sous-ensemble de données d’objet de fournisseur sur la base d’un mappage entre les données d’objet d’intermédiation et les données d’objet de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; et fournissant, via le serveur d’intermédiation, l’objet d’intermédiation au dispositif client qui a demandé le au moins un élément fourni par au moins un système de fournisseur, l’objet d’intermédiation étant fourni à la place de l’objet de fournisseur. Dans certains exemples, le procédé comprend par ailleurs le stockage, dans au moins une ou plusieurs mémoires, d’un ou de plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation en association à un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur. Dans certains exemples, le procédé comprend par ailleurs la réception, au serveur d’intermédiation, d’une pluralité d’objets de fournisseur, dans lequel les données d’objets d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objets de fournisseur de la pluralité des objets de fournisseur sur la base d’un ou de plusieurs mappages entre les données d’objets d’intermédiation et les données d’objets de fournisseur respectif, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur respectif, incluant un quelconque identifiant d’objet de fournisseur dans une forme d’origine respective. Dans certains exemples, le procédé comprend par ailleurs la réception au serveur d’intermédiation, en provenance du dispositif client, d’une requête incluant l’identifiant d’objet d’intermédiation ; et la requête, en provenance dudit au moins un système de fournisseur, d’informations supplémentaires associées audit au moins un élément sur la base d’un ou de plusieurs de : au moins un de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation stocké, dans une ou plusieurs mémoires, en association à un ou plusieurs dudit au moins un objet de fournisseur et de l’identifiant d’objet de fournisseur ; et une version cryptée d’une portion dudit au moins un objet de fournisseur incluse à l’objet d’intermédiation. Dans certains exemples, le au moins un objet de fournisseur comprend un ou plusieurs d’un élément d’offre de fournisseur et d’un élément de service de fournisseur représentant une pluralité d’éléments fournis par le au moins un système de fournisseur, et l’objet d’intermédiation comprend un ou plusieurs éléments d’offre d’intermédiation et un élément de service d’intermédiation correspondant respectivement à un ou plusieurs des éléments d’offre de fournisseur et des éléments de service de fournisseur. Un autre aspect de la spécification fournit un serveur comprenant : une interface de communication ; et un contrôleur configuré pour : recevoir, via l’interface de communication, en provenance d’au moins un système de fournisseur, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; générer, au serveur d’intermédiation, un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation, les données d’objet d’intermédiation remplies avec au moins un sous-ensemble de données d’objets de fournisseur sur la base d’un mappage entre les données d’objet d’intermédiation et les données d’objet de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine et ; fournir, via le serveur d’intermédiation, l’objet d’intermédiation au dispositif client qui a demandé le au moins un élément fourni par au moins un système de fournisseur, l’objet d’intermédiation étant fourni à la place de l’objet de fournisseur. Un autre aspect de la spécification fournit un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant : des moyens de programmation lisibles par ordinateur pour recevoir, à un serveur d’intermédiation, en provenance d’au moins un système de fournisseur, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; des moyens de programmation lisibles par ordinateur pour générer, au serveur d’intermédiation, un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation les données d’objet d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objet de fournisseur sur la base d’un mappage entre les données d’objet d’intermédiation et les données d’objet de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; et des moyens de programmation lisibles par ordinateur pour fournir par le serveur d’intermédiation, l’objet d’intermédiation à un dispositif client qui a demandé le au moins un élément fourni par le au moins un système de fournisseur, l’objet d’intermédiation étant fourni à la place dudit au moins un objet de fournisseur lorsque le programme fonctionne sur un ordinateur. Dans certains exemples, le produit programme d’ordinateur comprenant les instructions de code de programme stocké sur un support lisible par ordinateur comprend : des moyens de programmation lisibles par ordinateur pour stocker, dans au moins une ou plusieurs mémoires, un ou plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation en association à un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur. Dans certains exemples, le produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprend : des moyens de programmation lisibles par ordinateur pour recevoir, au serveur d’intermédiation, une pluralité d’objets, dans lequel les données d’objet d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objets de fournisseur de la pluralité des objets de fournisseur sur la base d’un ou de plusieurs mappages entre les données d’objets d’intermédiation et les données d’objets de fournisseur respectif, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur respectif, incluant un quelconque identifiant d’objet de fournisseur respectif, dans une forme d’origine respective. Un autre aspect de la spécification fournit un procédé comprenant : la réception, à un serveur d’intermédiation, en provenance d’au moins un système de fournisseur, d’au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; la génération, au serveur d’intermédiation, d’un objet d’intermédiation, correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation comprenant une intermédiation remplie avec au moins un sous-ensemble de données d’objets de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; la génération, au serveur d’intermédiation, d’un identifiant intermédiaire d’au moins une portion des données d’objet de fournisseur arrangée dans un format prédéterminé ; la fourniture, au serveur d’intermédiation, d’un identifiant d’objet d’intermédiation en cryptant l’identifiant intermédiaire ; et la fourniture, par le serveur d’intermédiation, de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation à un dispositif client qui a demandé le au moins un élément, sans stocker l’objet d’intermédiation et l’identifiant d’objet d’intermédiation. Un autre aspect de la spécification fournit un serveur pour l’intermédiation entre un système de fournisseur et un dispositif client, le serveur comprenant : une interface de communication ; et un contrôleur configuré pour : recevoir, via l’interface de communication, en provenance d’au moins un système de fournisseur, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; générer un objet d’intermédiation, correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation comprenant une intermédiation remplie avec au moins un sous-ensemble de données d’objets de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; générer un identifiant intermédiaire d’au moins une portion des données d’objet de fournisseur arrangée dans un format prédéterminé ; générer un identifiant d’objet d’intermédiation en cryptant l’identifiant intermédiaire ; et fournir l’objet d’intermédiation et l’identifiant d’objet d’intermédiation à un dispositif client qui a demandé le au moins un élément, sans stocker l’objet d’intermédiation et l’identifiant d’objet d’intermédiation. Dans certains exemples, le contrôleur est par ailleurs configuré pour : recevoir, via l’interface de communication, en provenance du dispositif client, en réponse à la fourniture de l’objet d’intermédiation, l’identifiant d’objet d’intermédiation avec une requête pour des informations supplémentaires associées audit au moins un élément ; décrypter l’identifiant d’objet intermédiation pour obtenir ladite au moins la portion des données d’objet de fournisseur ; et demander l’information supplémentaire audit au moins un système de fournisseur en utilisant ladite au moins la portion des données d’objet de fournisseur, telle qu’elle est décryptée. Dans certains exemples, dans lequel le contrôleur est par ailleurs configuré pour générer l’identifiant intermédiaire à partir d’au moins la portion des données d’objet de fournisseur arrangée dans un format prédéterminé en : ayant recours à un ou plusieurs de la concaténation, l’assemblage, le groupement et l’organisation de ladite au moins la portion des données d’objet de fournisseur selon le format prédéterminé. Dans certains exemples, le contrôleur est par ailleurs configuré pour générer l’identifiant intermédiaire à partir d’au moins la portion des données d’objet de fournisseur arrangée dans un format prédéterminé en : incluant, un identifiant de format prédéterminé avec la portion des données d’objet de fournisseur arrangée dans le format prédéterminé. Dans certains exemples, le contrôleur est par ailleurs configuré pour générer l’identifiant d’objet d’intermédiation en incluant une version cryptée avec l’identifiant intermédiaire après le cryptage. Dans certains exemples, le format prédéterminé est dépendant d’un type d’objet de fournisseur. Dans certains exemples, l’objet d’intermédiation comprend l’identifiant d’objet d’intermédiation. Un autre aspect de la spécification fournit un support non transitoire lisible par ordinateur qui stocke un programme d’ordinateur, dans lequel l’exécution du programme d’ordinateur est pour : la réception, à un serveur d’intermédiation, en provenance d’au moins un système de fournisseur, d’au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; la génération, au serveur d’intermédiation, d’un objet d’intermédiation, correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation comprenant des données d’objet d’intermédiation remplie avec au moins un sous-ensemble de données d’objet de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; la génération, au serveur d’intermédiation, d’un identifiant intermédiaire d’au moins une portion des données d’objet de fournisseur arrangée dans un format prédéterminé ; et la fourniture, au serveur d’intermédiation, d’un identifiant d’objet d’intermédiation en cryptant l’identifiant intermédiaire ; et la fourniture, par le serveur d’intermédiation, de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation à un dispositif client qui a demandé le au moins un élément, sans stocker l’objet d’intermédiation et l’identifiant d’objet d’intermédiation. 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 maintenant faites à titre d’exemple uniquement, aux dessins en annexe dans lesquels : illustre un système pour l’intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client, conformément à des exemples non limitatifs. illustre un dispositif pour l’intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client, conformément à des exemples non limitatifs. illustre un procédé pour l’intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client, conformément à des exemples non limitatifs. illustre le dispositif client du système de la FIG. 1 transmettant une requête, conformément à des exemples non limitatifs. illustre le serveur d’intermédiation du système de la FIG. 1 fournissant un objet d’intermédiation au dispositif client conformément à des exemples non limitatifs. illustre le serveur d’intermédiation du système de la FIG. 1 fournissant plus d’un objet d’intermédiation au dispositif client conformément à des exemples non limitatifs. illustre un exemple d’une structure d’un objet d’intermédiation, conformément à des exemples non limitatifs. illustre un procédé pour l’intermédiation entre un système de fournisseur et un dispositif client en utilisant les identifiants d’objets intermédiation qui ne sont pas stockés par un serveur d’intermédiation. illustre un exemple d’un procédé utilisé pour générer un objet d’intermédiation et un identifiant d’objet intermédiation, conformément à des exemples non limitatifs. illustre un exemple d’un procédé utilisé pour générer un objet l’intermédiation et un identifiant d’objet d’intermédiation, conformément à des exemples qui ne sont pas limitatifs. illustre un exemple d’un procédé utilisé pour générer un objet d’intermédiation et un identifiant d’objet d’intermédiation conformément à des exemples non limitatifs. illustre un exemple d’un procédé utilisé pour générer un objet d’intermédiation et un identifiant d’objet d’intermédiation conformément à des exemples non limitatifs. illustre un format prédéterminé pour générer un identifiant intermédiaire selon des exemples non limitatifs. DESCRIPTION DÉTAILLÉE FIG. 1 illustre un système 100 pour l’intermédiation entre un système de fournisseur qui fournit des objets de fournisseur et un dispositif client. Les objets de fournisseurs, dans les exemples exposés dans la présente, peuvent comprendre des objets de fournisseur et/ou des enregistrements de données qui correspondent à des produits et/ou à des éléments, tels que des biens et des services liés au voyage (p. ex. des vols, des réservations d’hôtel, des locations de véhicules et ainsi de suite) fournis par le système du 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, de l’alimentation pendant le vol, des distractions et similaires). Cependant, comme le reconnaîtront les hommes de métier, 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 exposés en lien avec les exemples fournis dans la présente. Le système 100 inclut un ou plusieurs systèmes de fournisseurs 104 et/ou au moins un système de fournisseur 104 (p. ex. un ou plusieurs serveurs où 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 des entités fournisseuses respectives (p. ex. d’autres compagnies aériennes) bien qu’un seul système de fournisseur 104 soit montré à titre d’exemple. Dans certains exemples, le système du fournisseur 104 peut stocker un répertoire 108 contenant une pluralité d’objets de fournisseur. 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 système de distribution mondiale (GDS), des enregistrements d’offre dans le contexte d’un échange de données basé sur la nouvelle norme de capacité de distribution (NDC) et/ou un quelconque autre format approprié. En effet les objets de fournisseur peuvent comprendre des objets de données et/ou des enregistrements de données, par exemple stockant une recommandation Edifact ou une offre NDC et/ou toutes autres données appropriées représentant au moins un élément fourni par le système de fournisseur 104. Par ailleurs, lorsque les objets de fournisseurs comprennent des offres NDC, les offres NDC peuvent être stockées dans le répertoire 108 ; cependant lorsque les objets de fournisseurs comprennent des recommandations Edifact, les recommandations Edifact ne peuvent pas être stockées dans le répertoire 108. 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 s’y limiter un ou plusieurs vols, voyages en train, séjours d’hôtel, accès au salon de l’aéroport, surclassements de sièges, services d’enregistrement de bagages, alimentation pendant le vol, distraction et ainsi de suite et/ou des services associés. Ainsi dans les exemples discutés ci-dessous, chaque objet de fournisseur peut définir un vol géré par l’entité fournisseuse et/ou des services de voyage 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 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 champ et/ou de données d’un objet de fournisseur peut dépendre d’un type d’objet de données. 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 pour accéder à un salon de l’aéroport et/ou une offre pour un surclassement de siège premium, peuvent inclure des informations liées au salon, au siège premium, etc. Les objets de fournisseur peuvent être générés pour un stockage dans le répertoire 108 en réponse à des requêtes reçues au système de fournisseur 104 en provenance d’autres composants du système 100. Par exemple, les requêtes peuvent être reçues d’un dispositif client 112, via un réseau 116 (p. ex. une quelconque combinaison appropriée de réseau de zone locale et étendue, incluant l’Internet) et via un serveur d’intermédiation 120. Comme cela sera décrit ci-dessous, 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, par exemple de sorte que le dispositif client 112 puisse demander des produits du système de fournisseur 104, et/ou de plusieurs systèmes de fournisseurs 104, via le serveur d’intermédiation 120. Le dispositif client 112, dans le présent exemple, peut être géré par une entité agente de voyages et génère donc et transmet des requêtes pour des objets de fournisseur (p. ex. représentant des produits qui peuvent être achetés) et/ou des requêtes pour acheter des produits (p. ex. représentés par les objets de fournisseur) au système de fournisseur 104 vers le serveur d’intermédiation 120 pour le compte d’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’exemple. Divers autres mécanismes pour initier la création d’objets de fournisseur sont aussi envisagés. Par exemple, les utilisateurs finaux (via des dispositifs informatiques supplémentaires qui ne sont pas illustrés dans la FIG. 1) peuvent initier la création d’objets de fournisseur via une interaction directe avec un site web hébergé par le serveur d’intermédiation 120. Divers mécanismes pour la création d’objets de fournisseur dans le répertoire 108 seront apparents aux hommes de métier, tels que les mécanismes d’« offre » et de « commande » spécifiés par la norme NDC. La création d’objets de fournisseur en réponse aux demandes d’achat de produits n’est pas détaillée dans la présente. Le dispositif client 112 est configuré pour recevoir des données contenues dans les objets de fournisseurs stockés dans le répertoire 108 via le serveur d’intermédiation 120. Les données obtenues par le dispositif client 112, via le serveur d’intermédiation 120, peuvent être présentées à des utilisateurs desservis par le dispositif client 112 ; d’autres informations associées aux éléments représentés par les objets de fournisseurs peuvent être demandées par le dispositif client 112 qui peut inclure, mais sans s’y limiter, que le dispositif client 112 commande les éléments. En d’autres termes, le système 100 permet au dispositif client 112 de demander d’autres informations associées aux éléments représentés par les objets de fournisseur stockés dans le répertoire 108, via le serveur d’intermédiation 120. Le dispositif client 112 peut être configuré pour demander les informations supplémentaires et/ou initier ces commandes en transmettant des requêtes au système de fournisseur 104 via le serveur d’intermédiation 120. Les objets de fournisseur fournis par le système de fournisseur 104 incluent généralement des données d’objet de fournisseur représentant au moins un élément fourni par le système de fournisseur 104. Dans certains exemples, les données d’objet de fournisseur peuvent inclure un identifiant d’objet de fournisseur et/ou des données d’identifiant d’objet de fournisseur qui identifient l’objet du fournisseur auprès du système de fournisseur 104. Les données d’objet de fournisseur comprennent généralement des informations qui identifient un produit et/ou un service lié au voyage. Le fait que les données d’objet de fournisseur incluent ou non un identifiant d’objet de fournisseur spécifique peut dépendre du format de l’objet de fournisseur, s’il est NDC ou EDIFACT (p. ex. GDS). Par exemple lorsqu’un objet de fournisseur comprend une offre NDC, les données d’identifiant d’objet de fournisseur peuvent comprendre un identifiant généré par le système de fournisseur 104 qui identifie spécifiquement l’offre NDC. Cependant, lorsqu’un objet de fournisseur comprend une recommandation Edifact qui n’inclut généralement pas d’identifiant spécifique, la recommandation Edifact peut être identifiée par le système de fournisseur 104 sur la base de données d’identifiant d’objet de fournisseur telles que les caractéristiques de la recommandation Edifact telles qu’un attribut spécial (p. ex. une commande dans laquelle des données d’une recommandation sont présentées) et/ou le format des données de la recommandation Edifact. Le serveur d’intermédiation 120 maintient un répertoire local 124. Dans certains exemples, le répertoire local 104 peut contenir des versions des objets de fournisseur qui sont générés au serveur d’intermédiation 120, par exemple lorsqu’un objet de fournisseur est reçu au serveur d’intermédiation 120. Les versions des objets de fournisseurs générées par le serveur d’intermédiation 120 sont désignées ci-après indifféremment comme objets d’intermédiation. En général, un objet d’intermédiation correspond à au moins un objet de fournisseur. Par ailleurs, un objet d’intermédiation inclut des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifient l’objet d’intermédiation, les données d’objet d’intermédiation étant remplies avec au moins un sous-ensemble desdites données d’objet de fournisseur basées sur un mappage entre les données d’objet d’intermédiation et les données d’objet de fournisseur. Ce mappage peut être stocké dans une mémoire du serveur d’intermédiation 120. En général l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettent : l’objet de données de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine. Par exemple, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation sont généralement configurés de sorte que lorsqu’un utilisateur du dispositif client 112 a accès à l’objet d’intermédiation et à l’identifiant d’objet d’intermédiation, il est généralement incapable d’identifier spécifiquement le au moins un objet de fournisseur auprès du système du fournisseur 104. Par exemple, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation peuvent spécifiquement exclure et/ou omettre un identifiant d’objet de fournisseur et/ou des données d’identifiant d’objet de fournisseur. Cependant, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation sont généralement configurés pour permettre au serveur d’intermédiation 120 d’identifier le au moins un objet de fournisseur auprès du système de fournisseur 104 en utilisant par exemple : un ou plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation stockés en association à un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur ; et/ou des données cryptées dans l’identifiant d’objet d’intermédiation. Le serveur d’intermédiation 120 est par ailleurs configuré pour fournir l’objet d’intermédiation au dispositif client 112 qui a demandé le au moins un élément fourni par le système de fournisseur, l’objet d’intermédiation étant fourni à la place dudit au moins un objet de fournisseur, comme cela sera décrit de façon plus détaillée ci-dessous. Faisant maintenant référence à la FIG. 2, avant d’exposer en détail les fonctionnalités du système 100, certains composants du serveur d’intermédiation 120 vont maintenant être décrits de façon plus détaillée. Bien qu’illustré comme étant un dispositif, le serveur d’intermédiation 120 peut comprendre un ou plusieurs dispositifs informatiques et/ou un plusieurs dispositifs informatiques dématérialisés (cloud) qui peuvent être géographiquement distribués. Comme le montre la FIG. 2, le serveur d’intermédiation 120 inclut au moins un contrôleur 220, tel qu’une unité centrale de traitement (CPU) ou similaire. Le processeur 220 est interconnecté à une mémoire 222 stockant une application 223, la mémoire 222 est implémentée comme un support non transitoire lisible par ordinateur approprié (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 similaires). Le processeur 220 et la mémoire 222 sont généralement compris 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’intermédiation 120 de communiquer avec les autres dispositifs informatiques du système 100 (c.-à-d. le système du fournisseur 104 et le dispositif client 112) 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 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’intermédiation 120 peut aussi inclure des dispositifs d’entrée et de sortie connectés au contrôleur 220, tels que des claviers, des souris, des écrans, et similaires (non illustrés). Les composants du serveur d’intermédiation 120 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’intermédiation 120 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. Comme illustrée, la mémoire 222 peut stocker le répertoire local 124 mentionné par rapport à la FIG. 1. Cependant, dans d’autres exemples, le répertoire local 124 peut être externe au serveur d’intermédiation 120 et accessible au contrôleur 220 par exemple via l’interface de communication 228. 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’intermédiation 120 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. Comme illustrée, la mémoire 222 stocke par ailleurs un mappage 235 entre les données d’objets d’intermédiation et les données d’objets de fournisseur. Par exemple, le mappage 235 peut indiquer des champs des objets d’intermédiation qui correspondent aux champs respectifs des objets de fournisseur. Par exemple, les données d’objets de fournisseur d’un type donné, tel qu’un numéro de vol, peuvent se trouver dans un champ donné d’un objet de fournisseur ; de façon similaire un objet d’intermédiation peut inclure un champ donné respectif où doit être stocké un numéro de vol. Le mappage 235 peut indiquer une correspondance entre ces champs des objets de fournisseur et des objets intermédiation de sorte que des champs donnés des objets intermédiation peuvent être remplis avec les informations données de champs correspondants des objets de fournisseur. En général, le mappage 235 est préconfiguré à la mémoire 222. Reformulé différemment, le mappage 235 est généré en supposant que les objets de fournisseur ont un format cohérent (et/ou similaire) et/ou des objets de fournisseur d’un type donné ont un format respectif cohérent (et/ou similaires). Par ailleurs, alors qu’un seul mappage 235 est illustré, la mémoire 222 peut stocker différents mappages 235 pour des formats d’objets de fournisseurs différents et/ou des types d’objets de fournisseur différents. Par exemple, alors qu’un seul système de fournisseur 104 est décrit dans la présente, le serveur d’intermédiation 120 peut être en communication avec plus d’un système de fournisseur 104 (p. ex. des compagnies aériennes différentes) qui peuvent chacun générer et/ou fournir des objets de fournisseurs respectifs de formats différents. Autrement, un système de fournisseur donné 104 peut générer et/ou fournir des objets de fournisseur ayant différents formats pour différents types d’éléments (p. ex. des offres de vol, des offres de salon, des offres de sièges premium, et ainsi de suite). En général, la mémoire 222 stocke un mappage respectif 235 pour chaque type d’objet de fournisseur qui peut être reçu. Cependant, les objets d’intermédiation qui sont générés peuvent avoir un format cohérent et/ou similaire. Par conséquent, via le mappage 235 (et/ou les mappages 235), les objets d’intermédiation peuvent être remplis et fournis au dispositif client 112 dans un format cohérent et/ou similaire quel que soit le format et/ou le type d’objet de fournisseur à partir duquel les données sont utilisées pour remplir les objets d’intermédiation. L’exécution de l’application 223 comme elle sera exposée ci-dessous, configure le serveur d’intermédiation 120 pour, dans un mode : recevoir, en provenance d’au moins un système de fournisseur 104 (p. ex. le système de fournisseur 104), au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; générer, au serveur d’intermédiation, un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation, les données d’objet d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objet de fournisseur sur la base d’un mappage 235 entre les données d’objet d’intermédiation et les données d’objet de fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; et fournir le serveur d’intermédiation à un dispositif client (p. ex. le dispositif client 112) qui a demandé le au moins un élément fourni par au moins un système de fournisseur, l’objet d’intermédiation étant fourni à la place de l’objet de fournisseur. Bien que la structure du système de fournisseur 104 et du dispositif client 112 ne soit pas décrite en détail, le système de fournisseur 104 et le dispositif client 112 sont censés avoir une structure similaire à celle du serveur d’intermédiation 120, mais adaptée à la fonctionnalité du système de fournisseur 104 et du dispositif client 112. L’attention se porte maintenant sur la FIG. 3 qui illustre un organigramme représentatif du procédé 300 pour l’intermédiation entre un système de fournisseur qui fournit des objets de fournisseur à un dispositif client. 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’intermédiation 120, et spécifiquement le contrôleur 220 du serveur d’intermédiation 120. Dans l’exemple illustré, les instructions représentées par les blocs de la FIG. 3 sont stockées dans la mémoire 222 par exemple comme l’application 223. Le procédé 300 de la FIG. 3 est une manière possible de configurer le contrôleur 220 et/ou le serveur d’intermédiation 120 et/ou le système 100. Par ailleurs la discussion qui suit du 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 montrée et, de même, les divers blocs peuvent être mis en œuvre en parallèle 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é sur des variations du système 100 de la FIG. 1. Au bloc 302, le contrôleur 220 et/ou le serveur d’intermédiation 120 reçoivent (p. ex. via l’interface de communication 228), en provenance d’au moins un système de fournisseur, au moins un objet de fournisseur 104, un d’objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le système de fournisseur. Ainsi que décrit ci-dessus, les données d’objet de fournisseur peuvent inclure un identifiant d’objet de fournisseur et/ou des données d’identifiant d’objet de fournisseur qui identifient l’objet du fournisseur auprès du système de fournisseur. 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. Les messages peuvent être associés à des objets de fournisseur qui peuvent comprendre des offres NDC ou des recommandations Edifact (p. ex. conformément à des échanges de données GDS) et similaires et/ou être dans un quelconque format approprié ; le format, etc. des messages peut donc dépendre de la capacité des systèmes de fournisseurs 104 et/ou des sources de messages et/ou du fait que les systèmes de fournisseurs 104 et/ou les sources de message fonctionnent selon le format d’échange de données basé sur NDC ou GDS, et/ou un autre type de format d’échange de données. En général, les offres NDC peuvent inclure des identifiants d’objets de fournisseur alors que les recommandations Edifact peuvent ne pas inclure les identifiants d’objet de fournisseur, bien que les caractéristiques d’une recommandation Edifact (p. ex. son format et ainsi de suite) peuvent permettre à la recommandation Edifact d’être identifiée par le système de fournisseur 104. Dans certains exemples, au bloc 302, le contrôleur 220 et/le serveur d’intermédiation 120 peuvent : recevoir, en provenance du dispositif client 112, une requête pour le au moins un élément fourni par le système de fournisseur 104 ; demander, à partir du système de fournisseur 104, le au moins un objet de fournisseur basé sur la requête reçue du dispositif client 112 ; et recevoir, du système de fournisseur 104, le au moins un objet de fournisseur. Par conséquent, dans ces exemples, le au moins un objet de fournisseur est reçu en réponse à une requête du dispositif client 112 reçue au serveur d’intermédiation 120 ; en particulier, la requête peut être pour une offre de vols vers des destinations données à des dates particulières et le serveur d’intermédiation 120 peut demander au système de fournisseur 104 une offre pour ces vols. Le au moins un objet de fournisseur renvoyé au serveur d’intermédiation 120, en provenance du système de fournisseur 104, peut comprendre une offre pour ces vols et leur offre peut inclure d’autres éléments tels qu’une offre pour un accès au salon, une offre pour un surclassement en siège premium et ainsi de suite. Cependant dans d’autres 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 similaire, 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 obtenir un enregistrement d’offres pour des vols vers des destinations données pour des jours particuliers. Ces demandes peuvent être transmises et/ou déclenchées par le serveur d’intermédiation 120 et les objets de fournisseurs qui en résultent et/ou les messages peuvent être stockés dans une antémémoire et utilisés pour répondre ultérieurement à une requête du dispositif client 112 pour ces vols sans demander, à nouveau, l’offre au système de fournisseur 104. Un tel système est décrit dans la demande en co-instance du demandeur dont le titre est « DISPOSITIF, SYSTÈME ET PROCÉDÉ POUR FOURNIR DES OBJETS DE FOURNISSEURS À PARTIR D’UNE ANTÉMÉMOIRE ayant le numéro français de demande FR1911662, enregistré le même jour que la présente spécification et incorporée dans la présente en guise de référence. Au bloc 304, le contrôleur 220 et/ou le serveur d’intermédiation 120 génère un objet d’intermédiation correspondant au moins à un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet intermédiation qui identifient l’objet d’intermédiation, les données d’objet intermédiation étant remplies par au moins un sous-ensemble des données d’objets de fournisseurs basées sur un mappage 235 entre les données d’objet d’intermédiation et les données d’objet de fournisseur, l’objet d’intermédiation et les identifiants d’objet intermédiation omettant : les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine. Dans certains exemples, un objet de fournisseur peut comprendre un ou plusieurs éléments d’offre de fournisseur et un élément de service de fournisseur représentant une pluralité d’éléments fournis par le système du fournisseur et l’objet d’intermédiation généré peut comprendre un ou plusieurs d’un élément d’offre d’intermédiation et d’un élément de service d’intermédiation correspondant respectivement à un ou plusieurs de l’élément d’offre de fournisseur et l’élément de service de fournisseur. Par exemple, un élément de service de fournisseur peut comprendre des données indicatives de services fournis par le système du fournisseur 104, tels que des vols, un accès au salon, etc. ; un élément d’offre de fournisseur peut comprendre les éléments de service du fournisseur, mais livrés avec des informations de coût et/ou un élément d’offre de fournisseur peut comprendre une pluralité d’éléments de services de fournisseurs livrés avec un prix donné. Cependant, les offres NDC peuvent inclure à la fois des éléments de service de fournisseurs et des éléments d’offre de fournisseurs alors que les recommandations Edifact peuvent inclure des éléments de services de fournisseurs, mais ne fournissent pas d’éléments d’offre (ce qui peut être particulier au format NDC) ; à ce titre la structure de l’objet de fournisseur peut dépendre du fait que le système de fournisseur 104 opère selon la norme NDC ou selon un échange de données basé sur un GDS. De façon similaire, l’objet d’intermédiation généré peut comprendre un ou plusieurs éléments d’offre d’intermédiation et un élément de service d’intermédiation correspondant respectivement à un ou plusieurs de l’élément d’offre de fournisseur et de l’élément de service de fournisseur. Par ailleurs, un objet d’intermédiation peut être généré à partir de plus d’un objet de fournisseur comme cela sera décrit plus en détail ci-dessous. Par ailleurs l’identifiant d’objet d’intermédiation peut être généré d’une quelconque manière appropriée de sorte que l’identifiant d’objet d’intermédiation puisse être utilisé pour identifier et/ou identifier de façon unique l’objet d’intermédiation auprès du serveur d’intermédiation 120. Dans certains exemples, le serveur d’intermédiation 120 peut attribuer et/ou attribuer de façon unique l’identifiant d’objet d’intermédiation à l’objet d’intermédiation. Dans d’autres exemples, comme décrit ci-dessus, le serveur d’intermédiation 120 peut crypter une portion des données d’objets de fournisseur pour obtenir l’identifiant d’objet d’intermédiation, ou ne peut pas, inclure un identifiant d’objet de fournisseur dépendant par exemple du fait que le au moins un objet de fournisseur inclut une offre NDC ou une recommandation Edifact. Par conséquent, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation n’incluent pas les données d’objet de fournisseur et tout identifiant d’objet de fournisseur, dans une forme d’origine, bien que l’objet d’intermédiation contienne des données provenant des données d’objet de fournisseur en fonction du mappage. Formulé autrement, l’objet d’intermédiation inclut des données provenant des données d’objet de fournisseur, mais qui sont restructurées (p. ex. en fonction du mappage) pour empêcher le dispositif client 112 d’identifier les objets de fournisseur auprès du système de fournisseur 104, et/ou restructurées d’une manière qui empêche la capacité du dispositif client 112 de communiquer avec le système de fournisseur 104 directement par rapport audit au moins un objet de fournisseur 104, afin de réduire par exemple la charge sur le système du fournisseur 104 ; comme cela sera décrit ci-dessous, dans des environnements réels de l’industrie du voyage, des millions ou des milliards de requêtes par jour peuvent être générées représentant des recherches pour des éléments fournis par des systèmes de fournisseurs 104 et le serveur d’intermédiation 120 généralement sert d’intermédiaire entre le dispositif client 112 et le système du fournisseur 104 pour contrôler et/ou réduire la charge sur le système du fournisseur 104. Quoi qu’il en soit, le serveur d’intermédiation 120 est généralement configuré pour déterminer qu’un objet d’intermédiation est associé à au moins un objet de fournisseur. Par exemple, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent stocker, au moins une ou plusieurs mémoires (p. ex. la mémoire 222 et/ou une mémoire externe accessible au contrôleur 220 et/ou au serveur d’intermédiation 120), un ou plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation en association à un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur. Par conséquent, lorsque les communications concernant l’objet d’intermédiation sont reçues (par exemple par le dispositif client 112 demandant d’autres informations associées audit au moins un élément), les communications incluant l’identifiant d’objet d’intermédiation, et similaires, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent déterminer l’objet de fournisseur associé, via l’association stockée entre un ou plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation et le un ou plusieurs d’au moins un objet de fournisseur et de l’identifiant d’objet de fournisseur. Dans d’autres exemples, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent inclure une version cryptée d’une portion dudit au moins un objet de fournisseur dans l’objet d’intermédiation, par exemple dans un champ donné de l’objet d’intermédiation. Par conséquent, dans ces exemples, le dispositif client 112 peut inclure, par exemple, dans une requête pour d’autres informations associées audit au moins un élément indiqué par le au moins un objet de fournisseur, la version cryptée de la portion dudit au moins un objet de fournisseur, de sorte que le serveur d’intermédiation 120 puisse décrypter la version cryptée afin d’obtenir le au moins un objet de fournisseur. Dans ces exemples, on comprendra que le serveur d’intermédiation 120, mais pas le dispositif client 112, a accès aux clés cryptographiques et similaires, pour crypter et/ou décrypter le au moins un objet de fournisseur. Alors que le cryptage et le décryptage ne sont pas décrits en détail dans la présente, un quelconque processus adapté pour le cryptage et/ou le décryptage de l’objet de fournisseur est dans le champ d’application de la présente spécification. Par ailleurs, comme cela sera décrit de façon plus détaillée ci-dessous, dans certains exemples, des techniques de cryptage peuvent être utilisées pour éviter le stockage des objets de fournisseur, des objets d’intermédiation, des identifiants d’objet de fournisseur et/ou des identifiants d’objet intermédiation dans le répertoire 124. Au bloc 306, le contrôleur 220 et/ou le serveur d’intermédiation 120 fournit (p. ex. via l’interface de communication 228) l’objet d’intermédiation au dispositif client 112 qui a demandé le au moins un élément fourni par au moins un système de fournisseur 104, l’objet d’intermédiation étant fourni à la place dudit au moins un objet de fournisseur. Dans certains exemples, le contrôleur 220 et/ou le serveur d’intermédiation 120 peut recevoir en provenance du dispositif client 112, une requête incluant l’identifiant d’objet d’intermédiation. La requête peut-être pour d’autres informations associées audit au moins un élément représenté par le au moins un objet de fournisseur associé à l’objet d’intermédiation transmis au dispositif client 112. Dans certains exemples, les autres informations associées audit au moins un élément de la requête peuvent être de commander le au moins un objet de fournisseur (dans un échange de données NDC, une requête « créer commander ») et/ou peut représenter une étape intermédiaire dans la commande de l’objet de fournisseur (p. ex. la requête peut être pour un objet de prix finalisé [p. ex. dans un échange de données NDC, une requête « ¨prix d’offre »] et/ou un itinéraire, et similaires, pour le au moins un objet de fournisseur). Dans ces exemples, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent demander les autres informations pour le au moins un élément, en provenance du système de fournisseur 104, sur la base dudit au moins un objet de fournisseur et/ou un identifiant d’objet de fournisseur et/ou des données d’identifiant d’objet de fournisseur ainsi que déterminé à partir de l’identifiant d’objet d’intermédiation et un ou plusieurs de : au moins un de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation stocké, à une ou plusieurs mémoires, en association à un ou plusieurs dudit au moins un objet de fournisseur et de l’identifiant d’objet de fournisseur ; et une version cryptée d’une portion dudit au moins un objet de fournisseur inclus à l’objet d’intermédiation. Ces exemples sont décrits ci-dessus. Dans certains exemples, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent demander d’autres informations associées à au moins un élément du système du fournisseur 104, en réponse à la requête. Cependant, dans d’autres exemples la requête pour les autres informations associées à au moins un élément peut être une étape intermédiaire avant de commander le au moins un élément, et la commande dudit au moins un élément peut survenir en réponse à une autre requête reçue du dispositif client 112. Bien que le procédé 300 ait été décrit par rapport à au moins un objet de fournisseur et/ou un système de fournisseur 104, le procédé 300 peut être adapté à plus d’un objet de fournisseur et/ou plus d’un système de fournisseur 104. Par exemple, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent, au bloc 302, recevoir (p. ex. d’un ou de plusieurs systèmes de fournisseurs 104) une pluralité d’objets de fournisseur. Chacun des objets de fournisseur reçu peut inclure un identifiant d’objet de fournisseur respectif et/ou des données d’identifiant d’objet de fournisseur respectif comme décrit ci-dessus. Le contrôleur 220 et/ou le serveur d’intermédiation 120 peut, dans ces exemples, remplir au bloc 304 les données d’objets intermédiation de l’objet d’intermédiation avec au moins un sous-ensemble de données d’objets de fournisseurs respectifs de la pluralité des objets de fournisseurs sur la base d’un ou de plusieurs mappages 235 entre les données d’objet d’intermédiation et les données d’objets de fournisseurs respectifs, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objets de fournisseurs respectifs, incluant un quelconque des identifiants d’objets de fournisseurs respectifs, dans une forme d’origine respective. À nouveau, l’objet intermédiation inclut généralement au moins un sous-ensemble de données d’objets de fournisseurs respectifs, mais elles sont restructurées pour empêcher le dispositif client 112 d’identifier les objets de fournisseur du système du fournisseur 104. Par conséquent, lorsque par exemple plus d’un objet de fournisseur est reçu au serveur d’intermédiation 120, par exemple avec différents formats et (p. ex. dans le cas des offres NDC) des identifiants d’objets de fournisseur et/ou des données d’identifiants d’objets de fournisseur (p. ex. dans le cas des recommandations Edifact), le serveur d’intermédiation 120 convertit généralement les objets de fournisseur dans un format d’intermédiation commun, en générant des objets d’intermédiation respectifs, et il identifie les objets d’intermédiation avec les identifiants d’objet d’intermédiation. Ces exemples apportent de l’homogénéité aux communications entre le dispositif client 112 et les systèmes de fournisseurs 104 qui peut rendre la communication entre eux plus efficace ; par exemple, les services de voyage et/ou les ressources informatiques implémentées au dispositif client 112 n’ont pas besoin d’être adaptés à de nombreux formats d’objets de fournisseur. En effet, en réponse à une requête d’un dispositif client 112, le serveur d’intermédiation 120 peut généralement répondre avec des dizaines à des centaines de milliers d’objets intermédiation, chacun d’entre eux pouvant correspondre à un objet de fournisseur reçu d’un ou de plusieurs systèmes de fournisseurs 104 ; par conséquent le nombre de formats, et similaires, des objets de fournisseur peut être très important. Plutôt que d’adapter les services de voyage et/ou les ressources informatiques implémentées au dispositif client 112 pour traiter un si grand nombre de formats, ces services de voyage et/ou ces ressources informatiques implémentées au dispositif client 112 peuvent être adaptées au format commun d’intermédiation, ce qui peut conduire à une utilisation plus efficace des ressources informatiques au dispositif client 112. De façon similaire, les identifiants d’objets d’intermédiation peuvent aussi être dans un format commun qui peut aussi conduire à une utilisation plus efficace des ressources de traitement au dispositif client 112, car les services de voyage et/ou les ressources informatiques implémentées au dispositif client 112 n’ont pas besoin d’être adaptés pour de nombreux identifiants d’objets de fournisseurs différents et/ou de types de données d’identifiants d’objets de fournisseurs. Par ailleurs, l’objet d’intermédiation peut inclure à la fois des offres NDC et des recommandations Edifact (p. ex. les objets de fournisseurs à partir desquels l’objet d’intermédiation est généré peuvent être de formats différents) par exemple de différents systèmes de fournisseurs 104. Chacune des offres NDC et des recommandations Edifact peut être dans des formats différents et par ailleurs ces formats peuvent être particuliers à un système de fournisseur donné, comme des identifiants d’offres NDC associés et/ou des caractéristiques d’une recommandation Edifact. Lorsque de telles offres NDC et/ou recommandations Edifact sont fournies au dispositif client 112 dans des formats tels qu’ils ont été générés, le dispositif client 112 (p. ex. les services de voyage et/ou les ressources informatiques et/ou les ressources de traitement) peut être adapté à chaque format différent des offres NDC et/ou des recommandations Edifact qui peuvent être reçues au dispositif client 112. La fonctionnalité du serveur d’intermédiation 120 peut généralement parer à ce problème. Par ailleurs, dans certains exemples, le serveur d’intermédiation 120 peut combiner deux ou plusieurs objets de fournisseur en un objet d’intermédiation (p. ex. combiner deux ou plusieurs offres NDC, combiner deux ou plusieurs recommandations Edifact et/ou combiner au moins une offre NDC et au moins une recommandation Edifact) ; par ailleurs les deux ou plusieurs objets de fournisseur combinés en un objet d’intermédiation peuvent provenir d’un ou de plusieurs systèmes de fournisseurs 104. Dans ces exemples, un objet d’intermédiation peut être généré, et un identifiant d’objet d’intermédiation peut être généré pour l’objet d’intermédiation généré à partir de la combinaison des deux ou plusieurs objets de fournisseurs. Le répertoire 124 peut stocker des associations entre un ou plusieurs objets d’intermédiation et identifiants d’objets d’intermédiation en association à un ou plusieurs des objets de fournisseurs et des identifiants d’objets de fournisseurs des objets de fournisseurs combinés. L’attention se porte maintenant vers la FIG. 4 et la FIG. 5 qui illustrent un exemple du procédé 300. Chacune de la FIG. 4 et de la FIG 5 décrit le système 100, mais sans le réseau 116. Plutôt, la FIG. 4 et la FIG. 5 montrent des liens de communication entre les composants du système 100 qui sont représentés par des flèches à doubles pointes entre chaque ; ces liens de communication peuvent inclure le réseau 116. Sinon, la FIG. 4 et la FIG. 5 sont similaires à la FIG. 1 avec des composants similaires ayant des numéros similaires. L’attention étant dirigée d’abord vers la FIG. 4, le dispositif client 112 génère et transmet une requête 401 au serveur d’intermédiation 120. La requête 401 peut représenter une recherche pour des éléments fournis par le système de fournisseur 104, tels que des vols entre un lieu d’origine et un lieu de destination à une date particulière, et ainsi de suite. Dans un exemple de la présente, la requête 401 peut représenter une recherche pour des vols au départ de Toronto, Canada (p. ex. ayant un code aéroport « YYZ ») à destination de Nice, France (p. ex. ayant un code aéroport « NCE ») à la date du 31 juillet 2019. Le serveur d’intermédiation 120 reçoit la requête 401 et génère une requête 402 pour des objets de fournisseur qui représentent les éléments définis par la requête 401. La requête 402 peut être dans un même format que la requête 401, ou dans un format différent. Par exemple, la requête 402 peut être dans un format différent qui est particulier au système du fournisseur 104. L’attention est maintenant dirigée vers la FIG. 5 dans laquelle le système de fournisseur 104 répond à la requête 402 en transmettant un objet de fournisseur 501 au serveur d’intermédiation 120. L’objet de fournisseur 501 peut être un d’une pluralité d’objets de fournisseur transmis par le système du fournisseur 104, chacun représentant différents éléments disponibles (p. ex. des vols) qui correspondent à la recherche représentée par la requête 401. Ainsi qu’illustré, l’objet de fournisseur 501 inclut des données d’objet de fournisseur dans un format structuré qui inclut les données d’objet de fournisseur (représentant un vol) remplissant divers champs. Ainsi qu’illustré, les champs sont délimités par deux points (p. ex. « : ») bien que lorsque l’objet de fournisseur 501 comprend une offre NDC, les champs peuvent être délimités en utilisant des crochets (p. ex. «   ») ; cependant les champs peuvent être délimités d’une quelconque manière appropriée. Tel qu’illustré, l’objet de fournisseur 501 représente un vol (p. ex. un élément fourni par le système du fournisseur 104) de Toronto (p. ex. le champ « origine ») à Nice (p. ex. le champ « destination ») opéré par une compagnie aérienne dénommée « ACME » (p. ex. le champ « compagnie aérienne ») le 31 juillet 2019 (p. ex. le champ « date ») et avec un prix de «  (p. ex. le champ « prix »). L’objet de fournisseur 501 inclut par ailleurs un champ « IDObjetFournisseur » qui inclut un identifiant d’objet de fournisseur « aQ3 ». Alors que l’objet de fournisseur 501 est illustré avec certains champs et/dans un certain format, l’objet de fournisseur 501 peut inclure tous champs pertinents et/ou être dans un quelconque format approprié. Tel qu’illustré, l’objet de fournisseur 501 est stocké dans le répertoire 108 au système de fournisseur 104. On comprend par ailleurs que d’autres informations associées à l’élément représenté par l’objet de fournisseur 501 (qui peuvent inclure, mais ne sont pas limitées à commander et/ou à réserver et/ou à acheter le au moins un élément) peuvent survenir via l’identifiant d’objet de fournisseur « aQ3 ». En particulier, l’objet de fournisseur 501 peut comprendre une offre NDC et par conséquent l’identifiant d’objet de fournisseur « aQ3 » peut comprendre un identifiant spécifique de l’offre NDC générée par le système de fournisseur 104 qui identifie et/ou identifie de façon unique l’offre NDC auprès du système de fournisseur 104. Par conséquent, dans la FIG. 5, le serveur d’intermédiation 120 reçoit (p. ex. au bloc 302 du procédé 300) l’objet de fournisseur 501 et génère (au bloc 304 du procédé 300) un objet d’intermédiation 502 incluant les données d’objet d’intermédiation (décrit ci-dessous) et un identifiant d’objet d’intermédiation, qui identifie l’objet d’intermédiation 502, les données d’objet d’intermédiation étant remplies avec au moins un sous-ensemble des données d’objet de fournisseur de l’objet de fournisseur 501, basé sur un mappage 235-1 entre les données d’objet d’intermédiation (p. ex. un format et/une structure dont on voit le côté gauche du mappage 235-1) et les données d’objet de fournisseur (p. ex. un format et/ou une structure dont on voit le côté droit sur le mappage 235-1), l’objet d’intermédiation 502 omettant les données d’objet de fournisseur et l’identifiant d’objet de fournisseur dans une forme et/ou une structure d’origine. Alors que l’objet d’intermédiation 502 est illustré dans un certain format, l’objet d’intermédiation 502 peut être dans un format de langage de balisage extensible (XML). Par conséquent, le mappage 235-1 peut être pour des offres NDC générées par un système de fournisseur particulier 104 opérant selon l’échange de données NDC. Ainsi qu’illustré, un deuxième mappage 235-2 est stocké au serveur d’intermédiation 120 qui peut être pour des recommandations Edifact générées par un système de fournisseur particulier 104 opérant selon l’échange de données GDS. Tel qu’illustré, l’objet d’intermédiation 502 inclut des champs « IDintermédiation », « compagnie aérienne », « origine », « destination », « date » et « prix ». Le mappage illustré 235-1, mappe le champ « compagnie aérienne » de l’objet d’intermédiation 502 sur le champ « compagnie aérienne » de l’objet de fournisseur 501 ainsi que représenté de façon graphique par une flèche entre les deux (différente des flèches de liens de communication). Des mappages similaires d’autres champs de l’objet d’intermédiation 502 sur des champs correspondants de l’objet de fournisseur 501 sont illustrés, autres que les champs des identifiants d’objets respectifs. En particulier, les champs « date » et « prix » pour chacun des objets 501, 502 ont des positions différentes dans les objets 501, 502 ; par exemple dans l’objet d’intermédiation 502, les positions des champs « date » et « prix » sont inversées en comparaison à ceux de l’objet de fournisseur 501. Par ailleurs, le format du champ « prix » dans les objets 501, 502 est différent ; dans l’objet de fournisseur 501 un symbole de devise (p. ex. «€») est utilisé alors que dans l’objet d’intermédiation 502 un nom de devise (p. ex.« Euro ») est utilisé. Par conséquent, l’objet d’intermédiation 502 inclut des données d’objet de fournisseur de l’objet de fournisseur 501, mais dans un format et/ou une structure différente et omet par ailleurs l’identifiant d’objet de fournisseur. Bien qu’un tel exemple soit relativement simpliste on comprendra que les différences de format et/ou de structures entre les objets 501, 502 peuvent être beaucoup plus complexes. Par exemple, les dates, les horaires, les noms de compagnie aérienne, etc. peuvent être dans des formats différents et le mappage 235-1 peut inclure des données pour convertir les données d’objet de fournisseur dans un format commun de données d’objet d’intermédiation. Par ailleurs, ainsi qu’illustrés, les champs de l’objet d’intermédiation 502 sont remplis avec les données de fournisseur provenant des champs correspondants de l’objet de fournisseur 501, tels qu’identifiés via le mappage 235-1. Alors que les présents exemples sont décrits par rapport à toutes les données de fournisseur qui sont mappées sur l’objet d’intermédiation 502, dans d’autres exemples certaines des données de fournisseur peuvent être omises de l’objet d’intermédiation 502 (p. ex., les données de fournisseur peuvent être particulières à des services internes du système de fournisseur 104). Par ailleurs l’objet d’intermédiation 502 est rempli par un identifiant d’objet d’intermédiation « 8f5 » dans le champ « IDintermédiation » qui est fourni à la place de l’identifiant d’objet de fournisseur (p. ex. l’IDobjetfournisseur) « aQ3 ». Dans certains exemples qui seront décrits plus en détail ci-dessous, l’identifiant d’objet d’intermédiation « 8f5 » peut être généré en traitant les données d’objet de fournisseur et/ou l’identifiant d’objet de fournisseur ; par exemple l’identifiant d’objet d’intermédiation « 8f5 » peut être généré en cryptant une ou plusieurs des données d’objet de fournisseur et l’IDObjetFourniseur « aQ3 » (et/ou les données d’identifiant d’objet de fournisseur). Par conséquent, dans certains exemples l’identifiant d’objet d’intermédiation peut comprendre une version cryptée d’une portion de l’objet de fournisseur, ainsi que décrit ci-dessus. Ainsi qu’illustré, l’identifiant d’objet d’intermédiation « 8f5 » est stocké dans le répertoire 124 en association aux données d’identifiant d’objet de fournisseur « aQ3 », ainsi que représenté par une ligne pointillée entre les deux. Cependant, lorsque l’identifiant d’objet d’intermédiation « 8f5 » est généré en cryptant l’IDObjetFournisseur « aQ3 (et/ou les données d’identifiant d’objet de fournisseur) l’IDObjetFournisseur « aQ3 » (et/ou les données d’identifiant d’objet de fournisseur) peut ne pas être stocké dans le répertoire 124, car l’IDObjetFournisseur « aQ3 » (et/ou les données d’identifiant d’objet de fournisseur) peut être obtenu en décryptant l’identifiant d’objet d’intermédiation « 8f5 ». Ainsi qu’illustrés, les objets 501, 502 peuvent aussi être stockés dans le répertoire 124. Le serveur d’intermédiation 120 transmet (p. ex. au bloc 306 du procédé 300) l’objet d’intermédiation 502 au dispositif client 112 qui reçoit l’objet d’intermédiation 502 pour un traitement, et similaire. Bien que cela ne soit pas illustré, le dispositif client 112 peut demander d’autres informations associées à l’objet de fournisseur 501, telles qu’un prix finalisé et/ou des informations finalisées pour le vol et ainsi de suite, par exemple en transmettant une autre requête au serveur d’intermédiation 120 qui inclut l’identifiant d’objet d’intermédiation « 8f5 » tel qu’il a été extrait du champ « IDintermédiation ». Le serveur d’intermédiation 120 peut ensuite récupérer l’identifiant d’objet de fournisseur, et similaires, « aQ3 » à partir du répertoire basé sur l’association entre les identifiants d’objets (et/ou en décryptant l’identifiant d’objet d’intermédiation « 8f5 ») et il peut demander un prix finalisé et/ou des informations finalisées pour le vol, et ainsi de suite, au système de fournisseur 104 qui peut renvoyer les informations demandées, par exemple sous forme d’objet actualisé et/ou nouveau (qui peut avoir le même identifiant d’objet de fournisseur « aQ3 » cependant, dans l’échange de données NDC, l’objet de fournisseur actualisé et/ou nouveau généralement a un identifiant d’objet de fournisseur différent), et ainsi de suite ; le serveur d’intermédiation 120 peut à nouveau convertir l’objet de fournisseur actualisé en objet d’intermédiation actualisé comme décrit ci-dessus. Autrement, l’information demandée peut être échangée dans un quelconque format approprié en utilisant les identifiants d’objets, avec le serveur d’intermédiation 120 servant d’intermédiaire pour cet échange d’informations en utilisant les identifiants d’objets tels qu’ils sont stockés dans le répertoire 124. Une demande d’achat de l’élément représenté par l’objet de fournisseur 501 peut procéder d’une manière similaire. Ainsi qu’illustré, le serveur d’intermédiation 120 stocke un deuxième mappage 235-2 entre les données d’objet d’intermédiation (p. ex. un format et/une structure dont on voit le côté gauche du mappage 235-2) et les données d’objet de fournisseur qui peuvent être pour des recommandations Edifact (p. ex. un format et/ou une structure dont on voit le côté droit sur le mappage 235-2). Le mappage illustré 235-2 montre que les recommandations Edifact ont un format et/ou une structure qui diffère des offres NDC (p. ex. les mappages 235-1, 235-2 ont des formats et/ou des structures qui diffèrent). Par exemple, les champs de la recommandation Edifact peuvent être dans un format différent de ceux d’une offre NDC et ne sont pas strictement délimités ; plutôt, les champs sont indiqués par un ordre textuel des champs, ainsi que représentés par le format d’une recommandation Edifact montrée du côté droit du mappage 235-2 qui est sous forme de boites plutôt que la liste du mappage 235-1 qui est délimité de façon ordonnée/par caractère. Un autre exemple d’une recommandation Edifact est décrit ci-dessous par référence à la FIG. 6. Par ailleurs, le mappage illustré 235-2 montre que des offres Edifact n’incluent pas un identifiant d’objet de fournisseur explicite. Le mappage illustré 235-2, mappe le champ « compagnie aérienne » d’un objet d’intermédiation sur un champ « code de compagnie aérienne » d’une recommandation Edifact ainsi que représenté graphiquement par une flèche entre les deux. De façon similaire, les mappages des autres champs d’objets d’intermédiation sur des champs correspondants de recommandations Edifact sont illustrés. Ainsi qu’illustrés, les champs de la recommandation Edifact ne peuvent pas tous être mappés sur les données d’objet d’intermédiation ; par exemple un code RBD (p. ex. un code indicateur d’enregistrement de réservation) n’est pas mappé et un type de tarif ne l’est pas non plus. L’attention se porte maintenant vers la FIG. 6 qui illustre un exemple du procédé 300. Cependant, dans la FIG. 6, le serveur d’intermédiation 120 est en communication avec deux systèmes de fournisseurs 104-1, 104-2. Le système de fournisseur 104-1 peut être le même système de fournisseur 104 illustré dans la FIG. 1, la FIG. 4 et la FIG. 5, qui fournit des objets de fournisseur dans un format NDC ; cependant, ainsi que décrit ci-dessous, le système de fournisseur 104-1 peut fournir des objets de fournisseur dans un format Edifact (p. ex. GDS). Dans la FIG. 6, le dispositif client 112 transmet une requête 601 au serveur d’intermédiation 120 qui peut représenter une recherche pour le pour les mêmes éléments représentés par la requête 401. Le serveur d’intermédiation 120 reçoit la requête 601 et en réponse génère et transmet les requêtes respectives 602-1, 602-2 pour les éléments aux systèmes de fournisseurs 104-1, 104-2, les requêtes respectives 602-1, 602-2 étant formatées pour le système de fournisseur particulier 104 auquel les requêtes 602-1, 602-2 sont transmises. Ainsi qu’illustré, le système du fournisseur 104-1 transmet un objet de fournisseur 611-1 qui a un même format/structure et données d’objets de fournisseur que ceux de l’objet de fournisseur 501 (p. ex. un format NDC). Cependant, le système de fournisseur 104-2 transmet un objet de fournisseur 611-2 ayant un format différent (p. ex. un Edifact [p. ex. GDS]) que l’objet de fournisseur 611-1. Par exemple, les champs pour l’origine, la destination, la compagnie aérienne, les horaires et sont dans des formats différents. Par ailleurs, les objets de fournisseurs 611-1, 611-2 sont structurés différemment ; par exemple l’objet de fournisseur 611-1 est dans une forme ordonnée, une liste délimitée par des caractères, avec des identifiants de champ nommant les champs ; cependant l’objet de fournisseur 611-2 est dans un format texte avec des identifiants de champs pour certains champs et pas pour d’autres, et un champ étant identifiable par un ordre textuel des champs (p. ex. le premier texte est un numéro de vol, le second texte [séparé du premier texte par un espace] est une origine, etc.) Cependant, il faut comprendre que les objets de fournisseur 611-1, 611-2 illustrés sont uniquement des exemples ; par exemple, les offres NDC (p. ex. l’objet de fournisseur 611-1) peuvent comprendre un format XML (p. ex. un champ d’identifiant peut être délimité par des crochets, tels que «   », et similaires). Ainsi qu’illustré, un identifiant d’une compagnie aérienne de l’objet de fournisseur 611-1 est dans un champ « compagnie aérienne » et est représenté par un nom de la compagnie aérienne « ACME ». Cependant un identifiant (p. ex. « FL » d’une compagnie aérienne de l’objet de fournisseur 611-2 est en première position de texte et est incorporé dans un numéro de vol « FL123 ». De façon similaire, le prix de l’objet de fournisseur 611-1 est représenté dans un format ou le type de devise (p. ex. Euros) est présenté dans un format symbolique (« € ») alors que le prix dans l’objet de fournisseur 611-2 est représenté dans un format texte (p. ex. « Euro »). Quoi qu’il en soit, chacun des objets de fournisseurs 611-1, 611-2 représente un vol respectif différent de Toronto à Nice le 31 juillet 2019, fournis par des compagnies aériennes différentes. Ainsi que décrit ci-dessus, le serveur d’intermédiation 120 stocke les mappages 235-1, 235-2 entre chacun des objets de fournisseurs 611-1, 611-2 et les objets d’intermédiation 612-1, 612-2. Par conséquent, le serveur d’intermédiation 120 génère des objets d’intermédiation correspondants respectifs 612-1, 612-2 ayant un même format et étant identifiés en utilisant des identifiants d’objets d’intermédiation respectifs différents (p. ex. « 8f5 » identifie l’objet d’intermédiation 612-1 et « 4g7 » identifie l’objet d’intermédiation 612-2), mais ayant un format similaire (p. ex. chiffre-lettre-chiffre). La génération des identifiants d’objets d’intermédiation peut survenir d’une quelconque manière appropriée et est décrite de façon plus détaillée ci-dessous. Par conséquent, le serveur d’intermédiation 120 convertit les données d’objet de fournisseurs respectifs 611-1, 611-2 en formats respectifs communs des données d’objets d’intermédiation (p. ex. un identifiant de compagnie aérienne de l’objet de fournisseur 611-2 est converti en nom d’aéroport [« FL » est converti en « Fliright »] et un type de devise de l’objet de fournisseur 611-1 est converti en un nom de devise [p. ex. le symbole de l’Euro € est converti au mot « Euro »], et ainsi de suite). Les objets de fournisseurs 611-1, 611-2 sont transmis au dispositif client 112. Par ailleurs les associations entre les identifiants d’objets d’intermédiation respectifs et les diverses données des objets de fournisseurs 611 sont stockées dans le répertoire 124 (p. ex. l’identifiant d’objet d’intermédiation « 8f5 » est stocké dans le répertoire 124 en association avec les données d’identifiant d’objet de fournisseur « aQ3 » et l’identifiant d’objet d’intermédiation « 4f7 » est stocké dans le répertoire 124 en association avec l’objet de fournisseur 611-2). [close bracket missing in source] Bien que ce ne soit pas illustré, les objets de fournisseur 611-1 et les objets d’intermédiation 612-1, 612-2 peuvent aussi être stockés dans le répertoire 124 (p. ex. de façon similaire à ce qui est illustré dans la FIG. 5 par rapport aux objets 501, 502). Bien que les objets d’intermédiation 612 décrits précédemment soient illustrés comme ayant un format donné pour un vol aller simple, les objets d’intermédiation 612 peuvent avoir un quelconque format approprié et/ou avoir une quelconque structure appropriée ; cependant le format des objets intermédiation 612 est un format commun. L’attention se porte maintenant vers la FIG. 7 qui illustre une structure exemplaire 700 d’un objet d’intermédiation exemplaire 701. L’objet d’intermédiation 701 peut représenter un vol retour de Toronto à Nice et peut être généré à partir d’un objet de fournisseur qui a été généré en réponse à une requête pour ce vol de retour. Bien que ce ne soit pas illustré, l’objet d’intermédiation 701 inclut un identifiant d’objet intermédiation ainsi que décrit ci-dessus. Par ailleurs, alors que la structure 700 est illustrée graphiquement, on comprendra que l’objet d’intermédiation exemplaire 701 peut être dans un format XML. En particulier, l’objet d’intermédiation 701 peut comprendre un ou plusieurs éléments d’offre d’intermédiation 702 qui peuvent comprendre des éléments respectifs de services d’intermédiation 703. Les éléments de services d’intermédiation 703 peuvent chacun représenter un élément individuel offert par un système de fournisseur 104. Tels qu’illustrés, les éléments de services d’intermédiation 703 peuvent représenter un vol aller simple de Toronto à Nice (p. ex. YYZ-NCE) combiné à un vol aller simple de Nice à Toronto (NCE-YYZ) pour un total de $ 980 et les éléments de services d’intermédiation 703 représentant le vol peuvent être obligatoires. Cependant les éléments de services d’intermédiation 703 peuvent par ailleurs représenter : une offre pour un accès au salon à Toronto combinée à une offre pour un accès au salon à Nice, pour un coût total de $110 ; et une offre pour un siège premium sur le vol Toronto Nice combinée à une offre pour un siège premium sur le vol Nice Toronto, pour un coût de $ 250, et ; ces services peuvent être optionnels. Par exemple, les services optionnels peuvent représenter des services qui peuvent être achetés en option lors de l’achat des services obligatoires. Chacun des éléments de service d’intermédiation 703 représente par conséquent un élément respectif différent (p. ex. un service) fourni par un système de fournisseur 104. Les éléments de services d’intermédiation 703 peuvent être combinés en éléments d’offre d’intermédiation 702. Par exemple ainsi qu’illustrés, les vols aller simple sont combinés en un élément d’offre d’intermédiation obligatoire (p. ex. un vol retour de Toronto à Nice) pour $ 980 ; dans d’autres exemples, les vols aller simple peuvent être offerts séparément à des prix respectifs. De façon similaire, les accès au salon à Toronto et à Nice peuvent être combinés en un élément d’offre optionnel pour $ 110 ; dans d’autres exemples, les accès au salon à Toronto et à Nice peuvent être offerts séparément à des prix respectifs. De façon similaire, le siège premium de Toronto à Nice, et le siège premium de Nice à Toronto peuvent être combinés en un élément d’offre optionnel pour $250 ; dans d’autres exemples, les sièges premium pour chaque aller simple peuvent être offerts séparément à des prix respectifs. Par conséquent, si une requête pour acheter des éléments représentés par l’objet d’intermédiation 701 est reçue, la requête peut inclure une requête pour l’achat d’éléments obligatoires d’offre groupés 702 et optionnellement une requête pour l’achat d’un ou de plusieurs éléments optionnels d’offre groupés 702. En particulier, divers éléments de service d’intermédiation individuels 703 ne peuvent pas être achetés individuellement. La structure exemplaire 700 de l’objet d’intermédiation exemplaire 701 peut être particulière pour des objets de fournisseur basés sur la NDC à partir desquels l’objet d’intermédiation exemplaire 701 est généré, car les objets de fournisseur basés sur la NDC correspondent à des éléments d’offre d’intermédiation 702 et les services d’offres de fournisseurs correspondent à des éléments de service d’intermédiation 703. Cependant, lorsqu’un objet de fournisseur à partir duquel un objet d’intermédiation est généré a un format de recommandation Edifact, l’objet d’intermédiation peut ne pas inclure une couche éléments d’offre d’intermédiation, car les recommandations Edifact n’incluent pas d’éléments d’offre de fournisseur. Dans le monde réel des environnements de l’industrie du voyage, des millions à des milliards de requêtes par jour peuvent être générées représentant des recherches pour des éléments fournis par des systèmes de fournisseurs 104. Pour chaque requête/recherche, des centaines de réponses peuvent être générées ; par conséquent, des dizaines à des centaines de milliards d’objets d’intermédiation peuvent être générés par le serveur d’intermédiation 120 chaque jour avec seulement une petite fraction de ces objets intermédiation qui aboutissent à une commande pour un élément (p. ex. un vol) fourni par un système de fournisseur 104. Dans des exemples décrits précédemment, les identifiants d’objets d’intermédiation peuvent être stockés par le serveur d’intermédiation 120 ; cependant, avec potentiellement des centaines de milliards d’objets intermédiation chaque jour, stockant des informations associées à chacun, ainsi que décrit par rapport à la FIG. 6 pouvant placer une charge de stockage excessive sur le serveur d’intermédiation 120. L’attention est par conséquent maintenant dirigée vers la FIG. 8 qui illustre un organigramme représentatif d’un procédé 800 pour l’intermédiation entre un système de fournisseur et des identifiants d’objets d’intermédiation d’un dispositif client qui ne sont pas stockés par le serveur d’intermédiation. Les opérations du procédé 800 de la FIG. 8 correspondent à des instructions lisibles par machine qui sont exécutées par le serveur d’intermédiation 120, et spécifiquement le contrôleur 220 du serveur d’intermédiation 120. Dans l’exemple illustré, les instructions représentées par les blocs de la FIG. 8 sont stockées dans la mémoire de 222 par exemple comme l’application 223 et/ou un module de l’application 223. Le procédé 800 de la FIG. 8 est une manière possible de configurer le contrôleur 220 et/ou le serveur d’intermédiation 120 et/ou le système 100. En effet, le procédé 800 peut représenter un autre mode du serveur d’intermédiation 120 différent du mode représenté par le procédé 300. Par ailleurs la discussion qui suit du procédé 800 de la FIG. 8 conduira à une compréhension plus avancée du système 100 et de ses divers composants. Le procédé 800 de la FIG. 8 n’a pas besoin d’être mis en œuvre dans la séquence exacte telle qu’elle est montrée et de même les divers blocs peuvent être mis en œuvre en parallèle plutôt qu’en séquence. Par conséquent, les éléments du procédé 800 sont désignés dans la présente comme étant des « blocs » plutôt que des « étapes ». Le procédé 800 de la FIG. 8 peut également être implémenté sur des variations du système 100 de la FIG. 1. Au bloc 802, le contrôleur 220 et/ou le serveur d’intermédiation 120 reçoivent (p. ex. via l’interface de communication 228), d’au moins un système de fournisseur 104, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par au moins un système de fournisseur 104. Le bloc 802 est généralement similaire au bloc 302 du procédé 300. Au bloc 804, le contrôleur 220 et/ou, le serveur d’intermédiation 120, génère un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation comprenant des données d’objets d’intermédiation remplies avec au moins un sous-ensemble de données d’objets de fournisseur, l’objet d’intermédiation omettant les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine. Le bloc 804 est généralement similaire aux aspects d’objets d’intermédiation du bloc 304 du procédé 300 et peut être basé sur les mappages 235, et similaires, comme décrit précédemment. La génération d’un identifiant d’objet intermédiaire dans ce mode va maintenant être décrite. Au bloc 806, le contrôleur 220 et/ou le serveur d’intermédiation 120 génèrent un identifiant intermédiaire à partir d’au moins une portion des données d’objet de fournisseur arrangées dans un format prédéterminé. Par conséquent, l’identifiant intermédiaire inclut des données qui peuvent permettre au serveur d’intermédiation 120 d’identifier, auprès du système de fournisseur 104, l’objet de fournisseur reçu au bloc 802. La portion des données d’objets de fournisseurs qui forme l’identifiant intermédiaire peut être la même, ou être différente du sous-ensemble de données d’objet de fournisseur utilisé pour générer les données d’objets d’intermédiation au bloc 804. En général, la portion des données d’objet de fournisseur qui est utilisée pour générer l’identifiant intermédiaire permet généralement au serveur d’intermédiation 120 d’identifier l’objet de fournisseur ; par exemple, lorsque les données d’objets de fournisseur incluent un identifiant d’objet de fournisseur (comme avec une offre NDC), l’identifiant intermédiaire inclut généralement au moins l’identifiant d’objet de fournisseur. Dans certains exemples, l’identifiant intermédiaire peut inclure toutes les données d’objet de fournisseur. Dans certains exemples, le contrôleur 220 et/ou le serveur d’intermédiation 120 peut générer un identifiant intermédiaire à partir d’au moins une portion des données d’objet de fournisseur arrangées dans un format prédéterminé en : ayant recours à un ou plusieurs de la concaténation, l’assemblage, le groupement et l’organisation de ladite au moins la portion des données d’objet de fournisseur selon le format prédéterminé. En particulier, les données d’objets de fournisseur peuvent être concaténées ensemble dans un ordre particulier défini par le format prédéterminé, ainsi que décrit ci-dessous de façon plus détaillée par rapport à la FIG. 10 10. Par ailleurs, plus d’un format prédéterminé peut être utilisé pour générer un identifiant intermédiaire. Par exemple, le format prédéterminé peut être dépendant d’un type d’objet de fournisseur ; en particulier, un format prédéterminé peut être utilisé pour les offres NDC et un autre format peut être utilisé pour les recommandations Edifact. En effet un format prédéterminé différent peut être utilisé pour différents types d’offres NDC et/ou différents types de recommandations Edifact et/ou différents systèmes de fournisseurs 104. Pour indiquer quel format prédéterminé est utilisé pour générer un identifiant intermédiaire, le contrôleur 220 et/ou le serveur d’intermédiation 120 peut générer l’identifiant intermédiaire à partir d’au moins la portion des données d’objets de fournisseur arrangée dans un format prédéterminé en : incluant, dans l’identifiant intermédiaire, un identifiant de format prédéterminé avec la portion des données d’objet de fournisseur arrangée dans le format prédéterminé. L’identifiant de format prédéterminé peut être sous forme de texte alphanumérique associé un format prédéterminé respectif. En effet l’application 223 peut stocker à la fois les identifiants de format prédéterminé et les formats prédéterminés et/ou la mémoire 222 peut stocker séparément les identifiants de format prédéterminé et les formats prédéterminés, par exemple en association les uns avec les autres. Au bloc 808, le contrôleur 220 et/ou le serveur d’intermédiation 120, génèrent un identifiant d’objet d’intermédiation en cryptant l’identifiant intermédiaire. Par exemple, le cryptage peut se faire d’une quelconque manière appropriée et on comprendra que le serveur d’intermédiation 120 a été provisionné avec les clés cryptographiques appropriées (p. ex. dans la mémoire 222) et des algorithmes cryptographiques pour crypter et décrypter, l’identifiant intermédiaire. Ces clés cryptographiques peuvent être symétriques ou asymétriques. Par ailleurs, différentes clés cryptographiques peuvent être utilisées pour des objets de fournisseurs différents et/ou pour des systèmes de fournisseurs différents 104 (p. ex. le serveur d’intermédiation 120 peut être provisionné avec des clés cryptographiques respectives pour les offres NDC, les recommandations Edifact et/ou diverses clés cryptographiques respectives pour différents systèmes de fournisseurs 104). Dans certains exemples, le contrôleur 220 et/ ou le serveur d’intermédiation 120 peuvent générer l’identifiant d’objet d’intermédiation en incluant une version cryptée avec l’identifiant intermédiaire après le cryptage. Par exemple, un identifiant alphanumérique qui identifie généralement au serveur d’intermédiation 120 les clés cryptographiques et où l’algorithme cryptographique utilisé pour crypter (et/ou décrypter) l’identifiant intermédiaire crypté, peut être concaténé, et similaires, à l’identifiant intermédiaire crypté. Cependant, un tel identifiant de version de cryptage n’indique pas explicitement les clés cryptographiques et/ou l’algorithme cryptographique utilisé pour crypter (et/ou décrypter) l’identifiant intermédiaire crypté ; plutôt, un tel identifiant de version de cryptage peut être stocké dans la mémoire 222 en association avec les clés cryptographiques et/ou l’algorithme cryptographique utilisé pour crypter (et/ou décrypter) l’identifiant intermédiaire crypté ; Reformulé différemment, l’identifiant de version de cryptage ne permet pas au dispositif client 112 de décrypter l’identifiant intermédiaire crypté. Par ailleurs, l’identifiant d’objet d’intermédiation peut être utilisé pour remplir un champ de l’objet d’intermédiation de sorte que l’objet d’intermédiation comprenne l’identifiant d’objet intermédiation comme cela est décrit ci-dessous par rapport à la FIG. 11. Au bloc 810, le contrôleur 220 et/ou le serveur d’intermédiation 120, fournit (via l’interface de communication 228) l’objet d’intermédiation avec l’identifiant d’objet d’intermédiation à un dispositif client 112 qui a demandé le au moins un élément, sans stocker l’objet d’intermédiation et l’identifiant d’objet d’intermédiation. Le bloc 810 est généralement similaire au bloc 306 du procédé 300, cependant l’objet d’intermédiation et l’identifiant d’objet d’intermédiation ne sont pas stockés ; de même ni l’objet de fournisseur ni un quelconque identifiant d’objet de fournisseurs ne sont stockés. Par conséquent, lorsque le dispositif client 112 reçoit l’objet d’intermédiation et demande plus tard d’autres informations associées à le au moins un élément fourni par le système de fournisseur, le dispositif client 112 peut transmettre l’identifiant d’objet d’intermédiation (et en option l’objet d’intermédiation) au serveur d’intermédiation 120 qui peut ensuite décrypter l’identifiant d’objet d’intermédiation pour obtenir l’identifiant intermédiaire et la portion des données d’objet de fournisseur utilisée pour générer l’identifiant intermédiaire. La portion des données d’objet de fournisseur peut être utilisée par le serveur d’intermédiation 120 pour demander les autres informations du système de fournisseur. Reformulé différemment, le contrôleur 220 et/ou le serveur d’intermédiation 120 peuvent par ailleurs être configurés pour : recevoir (p. ex. via l’interface de communication 228), en provenance du dispositif client 112, en réponse à la fourniture de l’objet d’intermédiation, l’identifiant d’objet d’intermédiation avec une requête pour d’autres informations associées à le au moins un élément (p. ex. représenté par l’objet de fournisseur reçu au bloc 802) ; décrypter l’identifiant d’objet d’intermédiation pour obtenir ladite au moins la portion des données d’objet de fournisseur ; et demander les autres informations du système du fournisseur 104 en utilisant ladite au moins la portion des données d’objet de fournisseur telle qu’elle est décryptée. L’attention se porte maintenant à la FIG. 9, la FIG. 10, la FIG. 11 et la FIG. 12 qui illustrent un exemple du procédé 800, lorsqu’il est utilisé pour générer un objet d’intermédiation et un identifiant d’objet d’intermédiation basé sur un objet de fournisseur qui comprend une recommandation Edifact. L’attention est d’abord dirigée vers la FIG. 9, le serveur d’intermédiation 120 peut recevoir, du dispositif client 112, une requête 901 pour au moins un élément fourni par le système de fournisseur 104 et le serveur d’intermédiation 120 peut transmettre au système de fournisseur 104 une requête 902 pour des objets de fournisseur représentant les éléments définis par la requête 901. Les requêtes 901, 902 sont par conséquent respectivement similaires aux requêtes 401, 402 de la FIG. 4. Ainsi qu’illustré, le serveur d’intermédiation 120 reçoit (p. ex. au bloc 802 du procédé 800), en provenance du système de fournisseur 104, en réponse à la transmission de la requête 902, un objet de fournisseur 911. Tel qu’illustré, l’objet de fournisseur 911 est similaire à l’objet de fournisseur 611-2 et par conséquent l’objet de fournisseurs 911 peut comprendre une recommandation Edifact. Tel qu’illustré, le serveur d’intermédiation 120 stocke par ailleurs un ou plusieurs formats prédéterminés 935 pour générer un identifiant intermédiaire et un identifiant d’objet d’intermédiation comme cela sera décrit maintenant. Tel qu’illustré, l’objet de fournisseur 911 est stocké dans le répertoire 108 du système de fournisseur 104. L’attention se porte maintenant vers la FIG. 10 qui illustre le serveur d’intermédiation 120 générant un identifiant d’objet d’intermédiation conformément au procédé 800. Bien que la génération d’un objet d’intermédiation ne soit pas décrite en détail dans cet exemple, on comprendra que le serveur d’intermédiation 120 génère (p. ex. au bloc 804 du procédé 800) un objet d’intermédiation à partir de l’objet de fournisseur 911 ainsi que cela a été décrit par rapport à la FIG. 6. Tel qu’illustré dans la FIG. 10, le serveur d’intermédiation 120 génère (p. ex. au bloc 806 du procédé 800) un identifiant intermédiaire 1011 à partir d’au moins une portion des données d’objets de fournisseur de l’objet de fournisseur 911 arrangées dans un format prédéterminé 935 par exemple un format prédéterminé pour une recommandation Edifact. En effet, le format prédéterminé 935 peut comprendre un mappage entre les données d’objet de fournisseur 911 et les positions du texte de l’identifiant intermédiaire 1011. Par exemple, ainsi qu’illustré, le format prédéterminé 935 indique que l’identifiant intermédiaire 1011 est rempli en incluant un identifiant de format prédéterminé (p. ex. « 01 ») en première position de texte et un identifiant de type de contenu (p. ex. « E » en deuxième position de texte et la concaténation d’au moins une portion des données d’objets de fournisseur de l’objet de fournisseur 911 à l’identifiant de format. Tel qu’illustré, l’identifiant intermédiaire 1011 comprend, dans l’ordre : — un identifiant de format qui indique lequel de la pluralité des formats prédéterminés 935 a été sélectionné pour générer l’identifiant intermédiaire 1011. – un type de contenu de l’objet de fournisseur 911 ; ainsi qu’illustré, le type de contenu (« E ») indique que l’objet de fournisseur 911 comprend une recommandation Edifact, bien que d’autres types de contenu puissent être indiqués en utilisant un autre texte alphanumérique (p. ex. E = Edifact, L = Bas prix, H = Hôtel, N = Offre NDC M = Combinaison NDC/Edifact, etc.). – Un code de compagnie aérienne, un numéro de vol et un RBD (p. ex. « FL123Y ») à partir des données d’objet de fournisseur de l’objet de fournisseur 911. – Une origine (p. ex. «YYZ») à partir des données d’objet de fournisseur de l’objet de fournisseur 911. – Une destination (p. ex. « NCE ») à partir des données d’objet de fournisseur de l’objet de fournisseur 911. – Un nombre de personnes et un code de type de passager (PTC) (p. ex. « 1ADT »=1 Adulte) à partir des données d’objet de fournisseur de l’objet de fournisseur 911. – Un séparateur optionnel (p. ex. « – » qui n’est pas présent dans les données d’objet de fournisseur de l’objet de fournisseur 911). – Un type de tarif (p. ex. « YECOBASIC ») à partir des données d’objet de fournisseur de l’objet de fournisseur 911. – Un autre séparateur optionnel (p. ex. “-“ qui n’est pas présent dans les données d’objet de fournisseur de l’objet de fournisseur 911). – Un prix (p. ex. « 200 EUR ») à partir des données d’objet de fournisseur de l’objet de fournisseur 911. Cependant, bien qu’un format prédéterminé spécifique 935 soit illustré, tout format prédéterminé approprié 935 est dans le champ de la présente spécification. Par exemple, les données d’objet de fournisseur illustrées, l’identifiant de format prédéterminé et/ou le type de contenu peuvent être arrangés d’une quelconque manière appropriée et/ou dans un quelconque ordre approprié incluant, sans s’y limiter, en intercalant du texte de champs différents de l’objet de fournisseur 911. Par ailleurs, alors que le format prédéterminé spécifique 935 indique la concaténation des données d’objet de fournisseur, un format prédéterminé 935 peut indiquer un quelconque assemblage, groupement et organisation appropriés des données d’objet de fournisseurs. Tel qu’illustré, le serveur d’intermédiation 120 génère (p. ex. au bloc 808 du procédé 800) un identifiant d’objet d’intermédiation 1021 en cryptant l’identifiant intermédiaire 1011 en utilisant une quelconque clé cryptographique et des algorithmes cryptographiques pertinents. Le serveur d’intermédiation 120 ajoute par ailleurs un identifiant de version de cryptage (p. ex. « 01 ») à l’identifiant intermédiaire crypté (p. ex. ^goisadgjap##@$ % adfgAG2a*) pour indiquer quelle clé cryptographique et quels algorithmes cryptographiques ont été utilisés pour crypter l’identifiant intermédiaire 1011. L’attention se porte maintenant vers la FIG. 11 qui illustre le serveur d’intermédiation 120 fournissant (p. ex. au bloc 810 du procédé 800) un objet d’intermédiation 1112 (p. ex. tel que généré au bloc 804) au dispositif client 112 en réponse à la réception de la requête 901. Tel qu’illustré, l’objet d’intermédiation 1112 est similaire à l’objet d’intermédiation 612-2, mais inclut l’identifiant d’objet d’intermédiation 1021. En particulier, ni l’objet d’intermédiation 1102, ni l’identifiant d’objet d’intermédiation 1021, ou l’objet de fournisseur 911 ne sont stockés dans le répertoire 124. L’attention est maintenant dirigée vers la FIG. 12 qui décrit le serveur d’intermédiation 120 recevant en provenance du dispositif client 112 une requête 1201 pour d’autres informations associées à le au moins un élément représenté par l’objet de fournisseur 911 et/ou l’objet d’intermédiation 1112. Formulé d’une autre façon, un utilisateur du dispositif client 112 peut avoir passé en revue les informations de l’objet d’intermédiation 1112 et avoir actionné le dispositif client 112 pour générer la requête 1201, par exemple pour demander un prix final (p. ex. 200 euros peut être un prix estimé et/ou un prix publié) et/ou des informations finalisées pour l’élément (p. ex. telles qu’un horaire, etc., pour un vol) représenté par l’objet de fournisseur 911 et/ou l’objet d’intermédiation 1112 et/ou pour commander (et/ou réserver et/ou acheter) l’élément. Bien que la requête 1201 puisse inclure d’autres informations (p. ex. de l’objet d’intermédiation 1112 et/ou des indicateurs indiquant quelle autre information est demandée), telle qu’elle est illustrée la requête 1201 inclut l’identifiant d’objet d’intermédiation 1021. Tel qu’illustré, bien que le serveur d’intermédiation 120 n’ait stocké ni l’objet d’intermédiation 1112, ni l’identifiant d’objet intermédiation 1021, ni l’objet de fournisseur 911, le serveur d’intermédiation 120 peut obtenir les informations incorporées dans l’identifiant d’objet intermédiation 1021 en décryptant l’identifiant d’objet d’intermédiation 1021 en utilisant par exemple des clés cryptographiques et/ou un algorithme cryptographique indiqué par l’identifiant de version de cryptage (p. ex. « 01 ») de l’identifiant d’objet d’intermédiation 1021. En effet, à partir du format prédéterminé 935 indiqué par l’identifiant de format des informations incorporées dans l’identifiant d’objet d’intermédiation 1021, le serveur d’intermédiation 120 peut obtenir et/ou reconstruire la portion des données d’objet de fournisseur de l’objet de fournisseur 911 ; par exemple, tel qu’illustré, le serveur d’intermédiation 120 génère au moins un objet de fournisseur reconstruit partiellement 1211 (p. ex. qui est, tel qu’illustré, similaire à l’objet de fournisseur 911). Le serveur d’intermédiation 120 peut ensuite transmettre une requête 1212 pour les autres informations demandées par le dispositif client 112 au système du fournisseur 104 en utilisant, par exemple, au moins une portion de l’objet de fournisseur reconstruit 1211 dans la requête. Bien que le procédé 800 ait été décrit par rapport à une recommandation Edifact et un format prédéterminé 935, d’autres formats prédéterminés peuvent donc être utilisés pour d’autres types d’objets de fournisseur. Par exemple, l’attention est maintenant dirigée vers la FIG. 13 qui illustre un format prédéterminé 935N pour générer un identifiant intermédiaire basé sur au moins une portion d’un objet de fournisseur qui comprend une offre NDC. Par exemple, le format prédéterminé 935N comprend un identifiant de format prédéterminé (p. ex. « 02 » indicatif de la structure du format prédéterminé 935N, similaire à un identifiant de format décrit par rapport à la FIG. 10), un type de contenu (p. ex. « N » indiquant que le contenu d’un identifiant intermédiaire généré à partir du format prédéterminé 935N est pour une offre NDC), un identifiant d’offre (p. ex. un identifiant d’offre NDC tel qu’une IDOffreFournisseur) et un identifiant de corrélations (p. ex. un identifiant de transaction associé à un utilisateur du dispositif client 112). Alors que d’autres champs d’une offre NDC ne sont pas inclus dans le format prédéterminé 935N illustré, dans d’autres exemples des champs tels qu’un prix, un code de compagnie aérienne, une origine, une destination, etc. peuvent être inclus dans le format prédéterminé 935N. Dans l’exemple illustré, un identifiant d’offre incorporé dans un identifiant intermédiaire généré à partir du format prédéterminé 935N peut être utilisé pour identifier un objet de fournisseur associé à un système de fournisseur 104. Dans cette spécification, les éléments peuvent être décrits comme étant « configuré pour » mettre en œuvre une ou plusieurs fonctions ou comme étant « configuré 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 actionnable 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 du langage « au moins un... » et « un ou plusieurs... » Les termes « environ », « substantiellement », « essentiellement », « approximativement », et 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écrits dans la présente 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 [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, la ROM, 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. On comprendra encore par ailleurs que le code de programme lisible par ordinateur et/ou le support utilisable par ordinateur peuvent comprendre un code de programme lisible par ordinateur non transitoire et/ou un support utilisable par ordinateur non transitoire. Autrement, le code de programme lisible par ordinateur pourrait être stocké à distance, mais être transmissible à ces composants via un modem ou similaire 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 similaire système de transmission) ou une combinaison de ceux-ci. Un procédé pour l’intermédiation entre un système de fournisseur et un dispositif client, le procédé comprenant : la réception, à un serveur d’intermédiation, d’au moins un système de fournisseur, d’au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; la génération, au serveur d’intermédiation, d’un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation, les données d’objet d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objet de fournisseur sur la base d’un mappage entre les données d’objet d’intermédiation et les données d’objet de fournisseur, fournissant ainsi une traduction des objets du fournisseur dans un format d'intermédiation commun accessible par des ressources de calcul mises en œuvre sur le dispositif client sans qu'il soit nécessaire d'adapter les ressources de calcul du dispositif client à des données spécifiques de l'objet du fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et tout identifiant d’objet de fournisseur dans une forme d’origine ; et fournissant, par le serveur d’intermédiation, l’objet d’intermédiation au dispositif client qui a demandé le au moins un élément fourni par au moins un système de fournisseur, l’objet d’intermédiation étant fourni à la place dudit au moins un objet de fournisseur. Le procédé de la revendication 1, comprenant par ailleurs : le stockage, dans au moins une ou plusieurs mémoires, d’un ou de plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation en association avec un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur. Le procédé de l’une quelconque des revendications 1 à la revendication 2, comprenant par ailleurs : la réception, au serveur d’intermédiation, d’une pluralité d’objets de fournisseur, dans lequel les données d’objet d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objet de fournisseur de la pluralité des objets de fournisseur sur la base d’un ou de plusieurs mappages entre les données d’objet d’intermédiation et les données d’objet de fournisseur respectif, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur respectif, incluant un quelconque des identifiants d’objets de fournisseurs respectifs, dans une forme d’origine respective. Le procédé de l’une quelconque des revendications 1 à la revendication 3, comprenant par ailleurs : la réception au serveur d’intermédiation, en provenance du dispositif client, d’une requête incluant l’identifiant d’objet d’intermédiation ; et la requête, en provenance dudit au moins un système de fournisseur, d’informations supplémentaires associées audit au moins un élément sur la base d’un ou de plusieurs de : au moins un de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation stocké, dans au moins une ou plusieurs mémoires, en association à un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur ; et une version cryptée d’une portion de l'au moins un objet de fournisseur inclus à l’objet d’intermédiation. Le procédé de l’une quelconque de la revendication 1 a la revendication 4 dans lequel le au moins un objet de fournisseur comprend un ou plusieurs d’un élément d’offre de fournisseur et d’un élément de service de fournisseur représentant une pluralité d’éléments fournis par le au moins un système de fournisseur, et l’objet d’intermédiation comprend un ou plusieurs éléments d’offre d’intermédiation et un élément de service d’intermédiation correspondant respectivement à un ou plusieurs des éléments d’offre de fournisseur et des éléments de service de fournisseur. Un serveur pour l’intermédiation entre un système de fournisseur et un dispositif client, le serveur comprenant : une interface de communication ; et un contrôleur configuré pour : recevoir, via l’interface de communication, d’au moins un système de fournisseur, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; générer un objet d’intermédiation, correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation comprenant une intermédiation remplie avec au moins un sous-ensemble de données d’objets de fournisseur basée sur un mappage entre les données de l'objet d'intermédiation et les données de l'objet fournisseur, fournissant ainsi une traduction des objets fournisseurs dans un format d'intermédiation commun accessible par des ressources informatiques mises en œuvre sur le dispositif client sans qu'il soit nécessaire d'adapter les ressources informatiques du dispositif client à des données spécifiques de l'objet fournisseur, l’objet d’intermédiation omettant les données d’objet de fournisseur et un quelconque identifiant d’objet de fournisseur, dans une forme d’origine ; générer un identifiant intermédiaire d’au moins une portion des données d’objet de fournisseur arrangée dans un format prédéterminé ; générer un identifiant d’objet d’intermédiation en cryptant l’identifiant intermédiaire ; et fournir l’objet d’intermédiation et l’identifiant d’objet d’intermédiation à un dispositif client qui a demandé le au moins un élément, sans stocker l’objet d’intermédiation et l’identifiant d’objet d’intermédiation. Le serveur de la revendication 6, dans lequel le contrôleur est par ailleurs configuré pour : recevoir, via l’interface de communication, en provenance du dispositif client, en réponse à la fourniture de l’objet d’intermédiation, l’identifiant d’objet d’intermédiation avec une requête pour des informations supplémentaires associées audit au moins un élément ; décrypter l’identifiant d’objet d’intermédiation pour obtenir ladite au moins la portion de données d’objet de fournisseur ; et demander les informations supplémentaires audit au moins un système de fournisseur en utilisant ladite au moins la portion des données d’objet de fournisseur telle qu’elle est décryptée. Le serveur de l’une quelconque de la revendication 6 à la revendication 7, dans lequel le contrôleur est par ailleurs configuré pour générer l’identifiant intermédiaire à partir d’au moins la portion des données d’objet de fournisseur arrangée dans un format prédéterminé en : ayant recours à un ou plusieurs de la concaténation, l’assemblage, le groupement et l’organisation de ladite au moins la portion des données d’objet de fournisseur selon le format prédéterminé. Le serveur de l’une quelconque de la revendication 6 à la revendication 8, dans lequel le contrôleur est par ailleurs configuré pour générer l’identifiant intermédiaire à partir d’au moins la portion des données d’objet de fournisseur arrangée dans un format prédéterminé en : incluant un identifiant de format prédéterminé avec la portion des données d’objet de fournisseur arrangée dans le format prédéterminé. Le serveur de l’une quelconque de la revendication 6 à la revendication 9, dans lequel le contrôleur est par ailleurs configuré pour générer l’identifiant d’objet d’intermédiation en incluant un identifiant de version cryptée avec l’identifiant intermédiaire après le cryptage. Le serveur de l’une quelconque de la revendication 6 à la revendication 10, dans lequel le format prédéterminé est dépendant d’un type d’objet de fournisseur. Le serveur de l’une quelconque de la revendication 6 à la revendication 11, dans lequel l’objet d’intermédiation comprend l’identifiant d’objet d’intermédiation. Un produit programme d’ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur comprenant : des moyens de programmation lisibles par ordinateur pour recevoir, à un serveur d’intermédiation, en provenance d’au moins un système de fournisseur, au moins un objet de fournisseur qui inclut des données d’objet de fournisseur représentant au moins un élément fourni par le au moins un système de fournisseur ; des moyens de programmation lisibles par ordinateur pour générer, au serveur d’intermédiation, un objet d’intermédiation correspondant audit au moins un objet de fournisseur, l’objet d’intermédiation incluant des données d’objet d’intermédiation et un identifiant d’objet d’intermédiation qui identifie l’objet d’intermédiation, les données d’objet d’intermédiation étant remplies avec au moins un sous-ensemble de données d’objet de fournisseur sur la base d’un mappage entre les données d’objet d’intermédiation et les données d’objet de fournisseur, fournissant ainsi une traduction des objets du fournisseur dans un format d'intermédiation commun accessible par des ressources de calcul mises en œuvre sur le dispositif client sans qu'il soit nécessaire d'adapter les ressources de calcul du dispositif client à des données spécifiques de l'objet du fournisseur, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objet de fournisseur et tout identifiant d’objet de fournisseur dans une forme d’origine ; et des moyens de programmation lisibles par ordinateur pour fournir par le serveur d’intermédiation, l’objet d’intermédiation à un dispositif client qui a demandé le au moins un élément fourni par le au moins un système de fournisseur, l’objet d’intermédiation étant fourni à la place dudit au moins un objet de fournisseur, lorsque le programme fonctionne sur un ordinateur. Le produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur de la revendication 13 comprenant : des moyens de programmation lisibles par ordinateur pour stocker, dans au moins une ou plusieurs mémoires, un ou plusieurs de l’objet d’intermédiation et de l’identifiant d’objet d’intermédiation en association à un ou plusieurs dudit au moins un objet de fournisseur et l’identifiant d’objet de fournisseur. Un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur de la revendication 13 comprenant : des moyens de programmation lisibles par ordinateur pour recevoir, au serveur d’intermédiation, une pluralité d’objets de fournisseur, dans lequel les données d’objet d’intermédiation sont remplies avec au moins un sous-ensemble de données d’objets de fournisseurs de la pluralité des objets de fournisseur sur la base d’un ou de plusieurs mappages entre les données d’objet d’intermédiation et les données d’objets de fournisseurs respectifs, l’objet d’intermédiation et l’identifiant d’objet d’intermédiation omettant : les données d’objets de fournisseurs respectifs, incluant un quelconque des identifiants d’objets de fournisseurs respectifs, dans une forme d’origine respective.