FR3105523A1

FR3105523A1 - Système et procédé pour optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes

Info

Publication number: FR3105523A1
Application number: FR1915430A
Authority: FR
Inventors: Olivier Amadieu; Jean-Chafic Hays; Fadi AKRIMI; Aurelie Camberbec
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2019-12-23
Filing date: 2019-12-23
Publication date: 2021-06-25
Anticipated expiration: 2039-12-23
Also published as: FR3105523B1

Abstract

Un procédé d'optimisation de la transmission des demandes de contenu mis à jour provenant de sources de données externes comprend : de stocker un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à un délai d'expiration ; de stocker un ensemble de paramètres d'optimisation ; d'obtenir une instruction pour demander un contenu mis à jour correspondant à l'objet de données ; en réponse à l'obtention de l'instruction, de déterminer, en fonction des paramètres d'optimisation et du délai d'expiration, s'il faut demander un contenu mis à jour aux sources de données externes ; lorsque la détermination est affirmative, de transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et en réponse à la transmission de ladite au moins une demande de mise à jour, de recevoir et de stocker les ensembles respectifs de contenu mis à jour provenant des sources de données externes.

Description

Système et procédé pour optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes

La spécification porte généralement sur les systèmes informatiques, et plus particulièrement sur un système et un procédé pour optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes.

Contexte

Certains systèmes informatiques génèrent des données à fournir aux sous-systèmes clients selon des mécanismes complexes et hautement variables. Les exemples sont des systèmes qui génèrent des données représentant des articles tels que les produits et services de voyage, dont chacun peut avoir de nombreux attributs qui peuvent être sélectionnés dynamiquement au moment de la génération en fonction d'une large variété de conditions. Les attributs des données ci-dessus, tels que le prix et la disponibilité des sièges pour un vol, peuvent varier sur des périodes de temps relativement courtes (p. ex. une journée).

En raison de la variabilité des données susmentionnées dans le temps, les opérateurs des sous-systèmes clients peuvent lancer des demandes exploratoires supplémentaires dans un effort visant à déterminer si des articles présentant des caractéristiques plus souhaitables (p. ex. des prix plus bas) sont devenus disponibles depuis la demande initiale. Toutefois, en raison de la nature intensive des calculs pour produire ces données, des demandes répétées peuvent imposer une charge excessive aux ressources de mise en réseau et de traitement.

Résumé

Un aspect de la spécification fournit un procédé d'optimisation de la transmission de demandes de contenu mis à jour provenant de sources de données externes, comprenant : de stocker, au niveau d'un serveur d'intermédiation, un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à une date d'expiration ; de stocker, au niveau du serveur d'intermédiation, un ensemble de paramètres d'optimisation ; d'obtenir une instruction au niveau du serveur d'intermédiation pour demander un contenu mis à jour correspondant à l'objet de données ; en réponse à l'obtention de l'instruction, de déterminer, sur la base des paramètres d'optimisation et du délai d'expiration, s'il convient de demander un contenu mis à jour auprès des sources de données externes ; lorsque la détermination est affirmative, de transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et en réponse à la transmission de ladite au moins une demande de mise à jour, de recevoir et de stocker des ensembles respectifs de contenu mis à jour provenant des sources de données externes.

Le procédé peut en outre comprendre : en réponse à la réception et au stockage des ensembles de contenu mis à jour, l'évaluation de chaque ensemble de contenu mis à jour par rapport au contenu initial ; et la détermination, sur la base des évaluations, s'il convient de remplacer le contenu initial par un ensemble sélectionné du contenu mis à jour.

Déterminer s'il convient de remplacer le contenu initial par l'ensemble sélectionné du contenu mis à jour peut inclure d'envoyer une sollicitation contenant au moins un des ensembles de contenu mis à jour à un sous-système client pour sélection.

Déterminer s'il convient de remplacer le contenu initial par l'ensemble sélectionné du contenu mis à jour peut inclure le remplacement automatique du contenu initial par l'ensemble sélectionné du contenu mis à jour.

Obtenir l'instruction peut inclure de recevoir l'instruction au niveau du serveur d'intermédiation à partir d'un sous-système client.

Le procédé peut en outre comprendre le stockage, au niveau du serveur d'intermédiation, de données de mise à jour de la planification de la configuration ; dans lequel l'obtention de l'instruction comprend la génération de l'instruction au niveau du serveur d'intermédiation en fonction des données de la planification de la configuration.

Les paramètres d'optimisation peuvent inclure au moins l'un des éléments suivants : (i) un seuil de fréquence de demande de mise à jour, et (ii) un seuil temporel ; et de déterminer si demander un contenu mis à jour peut inclure au moins l'un des éléments suivants : (i) déterminer si le seuil de fréquence de demande de mise à jour a été dépassé, et (ii) déterminer si une différence entre une heure actuelle et l'heure d'expiration est inférieure au seuil temporel.

Les paramètres d'optimisation peuvent inclure des données des tendances historiques correspondant au contenu initial ; et la détermination de la nécessité de demander un contenu actualisé peut inclure : l'identification des données des tendances actuelles correspondant au contenu initial ; la comparaison des données des tendances actuelles avec les données des tendances historiques ; et lorsque les données des tendances actuelles et les données des tendances historiques correspondent, déterminer s'il convient de demander un contenu mis à jour sur la base des données des tendances historiques.

Un autre aspect de la spécification prévoit un serveur d'intermédiation pour optimiser la transmission de demandes de contenu mis à jour provenant de sources de données externes, le serveur d'intermédiation comprenant : une mémoire stockant (i) un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à une heure d'expiration, et (ii) un ensemble de paramètres d'optimisation ; une interface de communication ; et un processeur connecté à l'interface de communication et la mémoire, le processeur étant configuré pour : obtenir une instruction au niveau du serveur d'intermédiation pour demander un contenu mis à jour correspondant à l'objet de données ; en réponse à l'obtention de l'instruction, déterminer, sur la base des paramètres d'optimisation et de l'heure d'expiration, s'il convient de demander un contenu mis à jour à partir des sources de données externes ; lorsque la détermination est affirmative, transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et en réponse à la transmission de ladite au moins une demande de mise à jour, recevoir et stocker des ensembles respectifs de contenu mis à jour à partir des sources de données externes.

Le processeur peut en outre être configuré pour : en réponse à la réception et au stockage des ensembles de contenu mis à jour, évaluer chaque ensemble de contenu mis à jour par rapport au contenu initial ; et déterminer, sur la base des évaluations, s'il convient de remplacer le contenu initial par un ensemble sélectionné de contenu mis à jour.

Le processeur peut être configuré, pour déterminer s'il convient de remplacer le contenu initial par l'ensemble sélectionné du contenu mis à jour, pour envoyer une sollicitation contenant au moins un des ensembles de contenu mis à jour à un sous-système client pour sélection.

Le processeur peut être configuré, pour déterminer s'il convient de remplacer le contenu initial par l'ensemble sélectionné du contenu mis à jour, pour remplacer automatiquement le contenu initial par l'ensemble sélectionné du contenu mis à jour.

Le processeur peut être configuré, afin d'obtenir l'instruction, pour recevoir l'instruction au niveau du serveur d'intermédiation à partir d'un sous-système client.

Le processeur peut être configuré, afin d'obtenir l'instruction, pour générer l'instruction en fonction des données de la planification de la configuration stockées dans la mémoire.

Les paramètres d'optimisation peuvent inclure au moins : (i) une demande de mise à jour du seuil de fréquence, et (ii) un seuil temporel ; et le processeur peut être configuré, pour déterminer s'il convient de demander un contenu mis à jour, pour au moins : (i) déterminer si la demande de mise à jour du seuil de fréquence de demande a été dépassée, et (ii) déterminer si une différence entre une heure actuelle et l'heure d'expiration est inférieure au seuil temporel.

Les paramètres d'optimisation comprennent les données des tendances historiques correspondant au contenu initial ; et le processeur peut être configuré, pour déterminer s'il convient de demander un contenu mis à jour, pour : identifier les données des tendances actuelles correspondant au contenu initial ; comparer les données des tendances actuelles aux données des tendances historiques ; et lorsque les données des tendances actuelles et les données des tendances historiques correspondent, déterminer s'il convient de demander un contenu mis à jour en sur la base des données des tendances historiques.

Un autre aspect de la spécification prévoit un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant : un programme lisible par ordinateur pour stocker (i) un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à une heure d'expiration, et (ii) un ensemble de paramètres d'optimisation ; un programme lisible par ordinateur pour obtenir une instruction au niveau du serveur d'intermédiation afin de demander un contenu mis à jour correspondant à l'objet de données ; un programme lisible par ordinateur pour, en réponse à l'obtention de l'instruction, déterminer, sur la base des paramètres d'optimisation et du délai d'expiration, s'il faut demander un contenu mis à jour provenant de sources de données externes ; des moyens de programme lisibles par ordinateur pour, lorsque la détermination est affirmative, transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et des moyens de programme lisibles par ordinateur pour, en réponse à la transmission de la au moins une demande de mise à jour, recevoir et stocker des ensembles respectifs de contenu mis à jour provenant des sources de données externes, lorsque ledit programme fonctionne sur un serveur d'intermédiation.

Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles:

est un schéma illustrant un système pour optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes ;

est un schéma illustrant certains composants internes du serveur d'intermédiation de la FIG. 1 ;

est un organigramme d'un procédé permettant d'optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes ;

est un schéma illustrant un exemple d’exécution du bloc 305 du procédé de la FIG. 3 ;

est un organigramme d'un procédé pour exécuter le bloc 315 du procédé de la FIG. 3 ;

est un organigramme d'un autre procédé pour exécuter le bloc 315 du procédé de la FIG. 3 ; et

est un diagramme illustrant les données des tendances utilisées dans l'exécution du procédé de la FIG. 6.

Description détaillée

La FIG. 1 illustre un système 100 pour optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes. Dans le système 100, divers sous-systèmes informatiques interagissent pour générer et traiter des données relatives à une large variété d'activités. Dans les exemples présentés ci-dessous, les sous-systèmes du système 100 interagissent pour générer et traiter les données relatives à la livraison des articles aux clients. Les articles, dans les exemples, ci-dessous, sont des produits et des services liés aux voyages, tels que les billets d'avion, les réservations d'hôtel, les réservations de location de véhicules, et autres similaires.

Une large variété d'autres activités peuvent être rendues possibles par l'échange de données entre les sous-systèmes indiqués dans la FIG. 1, et la nature spécifique des données traitées dans le cadre du système 100 n'est pas particulièrement limitée. Plus généralement, la génération des données traitées dans le système 100 impose une charge de calcul non négligeable sur le ou les composants qui génèrent les données. Les données ne sont pas simplement extraites de référentiels pour transmission en réponse à des demandes, mais sont au contraire générées dynamiquement en réponse à chaque demande à partir d'une variété de données d'entrée, de règles de génération, et autre similaire. En outre, le volume des demandes et des données associées dans le système 100 peut être important (p. ex. de l'ordre de millions de demandes par jour). Comme cela sera vu plus loin, au moins certains éléments du système 100 sont configurés pour optimiser la transmission des demandes de données afin de réduire, sous certaines conditions, les demandes susmentionnées adressées au système 100.

Dans l'exemple illustré, le système 100 comprend au moins un sous-système client 104, dont deux exemples 104-1 et 104-2 sont représentés dans la FIG. 1 (appelés collectivement sous-systèmes client 104 et, de manière générique, sous-système client 104). Chaque sous-système client 104 est exploité par une entité cliente qui peut également être appelée un vendeur. Le vendeur peut être, par exemple, une agence de voyage. Les sous-systèmes clients 104 génèrent des demandes, par exemple au nom des clients, pour des articles de voyage. Les demandes précisent divers attributs des articles de voyage, tels que les lieux d'origine et de destination, les heures et les dates de voyage, et autres similaires. Les réponses aux demandes des sous-systèmes clients 104 sont générées par, ou au nom, des entités qui fournissent les articles, appelées ici fournisseurs. Par conséquent, dans le présent exemple les fournisseurs sont des entités telles que des compagnies aériennes, des exploitants d'hôtels ou autres similaires qui livrent les articles au client, ou à d'autres entités de ce type pour une éventuelle livraison au client, après l'achat des articles (cet achat étant effectué, par exemple, par l'intermédiaire d'un sous-système client 104). Les fournisseurs peuvent également être désignés de manière interchangeable comme distributeurs, ce qui reflète le fait que dans certains cas, un article tel qu'un vol peut être réservé par l'entremise d'une première compagnie aérienne (p. ex. le distributeur) et exploité par une autre compagnie aérienne (p. ex. le fournisseur).

Chaque entité fournisseuse exploite un sous-système fournisseur 108 (qui peut également être appelé sous-système distributeur), dont deux exemples de sous-systèmes fournisseurs 108-1 et 108-2 sont présentés dans la FIG. 1. Chacun des sous-systèmes clients 104 et les sous-systèmes fournisseurs 108 sont mis en œuvre en tant qu'au moins un dispositif informatique avec des ensembles d'entrée et de sortie et des dispositifs de communication pour échanger des données via un réseau 112. Le réseau 112 peut comprendre toute combinaison appropriée de réseaux locaux et étendus, y compris l'Internet. Bien que deux sous-systèmes clients 104 et deux sous-systèmes fournisseurs 108 soient représentés dans la FIG. 1, le système 100 peut inclure un nombre plus ou moins important de sous-systèmes clients 104 et de sous-systèmes fournisseurs 108 dans d'autres exemples.

La génération de réponses aux demandes des sous-systèmes clients 104 peut prendre différentes formes. Dans l'exemple illustré, les sous-systèmes fournisseurs 108 sont supposés générer localement des réponses à ces demandes, bien que, comme cela sera vu plus loin, les demandes ne soient pas transmises directement des sous-systèmes clients 104 aux sous-systèmes fournisseurs 108. En tout état de cause, dans l'exemple illustré, chaque sous-système fournisseur 108 comprend un module de génération d'offres (p. ex. des instructions lisibles par ordinateur et le matériel d'exécution correspondant, ainsi que diverses données stockées à utiliser pour générer des réponses) qui permet aux sous-systèmes fournisseurs 108 de générer des données de réponse sur la base des attributs spécifiés dans la demande émanant d'un sous-système client 104. Les données de réponse peuvent également être appelées " données d'offre " et définissent un ou plusieurs articles qui correspondent ou correspondent partiellement aux attributs demandés.

Comme le percevront clairement les hommes de métier, dans le contexte des articles de voyage, divers canaux de distribution peuvent être utilisés par le sous-système fournisseur 108 et d'autres composantes du système 100 pour traiter les demandes et générer des données. Un canal de distribution englobe un ensemble d'entités au sein du système 100, ainsi que la syntaxe des messages, le séquençage des messages et autres similaires. Dans les exemples présentés ici, les sous-systèmes fournisseurs 108 mettent en œuvre le canal de distribution de nouvelle capacité de distribution (NDC, New Distribution Capability). La norme NDC définit un format de données basé sur le langage de balisage extensible (XML, eXtensible Markup Language), ainsi que la syntaxe des messages, les appels API et autres similaires, pour les messages échangés entre les sous-systèmes clients 104 et les sous-systèmes fournisseurs 108. Les demandes de contenu transmises aux sous-systèmes fournisseurs 108 peuvent donc inclure des messages AirShopping (AchatAérien), des messages OfferPrice (PrixOffre) et autres similaires, selon la norme NDC. Divers autres types de messages seront également adressés aux hommes de métier, dont d'autres exemples seront également mentionnés ci-dessous.

Les données générées au sein du système 100, telles que les données représentant les articles de voyage générées par les sous-systèmes fournisseurs 108, sont également appelées contenu dans le présent document. La génération de contenu est non seulement complexe sur le plan des calculs, mais peut également être hautement variable en fonction d'une large variété de conditions. Par exemple, une demande définissant des paramètres de vol spécifiques (p. ex. un vol sans escale de Barcelone à Montréal le 16 février) peut renvoyer un contenu définissant un vol avec un premier prix. La même demande faite le lendemain peut renvoyer le contenu définissant un vol avec un second prix différent du premier. Les prix distincts peuvent même correspondre à un même vol, opéré par la même compagnie aérienne. D'autres attributs d'articles définis dans le contenu généré par les sous-systèmes fournisseurs 108 peuvent être soumis à des variations similaires, comme les services auxiliaires inclus dans un vol et autres similaires.

Les variations de contenu telles que celles mentionnées ci-dessus peuvent être partiellement ou entièrement opaques pour un opérateur d'un sous-système client 104. En outre, un ensemble donné de contenus, définissant un ou plusieurs articles qui peuvent être achetés par ou pour le compte d'un client, peut inclure une durée de validité. Le contenu mentionné ci-dessus définit une offre, qui peut être réservée par ou au nom d'un client (entraînant ainsi la génération d'une commande). La durée de validité est fixée par le sous-système fournisseur 108, et indique une période de temps (à partir de la génération du contenu) pendant laquelle l'offre est valable. Par exemple, un sous-système fournisseur 108 peut transmettre un contenu à sous-système client 104 définissant le vol susmentionné de Barcelone à Montréal, avec une durée de validité indiquant que l'offre est valable pendant trois jours. Si le sous-système client 104 tente de réserver (c'est-à-dire de convertir en commande) l'offre quatre jours plus tard, la demande peut être refusée et le sous-système client 104 peut être tenu d'obtenir de nouvelles offres.

Lorsqu'une offre est réservée, sécurisant l'article pertinent au nom d'un client, le sous-système fournisseur 108 concerné peut également fournir au sous-système client 104 qui a initié la réservation un délai d'expiration. Le délai d'expiration indique une période temporelle pendant laquelle une condition doit être remplie pour que la réservation reste active. La condition peut être, par exemple, la fourniture d'un paiement pour le(s) article(s) correspondant(s) au sous-système fournisseur 108. Autrement dit, dans certaines implémentations, une offre peut être réservée sans qu'un paiement immédiat ne soit effectué. Par exemple, un sous-système client 104 peut réserver une offre, en sécurisant l'article concerné au nom d'un client, mais peut être autorisé à effectuer un paiement dans les 24 heures. La période de 24 heures est le délai d'expiration, et si le paiement n'est pas effectué dans le cadre du délai d'expiration, la réservation est révoquée. Dans d'autres exemples, plutôt que de révoquer la réservation après le délai d'expiration, le prix de l'article peut être sujet à modification.

L'opacité des variations de contenu, ainsi que la disponibilité du délai d'expiration susmentionné, peuvent amener le contrôle des sous-systèmes clients 104 (p. ex. par leurs opérateurs) à demander un contenu actualisé à au moins certains des sous-systèmes fournisseurs 108. Sur demande, le contenu mis à jour peut être évalué pour déterminer s'il est plus souhaitable que le contenu actuellement réservé (c'est-à-dire "meilleur" que la commande actuellement réservée). Les mécanismes utilisés pour effectuer une telle évaluation dépassent le cadre de la présente discussion. Les exemples de contenu plus souhaitable que le contenu initial (réservé), peuvent inclure le contenu définissant le même article à un prix inférieur, y compris les services auxiliaires supplémentaires (ou plus pertinents pour le client), et autres similaires.

Lorsque le contenu mis à jour est jugé plus souhaitable, le contenu initial peut être remplacé par le contenu mis à jour. Divers mécanismes peuvent être utilisés pour ce remplacement, en fonction notamment du ou des sous-systèmes fournisseurs 108 d'où proviennent le contenu initial et le contenu mis à jour.

Comme le percevront désormais clairement les hommes de métier, les demandes de contenu actualisé générées par les sous-systèmes clients 104 à la suite de réservations peuvent entraîner une charge de calcul supplémentaire importante sur les composants du système 100 tels que les sous-systèmes fournisseurs 108, ainsi qu'une augmentation du trafic sur le réseau 112. Le système 100 est donc également configuré pour optimiser la génération et la transmission de ces demandes de contenu actualisé. L'optimisation permise par le système 100 peut permettre aux sous-systèmes clients 104 de continuer à déterminer si de meilleures offres sont disponibles plutôt qu'une commande initiale, tout en atténuant l'impact de ces déterminations sur les ressources de calcul au sein du système 100.

A cette fin, le système 100 comprend un serveur d'intermédiation 116 (également appelé ici simplement le serveur 116) connecté au réseau 112. Les demandes générées par les sous-systèmes clients 104 sont transmises via le réseau 112 au serveur d'intermédiation 116. Le serveur d'intermédiation 116 reçoit les demandes des sous-systèmes clients 104, et transmet ces demandes aux sous-systèmes fournisseurs 108. Le serveur d'intermédiation 116 reçoit également les réponses du sous-système fournisseur 108, pour les renvoyer au sous-système client 104. Le serveur 116 peut également relayer des messages entre les sous-systèmes clients 104 et les sous-systèmes fournisseurs 108 pour réserver des offres (c'est-à-dire pour générer des commandes) et pour modifier ces commandes.

Le serveur 116 obtient également des instructions, par exemple directement des sous-systèmes clients 104 ou sur la base des paramètres de configuration enregistrés, pour vérifier la présence de contenu mis à jour correspondant à du contenu précédemment réservé. En réponse à ces instructions, le serveur 116 effectue diverses actions pour déterminer s'il faut vérifier le contenu mis à jour, et sélectionne un mécanisme pour effectuer cette vérification lorsque la détermination est positive. Les paramètres de configuration susmentionnés, ainsi que d'autres données de configuration qui seront abordées plus en détail ci-dessous, sont stockés sur le serveur 116 dans un référentiel de configuration 120. Le serveur 116 peut également stocker le contenu lui-même (par exemple, toute commande réservée) dans un référentiel de contenu 124.

Avant de poursuivre la discussion sur la fonctionnalité des différents composants du système 100, certains composants internes du serveur d'intermédiation 116 seront décrits en relation avec la FIG. 2.

Faisant référence à la FIG. 2, le serveur d’intermédiation 116 inclut au moins un processeur 200, tel qu’une unité de traitement centrale (CPU), et autres similaires. Le processeur 200 est interconnecté à une mémoire 204 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire (RAM), mémoires morte (ROM), mémoires programmables à lecture seule effaçables électriquement (EEPROM), mémoires flash, stockage informatique magnétique, et autres similaires). Le processeur 200 et la mémoire 204 sont généralement compris d’un ou de plusieurs circuits intégrés (ICs).

Le processeur 200 est aussi relié à une interface de communication 208, qui permet au serveur 116 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 112. L’interface de communication 208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d’interface de réseau (NICs), des unités de radio, et autres similaires) pour communiquer via le réseau 112. Les composants spécifiques de l’interface de communication 208 sont sélectionnés en fonction de la nature du réseau 112. Le serveur 116 peut aussi inclure des dispositifs d’entrée et de sortie connectés au processeur 200, tel que des claviers, des souris, des écrans, et autres similaires (non illustrés).

Les composants du serveur 116 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 116 inclut une pluralité de processeurs qui peuvent soit partager la mémoire 204 et l’interface de communications 208, ou soit qui ont chacun des interfaces de communications et des mémoires associées distinctes.

La mémoire 204 stocke les référentiels120 et 124, ainsi que des instructions lisibles par ordinateur et exécutables par le processeur 200 pour mettre en œuvre diverses fonctionnalités. Les instructions lisibles par ordinateur peuvent également être appelées applications, et dans l'exemple illustré, la mémoire 204 stocke un contenu traitant l'application 212 (également appelée ici simplement l'application 212). Dans la description ci-dessous, le processeur 200, et de façon plus générale le serveur 116, sont censés mettre en œuvre, ou être configurés pour mettre en œuvre, ces actions. Il est entendu qu'ils sont ainsi configurés via l'exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204, y compris l'application 212.

L'exécution de l'application 212 par le processeur 200 configure le serveur 116 pour obtenir des instructions afin de demander un contenu mis à jour correspondant au contenu stocké dans le référentiel 124, et pour traiter ces demandes comme décrit en détail ci-dessous.

Faisant maintenant référence à la FIG. 3, certains aspects de l’exploitation du système 100 seront décrits plus en détail. Plus précisément, la FIG. 3 illustre un procédé 300 d'optimisation de la transmission des demandes de contenu actualisé provenant de sources de données externes. Les performances du procédé 300 seront abordées en conjonction avec ses performances au sein du système 100, et plus particulièrement par le serveur d'intermédiation 116 via l'exécution de l'application d'intégration 212.

Au bloc 305, le serveur 116 reçoit du contenu pour le stockage dans le référentiel 124. La réception du contenu peut être précédée d'une variété d'autres actions qui sortent du contexte de la présente discussion. En bref, ces actions comprennent la réception d'une demande d'offres au serveur 116 en provenance d'un sous-système client 104 (p. ex. le sous-système client 104-1), et la transmission de demandes à au moins un des sous-systèmes fournisseurs 108 sur la base de la demande d'offres. Les actions comprennent en outre la réception des offres des sous-systèmes fournisseurs 108, la transmission des offres au sous-système 104-1 du client et la réception d'une sélection d'un sous-ensemble d'offres de réservation du sous-système client 104-1. En d'autres termes, le contenu reçu au bloc 305 correspond à une offre réservée, également appelée commande.

Faisant référence à la FIG. 4, un exemple d’exécution du bloc 305 est présenté. En particulier, le sous-système fournisseur 108-1 est représenté en train de transmettre un contenu sous la forme d'un objet de données 400 au serveur 116 via le réseau 112. L'objet de données existantes 400 peut être, par exemple, un enregistrement de Commande résultant d'une demande antérieure par le sous-système client 104-1 pour enregistrer une offre.

L'objet de données 400 est stocké dans le référentiel 124. Les contenus de l'objet de données 400 sont également représentés dans la FIG. 4. Dans l'exemple illustré, l'objet de données 400 comprend un champ d'identification d'enregistrement 404 (p. ex. une référence de réservation), un champ de nom 408 et un champ de définition d'article 412. Le champ de définition d'article 412 comprend divers attributs de l'article défini par l'objet de données 400, tels qu'un identificateur de vol ("6X 001"), un identificateur d'origine (correspondant à Barcelone dans cet exemple), un identificateur de destination (correspondant à Montréal dans cet exemple) et un prix. L'objet de données 400 définit également un délai d'expiration de 48 heures à partir de la génération de la commande (qui peut également être indiqué dans l'objet de données 400). Le délai d'expiration peut être définie d'autres façons également ; par exemple, l'expiration peut être définie comme une heure et une date plutôt qu'une durée. Une grande variété d'attributs supplémentaires peut être incluse dans le champ 412, et divers autres champs peuvent également être inclus dans l'objet de données 400.

Revenant à la FIG. 3, au bloc 310 le serveur 116 obtient une instruction pour demander un contenu mis à jour. En particulier, l'instruction est de demander un contenu actualisé correspondant à l'objet de données 400 indiqué dans la FIG. 4. Le serveur 116 peut exécuter plusieurs instances du procédé 300 en parallèle, chacune correspondant à un objet de données différent.

Diverses origines sont envisagées pour l'instruction obtenue au bloc 310. Dans certains exemples, le serveur 116 obtient une telle instruction en recevant l'instruction du sous-système client 104 associé à l'objet de données concerné. Ainsi, dans l'exemple de la FIG. 4, le sous-système client 104-1 avec lequel l'objet de données 400 est stocké peut transmettre au serveur 116, via le réseau 112, une instruction de vérification du contenu mis à jour. Dans d'autres exemples, le serveur 116 génère automatiquement la demande en interne, par exemple à une fréquence configurable.

Le mécanisme par lequel le serveur 116 obtient l'instruction au bloc 310 peut être défini dans la mise à jour des données de la planification de la configuration stockées dans le référentiel 120. Un exemple de mise à jour des données de la planification de la configuration est présenté ci-dessous dans le Tableau 1.
Mise à jour de la planification de la configuration

Sous-système client	Demandes automatiques	Fréquence
104.-1	Activée	12h tous les jours
104.-2	Désactivée	Non applicable

Comme cela a été vu ci-dessus, différents modes d'obtention de l'instruction ci-dessus au niveau du serveur 116 peuvent être spécifiés pour chaque sous-système client 104. Par exemple, le Tableau 1 indique que la génération automatique d'instructions pour demander un contenu actualisé est activée pour le sous-système client 104-1, mais désactivée pour le sous-système client 104-2. Par conséquent, la performance du bloc 310 pour les objets de données associés au sous-système client 104-2 implique de recevoir une instruction explicite du sous-système client 104-2.

Les performances du bloc 310 pour les objets de données associés au sous-système client 104-1 comprennent toutefois la génération automatique, par le serveur 116 lui-même, de telles demandes selon les paramètres indiqués dans le Tableau 1. Ainsi, dans l'exemple illustré, le serveur 116 est configuré pour générer une instruction au bloc 310 correspondant à l'objet de données 400 une fois par jour à 12h. L'activation de la génération automatique de demandes peut désactiver la réception d'instructions explicites. Dans d'autres exemples, cependant, le fait de permettre la génération automatique de demandes permet toujours de recevoir des instructions explicites pour demander un contenu mis à jour. Pour les demandes générées automatiquement, d'autres mécanismes que la mise en œuvre prévue indiquée dans le Tableau 1 peuvent être utilisés. Par exemple, le serveur 116 peut être configuré pour générer automatiquement une instruction au bloc 310 dans une période de temps prédéterminée du délai d'expiration spécifique à l'objet de données concerné. Autrement dit, le paramètre "fréquence" ci-dessus peut spécifier "1 heure avant l'expiration", par exemple.

Comme on peut le voir clairement désormais, la mise à jour des données de la planification de la configuration permet au serveur 116 de fonctionner en mode passif ou actif. En mode passif, un sous-système client 104 n'a pas besoin d'envoyer explicitement une instruction au serveur 116 via le réseau 112 (ce qui entraîne une charge supplémentaire du réseau). En mode actif, en revanche, le sous-système client 104 demande activement des contrôles de mise à jour. Une large variété d'autres paramètres peuvent également être enregistrés dans le Tableau 1. Par exemple, les configurations peuvent être spécifiques non seulement à un sous-système client 104, mais aussi à un appariement du sous-système client 104 et du client, à un appariement du sous-système client 104 et du sous-système fournisseur 108, et autres similaires.

Après la génération ou la réception d'une instruction de demande de contenu mis à jour, le serveur 116 détermine au bloc 315 s'il convient de lancer une vérification du contenu mis à jour lié à l'objet de données 400. Par exemple, toute instruction obtenue au bloc 310 peut être placée dans une file d'attente d'instructions dans la mémoire 204, et au bloc 315, le serveur 116 détermine s'il convient d'extraire une instruction de la file d'attente et générer une ou plusieurs demandes de mise à jour en fonction de l'instruction. La détermination au bloc 315 est basée sur l'un quelconque d'une variété de paramètres d'optimisation. Les paramètres d'optimisation, dont des exemples seront abordés ci-dessous, peuvent inclure des seuils de fréquence de mise à jour des demandes, des seuils temporels et des données des tendances historiques correspondant à l'objet de données 400.

La détermination au bloc 315 peut être basée sur différents facteurs. Dans certains exemples, en se tournant vers la FIG. 5, la détermination au bloc 315 peut être effectuée selon un procédé 500, dans lequel au moins un seuil est évalué au niveau du serveur 116. En particulier, au bloc 505, le serveur 116 est configuré pour déterminer un temps restant entre l'heure actuelle et l'heure d'expiration définie dans l'objet de données 400. Le serveur 116 est en outre configuré pour déterminer si le temps restant est inférieur à un seuil temporel. Le référentiel 120 peut stocker des seuils temporels pour chaque sous-système fournisseur 108, pour chaque appariement du sous-système fournisseur 108 et du sous-système client 104, un seuil unique à l'échelle du système, ou autre similaire.

Lorsque le temps restant avant l'expiration est inférieur au seuil susmentionné, le serveur 116 retourne au bloc 310. En revenant au bloc 310, le serveur 116 peut simplement rejeter l'instruction générée lors de l'exécution précédente du bloc 310, ou peut conserver l'instruction dans la file d'attente mentionnée ci-dessus pour la réévaluer lors d'une exécution ultérieure du bloc 315. En d'autres termes, lorsque le temps restant est suffisamment court, les demandes de mise à jour supplémentaires peuvent être supprimées par le serveur 116.

Lorsque la détermination au bloc 505 est négative, indiquant que le temps restant avant l'expiration n'est pas inférieur au seuil, le serveur 116 passe au bloc 510. Au bloc 510, le serveur 116 est configuré pour sélectionner l'un des sous-systèmes fournisseurs 108 auquel les demandes de mise à jour peuvent être envoyées. Autrement dit, les actions effectuées dans le restant du procédé 500 ne sont pas nécessairement limitées au sous-système fournisseur 108 qui est à l'origine de l'objet de données 400, mais peuvent être répétées pour d'autres sous-systèmes fournisseurs 108. Les sous-systèmes fournisseurs 108 qui sont sélectionnés parmi une performance donnée du procédé 500 peuvent être déterminés en fonction des paramètres de configuration dans le référentiel 120. Par exemple, ces paramètres peuvent spécifier les sous-systèmes fournisseurs 108 à sélectionner dans le bloc 510 pour chaque sous-système client 104.

Dans le présent exemple, au bloc 510, le sous-système fournisseur 108-1 est sélectionné. Au bloc 515, le serveur 116 détermine, pour le sous-système fournisseur 108 sélectionné, si une demande de mise à jour du seuil de fréquence été dépassée. Différentes formes de seuils de fréquence de demande de mise à jour sont envisagées. Des exemples de ces seuils, qui peuvent être stockés dans le référentiel 120, sont présentés ci-dessous dans le Tableau 2.
Seuils de fréquence

Sous-système fournisseur	Seuil de OrderReshop (RéachatCommande)	Seuil de AirShopping (AchatAérien)
108-1	3 par commande	Ne s’applique pas
108-2	Ne s’applique pas	10000 par jour

Comme le montre le Tableau 2, le référentiel 120 peut contenir des seuils de fréquence de demandes distincts pour différents types de demandes. Par exemple, l'exemple ci-dessus précise différents seuils pour les demandes "OrderReshop", qui sont des demandes basées sur le NDC spécifiquement pour la mise à jour de réservations existantes, et pour les demandes "AirShopping", qui comprennent une variété de demandes basées sur le NDC pour l'obtention de nouvelles offres (c'est-à-dire non liées à une réservation/commande existante). D'autres types de demandes de mise à jour sont également envisagés dans le cadre des systèmes basés sur le NDC, notamment les demandes de OfferPrice (PrixOffre), les demandes de SeatAvailability (DisponibilitéSiège) et les demandes de ServiceList (ListeServices).

Les seuils spécifiés dans le Tableau 2 peuvent être renseignés lors du déploiement du système 100, par exemple en fonction des exigences commerciales ou techniques communiquées au serveur 116 par les sous-systèmes fournisseurs 108. Dans d'autres exemples, les seuils peuvent être déterminés par le serveur 116 de manière dynamique. Plus précisément, le dépassement des seuils susmentionnés pour un sous-système fournisseur 108 donné peut entraîner le rejet des demandes de mise à jour ultérieures par le sous-système fournisseur 108. Le serveur 116 peut déterminer un seuil en fonction du nombre de demandes d'un type donné qui ont été envoyées à ce sous-système fournisseur 108 sur une période donnée (p. ex. un jour).

Au bloc 515, le serveur 116 détermine donc si l'un des seuils ci-dessus a été dépassé pour le sous-système fournisseur 108 sélectionné. Lorsque la détermination au bloc 515 est négative, le serveur 116 inclut le sous-système fournisseur 108 sélectionné dans le processus de génération de la demande de mise à jour qui sera abordée ci-dessous. Le serveur 116 détermine ensuite si un sous-système fournisseur 108 doit encore être traité au bloc 525.

Lorsque la détermination du bloc 515 est affirmative, le serveur 116 passe directement au bloc 525. En d'autres termes, le bloc 520 est contourné, et aucune demande de mise à jour ne sera transmise au sous-système fournisseur 108 sélectionné. Dans certains exemples, certains seuils de type de demande peuvent avoir été dépassés pour un sous-système fournisseur 108 donné, tandis que d'autres seuils peuvent ne pas avoir été dépassés. Dans de tels exemples, la détermination au bloc 515 peut être négative, et au bloc 520, le serveur 116 marque le sous-système fournisseur 108 concerné comme candidat pour une demande de mise à jour, et stocke également le(s) type(s) de demande pour lesquels les seuils n'ont pas été dépassés, pour une utilisation ultérieure.

Lorsque les sous-systèmes fournisseurs 108 restent à traiter, le serveur 116 passe du bloc 525 au bloc 510 pour sélectionner le sous-système fournisseur 108 suivant. Lorsque tous les sous-systèmes fournisseurs 108 ont été traités via les blocs 510-520, la détermination au bloc 525 est négative, et le serveur 116 passe au bloc 320 pour la génération des demandes de mise à jour.

Avant d'aborder le reste du procédé 300, la FIG. 6 illustre une autre fonctionnalité selon laquelle le serveur 116 peut effectuer la détermination au bloc 315. La FIG. 6 illustre un procédé 600 selon lequel le serveur 116 peut déterminer s'il convient de procéder à au moins une demande de mise à jour au bloc 315. Dans le présent exemple, le procédé 600 est illustré comme ayant été intégré à la fonctionnalité du procédé 500 abordé ci-dessus. Dans d'autres exemples, cependant, le procédé 600 peut être appliqué indépendamment du procédé 500 pour mettre en œuvre le bloc 315.

Au bloc 605, il est supposé dans le présent exemple que la détermination du bloc 505 était négative, ce qui indique qu'il reste suffisamment de temps avant l'expiration de l'objet de données 400 pour effectuer une demande de mise à jour. Au bloc 605, le serveur 116 est configuré pour récupérer les données des tendances pour un attribut donné spécifié dans l'objet de données 400. Par exemple, au bloc 605, le serveur 116 peut récupérer les données des tendances pour le prix des vols entre Barcelone et Montréal. Les données des tendances peuvent être récupérées à partir d'un autre référentiel sur le serveur 116, ou en demandant les données à un autre composant (non présenté) du système 100.

Les données des tendances extraites au bloc 605 comprennent les données des tendances actuelles, définissant les variations de l'attribut pertinent (p. ex. le prix) s'étendant de l'heure actuelle et de la date à ce jour par un intervalle configurable. Les données des tendances extraites au bloc 605 comprennent également des données des tendance historiques, définissant les variations du même attribut sur une période correspondante commençant plus tôt dans le temps. Par exemple, si les données des tendances actuelles indiquent des variations de prix entre trois mois et l'heure actuelle, les données des tendances historiques peuvent indiquer des variations de prix entre un an et trois mois auparavant et neuf mois auparavant. C'est-à-dire que les données des tendances actuelles représentent une période de trois mois, et les données des tendances historiques représentent la même période de trois mois sur une année précédente, ainsi que les trois mois suivants de l'année précédente.

Faisant référence à la FIG. 7, un exemple de données des tendances est présenté, comprenant les données des tendances actuelles 700 et les données des tendances historiques 704. Les données des tendances actuelles peuvent remonter sur une période prédéfinie, par exemple 5 mois, à partir de l'heure actuelle 708. Les données historiques des tendances 704 vont d'un an et cinq mois dans le passé (c'est-à-dire un an avant le début des données des tendance actuelles) à trois mois avant le début des données des tendance actuelles 700. Une large variété d'autres périodes peuvent également être utilisées. Une heure actuelle 708 est également indiquée, ainsi qu'une heure 712 à laquelle l'objet de données 400 a été généré (c'est-à-dire une heure de réservation). Dans la partie inférieure de la FIG. 7, les données des tendances 700 et 704 sont superposées, en ignorant l'année et en alignant les tendances par mois et par jour.

Revenant à la FIG. 6, au bloc 610, le serveur 116 est configuré pour déterminer si les données des tendances actuelles correspondent aux données des tendance historiques. Autrement dit, le serveur 116 est configuré pour déterminer, dans le présent exemple, si les récentes variations de prix des vols de Barcelone à Montréal sont similaires aux variations de prix des mêmes vols au cours de la même période sur l'année précédente. Diverses techniques peuvent être appliquées par le serveur 116 pour effectuer la détermination au bloc 610, et la correspondance n'a pas besoin d'être exacte.

Comme le montre la superposition de la FIG. 7, les données des tendances actuelles 700 suivent un cheminement similaire à celui des données des tendances historiques 704. La détermination au bloc 610 est donc affirmative. Le serveur 116 passe donc au bloc 615. Lorsque la détermination au bloc 610 est négative, indiquant que les données des tendances historiques ont peu de pouvoir prédictif sur les variations actuelles des prix, le serveur 116 passe au lieu de cela au bloc 510 et les données des tendances ne sont pas utilisées pour effectuer la détermination au bloc 315.

Au bloc 615, le serveur 116 détermine si les données historiques des tendances indiquent une tendance non avantageuse. Dans le présent exemple, le serveur 116 peut déterminer si les données historiques des tendances 704 indiquent que le prix est susceptible d'augmenter dans un avenir proche (p. ex. avant l'expiration de l'objet de données 400). En d'autres termes, lorsque les données des tendance historiques 704 et les données des tendance actuelles 700 correspondent, le serveur 116 est configuré pour prédire les changements futurs de l'attribut concerné en utilisant les données des tendances historiques. Lorsque la détermination au bloc 615 est négative, l'évaluation supplémentaire des seuils peut se poursuivre au bloc 510.

Comme le montre la FIG. 7, les données historiques des tendances 704 indiquent une hausse continue des prix au-delà de l'heure actuelle 708. La détermination au bloc 615 est donc affirmative, et le serveur 116 passe directement au bloc 310. En d'autres termes, le serveur 116 peut supprimer les demandes de mise à jour, soulageant ainsi le système 100 de la charge supplémentaire sur le réseau et en matière de calcul imposée par ces demandes, lorsque les données historiques indiquent que ces demandes ne sont pas susceptibles de déboucher sur de meilleures offres. Après une détermination positive au bloc 615, le serveur 116 peut également générer une alerte, un message d'avertissement ou autre similaire pour transmission au sous-système client 104 concerné, indiquant que si le paiement n'est pas effectué avant l'heure d'expiration, les données historiques indiquent une augmentation probable du prix. La définition de "non avantageux" au bloc 615 peut varier considérablement, en fonction de la configuration du serveur 116, et ne doit pas être limitée aux données sur les prix (ou spécifiquement à l'augmentation des prix).

Revenant à la FIG. 3, lorsque la détermination au bloc 315 est négative, comme indiqué précédemment, le serveur 116 supprime l'envoi des demandes de mise à jour et revient au bloc 310. La détermination au bloc 315 peut être effectuée plusieurs fois pour les sous-systèmes fournisseurs 108 distincts, et plusieurs instances des blocs suivants du procédé 300 peuvent donc également être effectuées. En d'autres termes, une détermination négative au bloc 315 indique que pour un sous-système fournisseur 108 donné, aucune demande de mise à jour ne sera envoyée. Toutefois, les demandes de mise à jour peuvent toujours être envoyées à d'autres sous-systèmes fournisseurs 108.

Après une détermination positive au bloc 315, au bloc 320 le serveur 116 génère et envoie une demande de mise à jour à au moins un sous-système fournisseur 108. En particulier, une demande de mise à jour est envoyée à chaque sous-système fournisseur 108 pour lequel une détermination positive a été effectuée au bloc 315.

La génération et la transmission des demandes de mise à jour au bloc 320 sont basées sur l'objet de données 400 lui-même, et sur d'autres paramètres d'optimisation dans le référentiel 120. Par exemple, le référentiel 120 peut préciser les types de demandes à employer pour chaque sous-système fournisseur 108. La sélection du type de demande peut également être informée par la détermination au niveau du bloc 515 (p. ex. le serveur 116 peut sélectionner un type de demande pour lequel la détermination au niveau du bloc 515 était négative).

Les demandes de mise à jour, en général, peuvent être des demandes de mise à jour explicites adressées au sous-système fournisseur 108 qui est à l'origine de l'objet de données 400, ou des demandes de nouvelles offres adressées à d'autres sous-systèmes fournisseurs 108. Les demandes de nouvelles offres (p. ex. les demandes NDC AirShopping) peuvent être remplies sur la base du contenu de l'objet de données 400. Ainsi, dans le présent exemple, une demande d'AirShopping peut être transmise au sous-système fournisseur 108-2 pour les vols de Barcelone à Montréal. D'autres attributs (p. ex. les dates, les services auxiliaires et autres similaires) peuvent également être spécifiés. Une demande de mise à jour (p. ex. une demande de NDC OrderReshop) peut être envoyée au sous-système fournisseur 108-1.

Lorsque les demandes de mise à jour ont été envoyées, au bloc 325, le serveur 116 est configuré pour recevoir des ensembles de contenu mis à jour de chaque sous-système fournisseur 108 auquel une demande a été envoyée au bloc 320. Au bloc 330, le serveur 116 est configuré pour évaluer automatiquement les ensembles de contenus mis à jour reçus au bloc 325. Les processus par lesquels le serveur 116 évalue les ensembles de contenu actualisés par rapport au contenu initial (p. ex. l'objet de données 400) dépassent le cadre de cette discussion. En général, le référentiel 120 peut contenir des algorithmes de notation et autres similaires à exécuter par le serveur 116 pour déterminer si un ensemble de contenu de mise à jour donné représente une "meilleure" offre que le contenu initial de l'objet de données 400, ainsi que les autres ensembles de contenu mis à jour.

Lorsque l'évaluation au bloc 330 indique que les ensembles de contenu mis à jour ne représentent pas de meilleures offres, les ensembles de contenu mis à jour peuvent être rejetés et le serveur 116 peut revenir au bloc 310. Toutefois, lorsqu'au moins un des ensembles de contenu mis à jour représente une meilleure offre, le serveur 116 peut automatiquement lancer une ou plusieurs actions pour remplacer le contenu initial, ou peut demander au sous-système client 104 concerné des instructions supplémentaires. Plus précisément, le référentiel 120 peut stocker (p. ex. en association avec les données de mise à jour de la planification de la configuration mentionnées ci-dessus) une indication pour chaque sous-système client 104 indiquant si le remplacement du contenu doit être effectué automatiquement.

Lorsque le serveur 116 est configuré (p. ex. pour le sous-système client 104 associé à l'objet de données 400) pour effectuer automatiquement le remplacement du contenu, au bloc 335 le serveur 116 sélectionne la meilleure offre parmi les ensembles de contenu mis à jour reçus au bloc 325, et génère au moins une demande de remplacement pour réserver le contenu mis à jour.

Dans d'autres exemples, comme mentionné, le serveur 116 est configuré pour demander au sous-système client 104 associé à l'objet de données 400 avant de passer au bloc 335. Autrement dit, les performances du bloc 330 comprennent à la fois d'identifier une meilleure offre et de déterminer si le sous-système client 104 concerné a donné l'instruction au serveur 116 de remplacer l'objet de données 400 par cette meilleure offre. Le serveur 116 peut donc compléter la performance du bloc 330 en envoyant un message au sous-système client 104 indiquant le contenu du contenu mis à jour sélectionné, et en attendant une sélection ou un rejet du contenu mis à jour du sous-système client 104. Lorsqu'une sélection est reçue, le serveur 116 passe au bloc 335. Sinon, le serveur 116 renvoie au bloc 310.

La nature de la ou des demandes de remplacement envoyées au bloc 335 varie selon le sous-système fournisseur 108 associé au contenu initial de l'objet de données 400, et le sous-système fournisseur 108 associé au contenu mis à jour sélectionné. Par exemple, les demandes de remplacement peuvent inclure une demande d'annulation au sous-système fournisseur 108 associé à l'objet de données 400 et une demande de réservation correspondant au contenu mis à jour sélectionné. Lorsque le contenu mis à jour sélectionné et le contenu initial correspondent au même sous-système fournisseur 108, une seule demande de remplacement sous la forme d'une demande de mise à jour (p. ex. OrderReshop) peut être utilisée au bloc 335. Dans d'autres exemples encore, le serveur 116 peut envoyer une seule demande de réservation au bloc 335, et ne prendre aucune mesure spécifique par rapport au contenu initial. Au lieu de cela, le contenu initial peut être laisser aller à expiration.

Des variantes des systèmes et procédés ci-dessus sont envisagées. Par exemple, bien que le délai d'expiration mentionné ci-dessus soit discuté en relation avec l'expiration d'un délai de paiement pour une réservation, divers autres délais d'expiration peuvent également être utilisés avec les processus discutés dans les présentes. Par exemple, certains contenus peuvent être associés à des périodes d'annulation arrivées à échéance, au-delà desquels l'annulation du contenu initial entraîne des frais.

Les hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité de l’application 212 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.

Claims

Un procédé d'optimisation de la transmission de demandes de contenu mis à jour provenant de sources de données externes, comprenant :
de stocker, au niveau d'un serveur d'intermédiation, un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à un délai d'expiration ;
de stocker, au niveau du serveur d'intermédiation, un ensemble de paramètres d'optimisation ;
d'obtenir une instruction au niveau du serveur d'intermédiation pour demander la mise à jour du contenu correspondant à l'objet de données ;
en réponse à l'obtention de l'instruction, de déterminer, sur la base des paramètres d'optimisation et du délai d'expiration, s'il convient de demander un contenu mis à jour auprès des sources de données externes ;
lorsque la détermination est affirmative, de transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et
en réponse à la transmission de ladite au moins une demande de mise à jour, de recevoir et de stocker des ensembles respectifs de contenu mis à jour à partir des sources de données externes.
Le procédé de la revendication 1, comprenant par ailleurs :
en réponse à la réception et au stockage des ensembles de contenu mis à jour, d'évaluer chaque ensemble de contenu mis à jour par rapport au contenu initial ; et
de déterminer, sur la base des évaluations, s'il convient de remplacer le contenu initial par un ensemble sélectionné du contenu mis à jour.
Le procédé de la demande 2, dans lequel la détermination du remplacement du contenu initial par l'ensemble sélectionné du contenu mis à jour comprend l'envoi d'une sollicitation contenant au moins un des ensembles de contenu mis à jour à un sous-système client pour sélection.
Le procédé de la revendication 2, dans lequel la détermination du remplacement du contenu initial par l'ensemble sélectionné du contenu mis à jour comprend le remplacement automatique du contenu initial par l'ensemble sélectionné du contenu mis à jour.
Le procédé de l'une quelconque des revendications 1 à 4, dans lequel l'obtention de l'instruction comprend de recevoir l'instruction au niveau du serveur d'intermédiation à partir d'un sous-système de client.
Le procédé de l'une quelconque des revendications 1 à 5, comprenant par ailleurs :
de stocker, au niveau du serveur d'intermédiation, des données de mise à jour de la planification de la configuration ; dans lequel l'obtention de l'instruction comprend la génération de l'instruction au niveau du serveur d'intermédiation en fonction des données de la planification de la configuration.
Le procédé de l'une quelconque des revendications 1 à 6, dans lequel les paramètres d'optimisation comprennent au moins un de : (i) une demande de mise à jour du seuil de fréquence, et (ii) un seuil temporel ; et
dans lequel la détermination de la nécessité de demander un contenu mis à jour comprend au moins un de (i) déterminer si la demande de mise à jour du seuil de fréquence a été dépassée, et (ii) déterminer si une différence entre une heure actuelle et l'heure d'expiration est inférieure au seuil de temps.
Le procédé de l'une des revendications 1 à 7, dans lequel les paramètres d'optimisation comprennent des données des tendances historiques correspondant au contenu initial ; et dans lequel la détermination de la nécessité de demander un contenu mis à jour comprend :
d'identifier les données des tendances actuelles correspondant au contenu initial ;
de comparer les données des tendances actuelles aux données des tendances historiques et
lorsque les données des tendances actuelles et les données des tendances historiques concordent, de déterminer s'il convient de demander un contenu mis à jour sur la base des données des tendances historiques.
Un serveur d'intermédiation pour optimiser la transmission des demandes pour un contenu mis à jour à partir de sources de données externes, le serveur d'intermédiation comprenant :
une mémoire stockant (i) un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à une heure d'expiration, et (ii) un ensemble de paramètres d'optimisation ;
une interface de communication ; et
un processeur connecté à l'interface de communication et à la mémoire, le processeur étant configuré pour:
obtenir une instruction au niveau du serveur d'intermédiation pour demander du contenu mis à jour correspondant à l'objet de données ;

en réponse à l'obtention de l'instruction, déterminer, sur la base des paramètres d'optimisation et de l'heure d'expiration, s'il convient de demander un contenu mis à jour à partir des sources de données externes ;

lorsque la détermination est affirmative, transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation et

en réponse à la transmission de ladite au moins une demande de mise à jour, recevoir et stocker des ensembles respectifs de contenu mis à jour à partir des sources de données externes.
Le serveur d'intermédiation de la revendication 9, dans lequel le processeur est configuré par ailleurs pour :
en réponse à la réception et au stockage des ensembles de contenu mis à jour, évaluer chaque ensemble de contenu mis à jour par rapport au contenu initial ; et
déterminer, sur la base des évaluations, s'il convient de remplacer le contenu initial par un ensemble sélectionné du contenu mis à jour.
Le serveur d'intermédiation de la revendication 10, dans lequel le processeur est configuré, pour déterminer s'il convient de remplacer le contenu initial par l'ensemble sélectionné du contenu mis à jour, pour envoyer une sollicitation contenant au moins un des ensembles de contenu mis à jour à un sous-système client pour sélection.
Le serveur d'intermédiation de la revendication 10, dans lequel le processeur est configuré, pour déterminer s'il convient de remplacer le contenu initial par l'ensemble sélectionné du contenu mis à jour, pour remplacer automatiquement le contenu initial par l'ensemble sélectionné du contenu mis à jour.
Le serveur d'intermédiation de l'une quelconque des revendications 9 à 12, dans lequel le processeur est configuré, afin d'obtenir l'instruction, pour recevoir l'instruction au serveur d'intermédiation provenant d'un sous-système client.
Le serveur d'intermédiation de l'une quelconque des revendications 9 à 13, dans lequel le processeur est configuré, afin d'obtenir l'instruction, pour générer l'instruction en fonction des données de la planification de la configuration stockées dans la mémoire.
Le serveur d'intermédiation de l'une quelconque des revendications 9 à 14, dans lequel les paramètres d'optimisation comprennent au moins un de (i) une demande de mise à jour du seuil de fréquence, et (ii) un seuil temporel ; et
dans lequel le processeur est configuré, pour déterminer s'il convient de demander un contenu mis à jour, pour au moins un de: (i) déterminer si la demande de mise à jour du seuil de fréquence a été dépassée, et (ii) déterminer si une différence entre une heure actuelle et l'heure d'expiration est inférieure au seuil temporel.
Le serveur d'intermédiation de l'une quelconque des revendications 9 à 15, dans lequel les paramètres d'optimisation comprennent des données des tendances historiques correspondant au contenu initial ; et dans lequel le processeur est configuré, pour déterminer s'il convient de demander un contenu mis à jour, pour :
identifier les données des tendance actuelles correspondant au contenu initial ;
comparer les données des tendances actuelles aux données des tendances historiques ; et
lorsque les données des tendances actuelles et les données des tendances historiques concordent, déterminer s'il convient de demander un contenu actualisé sur la base des données des tendances historiques.
Un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant :
des moyens de programmes lisibles par ordinateur pour stocker (i) un objet de données contenant un contenu initial reçu d'au moins une des sources de données externes et associé à un délai d'expiration, et (ii) un ensemble de paramètres d'optimisation ;
des moyens de programmes lisibles par ordinateur pour obtenir une instruction au niveau du serveur d'intermédiation pour demander un contenu actualisé correspondant à l'objet de données ;
des moyens de programmes lisibles par ordinateur pour, en réponse à l'obtention de l'instruction, déterminer, sur la base des paramètres d'optimisation et du délai d'expiration, s'il faut demander un contenu mis à jour aux sources de données externes ;
des moyens de programmes lisibles par ordinateur pour, lorsque la détermination est affirmative, transmettre au moins une demande de mise à jour à au moins une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et
des moyens de programmes lisibles par ordinateur pour, en réponse à la transmission de ladite au moins une demande de mise à jour, recevoir et stocker des ensembles respectifs de contenu mis à jour provenant de sources de données externes,
quand ledit programme fonctionne sur un serveur d'intermédiation.