FR3052898A1 - - Google Patents

Abstract

Des systèmes, des procédés et des produits-programmes d'ordinateur pour explorer des registres de requêtes de recherche. Un système d'entrepôt de données incluant une base de données des requêtes qui conservent des données relatives à des requêtes de recherche, une base de données historiques des réservations qui conservent les données relatives à des produits vendus et une application pour entreposer des données qui extrait et traite la requête de recherche et les données de réservation de la base de données des requêtes et de la base de données historiques des réservations pour produire des données statistiques. L'application pour entreposer des données génère des courbes historiques de saisies des requêtes, des réservations et de réservations pour des vols spécifiques, sur la base des données statistiques extraites. Une moyenne pondérée des courbes de saisies des requêtes et des réservations historiques, qui est la mieux adaptée à la courbe de saisies de vol spécifique, est déterminée. Un facteur de pondération ayant produit la meilleure adaptation est ensuite utilisé pour prévoir la demande future de vols.

Description

ENTREPÔT DE DONNÉES POUR REGISTRES DE REQUÊTES DE RECHERCHE

PAR EXPLORATION CONTEXTE

[0001] L'invention concerne de façon générale des ordinateurs et des logiciels et, en particulier, des procédés, des appareils et des produits-programmes d'ordinateur pour l'analyse de larges volumes de données liés à des requêtes de recherche en provenance d'un système de gestion de voyages.

[0002] Dans les dernières décennies, l'industrie du voyage a pris une ampleur significative qui a donné lieu à une augmentation à la fois du nombre de fournisseurs de voyages et de la quantité de données à gérer parmi ces fournisseurs. Au fur et à mesure que le nombre des fournisseurs s'est accru, des intermédiaires fournissant des systèmes de gestion de voyages ont fait leur apparition. Ces systèmes de gestion de voyages gèrent la communication entre le fournisseur de voyages et l'utilisateur final permettant ainsi aux utilisateurs des systèmes d'agence de voyages, des systèmes de réservation des compagnies aériennes et des sites Web de voyages de récupérer les informations d'un grand nombre de systèmes de fournisseurs de voyages.

[0003] Ces utilisateurs envoient souvent des requêtes de recherche de bas tarifs LFS (Low Fare Search) lorsqu'ils recherchent des vols. Les requêtes LFS définissent typiquement, une destination et une ou plusieurs dates et/ou horaires de voyage souhaités entre une origine et une destination. Les systèmes de gestion de voyages répondent typiquement à ces requêtes LFS en déterminant un ensemble d'un ou de plusieurs vols entre l'origine et la destination ainsi qu'un tarif applicable à chaque vol. Les tarifs peuvent être déterminés par un moteur de tarification qui utilise les données tarifaires publiées par un fournisseur de données tarifaires telles qu'APTCO (Airline Tariff Publishing Company) pour calculer les tarifs. Les résultats de recherche incluent typiquement une liste d'options de voyage qui inclut des informations concernant les vols et les tarifs.

[0004] Les requêtes LFS sont souvent utilisées pour identifier des vols potentiels au stade préliminaire de planification d'un voyage. Ainsi les utilisateurs soumettent généralement de multiples requêtes avant de sélectionner et de confirmer un vol. Les passagers sans projet de voyage spécifique peuvent aussi soumettre des requêtes par simple curiosité ou pour déterminer où ils aimeraient voyager. Le nombre de requêtes LFS reçues par les systèmes de gestion de voyages peut donc excéder le nombre de places finalement vendues, par un facteur important. En raison du nombre important des requêtes LFS reçues, les systèmes de gestion de voyages peuvent avoir des difficultés à gérer les requêtes LFS et généralement suppriment les requêtes LFS une fois qu'une réponse leur a été envoyée. Les systèmes de gestion de voyages conventionnels sont donc incapables de fournir des informations détaillées associées aux requêtes LFS qui ont été reçues au cours d'une période.

[0005] Ainsi, des systèmes, des procédés et des produits-programmes d'ordinateur améliorés pour la gestion et l'analyse des requêtes LFS sont nécessaires afin d'améliorer la capacité des systèmes de gestion de voyages à suivre et à fournir des informations liées aux requêtes LFS. RÉSUMÉ [0006] Dans un mode de réalisation de l'invention, un système d'entrepôt de données est révélé. Le système inclut un ou plusieurs processeurs et une mémoire couplée aux processeurs. La mémoire enregistre les premières données comprenant une première base de données des registres de requêtes et des instructions qui, lorsqu'elles sont exécutées par au moins un des processeurs, amènent le système à recevoir une pluralité de requêtes de recherche. Chaque requête de recherche peut être reçue à une heure de réception et peut définir une heure de départ et une paire origine-destination. Les instructions peuvent par ailleurs amener le système à déterminer, pour chaque requête de recherche, un laps de temps entre l'heure de réception et l'heure de départ. Chaque enregistrement d'un registre de requêtes peut aussi indiquer un nombre de places et le laps de temps jusqu’au départ associé à chaque place, pour la paire origine-destination à laquelle l'enregistrement du registre de requête est associé.

[0007] Un procédé de traitement des transactions est également révélé. Le procédé peut inclure la réception d'une pluralité de requêtes de recherche par le système d'entrepôt de données. Chaque requête de recherche peut être reçue à l’heure de réception et peut définir l'heure de départ et la paire origine-destination. Le procédé peut par ailleurs inclure, pour chaque requête de recherche, la détermination du laps de temps avant le départ, à partir de l'heure de réception jusqu'à l'heure de départ de la requête de recherche, et la conservation de secondes données confirmant la réception de la requête de recherche et le laps de temps avant le départ dans l'enregistrement de registre de la requête associé à la paire origine-destination. Chaque enregistrement d'un registre de requêtes peut être conservé dans la première base de données et peut indiquer le nombre de places et le laps de temps avant le départ associé à chaque place de la paire origine-destination à laquelle l'enregistrement de registre de requête est associé.

[0008] Dans un autre aspect de l'invention, les instructions peuvent par ailleurs amener le système à définir un index incluant une pluralité de champs correspondant à une paire origine-destination respective. Chaque champ peut définir l'emplacement de chaque enregistrement d'un registre de requêtes qui est associé à la paire origine-destination respective, dans la première base de données.

[0009] Dans certains exemples, les requêtes sont pour des recherches de bas tarifs.

[0010] Dans un autre aspect de l'invention, les instructions peuvent par ailleurs, amener le système à recevoir une requête pour obtenir les données statistiques d'une paire origine-destination respective pour une période donnée. En réponse à la réception de la requête, le système peut récupérer un ou plusieurs enregistrements de registre de requêtes dans la première base de données. Chacun d'un ou de plusieurs enregistrements de registre de requêtes récupéré peut être associé avec la paire origine-destination et peut inclure des données relatives aux requêtes de recherche définissant une heure de départ respective dans la période. Le système peut extraire les secondes données de chaque enregistrement de registre de requêtes récupéré, générer une première courbe de saisies illustrant l’intensité des requêtes de recherche pour la paire origine-destination respective, par rapport au laps de temps avant le départ pendant la période donnée, sur la base des secondes données et faire une prévision de la demande de places pour la paire origine-destination respective en utilisant la première courbe de saisies.

[0011] Dans certains exemples l'heure de départ, définie par chacun d’un ou de plusieurs enregistrements de registre de requêtes, est expirée au moment où 1a requête est reçue.

[0012] Dans un autre aspect de l'invention, la période peut couvrir une pluralité d'intervalles de départ et les instructions peuvent amener le système à anticiper la demande à l’aide de la première courbe de saisies, en interrogeant une seconde base de données pour obtenir des troisièmes données qui définissent une pluralité de places vendues pour la paire origine-destination respective dont le départ a eu lieu pendant la période. Le système peut par ailleurs générer une seconde courbe de saisies en utilisant les troisièmes données, la seconde courbe de saisies décrivant un nombre de réservations par rapport à l'heure de départ pendant la période. Le système peut générer une troisième courbe de saisies qui représente une moyenne pondérée de la première courbe de saisies et de la deuxième courbe de saisies. La demande de places peut ensuite être anticipée pour la paire origine-destination respective en utilisant la troisième courbe de saisie.

[0013] Dans un autre aspect de l'invention, les instructions peuvent par ailleurs amener le système à déterminer, pour au moins un intervalle de départ couvert sur la période, une courbe cible de saisies pour la paire origine-destination respective, à déterminer un facteur de pondération qui est le mieux adapté entre la troisième courbe de saisies et la courbe cible de saisies, et à prévoir la demande de places pour la paire origine-destination respective pour un intervalle de départ futur en utilisant la troisième courbe de saisies dont la pondération est la mieux adaptée.

[0014] Par exemple, pour au moins un intervalle de départ couvert sur la période, une quatrième courbe de saisies pour la paire origine-destination respective est déterminée et la demande de places pour la paire origine-destination respective pour un intervalle de départ futur est anticipée en utilisant la troisième courbe de saisies dont la pondération est la mieux adaptée, dans laquelle la quatrième courbe de saisies est une courbe cible de saisies.

[0015] Selon un autre aspect de l'invention, pour chaque intervalle de départ futur, une courbe partielle de saisies est déterminée pour les requêtes de recherche qui ont été satisfaites par une solution de voyage respective pour la paire origine-destination respective, dont le départ est prévu pendant l'intervalle de départ futur, une troisième courbe de saisies étant la mieux adaptée à la courbe partielle de saisies est déterminée et la demande de places pour la paire origine-destination respective pour un intervalle de départ futur est anticipée en utilisant la troisième courbe de saisies étant la mieux adaptée à la courbe partielle de saisies.

[0016] Selon un autre aspect de l’invention, la paire origine-destination respective peut être l'une d'une pluralité de paires origine-destination comprenant un réseau de voyage et une première courbe de saisies distincte est générée pour chaque intervalle de départ de chaque paire origine-destination de la pluralité de paires origine-destination.

[0017] Dans d'autres aspects de l'invention, chaque intervalle de départ peut couvrir un jour et/ou la période peut couvrir une année.

[0018] Un programme d'ordinateur est également révélé. Le programme d'ordinateur, par exemple sous la forme d'un produit-programme d'ordinateur, peut inclure un support durable de stockage de données lisibles par ordinateur et un code de programme enregistré sur le support. Le code de programme, lorsqu'il est exécuté par un ou plusieurs processeurs, peut amener les processeurs à recevoir une pluralité de requêtes de recherche. Chaque requête de recherche peut être reçue à l'heure de réception et peut définir l'heure de départ et la paire origine-destination. Pour chaque requête de recherche, le code de programme peut amener les processeurs à déterminer le laps de temps avant le départ, à partir de l'heure de réception jusqu’à l'heure de départ de la requête de recherche, et conserver les secondes données, indiquant la réception de la requête de recherche et l'heure de départ, dans l'enregistrement de registre de requête associé à la paire origine-destination. Chaque enregistrement de registre peut indiquer le nombre de places et l'heure de départ associée à chaque place de la paire origine-destination à laquelle l'enregistrement de registre de requête est associé.

[0019] Le résumé ci-dessus peut présenter une vue d'ensemble simplifiée de certains modes de réalisation de l'invention afin d'apporter une compréhension basique de certains aspects de l'invention discutés dans les présentes. Le résumé n'a pas pour but de donner une vue globale extensive de l’invention et ne prétend ni identifier un quelconque élément clé ou décisif, ni limiter la portée de l’invention. Le seul but du résumé est simplement de présenter des concepts sous une forme simplifiée à titre de préambule à la description détaillée présentée ci-dessous.

BRÈVE DESCRIPTION DES DESSINS

[0020] Les dessins font partie intégrante des spécifications ; ils illustrent des modes variés de réalisation de l'invention et, conjointement à la description générale de l'invention ci-dessus et la description détaillée des modes de réalisation fournie ci-après, servent à expliquer les modes de réalisation de l'invention.

[0021] La FIG. 1 est une vue schématique d'un environnement exemplaire incluant un système de gestion de voyages en communication avec une base de données de requêtes et une base de données historiques.

[0022] La FIG. 2 est une vue schématique d'un ordinateur exemplaire pouvant être utilisé pour fournir l'environnement d'exploitation de la FIG. 1.

[0023] La FIG. 3 est une vue schématique d'un système d'entrepôt de données incluant un module de prévision de la demande et un module de collection de données en communication avec les bases de données des requêtes de recherche et des réservations historiques de la FIG.l.

[0024] La FIG. 4 est une représentation graphique d'une paire de courbes pouvant être générées par le module de prévision de la demande de la FIG. 3.

[0025] La FIG. 5 est une représentation graphique des courbes de saisies de la FIG. 4 et d'une courbe de saisies de requêtes pouvant être générée en utilisant les données extraites de la base de données des requêtes de la FIG. 1.

[0026] La FIG. 6 est un diagramme séquentiel d'un processus de détermination d'un facteur de pondération pouvant être utilisé pour incorporer des données de requêtes de recherche dans le processus de prévisions.

[0027] La FIG. 7 est une représentation graphique d'une courbe de saisies de requêtes et d'une courbe potentielle de saisies de requêtes pouvant être utilisée pour corriger la prévision de la demande antérieure.

[0028] La FIG. 8 est un diagramme séquentiel d'un processus de correction de la prévision de la demande utilisant une courbe historique de saisies de requêtes et la courbe potentielle de saisies de requêtes de la FIG. 7.

DESCRIPTION DÉTAILLÉE

[0029] Les modes de réalisation de l'invention peuvent être mis en œuvre à l'aide d'un système de traitement de données fournissant des fonctions de base de données qui conservent, indexent, catégorisent et organisent les requêtes de recherche reçues par un système de gestion de voyages. Le système de gestion de voyages peut être configuré pour faciliter les interconnexions entre un ou plusieurs systèmes informatiques et systèmes de base de données. Les systèmes infonnatiques et les systèmes de base de données peuvent inclure un ou plusieurs systèmes de fournisseurs, des systèmes de gestion de base de données, des systèmes d'utilisateurs, et/ou tout autre système informatique ayant un lien avec l'apport de produits de voyage. Dans le contexte du voyage aérien, le système de gestion de voyages peut permettre aux voyageurs de rechercher et d’acheter des billets d'avion par l'entremise de multiples chames de vente et/ou de fournisseurs de produits de voyage. Un système d'entrepôt de données peut être configuré pour explorer et collecter les données relatives aux requêtes de recherche reçues du système de gestion de voyages et pour remplir de nouveaux enregistrements de base de données et/ou de systèmes avec des données fondées sur les données d'exploration, sous une forme traitée qui peut rapidement et facilement être analysée.

[0030] Faisant maintenant référence à la FIG. 1, un environnement d'exploitation 10 conforme à un des modes de réalisation de l'invention peut inclure un système de gestion de voyages 12, une base de données des requêtes 14, une base de données historiques des réservations 16, un système de fournisseur 18 et un système d'utilisateur 20. Chacun des systèmes : le système de gestion de voyages 12, la base de données des requêtes 14, la base de données historiques des réservations 16, le système fournisseur 18 et le système utilisateur 20 peuvent communiquer via un réseau 22. Le réseau 22 peut inclure un ou plusieurs réseaux privés ou publics (par ex., Internet) qui permettent l'échange de données entre des systèmes connectés via le réseau 22.

[0031] Le système de gestion de voyages 12 peut être configuré pour recevoir et traiter des requêtes provenant du système utilisateur 20. Le système utilisateur 20 peut être le système d'une agence de voyages, le système de réservation d'une compagnie aérienne, le système d'un site Web de voyages, ou tout autre système utilisé pour rechercher, réserver et acheter des produits de voyage. Les requêtes reçues par le système de gestion de voyages 12 peuvent inclure, par exemple, des requêtes de recherche telles que des recherches de bas tarifs LFS (Low Fare Search). Chaque requête de recherche peut inclure un ou plusieurs termes de recherche. Les termes de recherche peuvent inclure, par exemple, une origine, une destination, une quantité de places exigée, et une période de voyage désirée. En réponse à la réception d'une requête de recherche, le système de gestion de voyages 12 peut interroger un ou plusieurs systèmes de réservation des bases de données cache, ou toute autre source appropriée de solutions tarifées de voyage correspondant aux termes de la requête de recherche. Le système de gestion de voyages 12 peut traiter et renvoyer toutes, les solutions tarifées de voyage reçues, ou une portion d’entre elles, dans les résultats de recherche, au système utilisateur 20.

[0032] Les requêtes de recherche et/ou les données relatives à la définition, ou autrement la caractérisation des requêtes de recherche, peuvent être conservées dans la base de données des requêtes 14. Les données relatives aux requêtes de recherche peuvent inclure l'origine et la destination définies par la requête de recherche, l'heure à laquelle la requête de recherche a été reçue par le système de gestion de voyages 12 (ou « heure de réception »), un nombre de places demandé pour voyager d'une origine vers une destination, les horaires de voyage souhaités, ou tout autre paramètre relatif aux requêtes de recherche ou définis par celles-là.

[0033] Avant de réserver un vol, un utilisateur (p. ex., le voyageur ou l'agent de voyage travaillant pour le voyageur) peut rechercher des solutions de voyage qui satisfont les exigences du voyageur. Dans ce but, l'utilisateur peut saisir des termes de recherche dans l'application client telle que le navigateur Web ou une application de réservation fonctionnant sur le système utilisateur 20. L'application client peut ensuite transmettre une requête de recherche incluant les termes de la recherche à un serveur d'applications correspondant du système de gestion de voyages 12. L'utilisateur peut effectuer des recherches multiples pendant un temps avant de sélectionner et de réserver un ou plusieurs sièges ou « places », d'une solution de voyage. Ces recherches peuvent être effectuées lors d'une seule session, ou peuvent être effectuées au cours de sessions distinctes pendant une période. Quel que soit le cas, l'utilisateur peut éventuellement acheter une place proposée par une solution de voyage ou décider d'abandonner le voyage et mettre fin à la recherche de solutions de voyage à ce stade.

[0034] En réponse à la réception d'une requête de recherche en provenance de l'application client, le serveur d'applications peut déterminer les solutions de voyage qui satisfont les termes de la recherche. Le serveur d'application peut aussi faire des recherches dans la base de données des requêtes 14 pour interroger les enregistrements de registre correspondant à une paire origine-destination définie par la requête de recherche. Si l'enregistrement de registre de requête n'est pas trouvé pour la paire origine-destination, le serveur d'applications peut demander à la base de données des requêtes 14 de créer un enregistrement. Chaque enregistrement de registre de requête correspond à une paire origine-destination spécifique et à un intervalle de départ spécifique, p. ex., un jour spécifique, une semaine ou toute autre période pour laquelle la demande doit être anticipée. L'enregistrement de registre de requête peut aussi correspondre à un vol spécifique, en plus de l'intervalle de départ ou à sa place. La base de données des requêtes 14 peut aussi conserver les requêtes de recherche elles-mêmes ou toutes autres données relatives aux requêtes de recherche, en plus des enregistrements de registre de requête, ou à leur place.

[0035] Chaque enregistrement de registre de requête peut inclure un ou plusieurs champs pour enregistrer les données. Ces champs peuvent inclure, par exemple, un champ d'origine contenant les données qui définissent l'origine, un champ de destination contenant les données qui définissent la destination, un champ pour le vol et/ou un intervalle de départ contenant les données qui définissent la période de départ et un champ de compteur contenant les données qui définissent le nombre de fois qu'une requête de recherche a été reçue par le serveur d'applications avec des termes de recherche correspondant à la paire origine-destination et à l'heure à laquelle chacune des requêtes correspondantes a été reçue. Lorsqu'une requête de recherche est reçue par l'application de serveur, l'application de serveur peut ajouter des données aux champs du compteur pour chacun des enregistrements de registre de requête correspondant afin d'indiquer qu'une requête de recherche correspondante a été reçue. Le champ du compteur peut aussi inclure des données indiquant le nombre de places demandées par chaque requête de recherche. Le champ du compteur peut inclure un compteur qui est incrémenté par le nombre de places demandées dans la requête de recherche à chaque fois qu'une requête de recherche est reçue correspondant à l’enregistrement de registre de requête.

[0036] La base de données historiques des réservations 16 peut stocker des données relatives aux réservations qui ont été confirmées. Une fois qu'une ou plusieurs solutions de voyage appropriées sont identifiées par Tutilisateur, le système utilisateur 20 peut transmettre une requête à l'application de serveur demandant la confirmation de place(s) proposée(s) dans la ou les solution(s) de voyage. Cette requête peut être transmise à un ou à plusieurs systèmes de réservation. Si la requête est acceptée par les systèmes de réservation, une réservation peut être effectuée (p. ex., en créant un enregistrement de nom de passager dans une base de données d'enregistrements de noms de passagers) et un inventaire des places disponibles dans la classe de réservation correspondante de la solution de voyage réduit par le nombre de places confirmées.

[0037] En réponse à la réception d'une confirmation de la part du ou des système(s) de réservation, indiquant que la réservation de la place demandée a été confirmée, l'application du serveur peut demander à la base de données historiques des réservations 16 de créer et/ou de modifier un enregistrement de réservation pour indiquer que la réservation de la place correspondante a été confirmée et l'heure de la confirmation. Ces données peuvent être sauvegardées dans la base de données historiques des réservations pendant une période (p. ex., une année) après le départ des vols correspondant aux enregistrements de réservation.

[0038] Le système fournisseur 18 peut inclure un système de réservation informatique CRS (Computer Réservation System) qui permet au système de gestion des voyages de réserver et de payer des produits de voyage tels que des billets d'avion, des chambres d'hôtel, ou des véhicules de location. Pour les fournisseurs de voyages aériens, le CRS peut gérer des réservations pour des places entre des nœuds d'un réseau de voyage. Chaque nœud du réseau de voyage peut comprendre une station (p. ex., un aéroport) à partir duquel et vers lequel des vols dont gérés par le fournisseur. Le système fournisseur 18 peut aussi interagir avec d'autres systèmes de fournisseurs, soit directement, soit par l'entremise du système de gestion de voyages 12, pour permettre au transporteur émetteur de vendre des billets pour des places fournies par le transporteur de fait. Le transporteur de fait peut ensuite facturer le transporteur émetteur pour les produits fournis.

[0039] Faisant maintenant référence à la FIG. 2, le système de gestion de voyages 12, la base de données des requêtes 14, la base de données historiques des réservations 16, le système fournisseur 18, le système utilisateur 20 et le réseau 22 de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques tels que l'ordinateur exemplaire 30. L'ordinateur 30 peut inclure un processeur 32, une mémoire 34, un dispositif de stockage de mémoire de masse 36, une interface entrée/sortie (I/O) 38, et une interface homme-machine (HMI) 40. L'ordinateur 30 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources extérieures 42 par l'intemiédiaire du réseau 22 ou de l’interface I/O 38. Les ressources externes peuvent inclure, sans s’y limiter, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée qui peut être utilisée avec l'ordinateur 30, [0040] Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : des microprocesseurs, microcontrôleurs, des processeurs de signaux numériques, des micro-ordinateurs, des unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base d’instructions de fonctionnement enregistrées dans la mémoire 34. La mémoire 34 peut inclure un dispositif unique ou une pluralité de dispositifs de mémoire, notamment, mais sans s’y limiter, la mémoire à lecture seule (read-only memory (ROM), la mémoire à accès aléatoire (random access memory (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache memory), ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 36 peut inclure des dispositifs de stockage de données, tels qu’un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile, ou tout autre dispositif capable de stocker des informations.

[0041] Le processeur 32 peut fonctionner sous le contrôle d'un système d'exploitation 44 qui réside dans la mémoire 34. Le système d'exploitation 44 peut gérer les ressources informatiques afin que le programme codé de l'ordinateur, intégré sous la forme d'une ou plusieurs applications logicielles telles que l'application 46 qui réside dans la mémoire 34, puisse recevoir les instructions exécutées par le processeur 32. Le processeur 32 peut aussi exécuter l'application 46 directement, et dans ce cas le système d'exploitation 44 peut être omis. La ou les applications logicielles peuvent inclure un cas de fonctionnement comportant un serveur qui peut accepter des requêtes des applications clientes et leur fournir des réponses. Une ou plusieurs structures de données 48 peuvent aussi résider dans la mémoire 34 et peuvent être utilisées par le processeur 32, le système d'exploitation 44, et/ou l'application 46 pour stocker ou manipuler des données.

[0042] L'interface I/O 38 peut fournir une interface machine qui couple de manière opérationnelle le processeur 32 à d'autres dispositifs et systèmes tels que le réseau 22 ou la ressource externe 42. Le serveur d’application 46 peut ainsi collaborer avec le réseau 22 ou avec la ressource externe 42 en communiquant par l'intermédiaire de l'interface I/O 38 pour fournir les divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l'invention. L'application 46 peut aussi comporter un code de programme qui est exécuté par une ou plusieurs ressources externes 42, ou autrement repose sur les fonctions ou signaux fournis par d'autres composants de système ou de réseau externes à l'ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, on comprend que les modes de réalisation de l'invention peuvent inclure des applications situées à l'extérieur de l'ordinateur 30, distribuées à des ordinateurs multiples ou à d'autres ressources externes 42 ou fournies par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel qu'un service informatique cloud, par l'intermédiaire du réseau 22, [0043] Le HMI40 peut être couplé de façon fonctionnelle au processeur 32 de l'ordinateur 30 pour permettre à un utilisateur d'interagir directement avec l’ordinateur 30. Le HMI 40 peut inclure un écran vidéo ou alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de fournir des données à l'utilisateur. Le HMI 40 peut aussi inclure des dispositifs et des contrôles de saisie tels qu'un clavier alphanumérique, un dispositif de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou une saisie de Tutilisateur, et de transmettre la saisie au processeur 32.

[0044] Une base de données 50 peut résider sur le dispositif de mémoire de masse 36 et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. La base de données 50 peut inclure des données et accommoder les structures de données associées qui stockent et organisent les données. En particulier, la base de données 50 peut être aménagée avec toute organisation ou structure de base de données, notamment, mais sans s’y limiter, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, une base de données orientée-objet ou des combinaisons de celles-là.

[0045] Un système de gestion de bases de données sous forme d'application logicielle qui s'exécute sous la forme d'instructions sur le processeur 32 peut être utilisé pour accéder aux informations ou aux données stockées dans des enregistrements de la base de données 50 en réponse à une requête, lorsqu’une requête peut être déterminée de façon dynamique et exécutée par le système d'exploitation 44, d'autres applications 46 ou un ou plusieurs modules. Bien que des modes de réalisation de l'invention puissent être décrits dans les présentes en utilisant une terminologie de base de données relationnelle, hiérarchique, de réseau, orientée-objet, ou autre terminologie dans des cas spécifiques, les hommes de métier comprendront que les modes de réalisation de l’invention peuvent utiliser tout modèle approprié de gestion de base de données, et ne sont pas limités à tout type particulier de base de données.

[0046] Dans le contexte du voyage aérien, un « marché » peut désigner un aller simple entre un point d'origine spécifique et une destination spécifique, ou une paire origine-destination. La demande pour des places dans un marché peut désigner le nombre de places que les clients voudraient réserver sur le marché si l'offre était illimitée. Les places sur un marché peuvent être réparties entre des vols et/ou des fournisseurs multiples. L'inventaire d'un fournisseur peut contenir tous les vols avec leurs sièges disponibles. Une place peut se distinguer d'un siège sur la base du concept de la surréservation. La surréservation désigne la pratique qui consiste à ce que les fournisseurs vendent plus de places qu'il n'existe de sièges physiques sur un vol par anticipation de l'absence de passagers au moment du départ qui libérera des sièges. La demande peut dépendre de facteurs tels que le prix des places et l'heure de départ des places de leur point d'origine. Par exemple, la demande sur un marché particulier peut varier en fonction du prix, du jour de la semaine pour le départ du vol, et/ou de la période de l'année.

[0047] Un segment peut désigner le trajet effectué par un avion de ligne entre un point où les passagers montent à bord de l'appareil et un autre point où les passagers sortent de l'appareil pour la dernière fois. Un segment peut inclure tout nombre d'arrêts où les passagers peuvent sortir et remonter à bord du même appareil. Une étape peut désigner le trajet effectué par un avion de ligne d'une station de départ prévue à la prochaine station d'arrivée prévue. Ainsi, un segment peut inclure une ou plusieurs étapes effectuées par un seul avion de ligne.

[0048] Un vol peut désigner un ou plusieurs segments effectués ayant le même indicateur de vol et peut impliquer plus d'un appareil. Une solution de voyage peut désigner une combinaison d'un ou plusieurs vols qui constituent un aller simple à partir d'une origine spécifique vers une destination spécifique et qui décollent de l'origine à une heure spécifique. Ainsi, une solution de voyage peut inclure un cas de voyage spécifique entre une origine et une destination. Des solutions de voyage correspondant aux critères de la requête de recherche o peuvent être envoyées dans les résultats de recherche, et si une place proposée dans la solution de voyage est disponible, la personne qui a initié la recherche peut réserver la place pour voyager de l'origine à la destination.

[0049] La FIG. 3 décrit un système pour entreposer des données 60 pouvant héberger une ou plusieurs bases de données de requêtes 14, la base de données historiques des réservations 16, une application pour entreposer des données 62, une base de données d'inventaire 64, et/ou une base de données tarifaires 66. L'application pour entreposer les données 62 peut être hébergée par le système de gestion de voyages 12 ou par tout autre système approprié et peut fournir des fonctions d'analyse de données et de production de rapports. Dans ce but, l'application pour entreposer les données 62 peut inclure un module de collection de données 68, un module de prévision de la demande 70, un module d'attribution de places 72 et un module de tarification 74. Ces modules peuvent récupérer des données actuelles et historiques à partir de la base de données de requêtes 14 et de la base de données historiques des réservations 16, utiliser ces données pour créer des rapports de données et/ou d'analyse, et entreposer les rapports et/ou les données dans une ou plusieurs bases de données d'inventaire 64 et bases de données tarifaires 66. Ces rapports d'analyse et/ou de données peuvent inclure des prévisions de demande, des courbes de saisies, des recommandations d'attribution de places, et/ou des recommandations tarifaires.

[0050] Le module de collection de données 68 peut récupérer des données actuelles et historiques relatives à un nombre de requêtes de recherche reçues concernant un voyage dans chaque marché dans la base de données des requêtes 14 et des données historiques, relatives à un nombre de places vendues dans chaque marché, dans la base de données historiques des réservations 16. Le module de prévision de la demande 70 peut utiliser les données collectées par le module de collection de données 68 pour prévoir la demande de places, pour chaque marché. Ces prévisions peuvent être utilisées par le module d'attribution de places 72 pour émettre des rapports et/ou affecter les places d'une base de données d'inventaire 64 et par le module de tarification 74 pour émettre des rapports et/ou fixer des tarifs dans la base de données tarifaires 66. Dans un mode de réalisation de l'invention, la base de données tarifaires 66 peut être gérée par ATPCO.

[0051] Le module d'attribution de places 72 et le module de tarification 74 peuvent collaborer pour optimiser les recettes du transporteur en établissant une pluralité de classes tarifaires à l'intérieur de chaque marché desservi par le transporteur, en répartissant l'inventaire du transporteur entre les classes et en fixant un prix pour les unités de l'inventaire (p. ex., les places) dans chaque classe. Le module de prévision de la demande 70 peut surveiller la demande pour des billets dans chaque classe tarifaire par rapport à la prévision de la demande et actualiser la prévision de la demande sur cette base. Le volume d'inventaire mis à disponibilité et la tarification de chaque classe tarifaire, pour chaque vol dans chaque marché, peuvent à leur tour être ajustés par le module d'attribution de places 72 et par le module de tarification 74 sur la base de la prévision actualisée de la demande. L'objectif du module d'attribution de places 72 et du module de tarification 74 peut être d'affecter suffisamment d'inventaire aux passagers voyageant à tarif réduit de sorte que chaque avion soit plein au décollage, mais de ne pas attribuer trop d'inventaire à prix réduit aux passagers ayant réservé tôt empêchant ainsi les passagers de réserver plus tard une place à plein tarif sur le vol.

[0052] Si la prévision de la demande est précise, le module d'attribution de places 72 et le module de tarification 74 peuvent fixer des prix et répartir l'inventaire de façon à permettre à chaque vol d'être plein, ou presque plein, en faisant de sorte qu'une vente à prix réduit ne se fasse pas au détriment d'une vente à plein tarif. Les systèmes conventionnels peuvent prévoir la demande future en grande partie sur la base de la demande historique pour des places dans chaque marché. Ce fondement sur la demande antérieure peut produire des erreurs de prévision. Les erreurs de prévision peuvent conduire à des attributions moins qu'optimales de la capacité disponible entre marchés et entre classes dans chaque marché.

[0053] Par exemple si la demande prévue est moindre que la demande actuelle, trop de places peuvent être mises à disposition pour les passagers voyageant à tarif réduit. Il est possible, par conséquent, que les places soient vendues tôt, de sorte que les passagers réservant plus tard à plein tarif ne puissent pas acheter de billet. En revanche, si la prévision de la demande est plus importante que la demande actuelle, trop peu de places peuvent être mises à disposition assez tôt pendant la période de réservation pour les passagers voyageant à tarif réduit. Par conséquent, un avion peut décoller avec des sièges vides lorsque la demande prévue ne se matérialise pas. Des erreurs de prévision peuvent aussi conduire à une tarification moins qu'optimale de l'inventaire. Ne serait-ce que pour ces raisons, des erreurs de prévisions ont pour conséquence un manque à gagner pour le fournisseur par rapport aux recettes qui auraient pu être réalisées si la demande avait été anticipée correctement.

[0054] La prévision et l'optimisation peuvent apporter deux ensembles d'informations qui peuvent être utilisés pour la gestion des recettes. La prévision peut anticiper combien de places seront vendues dans un marché, et quand les places seront vendues par rapport à l'heure de départ. L'optimisation peut déterminer, sur la base de cette demande anticipée combien de places doivent être mises à disposition dans chaque classe de réservation pour le marché et à quel moment les places doivent être disponibles pour la réservation, c.-à.-d. à quel moment il faut ouvrir et fermer chaque classe de réservation.

[0055] Parce que les décisions d'attribution de places et de tarification sont enracinées dans la prévision de la demande, l'anticipation correcte de la demande a un impact direct sur le fonctionnement du système d'entrepôt de données 60. Les transporteurs peuvent utiliser la prévision de la demande pour déterminer le volume de capacité à fournir. Les prévisions à court terme peuvent être utilisées pour prendre des décisions telles que la tarification et l'affectation de capacité entre diverses classes de réservation pour des vols programmés. Les prévisions à long terme peuvent être utilisées pour prendre des décisions concernant les routes sur lesquelles porte l'offre, sur quels marchés se positionner, et le nombre et type d'appareils à acheter ou à louer.

[0056] Faisant maintenant référence au tableau 1, un tableau exemplaire de saisies est décrit pour des réservations sur des vols qui ont décollé, dans un marché particulier. Le tableau 1 peut être généré, par exemple, en utilisant des données conservées dans la base de données historiques des réservations 16. Le tableau de saisies inclut des colonnes et des rangs qui définissent des cellules, chaque cellule incluant des données qui sont associées au rang et à la colonne qui définissent la cellule. Chaque cellule peut être associée à un pointeur qui pointe vers un emplacement dans la mémoire où les données de la cellule sont enregistrées. Les données peuvent être calculées à partir de données enregistrées dans la base de données historiques des réservations 16, selon le besoin, ou elles peuvent être calculées antérieurement et enregistrées en mémoire.

[0057] Les données dans chaque cellule peuvent définir un nombre de places qui ont été vendues sur le marché à un moment spécifique avant la fin de la période de réservation (p. ex. x jours avant le départ), avec le moment spécifié correspondant à la colonne respective. Les colonnes peuvent être arrangées par ordre de temps croissant avant le départ, avec la colonne la plus à gauche (p. ex., la colonne A) correspondant au laps de temps le plus court avant le départ (p. ex., un Jour) et la colonne la plus à droite (p. ex., la colonne 1) correspondant au laps de temps le plus long avant le départ (p. ex., 360 jours). Le nombre de places dans chaque cellule peut être pour des places dont le départ a eu lieu pendant un intervalle de départ (p. ex., tous les vols partants sur une base quotidienne) correspondant au rang respectif de la cellule. Dans un mode de réalisation de l'invention, les données dans le tableau de saisies peuvent aussi inclure des places dont le départ est programmé. C’est-à-dire que le tableau peut inclure des données pour des vols qui n’ont pas encore décollé.

[0058] La période de réservation peut définir une durée pendant laquelle des places peuvent être réservées pour un départ pendant l'intervalle de départ correspondant. Les périodes typiques de réservation peuvent couvrir une période relativement longue, p. ex., six à douze mois, alors qu'un intervalle de départ typique peut couvrir une période relativement courte, p. ex., un à sept jours. La période de réservation peut aussi être couverte par les colonnes du tableau 1, de sorte que la colonne la plus à droite (p.ex., la colonne I) représente le tout premier moment auquel la solution de voyage peut-être réservée (p. ex., une année avant la date de départ). Il faut comprendre que la période de vente, l'intervalle de départ, le nombre de rangs et le nombre de colonnes du tableau 1 sont uniquement donnés à titre exemplaire et que les modes de réalisation de l'invention ne sont pas limités à une durée de temps particulière ou à la taille du tableau.

[0059] Chaque colonne peut correspondre à un échantillon de temps avant, ou à la date de départ, pour des places dans le rang correspondant. Ces échantillons de temps peuvent être espacés de façon égale (p. ex., des intervalles d'un jour ou d'une semaine), ou à de façon décalée avec un espacement qui change au fur et à mesure que la durée avant le départ diminue (p. ex., de façon à ce que l'intervalle entre les colonnes diminue au fur et à mesure que la date de départ approche).

[0060] Comme exemple de moments décalés, la colonne A représente un nombre total de places réservées au moment du départ pour des vols partant pendant l'intervalle de départ (p. ex., tous les vols partant le jour « 0 », le jour « 1 », etc.), la colonne B peut représenter le nombre total de places réservées 7 jours avant le départ, la colonne C peut représenter le nombre total de places réservées 14 jours avant le départ, la colonne D peut représenter le nombre total de places réservées 21 jours avant le départ, la colonne E peut représenter le nombre total de places réservées 28 jours avant le départ, la colonne F peut représenter le nombre total de places réservées 60 jours avant le départ, la colonne peut représenter le nombre total de places réservées 90 jours avant le départ, la colonne H peut représenter le nombre total de places réservées 180 jours avant le départ et la colonne I peut représenter le nombre total de places réservées 360jours avant le départ.

[0061] L'intervalle de départ peut correspondre à la durée entre chaque rang du tableau 1 et peut définir un échantillon de taux pour analyser les réservations. L'intervalle de départ peut être différent de l'espacement des échantillons de temps, ou peut coïncider avec l'espacement des échantillons de temps. Par exemple, l'intervalle de départ coïnciderait avec l'espacement de temps si l'intervalle de départ et l'espacement entre échantillons de temps, pour la solution de voyage, étaient tous deux d'un jour.

[0062] Pour les valeurs exemplaires ci-dessus, avec des échantillons de temps d'une semaine et un intervalle de départ d'un jour, la cellule définie par le rang O et la colonne A du tableau 1 indiquerait qu'au total 100 sièges auraient été vendus au moment du départ pour des vols ayant décollé le jour 0, qui peut être l'intervalle disponible de départ le plus récent pour les places de la solution de voyage dont le départ a eu lieu. La cellule définie par le rang O et la colonne B du tableau 1 indiquerait par ailleurs qu'une semaine avant le jour O (c.-à.-d. - 7 jours), 60 sièges étaient réservés sur des vols partant le jour O ; cela peut indiquer que 40 sièges ont été réservés sur des vols partant le jour O pendant la dernière semaine de la période de réservation. De façon similaire, la cellule définie par le rang -1 et la colonne A du tableau 1 indiquerait qu’au total 96 sièges étaient réservés avant le départ pour des vols partant à l'intervalle de départ -1, ce qui serait le jour avant l'intervalle de départ 0 c.-à-d.-d le jour -1).

[0063] La prévision quantitative peut utiliser des données historiques pour prédire la demande future.

Ce type de prévision peut être basé sur l’hypothèse que les tendances historiques vont continuer. La prévision quantitative peut utiliser des méthodes statistiques basées sur le temps, telles que la projection de tendances et les moyennes mobiles pour prédire la demande future sur la base des données historiques. En utilisant les données du tableau 1, à titre d'exemple, un type d'analyse quantitative peut déterminer un nombre moyen de réservations saisies entre des échantillons de temps (p. ex., entre A, B, C et D) pour des intervalles de départ dont les vols ont décollé (p. ex., les intervalles de départ 0,-1, -2, -3 et -4). La saisie des réservations PUd entre des échantillons de temps x et_y pour un intervalle de départ particulier D peut être exprimée par :

Eqn. 1

La moyenne des saisies PUavg peut être déterminée en utilisant :

Eqn. 2 où n est le nombre d’intervalles de départ servant d'assiette de calcul pour la moyenne. On doit comprendre que les équations 1 et 2 ne sont que des exemples et que d'autres méthodes pour déterminer la demande peuvent être utilisées pour les modes de réalisation de l'invention. Par exemple, les moyennes pourraient être pondérées en fonction de l'âge récent des données, ou déterminées par la seule addition des réservations pour des départs en semaine qui correspondent à l’intervalle de départ des réservations faisant l'objet d'une estimation.

[0064] L'application de la méthode décrite ci-dessus aux nombres exemplaires du tableau 1, en additionnant les nombres saisis pour les réservations au nombre des réservations existantes dans les cellules pour l'intervalle de départ des vols n'ayant pas encore décollé (p. ex., les intervalles de départ +4, +3, +2, +1) pour prédire le nombre de réservations qui seront reçues, peut produire les résultats montrés dans le tableau 2.

[0065] Faisant maintenant référence à la FIG. 4, et à titre d'illustration uniquement, un graphique exemplaire 80 inclut un axe horizontal 82 correspondant aux nombres de jours avant le départ et un axe vertical 84 correspondant au nombre de places réservées, normalisé par rapport au nombre total de places confirmées au départ. Il faut comprendre que, pour décrire plus clairement les modes de réalisation de l'invention, les échelles de l'axe horizontal 82 et de l'axe vertical 84 sont peut-être déformées.

[0066] Le graphique 80 inclut une courbe de saisies 86 qui peut représenter les réservations à bas tarif et une courbe de saisies 88 qui peut représenter les réservations à plein tarif. Le module de prévision de la demande 70 peut générer les courbes de saisies 86 et 88 en analysant les enregistrements de réservation pour les vols qui ont décollé. Ces enregistrements de réservation peuvent être sélectionnés à partir d'un pool d'enregistrements dans la base de données historiques des réservations 16 pour prévoir la demande pour un marché spécifique ou pour une combinaison de marchés. Chacune des courbes de saisies 86 et 88 peut être basée sur des données historiques collectées à partir des vols qui ont décollé dans un ou plusieurs marchés en cours d'analyse. Bien que l'exemple présent décrive des courbes de saisies pour deux classes de réservation, par souci de clarté, il faut comprendre que les modes de réalisation de l'invention peuvent utiliser des courbes pour tout nombre de classes de réservation.

[0067] Comment peut le voir à partir des positions relatives de la courbe de saisies 86 et de la courbe de saisies 88, les réservations pour des places à tarif réduit dans cet exemple ont tendance à survenir plus tôt par rapport à l'heure de départ du vol que les réservations pour des places à plein tarif. Pour prédire la demande future dans un marché, le module de prévision de la demande 70 peut générer un « modèle » de courbe de saisies sur la base d'une moyenne pondérée des courbes de saisies pour plusieurs classes de réservation. Par exemple, pour un marché donné, le modèle de la courbe de saisies peut être apporté par :

où t représente le temps avant le départ,(/) représente le modèle de courbe de saisies,^i (/) représente la courbe de saisies pour des places réservées dans une classe de réservation (p. ex., des places à plein tarif), fpi (0 représente la courbe de saisies pour des places réservées dans une autre classe de réservation (p. ex., des places à tarif réduit), wi représente une moyenne pondérée appliquée àβ-ι (t), et W2 représente un poids appliqué à/f2 (0- saisi composite. À titre d'exemple uniquement, dans un marché particulier avec une classe de réservation à plein tarif et une classe de réservation à tarif réduit, le poids appliqué aux réservations à plein tarif peut être 0,30 et le poids appliqué aux réservations à tarif réduit peut être 0,70.

[0068] Les prévisions de la demande basée sur des confirmations historiques peuvent être calculées pour tous les vols dont le départ est programmé dans un laps de temps prédéterminé tel qu'une année. La demande restante peut ensuite être déterminée sur la base de l'heure de départ en utilisant le modèle de courbe de saisies. La demande restante peut être fournie au module d'attribution de places 72 et au module de tarification 74 pour calculer l'attribution optimale de places entre les classes de réservation et les tarifs optimaux des places dans chaque classe de réservation.

[0069] La prévision quantitative peut fournir un outil utile pour prédire la demande future de place dans un marché, cependant, elle peut aussi présenter certaines failles. Par exemple, la prévision quantitative peut avoir une capacité limitée à prédire la demande dans des marchés qui sont nouveaux pour un transporteur. La prévision quantitative peut aussi s’avérer défaillante quant à la prise en compte d'événements, tels que les changements dans l'économie, qui peuvent affecter la demande.

[0070] Le tableau 3 décrit une table exemplaire de saisies pour des requêtes de recherche dans un marché. Le tableau 3 peut être généré, par exemple, sur la base des données enregistrées dans la base de données des requêtes 14. Les données dans chaque cellule du tableau 3 peuvent définir un nombre de places pour lesquelles des requêtes de recherche ont été reçues avant l'heure définie par la colonne correspondante, pour des places dont le départ est fixé dans l'intervalle de départ correspondant à cellule. Les requêtes de recherche pour plus d'une place peuvent amener les données à être incrémentées, par un montant égal au nombre de places définies par la requête de recherche, afin de refléter le nombre de places demandées. Les données dans chaque cellule peuvent donc correspondre à une intensité d'activité des requêtes de recherche. Lorsque les requêtes de recherche n'indiquent pas un nombre de places, l'intensité peut être incrémentée avec une valeur par défaut, p. ex., une place.

[0071] À titre d'exemple il est présumé que les intervalles de départ et les échantillons de temps du tableau 3 sont égaux à un jour, le marché représenté par le tableau 3 représente une origine, New York, et une destination, Paris et l'intervalle de départ « 0 » correspond au 4 juillet 2016. Selon cet ensemble de présomptions, une requête de recherche reçue le 30 juin 2016 pour des vols de New York à Paris en partance le 4 juillet 2016 peut amener le nombre de requêtes de recherche indiquée par la cellule du rang 0/colonne E à être progressivement plus élevé que si la requête de recherche n'avait pas été reçue, p. ex., 202 comme indiqué plutôt que 201 (en supposant que la requête de recherche était pour une seule place). Comme pour les tableaux 1 et 2, la période de recherche, l'intervalle de départ, le nombre de rangs et le nombre de colonnes du tableau 3 sont donnés à titre d'exemple et les modes de réalisation de l'invention ne sont pas limités à une dur& ou à une taille de tableau particulière.

[0072] Il a été déterminé qu'une corrélation positive existe entre l'intensité des requêtes de recherche de bas tarifs et le nombre de réservations reçues au final. En raison de cette corrélation entre l'intensité des requêtes de recherche et le nombre de réservations, des données statistiques dérivées des requêtes de recherche peuvent s'avérer utiles pour prévoir la demande. Les données statistiques peuvent inclure, par exemple, un nombre de requêtes reçues pour une origine et une destination spécifiques, l'heure à laquelle chaque requête a été reçue, une différence entre l'heure d'arrivée et la date de départ demandées, ou « date -avant-départ », pour chaque requête, ou toutes autres données décrivant la requête et/ou le contexte de la requête.

[0073] L'usage des données des requêtes de recherche pour générer des courbes de saisies peut apporter plusieurs avantages par rapport à l'usage des seules données historiques de réservation. Un des avantages peut être que le volume des requêtes de recherche excède typiquement le nombre de sièges réservés par un facteur important. Cela peut permettre de déterminer des statistiques robustes à un niveau plus élevé de granularité par rapport à la fois aux intervalles de temps et à la taille des marchés analysés qu'il ne serait possible avec les données historiques de réservation. Un autre avantage peut être que le nombre actuel de requêtes de recherche peut être prédicatif de la demande future plus directement que les données historiques de réservation. Par exemple, parce que le volume des requêtes de recherche est orienté vers le futur, cela peut être utile pour prévoir la demande dans les marchés où les données historiques de réservation manquent, p. ex., les marchés qui sont nouveaux pour un transporteur. Le volume de requêtes de recherche peut aussi être sensible à des événements, tels que des changements dans l'économie, qui affectent la demande.

[0074] Faisant maintenant référence à la FIG. 5, le graphique 80 est décrit avec une courbe exemplaire supplémentaire de saisies 90 qui peut représenter les données des requêtes de recherche. Dans un mode de réalisation de l'invention, une courbe de saisies basée sur des données de requête de recherche peut être générée dans chaque marché pour lequel il faut anticiper la demande. Ces courbes de saisies peuvent être analysées pour déterminer si elles améliorent les prévisions générées à partir de données historiques des vols qui ont décollé. Le module de prévision de la demande 70 peut utiliser les données de requêtes de recherche pour modifier la prévision dans un marché particulier s'il s’avère que l'usage des données des requêtes de recherche améliore la qualité de la prévision dans ce marché.

[0075] Pour obtenir des statistiques robustes qui exigent généralement un grand nombre de points de données, les prévisions basées sur les données historiques de réservation peuvent être déterminées en utilisant les données regroupées d'un grand nombre de dates de départ. Par exemple, les courbes de saisies basées sur les données historiques des réservations, telles que les courbes 86 et 88, peuvent être basées sur les départs survenant au cours d'une période d'une année. Par contraste, en raison du nombre relativement plus important des requêtes de recherche de voyage reçues dans chaque marché, des données statistiques robustes de saisies peuvent être disponibles en utilisant les données des requêtes de recherche amassées sur des périodes plus courtes, telles que pour un jour de départ particulier.

[0076] Par exemple, les courbes de saisies basées sur des données provenant de la base de données des requêtes 14, telles que la courbe de saisies 90, peuvent être générées sur la base d'un sous-ensemble de dates de départ à partir duquel sont extraites les données de réservations utilisées pour générer des courbes de saisies de réservations telles que les courbes de saisies 86 et 88. Ces sous-ensembles peuvent inclure un jour particulier de la semaine (p. ex., les requêtes de recherche pour un départ le mardi), une période de voyage particulière (p. ex., la semaine des vacances de printemps), ou même des jours individuels (p. ex. le jour avant Thanksgiving). S'il y a des indications que la prévision serait améliorée en utilisant des données de requêtes de recherche, le modèle de courbe de saisies peut être ajusté pour les vols qui n'ont pas encore décollé sur la base d'un modèle de courbe de saisies de requête qui est le mieux adapté.

[0077] La FIG. 6, illustre un diagramme séquentiel d'un processus 100 qui peut être exécuté par le module de prévision de la demande 70 pour déterminer un facteur de pondération pouvant être utilisé pour incorporer des données de requêtes dans un processus de prévision. Dans le bloc 102, le processus 100 peut générer une courbe de saisies des réservations pour un marché en cours d'analyse. Le marché peut comprendre, par exemple, les vols d'un point d'origine vers une destination dans une paire origine-destination spécifique. La courbe moyenne des saisies des réservations peut être générée sur la base des vols qui ont décollé dans le marché au cours d'une période analysée, p. ex., l'année précédente. La courbe de saisies des réservations peut être une courbe normale des saisies et peut être générée en utilisant les enregistrements historiques des réservations pour déterminer le nombre de réservations et le moment auquel les réservations ont été faites au cours de la période analysée.

[0078] Dans le bloc 104, le processus 100 peut générer une courbe de saisies des requêtes pour le marché. La courbe de saisies des requêtes peut être générée en utilisant des enregistrements de requêtes de recherche afin de déterminer le nombre et/ou l'intensité des requêtes de recherche reçues pour les vols qui ont décollé dans le marché. Dans un mode de réalisation de l'invention, la courbe historique de saisies des requêtes peut être basée sur les statistiques des requêtes de recherche reçues pour les mêmes vols qui ont décollé, utilisées pour générer la courbe de saisies des requêtes. La courbe de saisies des requêtes peut être générée en utilisant les données des requêtes de recherche de toute la période en cours d'analyse (p. ex., une année), ou à partir d'un sous-ensemble de la période analysée (p. ex., une semaine ou un mois). Lorsque la courbe de saisies des requêtes est générée en utilisant des requêtes pour des vols dont les dates de départ appartiennent à un sous-ensemble de la période analysée, les courbes de saisies peuvent être générées pour de multiples sous-ensembles couvrant la totalité de la période analysée. Le processus de confirmation peut alors poursuivre avec le bloc 106.

[0079] Dans le bloc 106, le processus 100 peut déterminer un facteur de pondération a. Le facteur de pondération a peut avoir une valeur étant la mieux adaptée entre une courbe composite de saisies et une courbe cible de saisies. La courbe composite de saisies peut être une moyenne pondérée de la courbe de saisies des réservations et de la courbe de saisies des requêtes et peut être exprimée par :

où^(/) représente la courbe composite de saisies, _/*pc(0 représente la courbe de saisies des réservations, et fqpciS) représente la courbe de saisies des requêtes.

[0080] Pour le marché en cours d'analyse, la valeur du facteur de pondération a peut être ajustée pour une meilleure adaptation entre la courbe composite de saisies et la courbe cible de saisies en minimisant une fonction d'erreur. Par exemple, la valeur du facteur de pondération a peut être ajustée pour minimiser une fonction d'erreur de type des moindres carrés, telle que :

où fr(i) représente la courbe cible de saisies, (début est le point de départ pour la période par rapport à laquelle les courbes sont comparées, et (fin est le point d'achèvement de la période par rapport à laquelle les courbes sont comparées. On comprendra que l'équation ci-dessus est donnée à titre d'exemple uniquement et que d'autres méthodes peuvent être utilisées pour déterminer le facteur de pondération a sur la base de la courbe composite de saisies et de la courbe cible de saisies.

[0081] La courbe cible de saisies peut être générée sur la base de différents types de données en fonction du moment et du mode de génération de la courbe. Par exemple, quand une place sur un vol est initialement mise à disposition pour la vente (p. ex., un an avant le départ), le volume des réservations et des données de recherche pour le vol peut être limité. Dans ce cas, les données de réservation des vols qui ont décollé, qui sont similaires à celui qui est en cours d'analyse, peuvent être utilisées pour générer la courbe cible de saisies.

[0082] Au fur et à mesure que la date de départ approche, des données de recherche suffisantes peuvent devenir disponibles permettant à la courbe cible d'être générée sur la base, au moins en partie, des données de recherche pour le vol ou le marché en cours d'analyse. Si la courbe cible de saisies diffère sensiblement de la courbe composite de saisies, un nouveau facteur de pondération peut être déterminé par le module de prévision de la demande 70. À un moment donné, le nombre de réservations confirmées pour le vol peut aussi devenir suffisant pour générer la courbe cible de saisies. Tout comme pour la courbe de saisies des requêtes de réservation, s'il apparaît que la courbe de saisies des réservations pour le vol en question dévie sensiblement de la courbe composite de saisies, le module de prévision de la demande 70 peut recalculer le facteur de pondération a.

[0083] Quel que soit le cas, une fois que la courbe composite de saisiesβ (a, /) a été déterminée, le processus 100 peut procéder au bloc 108 et prévoir la demande pour des vols futurs en utilisant la courbe composite correspondant au sous-ensemble de la période analysée pour laquelle la demande est en cours de détermination.

[0084] Le processus 100 peut être exécuté pour chaque date de départ dans chaque marché. Le contrôle a posteriori apporté par le processus 100 peut permettre l'utilité des registres de requête de recherche pour prédire la demande future qui doit être évaluée sur la base de chaque marché et de chaque vol. La décision d'utiliser les données des requêtes de recherche peut se faire si le contrôle a posteriori indique que les données des requêtes de recherche amélioreront les prévisions de la demande. Cette nouvelle source de données peut s'avérer particulièrement utile quand le module de prévision de la demande 70 est utilisé pour prédire la demande pour des routes, telles que les nouvelles routes, pour lesquelles les données historiques de réservation sont limitées.

[0085] Le nombre de réservations sur des vols qui ont décollé peut être relativement limité à l'intérieur d'un marché particulier. Donc, pour donner des courbes de réservation statistiquement robustes, les données des réservations pour les vols qui ont décollé peuvent être agrégées sur une période relativement longue, p. ex., une année entière de dates de départ pour chaque marché, ou un vol dans le marché. Le nombre de requêtes de recherche est typiquement beaucoup plus important que le nombre de réservations pour un marché spécifique et/ou un vol spécifique ; il a été déterminé que des courbes de saisies de requêtes tout aussi robustes peuvent être générées en utilisant des sous-ensembles beaucoup plus petits de dates de départ et/ou de vols.

[0086] Cette caractéristique des courbes de saisies de requêtes peut permettre aux courbes de saisies de requêtes d'être générées et utilisées pour prédire la demande pour des dates de départ spécifiques. Cela peut permettre à des modes de réalisation du module de prévision de la demande 70 de fournir des prévisions de la demande qui reflètent plus correctement le comportement des clients que ne le peuvent les systèmes de gestion des recettes qui ne peuvent recourir à la base de données des requêtes 14, ou qui ne génèrent pas de courbes de saisies en utilisant des statistiques de requêtes de recherche. Le module de prévision de la demande 70 peut aussi ajuster la prévision de la demande pendant la période de prévision. Des ajustements peuvent être faits en réponse à la détermination qu'une courbe de saisies de requêtes ou de réservations « réelles » orientée vers le futur dévie d'une ou de plusieurs courbes de saisies utilisées pour prédire la demande pour un marché, un vol ou une date de départ en particulier.

[0087] Faisant maintenant référence à la FIG. 7, uniquement à titre d’illustration, un graphique exemplaire 120 inclut un axe horizontal 122 correspondant au nombre de jours avant le départ et un axe vertical 124 correspondant à un nombre de requêtes de recherche/réservations reçues pour des places dans le marché. Le nombre de requêtes de recherche/réservation représentée par l'axe vertical 124 peut être normalisé par rapport à un nombre total de requêtes de recherche/réservation reçues jusqu’à l'heure de départ pour le vol ou marché en cours d'analyse.

[0088] Le Graphique 120 inclut une courbe historique de saisies 126 et une courbe potentielle de saisies 128. Dans un mode de réalisation de l’invention, la courbe historique de saisies 126 peut être la courbe historique de saisies utilisée par le module de prévision de la demande 70 pour prévoir la demande pour un marché et/ou vol particulier, et la courbe potentielle de saisies 128 peut représenter une courbe partielle de saisies, générée sur la base de requêtes de recherche reçues jusqu’à un point présent dans le temps pour un ou plusieurs vols sur le marché. Dans un mode alternatif de l’invention, la courbe historique de saisies 126 peut être la courbe composite de saisies utilisée par le module de prévision de la demande 70 pour prévoir la demande pour un vol et/ou marché particulier, et la courbe potentielle de saisies 128 peut représenter une courbe partielle de saisies générée sur la base des réservations reçues jusqu’à un point présent dans le temps pour un ou plusieurs vols sur le marché.

[0089] Dans l'exemple présent, la courbe potentielle de saisies 128 s’achève à un point sur le graphique 120 correspondant à un point dans le temps, 150 jours avant le départ. Ce point dans le temps peut refléter, par exemple, les données les plus récentes de requêtes de recherche disponibles dans la base de données des requêtes 14, ou les données les plus récentes des réservations disponibles dans un ou plusieurs des systèmes de réservation. Comme on peut le voir, le tracé de la courbe potentielle de saisies 128 a commencé à dévier de la courbe historique de saisies 126. Cette déviation peut être indicative d'une erreur dans la prévision initiale de la demande pour le marché, de l'occurrence d'un événement qui a affecté 1a demande ou de tout autre changement dans le marché.

[0090] La FIG. 8 illustre un diagramme séquentiel d'un processus 130 qui peut être exécuté par le module de prévision de la demande 70 afin d'identifier et de corriger les prévisions erronées sur la base des données de requête de recherche pour des vols qui n'ont pas encore décollé. Dans le bloc 132, le processus 130 peut générer une courbe potentielle de saisies pour une date future de départ dans le marché en cours d'analyse. Parce que la courbe potentielle de saisies de requêtes est orientée vers le futur (c.-à.-d. que les vols impliqués n'ont pas encore décollé), la courbe potentielle de saisies peut être une courbe partielle de saisies telle que la courbe potentielle de saisies 128 décrite dans la FIG. 7.

[0091 ] Dans le bloc 134, le processus 130 peut comparer la courbe potentielle de saisies à la courbe historique de saisies utilisée pour générer la prévision de la demande actuelle, p. ex., une courbe cible, une courbe composite, une courbe de réservations ou de requêtes historiques. Cette comparaison peut impliquer la génération d’une erreur basée sur la divergence entre la courbe potentielle de saisies et la courbe historique de saisies. Par exemple, l'erreur peut être liée à une surface entre les courbes une distance entre les courbes ou tout autre paramètre approprié pour caractériser la quantité de divergence.

[0092] Si l'erreur ne dépasse pas un seuil prédéterminé (branche « NON » du bloc de décision 136), le processus 130 peut prendre fin sans modifier la prévision de la demande actuelle. Si l'erreur dépasse le seuil prédéterminé (branche « OUI » du bloc de décision 136), le processus 130 peut poursuivre au bloc 138.

Dans le bloc 138, le processus 130 peut sélectionner, générer, ou autrement déterminer une courbe historique complète de saisies qui correspond à courbe potentielle de saisies. Par exemple, le processus 130 peut comparer une pluralité de courbes historiques de saisies générées précédemment à la courbe potentielle de saisies et sélectionner la courbe historique de saisies qui correspond le mieux à la courbe potentielle de saisies. Le processus 130 peut aussi générer une courbe historique complète de saisies basée seulement sur la courbe potentielle de saisies en utilisant un algorithme de courbe partielle correspondante.

[0093] Dans le bloc 140, le processus 130 peut déterminer un nouveau facteur de pondération a en substituant courbe historique complète de saisies à la courbe historique de saisies utilisée précédemment. Le processus 130 peut ensuite poursuivre au bloc 142, mettre à jour la courbe composite de saisies pour le marché en cours d'analyse et générer une nouvelle prévision de la demande sur la base de la courbe composite actualisée des saisies. En apportant un grand nombre de points de données relatives à la demande de places faite bien à l'avance de la date de départ, les enregistrements des requêtes de recherche peuvent permettre la génération de statistiques robustes sous forme de courbes de saisies de requêtes. Ces courbes de saisies de requêtes peuvent permettre une prévision plus précise de la demande future et peuvent aussi permettre la correction des prévisions de la demande causée par des changements inattendus dans la demande.

[0094] Généralement, les routines exécutées pour mettre en œuvre les modes de réalisation de l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme « code de programme informatique » ou simplement « code de programme ». Un code de programme comporte typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l'ordinateur à effectuer des tâches nécessaires à l'exécution d'opérations et/ou d'éléments propres à la mise en œuvre des aspects variés des modes de réalisation de l'invention. Les instructions d'un programme, lisibles par ordinateur, pour effectuer les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, ou encore un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation.

[0095] Divers programmes codés décrits dans les présentes peuvent être identifiés selon l'application dans laquelle ils sont mis en œuvre dans des modes de réalisation spécifiques de l'invention. Ainsi l'invention ne devrait pas se limiter à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des routines, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les diverses manières d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels résidant dans un ordinateur typique (par ex., des systèmes d'exploitation, des bibliothèques, des APIs, des applications, des miniapplications [applets], des services Web, etc.), on remarquera que les modes de réalisation de l’invention ne sont pas limités à l'organisation spécifique et à la répartition des fonctionnalités de programme décrites dans les présentes.

[0096] Le code de programme mis en œuvre dans toute application/module décrit(e) dans les présentes peut être distribué individuellement ou collectivement comme un produit programme sous une variété de formes. En particulier, le code de programme peut être distribué en utilisant un support de stockage lisible par ordinateur, disposant d'instructions de programme lisibles par ordinateur en lui-même, permettant à un processeur d'effectuer des aspects des modes de réalisation de l'invention.

[0097] Les supports de stockage lisibles par machine, étant intrinsèquement durables, peuvent inclure des médias tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage d'information, telle que des instructions de programme lisibles par machine, des structures de données, des modules de programme, ou d'autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires RAM, ROM, EPROM (mémoire à lecture exclusivement, programmable et effaçable), une mémoire flash, ou toute technologie de support solide de mémoire, CD-ROM (disque compact portable doté d'une mémoire à lecture seule), ou tout autre stockage optique, bandes d'enregistrement magnétique, mémoire à disque magnétique ou tout autre support pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (par exemple, des ondes radio ou toute autre onde électromagnétique se propageant à travers un support de transmission tel qu'un guide d'ondes ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par une machine ou vers un ordinateur externe, ou vers un dispositif de stockage externe par l’entremise d’un réseau.

[0098] Les instructions de programme lisibles par ordinateur, stockées sur un support lisible par ordinateur, d'autres types d'appareils programmables de traitement de données ou d'autres dispositifs pour fonctionner d’une façon particulière, tels que les instructions stockées sur un support lisible par ordinateur, produisent un article de fabrication comprenant les instructions qui mettent en œuvre les fonctions, les actions et/ou les opérations précisées dans les organigrammes, les diagrammes de séquence et/ou les diagrammes blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général, un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu'elles sont exécutées à l'aide du ou des processeurs, accomplissent une séries de calculs pour mettre en œuvre les fonctions, les actions, et/ou les opérations spécifiées dans les organigrammes, les diagrammes séquentiels et/ou les diagrammes blocs.

[0099] Dans certains autres modes de réalisation, les fonctions, les actions et/ou des opérations spécifiées dans les organigrammes, les diagrammes séquentiels, et/ou les diagrammes blocs peuvent être recommandées, traitées en série, et/ou traitées en même temps, conformément aux modes de réalisation de l'invention. De plus, l'un quelconque des organigrammes, des diagrammes séquentiels et/ou des diagrammes blocs peut inclure plusieurs ou moins de blocs que ceux illustrés, tout en demeurant conformes aux modes de réalisation de l'invention.

[00100] Bien que l'invention soit illustrée par une description de modes de réalisation divers, et bien que ces modes de réalisation soient décrits de façon très détaillée, le demandeur n'a pas pour intention de restreindre ou de limiter, de quelque façon que ce soit, l'étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L'invention sous un angle plus large n'est donc pas limitée aux détails spécifiques, aux procédés et aux appareils représentatifs, ni aux illustrations montrées et décrites à titre exemplaire. Par conséquent, il est possible de s'écarter de ces détails sans dévier de l'esprit ou de la portée du concept inventif général du demandeur.

Claims (9)

1. REVENDICATIONS

   1. Un système d'entrepôt de données comprenant : un ou plusieurs processeurs ; et une mémoire couplée à un ou à plusieurs processeurs, la mémoire enregistrant des données comprenant une première base de données d'enregistrements de registre de requêtes et des instructions qui, lorsqu'elles sont exécutées par un ou plusieurs processeurs, amènent le système à : recevoir une pluralité de requêtes de recherche, chaque requête de recherche reçue à une heure de réception et définissant un horaire de départ et une paire origine-destination ; et pour chaque requête de recherche : déterminer un laps de temps avant le départ à partir de l'heure de réception jusqu'à l'heure de départ de la requête de recherche, et conserver les secondes données indiquant la réception de la requête de recherche et le laps de temps avant le départ, dans un enregistrement de registre de requête associé à la paire origine-destination, dans lequel chaque enregistrement de registre de requête indique un nombre de places et le laps de temps avant le départ associé à chaque place de la paire origine-destination à laquelle l'enregistrement de registre de requête est associé, recevoir une requête fournissant les données statistiques sur une période d’une paire origine-destination respective; en réponse à la réception de la requête, récupérer un ou plusieurs enregistrements de registre de requêtes dans la première base de données, chacun d'un ou de plusieurs enregistrements de registre de requêtes étant associé avec la paire origine-destination respective et incluant des données liées aux requêtes de recherche qui définissent un horaire de départ respectif dans la période; extraire les secondes données de chacun des enregistrements de registre de requêtes récupéré; générer une première courbe de saisies illustrant une intensité des requêtes de recherche pour la paire origine-destination respective par rapport au laps de temps avant le départ pendant la période donnée, sur la base des secondes données; dans lequel le système suit et fournit des données indiquant la réception de la requête de recherche et l'heure de départ; et prévoit une demande de places pour la paire origine-destination respective en utilisant la première courbe de saisies, dans lequel les prévisions utilisent des données historiques de requêtes de recherche pour prévoir la demande future plutôt que des seules données historiques de réservation.
2. 2. Le système selon la revendication 1, dans lequel les instructions amènent par ailleurs, le système à : définir un index incluant une pluralité de champs, chaque champ correspondant à une paire origine-destination respective, chaque champ définissant l'emplacement de chaque enregistrement de registre de requête associé à la paire origine-destination dans la première base de données.
3. 3. Le système selon la revendication 1 ou 2, dans lequel les requêtes de recherche sont pour des tarifs bas.
4. 4. Le système selon l’une quelconque des revendications 1 à 3 dans lequel l’heure de départ définie pour chacun d'un ou de plusieurs enregistrements de registre de requêtes est expirée au moment où la requête est reçue.
5. 5. Le système selon l’une quelconque des revendications 1 à 4 dans lequel la période couvre une pluralité d'intervalles de départ et les instructions amènent le système à prévoir la demande de places pour la paire origine-destination respective, utilisant la première courbe de saisies en : interrogeant une seconde base de données pour obtenir des troisièmes données qui définissent une pluralité de réservations de places pour la paire origine-destination respective dont le départ a eu lieu pendant la période ; générant une seconde courbe de saisies en utilisant les troisièmes données, la seconde courbe de saisies décrivant un nombre de réservations par rapport à l'heure de départ pendant la période ; et générant une troisième courbe de saisies qui représente une moyenne pondérée de la première courbe de saisies et de la seconde courbe de saisies, dans lequel la troisième courbe de saisies est utilisée pour prévoir la demande de places pour la paire origine-destination.
6. 6. Le système selon la revendication 5 dans lequel, pour au moins un intervalle de départ couvert dans la période, les instructions amènent par ailleurs le système à : déterminer une quatrième courbe de saisies pour la paire origine-destination respective ; déterminer un facteur de pondération le mieux adapté entre la troisième courbe de saisies et la quatrième courbe de saisies ; et prévoir la demande de places pour la paire origine-destination respective pour des intervalles de départ futur en utilisant la troisième courbe de saisies avec la pondération la mieux adaptée, dans lequel la quatrième courbe de saisies est une courbe cible de saisies.
7. 7. Le système selon la revendication 6 dans lequel, pour chaque intervalle de départ futur, les instructions amènent par ailleurs le système à : déterminer une courbe partielle de saisies des requêtes de recherche qui sont satisfaites par une solution de voyage respective pour la paire origine-destination respective dont le départ est programmé pendant l’intervalle de départ futur ; déterminer la troisième courbe de saisies étant la mieux adaptée à la courbe partielle de saisies ; et prévoir la demande de places pour la paire origine-destination respective pour l'intervalle de départ futur en utilisant la troisième courbe de saisies étant la mieux adaptée à la courbe partielle de saisies.
8. 8. Le système selon la revendication 7 dans lequel chaque intervalle de départ couvre une journée et la période couvre une année.
9. 9. Le système selon l’une quelconque des revendications 5 à 8 dans lequel la paire origine-destination respective est l’une d’une pluralité de paires origines-destination comprenant un réseau de voyage et les instructions amènent par ailleurs le système à : générer une première courbe distincte de saisies pour chaque intervalle de départ pour chaque paire origine-destination de la pluralité des paires origine-destination.