FR3074338A1 - Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne - Google Patents

Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne Download PDF

Info

Publication number
FR3074338A1
FR3074338A1 FR1761466A FR1761466A FR3074338A1 FR 3074338 A1 FR3074338 A1 FR 3074338A1 FR 1761466 A FR1761466 A FR 1761466A FR 1761466 A FR1761466 A FR 1761466A FR 3074338 A1 FR3074338 A1 FR 3074338A1
Authority
FR
France
Prior art keywords
product
request
date
numerical value
candidate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1761466A
Other languages
English (en)
Other versions
FR3074338B1 (fr
Inventor
Michel Demazeau
Celine Soubra
Jean-Philippe Perret
Marco Salibba
Jacques Bonaud
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amadeus SAS filed Critical Amadeus SAS
Priority to FR1761466A priority Critical patent/FR3074338B1/fr
Priority to US16/183,183 priority patent/US20190164239A1/en
Publication of FR3074338A1 publication Critical patent/FR3074338A1/fr
Application granted granted Critical
Publication of FR3074338B1 publication Critical patent/FR3074338B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/14—Travel agencies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0623—Item investigation
    • G06Q30/0625—Directed, with specific intent or strategy
    • G06Q30/0627—Directed, with specific intent or strategy using item specifications

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Les modes de réalisation de l'invention fournissent un dispositif de traitement de requête, implémenté dans un dispositif serveur (90), la requête identifiant des paramètres de requêtes et étant reçue depuis un dispositif client, la requête étant traitée par le dispositif serveur (90) à date de requête, le dispositif serveur (90) étant configuré pour déterminer un ensemble de produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante définie par la valeur courante du produit candidat à la date de requête, et pour transmettre à destination du dispositif client, au moins une partie des produits candidats et leur valeur numérique courante respective. Le dispositif de traitement de requête comprend en outre une unité de traitement (170) configurée pour déterminer au moins une valeur numérique ultérieure (75) du produit candidat sélectionné, égale à une estimation de la valeur numérique courante du produit candidat à une date postérieure à la date de requête.

Description

PROCEDE ET DISPOSITIF DE TRAITEMENT DE REQUETE ET DE DETERMINATION D’UNE VALEUR NUMERIQUE ULTERIEURE D’UN PRODUIT SELECTIONNE
Domaine de l’invention
L'invention concerne de manière générale les architectures client/serveur et en particulier un procédé et dispositif de traitement de requête et de détermination d’une valeur numérique ultérieure d’un produit sélectionné.
Etat de la technique
Dans un dispositif serveur fournisseur de produits, basé sur une architecture client/serveur, un utilisateur peut soumettre une requête depuis un dispositif client (dispositif utilisateur) à un dispositif serveur via un réseau de communication pour obtenir un produit. La requête comprend un ensemble de paramètres de requêtes pouvant être obligatoires ou optionnels. Le dispositif serveur peut alors traiter la requête pour déterminer un ensemble de produits candidats satisfaisant au mieux au moins certains des paramètres de la requête, chaque produit candidat ayant une valeur numérique représentant le prix du produit. Certains systèmes fournisseurs de produits peuvent délivrer des produits associés à une date de produit, comme par exemple un système fournisseur de voyage délivrant des produits candidats tels que des billets d’avion, la valeur du produit étant alors la valeur du billet à l’instant de traitement de la requête par le dispositif serveur. Une requête de voyage reçue par un tel système fournisseur de voyage comprend généralement une origine, une destination et une date de voyage.
Dans un exemple d’application à l'industrie du voyage, le dispositif serveur fournisseur de produits peut être un système de type GDS (« Global Distribution System >>, ou Système de Distribution Global) permettant aux utilisateurs de réserver et d’acheter des produits candidats tels que des billets d’avion, de train ou encore des nuitées d’hôtel, en ayant accès directement aux données fournies par le fournisseur de voyage (qui peut être par exemple, une compagnie aérienne dans le cas d’une réservation de billet d’avion).
Les systèmes informatiques fournisseurs de produits peuvent utiliser des algorithmes d’optimisation en fonction de différentes données (les algorithmes d’optimisation sont encore appelés algorithmes de Gestion des Recette ou « Revenue Management >> en langue anglo-saxonne). Par suite, le prix du billet peut varier dans le temps, c’est-à-dire augmenter ou diminuer entre la date de traitement de la requête et la date de voyage effective.
L’utilisateur sait généralement que pour une origine et une destination données, le prix du billet peut être différent selon la date de voyage. L’utilisateur, qui a identifié un produit candidat suite à une première requête, peut, pour différentes raisons, vouloir attendre le plus possible avant prendre un billet d’avion à un prix donné, ou savoir plus généralement quand acheter un billet au meilleur prix. Ainsi, à la suite d’une première requête lui proposant un produit candidat satisfaisant sa requête, l’utilisateur ne sait pas si le prix affiché restera le même, s’il va augmenter ou baisser prochainement, et de combien. Par exemple, s’il souhaite prendre un billet Paris CDG - New-York JFK avec un départ le 1er août 2017 et un retour le 15 août 2017, l’utilisateur peut voir le billet à 400 euros le 1er mars, à 420 euros le 1er avril, puis augmenter fortement pour passer à 900 euros à partir du 15 avril.
Pour optimiser le prix d’achat de son billet, l’utilisateur peut tenter de consulter des données statistiques ou utiliser sa propre expérience d’achats précédents. L’utilisateur peut ainsi se rendre compte, avant d’acheter son billet, qu’il risque de payer son billet plus cher s’il part en été, début octobre ou fin décembre, plutôt que le reste de l’année. En revanche, l’utilisateur maîtrise moins la stabilité d’un prix annoncé, pour une origine, une destination et une date données, avec une même compagnie. Il ne dispose également pas d’informations sur le(s) moment(s) de l’année où le prix du billet est le plus bas. Le prix peut varier en effet au cours du temps, selon la politique de « revenue management >> (ou « gestion des recettes ») qu’applique la compagnie aérienne. Le plus souvent, l’utilisateur est donc amené à vérifier régulièrement l’évolution du prix du billet avant de finaliser son achat. Ainsi, il arrive souvent que les utilisateurs depuis leurs dispositifs clients consultent à de très nombreuses reprises le prix du billet qui les intéresse, en émettant à chaque fois une nouvelle requête utilisateur au dispositif serveur (système fournisseur de voyage), la fréquence d’émission de telles requêtes par l’utilisateur pouvant augmenter fortement à certaines périodes, notamment lorsque l’utilisateur a une date cible pour finaliser son achat. L’utilisateur peut ainsi effectuer la même requête à plusieurs dates plus ou moins rapprochées, voire plusieurs fois par jour, pour vérifier que le billet n’a pas augmenté depuis la dernière requête. Ce sont autant de nouvelles requêtes qui impliquent des milliers de transactions additionnelles par rapport à la requête initiale qui a déjà été effectuée, à une date précédente. De telles requêtes consomment énormément de ressources du côté du dispositif serveur (système fournisseur de voyage), l’exécution de chaque requête par le dispositif serveur ayant en soi un coût computationnel très élevé.
Il existe donc un besoin pour un procédé et un dispositif amélioré de traitement des requêtes capable d’optimiser les ressources du dispositif serveur.
Définition générale
L’invention se rapporte pour cela à dispositif de traitement de requête, implémenté dans un dispositif serveur, la requête identifiant des paramètres de requêtes et étant reçue depuis un dispositif client connecté audit dispositif serveur, la requête étant traitée par le dispositif serveur à une date donnée dite date de requête, le dispositif serveur étant configuré pour déterminer un ensemble de produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante définie par la valeur courante du produit candidat à la date de requête, et pour transmettre à destination du dispositif client, au moins une partie des produits candidats et leur valeur numérique courante respective, le dispositif de traitement de requête comprenant en outre une unité de traitement configurée pour déterminer au moins une valeur numérique ultérieure du produit candidat sélectionné, égale à une estimation de la valeur numérique courante du produit candidat à une date postérieure à la date de requête, et pour transmettre au dispositif client ladite au moins une valeur numérique ultérieure.
Avantageusement, le produit candidat sélectionné peut être associé à au moins une classe de réservation, le dispositif de traitement de requête étant configuré pour effectuer une étape de fermeture de classe consistant à affecter à la valeur numérique ultérieure la valeur numérique courante de la classe de réservation disponible qui est la plus proche de la valeur numérique courante de la classe de réservation du produit candidat sélectionné.
Dans un mode de réalisation, la classe de réservation du produit sélectionné peut être obtenue sous la forme d’un doublet de disponibilité fourni par un serveur de disponibilité du dispositif serveur, l’étape de fermeture de classe comprenant une réinitialisation dudit doublet de disponibilité.
Le dispositif de traitement de requête peut comprendre en outre une unité d’interprétation configurée pour déterminer, pour le produit candidat sélectionné, si une condition de durée restrictive s’applique, le dispositif de traitement de requête étant configuré, en cas d’application de ladite condition de durée restrictive, pour déterminer une date de requête modifiée, en affectant à la valeur numérique ultérieure la valeur numérique courante du même produit candidat sélectionné auquel la condition de durée restrictive ne s’applique pas.
Avantageusement, le dispositif de traitement de requête peut être en outre configuré pour maintenir la date de requête en cas de non application de la condition de durée restrictive.
En particulier, la date de requête modifiée New_time_stamp peut être déterminée par la formule suivante :
New_time_stamp = travel_date - duration_ADVP + 1, où travel_date correspond à la date du produit, et duration_ADVP correspond à la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique.
Avantageusement, la détermination de la valeur numérique ultérieure peut être effectuée à partir d’un facteur de probabilité, déterminé en fonction d’au moins un des paramètres d’un groupe comprenant la date de la requête, la date de produit, la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique, et des valeurs observées de vitesse de fermeture de classes.
L’invention se rapporte également à un procédé de traitement d’une requête reçue depuis un dispositif client dans un dispositif serveur connecté au dispositif client, la requête identifiant des paramètres de requêtes, le procédé comprenant les étapes consistant à :
- déterminer un ensemble de produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante définie par la valeur courante du produit candidat à la date de requête,
- transmettre à destination du dispositif client, au moins une partie des produits candidats et leur valeur numérique courante respective, le procédé comprend en outre les étapes consistant à :
- sélectionner un des produits candidats transmis au dispositif client,
- déterminer au moins une valeur numérique ultérieure du produit candidat sélectionné, égale à une estimation de la valeur numérique courante du produit candidat à une date postérieure à la date de requête,
- transmettre au dispositif client ladite au moins une valeur numérique ultérieure.
Dans un mode de réalisation, le produit candidat sélectionné peut être associé à au moins une classe de réservation, le procédé comprenant une étape de fermeture de classe consistant à affecter à la valeur numérique ultérieure la valeur numérique courante de la classe de réservation disponible qui est la plus proche de la valeur numérique courante de la classe de réservation du produit candidat sélectionné.
Avantageusement, la classe de réservation du produit sélectionné peut être obtenue sous la forme d’un doublet de disponibilité fourni par un serveur de disponibilité du dispositif serveur, l’étape de fermeture de classe comprenant une réinitialisation dudit doublet de disponibilité.
Dans un mode de réalisation, le procédé peut comprendre en outre :
- une étape de détermination, pour le produit candidat sélectionné, de l’application d’une condition de durée restrictive, et
- en cas d’application de ladite condition de durée restrictive, une étape consistant à modifier la date de requête, en affectant à la valeur numérique ultérieure la valeur numérique courante du même produit candidat sélectionné auquel la condition de durée restrictive ne s’applique pas,
- en cas de non application de ladite condition de durée restrictive, une étape consistant à maintenir la date de requête.
Avantageusement, la date de requête modifiée New_time_stamp peut être déterminée par la formule suivante :
New_time_stamp = travel_date - duration_ADVP + 1, où travel_date correspondant à la date du produit, et duration_ADVP correspond à la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique.
La détermination de la valeur numérique ultérieure peut être effectuée à partir d’un facteur de probabilité, déterminé en fonction d’au moins un des paramètres d’un groupe comprenant la date de la requête, la date de produit, la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique, et des valeurs observées de vitesse de fermeture de classes.
Avantageusement, un affichage de la valeur numérique ultérieure associée au produit peut être généré sur une interface graphique d’un site Internet et/ou d’une application dédiée.
L’invention se rapporte également à un produit-programme d'ordinateur pour le traitement d’une requête, le produit-programme d'ordinateur comprenant un support durable de stockage de données lisibles par ordinateur et un code de programme enregistré sur le support durable de stockage lisible par ordinateur qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène le ou plusieurs processeurs à exécuter les étapes du procédé précité.
Description des figures
D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :
- la figure 1 illustre schématiquement les interactions entre un dispositif client et un dispositif serveur ;
- la figure 2 illustre schématiquement la composition du dispositif client et du dispositif serveur ;
- la figure 3 illustre schématiquement l’architecture du dispositif serveur selon l’invention ;
- la figure 4 illustre un diagramme séquentiel du procédé de traitement de requête selon l’invention ;
- la figure 5 illustre schématiquement les interactions entre un dispositif client et un dispositif serveur conformément à l‘invention ;
- la figure 6 illustre en détail l’étape de détermination de la valeur numérique ultérieure.
Description détaillée
La figure 1 représente schématiquement les interactions entre un dispositif client et un dispositif serveur. Au moins un dispositif client 100 et un dispositif serveur 90 sont connectés via un réseau de communication. Sur la figure 1, un seul dispositif client 100 est représenté. Toutefois, en variante, et de façon connue, l’environnement peut comprendre une pluralité de dispositifs clients 100. Le dispositif client 100 peut être associé à une pluralité de systèmes d'agences de voyages émettant des requêtes de services via des interfaces clientes respectives. Chaque système de gestion de voyages peut en outre être connecté à différents types de dispositifs clients soumettant différents types de demandes (ou requêtes) selon une approche client/serveur, tels que des dispositifs utilisateurs (ou voyageurs) via des interfaces utilisateurs respectives. Chaque système de gestion de voyages peut également être connecté à un ou plusieurs systèmes de fournisseurs de voyages. Dans une application préférée de l'invention à l'industrie du voyage, lorsqu’un utilisateur souhaite réserver un billet d’avion par exemple, il peut soumettre une requête 80, depuis un dispositif utilisateur (par exemple un ordinateur, une tablette ou un téléphone) muni d’un terminal de saisie et d’un dispositif affichage 100 via une interface graphique dédiée, en spécifiant une origine, une destination, et une date de départ. La requête 80 est alors transmise au dispositif serveur 90 via un réseau de communications 25. Le réseau 25 peut inclure des portions d'un ou de plusieurs réseaux privés ou publics (par ex., Internet, un réseau virtuel privé, un réseau local, un réseau étendu, un réseau de téléphone cellulaire, etc.) fournissant une interconnexion et facilitant l'échange de données contenant des informations. En réponse à la requête, le dispositif serveur 90 calcule alors une liste de produits candidats 70, comprenant les différentes options de voyage disponibles satisfaisant la requête, chaque option étant associée à un prix représentant le prix de l’option de voyage. Le dispositif serveur 90 retourne ensuite les options de voyage à l’utilisateur via l’interface utilisateur dédiée. Ainsi, le dispositif serveur 90 est capable de retourner la liste 70 des options de voyage calculées quelque temps après la saisie de la requête 80, via le réseau de communications 25. Dans les systèmes actuels de fourniture de voyage basés sur des architectures client/serveur, il est souhaitable que le délai entre la saisie de la requête et le retour des résultats soit plus bref possible pour optimiser l’expérience utilisateur.
Le dispositif serveur 90 et/ou les dispositifs client 100 peuvent être implémentés sur un ou plusieurs ordinateurs, tels que l'ordinateur 30, comme représenté sur la figure 2. L'ordinateur 30 peut comporter un processeur 32, une mémoire 34, un dispositif de mémoire de stockage de masse 36, une interface d'entrée/sortie (I/O) 38 et une Interface Homme-Machine (IHM) 40. L'ordinateur 30 peut également être couplé de manière fonctionnelle à une ou plusieurs ressources externes 42 via le réseau 25 et/ou une interface I/O 38. Des ressources externes peuvent inclure, mais sans y être limitées, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau à base de nuage, ou toute autre ressource informatique appropriée qui peut être utilisée par l'ordinateur 30. Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés parmi les microprocesseurs, les microcontrôleurs, les processeurs de signaux numériques, les micro-ordinateurs, les unités centrales de traitement, les réseaux prédiffusés programmables par l'utilisateur, les dispositifs logiques programmables, les machines d'état, les circuits logiques, les circuits analogiques, les circuits numériques, ou d'autres dispositifs qui manipulent des signaux (analogiques ou numériques) en fonction d'instructions d'opérations qui sont stockées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif mémoire ou une pluralité de dispositifs mémoire incluant, mais sans y être limités, une mémoire morte (ROM), une mémoire vive (RAM), une mémoire volatile, une mémoire non volatile, une mémoire à accès aléatoire statique (SRAM), une mémoire à accès aléatoire dynamique (DRAM), une mémoire flash, une mémoire cache, ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de stockage de masse 36 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un lecteur de cassette, un dispositif à semi-conducteurs non volatile, ou tout autre dispositif capable de stocker des informations. Une base de données 44 peut résider sur le dispositif de mémoire de stockage de masse 36, et peut être utilisée pour collecter et organiser des données utilisées par les différents systèmes et modules décrits ici. Le processeur 32 peut fonctionner sous la commande d'un système d'exploitation 46 qui réside dans la mémoire 34. Le système d'exploitation 46 peut gérer des ressources informatiques de telle sorte qu'un code de programme informatique intégré sous la forme d'une ou plusieurs applications logicielles, telles qu'une application 48 résidant dans la mémoire 34, peuvent avoir des instructions exécutées par le processeur 32. Dans une autre forme de réalisation, le processeur 32 peut exécuter l'application 48 directement, auquel cas le système de fonctionnement 46 peut être omis. Une ou plusieurs structures de données 50 peuvent également résider dans la mémoire 34, et peuvent être utilisées par le processeur 32, le système d'exploitation 46 et/ou l'application 48 pour le stockage ou la manipulation de données. L'interface I/O 38 peut fournir une interface machine qui couple fonctionnellement le processeur 32 à d'autres dispositifs et systèmes, tels que le réseau 22 et/ou une ressource externe 42. L'application 48 peut ainsi travailler en coopération avec le réseau 22 et/ou une ressource externe 42 en communiquant via l'interface I/O 38 pour fournir les différentes particularités, fonctions, applications, processus et/ou modules comprenant des formes de réalisation de l'invention. L'application 48 peut également avoir un code programme qui est exécuté par une ou plusieurs ressources externes 42, ou autrement s'appuyer sur des fonctions et/ou signaux fournis par d'autres composants système ou réseau externes à l'ordinateur 30. En effet, étant donné la presque infinité de configurations matérielles et logicielles possibles, l'homme du métier comprendra que les formes de réalisation de l'invention peuvent inclure des applications qui sont situées à l'extérieur de l'ordinateur 30, distribuées sur plusieurs ordinateurs ou d'autres ressources externes 42, ou fournies par des ressources informatiques (matérielles ou logicielles), sous la forme d'un service sur le réseau 22, tel qu'un service informatique en nuage. L'interface IHM 40 peut être couplée de manière fonctionnelle au processeur 32 de l'ordinateur 30 d'une manière connue, pour permettre à un utilisateur de l'ordinateur 30 d'interagir directement avec l'ordinateur 30. L'interface IHM 40 peut inclure des écrans vidéo et/ou alphanumériques, un écran tactile, un hautparleur, et tout autre indicateur audio et visuel approprié capable de fournir des informations à l'utilisateur. L'interface IHM 40 peut également inclure des dispositifs de saisie et des commandes tels qu'un clavier alphanumérique, un dispositif de pointage, des pavés numériques, des boutons poussoirs, des boutons de commande, des microphones, etc., capables de recevoir des commandes et données d'entrée en provenance de l'utilisateur et de transmettre les entrées introduites dans le processeur 32.
La figure 3 illustre une vue détaillée et schématique du dispositif serveur 90, dans un exemple d’application de l’invention au domaine de l’industrie du voyage, selon certains modes de réalisation. Le dispositif serveur 90 peut par exemple être un système de type GDS. La requête 80 peut être transmise par le dispositif client 100 via le réseau 25 au dispositif serveur 90. Le dispositif serveur 90 peut comprendre un moteur de recherche 110 (encore appelé « serveur de trajet >> ou « planificateur de voyage »). Le moteur de recherche 110 est configuré pour déterminer des produits candidats satisfaisant les paramètres de la requêtes, comprenant la date, l’origine et la destination spécifiées par l’utilisateur. Pour déterminer les options de voyages, le moteur de recherche 110 peut procéder en deux étapes. Dans une première étape, le moteur de recherche 110 peut déterminer des routes, ou itinéraires géographiques satisfaisant les paramètres de la requête 80. Le moteur de recherche 110 détermine généralement un nombre important de routes, en prenant en considération l’ensemble des connexions possibles entre l’origine et la destination, parmi les milliers de stations possibles (par exemple, aéroports commerciaux) dans la zone géographique considérée. Le moteur de recherche 110 peut en outre trier et filtrer un tel ensemble de connexions tout au long du processus, en fonction d'une liste de critères. Le moteur de recherche 110 peut également appliquer un coefficient multiplicateur à la distance séparant les stations d’origine et de destination, et écarter toutes les routes (avec escale) qui font parcourir une distance supérieure au produit de la distance séparant les stations d’origine et de destination par le coefficient multiplicateur. Dans une deuxième étape, le moteur de recherche 110 peut utiliser les routes sélectionnées comme étant les plus pertinentes pour créer les produits candidats correspondant à ces routes. Le moteur de recherche peut notamment consulter les horaires des produits candidats dans une base de données horaires 145. Les données présentes dans la base de données horaires 145 peuvent être importées depuis une table d’horaires 105, qui peut être utilisée de façon centralisée par plusieurs systèmes informatiques et mise à jour à une fréquence donnée (par exemple une fois par semaine, ou une fois par jour). La base de données horaires 145 peut comprendre les heures de départ et d’arrivée ainsi que les stations correspondantes (e.g. aéroport de la majorité des compagnies aériennes commerciales). A partir de ces données, le moteur de recherche 110 peut explorer les itinéraires d'origine à destination, triés et sélectionnés à partir d'une liste de critères sur ces segments d'itinéraires (par exemple un temps suffisant pour faire une escale). Le moteur de recherche 110 peut alors déterminer les différentes produits candidats possibles sous la forme d’une liste restreinte de produits candidats.
Une liste comprenant un nombre de produits candidats peut être ensuite transmise à un serveur de disponibilité 130. Le serveur de disponibilité peut être configuré pour vérifier les disponibilités des produits candidats qui lui sont transmises. Le serveur de disponibilité 130 peut être en outre configuré pour vérifier, pour chacun des produits candidats retenus dans les différentes classes de réservation, et fournis par le moteur de recherche 110, si des sièges sont encore disponibles. Le serveur de disponibilité 130 peut vérifier la disponibilité auprès des systèmes inventaires 160 des compagnies aériennes compl, comp2, comp3, comp4, ..., compN de différentes manières. Pour certaines compagnies, le serveur de disponibilité 130 peut être adapté pour interroger de façon dynamique le système inventaire 160 de la compagnie aérienne sur la disponibilité des places sur un vol pour une classe donnée (option dite « polling >> ou « interrogation >> en français, également appelée « Seamless availability >> ou « disponibilité transparente >>). D’autres systèmes inventaires 160 de compagnies peuvent envoyer des informations de statut (option dite «AVS», acronyme pour « Availibility Status» ou «Statut de Disponibilité» en français), lorsque le système inventaire 160 l’estime nécessaire, par exemple à chaque fois que la disponibilité change. Le système inventaire 160 propre à chaque compagnie peut être un système informatisé qui stocke des unités ou articles périssables d'un inventaire. Dans une application préférée de l'invention à l'industrie du voyage, le système inventaire peut stocker des unités ou articles représentant des sièges pour de multiples combinaisons de vols-dates d'un réseau aérien, ainsi que des cabines et/ou classes de réservation pour chacun de ces vols-dates. Pour chaque vol, le système inventaire 160 peut transmettre au serveur de disponibilité 130 un résultat d’inventaire, à savoir le nombre de sièges disponibles par classe sous la forme d’un doublet de disponibilité. Le doublet de disponibilité comprend une information à deux caractères juxtaposés, un des caractères étant formé d’une lettre désignant la classe, et l’autre caractère étant formé d’un chiffre désignant le nombre de sièges encore disponibles dans ladite classe. Par exemple, le système inventaire 160 peut transmettre doublet de disponibilité « B8 >> s’il reste encore huit sièges en classe B (pouvant appartenir par exemple au groupe de classe de réservation « première classe »), le doublet de disponibilité « J0 >> s’il ne reste plus de sièges en classe J (pouvant appartenir par exemple au groupe de classe de réservation classe économie »). Le serveur de disponibilité 130 met ainsi en relation chaque produit, déterminé par le moteur de recherche 110, avec la disponibilité dans chacune des classes, afin de construire différentes produits de voyage. Pour faciliter la description de certains modes de réalisation, l'invention sera faite en référence à une telle application de l'invention au secteur du voyage dans laquelle le système inventaire 160 est configuré pour stocker des sièges, à titre d’exemple non limitatif.
Les produits candidats ainsi obtenus peuvent être transmis à une plateforme de détermination de prix 120. Le nombre de produits candidats transmis à la plateforme de détermination de prix 120 peut être paramétré, et être fixé à un nombre prédéterminé. La plateforme de détermination de prix 120 peut être configurée pour déterminer un prix pour chacune des produits candidats transmises par le serveur de disponibilité 130. Le dispositif serveur 90 peut comprendre une base de données des tarifs 140, configurée pour importer des tarifs depuis une table de tarifs 115 fournie de façon centralisée à un ou plusieurs différents systèmes informatiques existants. Pour un trajet donné, défini par une origine et une destination, il peut exister différents tarifs applicables, chaque tarif étant associé à une des classes de réservation disponibles au sein d’un même vol. Telle qu’utilisée ici, l’expression « classe de réservation >> fait référence à un identifiant associé à un type de service associé à un vol tel qu’un service disponible à bord d’un vol, ou des conditions de modification de billet. Les classes de réservation peuvent être regroupées par groupes de classes de réservation, visibles par l’utilisateur par exemple par les libellés « première classe », « classe affaire >>, « classe économie >> ou encore « classe économie premium >>. Seul le prix correspondant à la classe la moins chère de groupe de classes peut être transmis à l’utilisateur.
La liste 70 de produits candidats est finalement fournie à l’utilisateur, via le terminal de saisie et d’affichage 100. Ainsi, pour chaque requête effectuée par un utilisateur, ce sont classiquement des milliers de transaction qui sont effectuées par le dispositif serveur 90. Le moteur de recherche 110 reçoit un volume de trafic très élevé, et doit répondre rapidement et de manière optimisée. Un tel moteur de recherche est généralement soumis à de très fortes contraintes en termes de performances et de temps de réponse. Par ailleurs, la plateforme de détermination de prix 120 est classiquement très consommatrice en termes de ressources informatiques, et notamment de ressources CPU. Une telle consommation est notamment due aux calculs de combinaisons tarifaires effectués en fonction des pays de voyage, du nombre d’escales pour chaque billet proposé, et plus généralement de la complexité de l’itinéraire.
La figure 4 illustre les différentes étapes du procédé selon l’invention. La figure 5 illustre les différentes interactions entre l’utilisateur et le serveur 90, conformément à certains modes de réalisation. Dans une première étape 1000, l’utilisateur saisit une requête 80 comprenant certains critères, par exemple une origine, une destination et au moins une date de voyage. A l’étape 1001, des produits candidats 70 satisfaisant au mieux les critères de la recherche sont déterminés, puis transmis à l’utilisateur à l’étape 1002 avec leur valeur numérique courante. Un produit candidat, pour lequel l’utilisateur peut souhaiter savoir quel sera sa valeur numérique ultérieure lors d’une prochaine modification, peut être sélectionné par l’utilisateur dans une deuxième requête
85, lors de l’étape 1003. La valeur numérique ultérieure 75 est déterminée à l’étape 1004 pour ledit produit candidat sélectionné, puis transmis à l’utilisateur à l’étape 1005.
La valeur numérique ultérieure, déterminée à l’étape 1004, peut être calculée de différentes manières. Un des produits candidats, parmi ceux transmis au dispositif client 100, peut être sélectionné par l’utilisateur, afin d’obtenir une estimation d’une valeur numérique ultérieure du produit candidat. La valeur numérique ultérieure correspond à la valeur numérique du produit candidat, à une date postérieure à la date de la requête. Dans un exemple d’application de l’invention au domaine de l’industrie du voyage, la valeur numérique ultérieure peut correspondre à une estimation du prix du billet à une date ultérieure. Pour un même billet, le prix du billet peut être modifié plusieurs fois à des dates ou instants différents. Ainsi, le procédé et le dispositif selon l’invention permettent de déterminer quel sera le prochain prix du billet, lors de sa prochaine modification, et d’apporter ainsi à l’utilisateur une information supplémentaire.
La sélection d’un des produits candidats par l’utilisateur peut être effectuée notamment lorsque le pointeur de l’utilisateur est maintenu au moins pendant une durée prédéterminée sur l’emplacement graphique désignant un des produits candidats. La sélection d’un des produits candidats peut également être effectuée par appui sur un bouton dédié de l’interface graphique. La deuxième requête 85 émise par l’utilisateur, et correspondant au produit candidat sélectionné, peut être transmise à une unité de traitement 170. La requête peut comprendre le plan de voyage sélectionné par l’utilisateur, par exemple l’origine, la destination, les dates de voyage, les numéros de vol et les codes de compagnie. Elle peut également comprendre des détails sur le plan de voyage sélectionné, comme par exemple le prix du billet et sa construction tarifaire, à savoir les classes des différents billets. L’unité de traitement 170 peut héberger une Rest API (Representational State Transfer Application Programming Interface), afin de mettre en oeuvre certaines étapes du procédé selon l’invention.
Selon un premier mode de réalisation, la réponse du serveur de disponibilité 130 comprenant le résultat de l’inventaire peut être récupérée par l’unité de traitement 170. Le résultat de l’inventaire peut comprendre le doublet de disponibilité comprenant le nombre de produits disponibles dans une classe donnée. Le doublet de disponibilité peut être réinitialisé par l’unité de traitement 170, de façon à affecter la valeur «0 >> au caractère désignant le nombre de sièges restants, déclenchant ainsi une procédure dite de fermeture de classe. De la sorte, une indisponibilité du produit sur la classe du produit candidat sélectionné peut être simulée par l’unité de traitement 170. Le doublet de disponibilité est ensuite transmis au serveur de disponibilité 130, et la valeur recalculée du produit, tenant compte de la fermeture de la classe, est déterminée par la plateforme de détermination de prix 120. Au cas où le produit comprend plusieurs segments, par exemple en cas d’escale dans le domaine du l’industrie du voyage, il peut y avoir plusieurs classes pour lesquelles une fermeture est à simuler.
L’unité de traitement 170 peut déclencher alors la fermeture de la classe selon toutes les combinaisons possibles créant ainsi un ou plusieurs produits similaires. Un produit est dit « similaire >> à un produit donné s’il a une date de produit ayant le même quantième et le même mois que le produit donné, ainsi que les mêmes segments et des services identiques.
L'unité de traitement 170 peut alors analyser les différents produits obtenus pour en déduire celui qui a la plus grande probabilité d'occurrence en observant le nombre de sièges disponibles par classe de service ainsi que la vélocité observée des ventes pour ladite classe.
Les triplets produits/prix/probabilité seront exposés à une application dite « appelante >>, qui décidera de la valeur numérique ultérieure 75 à transmettre à l'utilisateur.
La valeur numérique ultérieure 75 peut être ensuite effectée à la valeur numérique courante de la classe de réservation disponible qui est la plus proche de la valeur numérique courante de la classe de réservation du produit candidat sélectionné.
La valeur numérique ultérieure est ainsi déterminée par la plateforme de détermination de prix, en tenant compte de la fermeture de la classe courante, puis transmise à l’utilisateur, en même temps que la valeur courante du produit candidat sélectionné. La valeur numérique ultérieure 75 associée au produit peut également être générée sur une interface graphique d’un site Internet et/ou d’une application dédiée. Un tel mode de réalisation évite ainsi que l’utilisateur n’effectue ultérieurement une nouvelle requête, identique à sa requête initiale, optimisant ainsi des ressources informatiques des serveurs.
Selon un deuxième mode de réalisation, la valeur numérique ultérieure peut être déterminée en extrayant une information d’horodatage contenue dans les conditions d’applicabilité du produit. L’unité d’interprétation 180 peut être configurée pour extraire, dans les conditions d’applicabilité du produit, l’information relative à la condition de durée restrictive du produit candidat sélectionné par l’utilisateur dans la deuxième requête 85. La sélection par l’utilisateur d’un des produits candidats transmis dans la liste 70 génère une deuxième requête 85, transmise à l’unité de traitement 170. Dans un exemple de mise en oeuvre de l’invention appliqué à l’industrie du voyage, la condition de durée restrictive correspond à une réduction du prix du billet, si le billet est acheté suffisamment avant le voyage, par exemple, mais non exclusivement, quarante-cinq jours avant le départ. De façon générale, si la condition de durée restrictive s’applique au produit, une réduction de la valeur courante peut être appliquée. La date du produit (travel_date) et la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique (duration_ADVP) peuvent être obtenues par l’unité de traitement 170, par émission d’une requête auprès du serveur de disponibilité 130. La date de requête modifiée (New_time_stamp) peut être déterminée par l’unité de traitement 170 selon la formule suivante :
New_time_stamp = travel_date - duration_ADVP + 1
La valeur numérique ultérieure 75 peut être ainsi déterminée par la plateforme de détermination de prix 120, avec la date de requête modifiée pour laquelle la condition de durée restrictive ne s’applique plus, puis transmise à l’utilisateur, en même temps que la valeur courante du produit candidat sélectionné. La valeur numérique ultérieure associée au produit peut également être générée sur une interface graphique d’un site Internet et/ou d’une application dédiée.
Un tel mode de réalisation permet également d’optimiser les ressources informatiques des serveurs, en transmettant à l’utilisateur des informations d’aide à la décision sur l’évolution de la valeur du produit de voyage.
La figure 6 est un organigramme décrivant le procédé de choix de l’un ou de l’autre des modes de réalisation. A l’étape 2000, la classe du produit sélectionné est déterminée par l’unité de traitement 170. A l’étape 2001, la durée estimée avant la fermeture de la classe est calculée (d_close_class). Cette durée peut être calculée à partir de vitesses observées de fermeture de la classe du produit sélectionné, pour des produits identiques. A l’étape 2002, l’unité d’interprétation 180 extrait l’information relative à la condition de durée restrictive du produit candidat sélectionné. Le résultat de la détermination de la condition de durée restrictive est donc une durée en jours. Si la condition de durée restrictive (2003) ne s'applique pas au produit candidat sélectionné, la détermination de la valeur numérique ultérieure peut donc être réalisée exclusivement via une procédure de fermeture de classe, à l’étape 2004. Si la condition de durée restrictive (2003) s'applique au produit candidat sélectionné, l’unité de traitement 170 détermine, à l’étape 2005, la durée restante avant que la condition de durée restrictive ne s’applique plus (d_break_ADVP). Dans un exemple de mise en oeuvre de l’invention appliqué à l’industrie du voyage, si le produit candidat peut être sélectionné soixante jours avant le voyage, et que la condition de durée restrictive s’applique à plus de quarante-cinq jours, la durée restante avant que la condition de durée restrictive ne s’applique plus est égale à quinze jours. La durée estimée avant la fermeture de la classe est comparée (2006) à la durée restante avant que la condition de durée restrictive ne s’applique plus. Si la durée estimée avant la fermeture de la classe (d_close_class) est inférieure à la durée restante avant que la condition de durée restrictive ne s’applique plus (d_break_ADVP), la détermination de la valeur numérique ultérieure est donc réalisée exclusivement via une procédure de fermeture de classe, à l’étape 2004. A l’inverse, la détermination de la valeur numérique ultérieure est donc réalisée exclusivement en modifiant la date de requête de façon à ce que la valeur numérique ultérieure soit égale à la valeur numérique courante du même produit candidat sélectionné sans application de la condition de durée restrictive (étape 2007). La sélection de l’un ou l’autre des modes de réalisation permet ainsi de transmettre à l’utilisateur la valeur numérique ultérieure la plus probable.
Le dispositif et le procédé objets de l’invention permettent ainsi d’éviter une surcharge des dispositifs serveurs, en limitant le nombre de requêtes identiques par un même utilisateur. La transmission à l’utilisateur de données supplémentaires d’évolution du prix permet ainsi de réduire sensiblement le délai de réponses des dispositifs serveurs, et d’augmenter les performances du dispositif serveur.
Selon un mode de réalisation de l’invention, une valeur de maintien temporel du produit candidat peut être transmise à l’utilisateur, en même temps que la valeur numérique ultérieure, lui permettant de reporter la finalisation de l’achat du produit candidat. Dans un exemple de mise en oeuvre de l’invention appliqué à l’industrie du voyage, le billet peut être bloqué pendant une durée prédéterminée (par exemple vingt-quatre ou quarante-huit-heures) si l’option de maintien temporel du produit candidat a été sélectionnée. Il peut alors retarder l’achat du billet de la durée prédéterminée, et est garanti de pouvoir finaliser l’achat du billet souhaité avant la fin de la durée prédéterminée. Dans l’industrie aérienne, l’option de maintien temporel du produit candidat est généralement payante. La valeur de maintien temporel, qui correspond au prix à payer par l’utilisateur pour bloquer le produit candidat pendant la durée proposée, est généralement statique, à savoir qu’elle ne varie pas selon des critères contextuels liés aux résultats de la requête. La suggestion à l’utilisateur d’une option de maintien temporel du produit candidat ayant une valeur de maintien temporel supérieure à la différence entre la valeur numérique ultérieure et la valeur numérique courante n’inciterait pas l’utilisateur à sélectionner cette option. Il peut s’agir du cas, par exemple, où un produit sélectionné a une valeur courante égale à 500 Euros, une valeur numérique ultérieure égale à
550 Euros, et une valeur de maintien temporel égale à 100 Euros. Il y aurait alors, pour l’utilisateur, conflit entre la procédure de calcul de la valeur numérique ultérieure, et la valeur du maintien temporel affichée, ce qui rendrait le système de la compagnie aérienne, et notamment son calcul de valeur numérique ultérieure, obscur pour l’utilisateur. L’utilisateur pourrait alors être incité de refaire la même requête à une autre date, ce qui est contraire à l’effet recherché par la présente invention.
Le caractère dynamique de l’option de maintien temporel, et la détermination dynamique de la valeur de maintien temporel, au lieu d’une valeur du maintien temporel statique, permettrait d’adapter la valeur du maintien temporel en fonction de la valeur numérique courante et de la valeur numérique ultérieure. Selon un premier mode de réalisation, l’option de maintien temporel peut être proposée si la valeur numérique ultérieure est supérieure de plus d’un certain pourcentage à la valeur numérique courante (par exemple dix pourcents). Selon un deuxième mode de réalisation, l’option de maintien temporel peut être proposée s’il reste un nombre de sièges inférieur à un seuil dans la classe sélectionnée par l’utilisateur. Selon un troisième mode de réalisation, l’option de maintien temporel peut être proposée s’il y a un nombre de passagers dans la requête utilisateur qui dépasse un certain seuil (par exemple à partir de trois passagers). En effet, dans les deuxième et troisième modes de réalisation, les contraintes de disponibilités des sièges restants peuvent rendre opportune la souscription à l’option de maintien temporel. L’option de maintien temporel du produit candidat est donc proposée de façon dynamique, selon le contexte. La valeur de maintien temporel du produit candidat peut par ailleurs être déterminée de façon dynamique. Elle peut par exemple être déterminée en tenant compte de la différence entre la valeur numérique ultérieure et la valeur numérique courante, du nombre de sièges encore disponibles ou du nombre de passagers dans la requête utilisateur.
L’homme du métier comprendra que les procédés selon les modes de réalisation peut être mis en oeuvre de diverses manières par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels, notamment sous la forme de code de programme pouvant être distribué sous la forme d'un produit de programme, sous diverses formes. En particulier, le code de programme peut être distribué à l'aide de supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par ordinateur et des supports 5 de communication. Les procédés décrits dans la présente description peuvent être notamment implémentés sous la forme d’instructions de programme d’ordinateur exécutables par un ou plusieurs processeurs dans un dispositif informatique d'ordinateur. Ces instructions de programme d’ordinateur peuvent également être stockées dans un support lisible par ordinateur.

Claims (15)

  1. REVENDICATIONS
    1. Dispositif de traitement de requête, implémenté dans un dispositif serveur (90), la requête identifiant des paramètres de requêtes et étant reçue depuis un dispositif client connecté (100) audit dispositif serveur (90), la requête étant traitée par le dispositif serveur (90) à une date donnée dite date de requête, le dispositif serveur (90) étant configuré pour déterminer un ensemble de produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante définie par la valeur courante du produit candidat à la date de requête, et pour transmettre à destination du dispositif client (100), au moins une partie des produits candidats et leur valeur numérique courante respective, caractérisé en ce que le dispositif de traitement de requête comprend en outre une unité de traitement (170) configurée pour déterminer au moins une valeur numérique ultérieure (75) du produit candidat sélectionné, égale à une estimation de la valeur numérique courante du produit candidat à une date postérieure à la date de requête, et pour transmettre au dispositif client (100) ladite au moins une valeur numérique ultérieure.
  2. 2. Dispositif selon la revendication 1, dans lequel le produit candidat sélectionné est associé à au moins une classe de réservation, le dispositif de traitement de requête étant configuré pour effectuer une étape de fermeture de classe consistant à affecter à la valeur numérique ultérieure la valeur numérique courante de la classe de réservation disponible qui est la plus proche de la valeur numérique courante de la classe de réservation du produit candidat sélectionné.
  3. 3. Dispositif selon la revendication 2, dans lequel la classe de réservation du produit sélectionné est obtenue sous la forme d’un doublet de disponibilité fourni par un serveur de disponibilité (130) du dispositif serveur (90), l’étape de fermeture de classe comprenant une réinitialisation dudit doublet de disponibilité.
  4. 4. Dispositif selon l’une des revendications précédentes, comprenant en outre une unité d’interprétation (180) configurée pour déterminer, pour le produit candidat sélectionné, si une condition de durée restrictive s’applique, le dispositif de traitement de requête étant configuré, en cas d’application de ladite condition de durée restrictive, pour déterminer une date de requête modifiée, en affectant à la valeur numérique ultérieure la valeur numérique courante du même produit candidat sélectionné auquel la condition de durée restrictive ne s’applique pas.
  5. 5. Dispositif selon la revendication précédente, le dispositif de traitement de requête étant en outre configuré pour maintenir la date de requête en cas de non application de la condition de durée restrictive.
  6. 6. Dispositif selon la revendication 4, dans lequel la date de requête modifiée New_time_stamp est déterminée par la formule suivante :
    New_time_stamp = travel_date - duration_ADVP + 1, où travel_date correspond à la date du produit, et duration_ADVP correspond à la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique.
  7. 7. Dispositif selon l’une des revendications 2 à 6, dans lequel la détermination de la valeur numérique ultérieure est effectuée à partir d’un facteur de probabilité, déterminé en fonction d’au moins un des paramètres d’un groupe comprenant la date de la requête, la date de produit, la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique, et des valeurs observées de vitesse de fermeture de classes.
  8. 8. Procédé de traitement d’une requête (80) reçue depuis un dispositif client (100) dans un dispositif serveur (90) connecté au dispositif client (100), la requête identifiant des paramètres de requêtes, le procédé comprenant les étapes consistant à :
    -déterminer (1001) un ensemble de produits candidats satisfaisant au moins certains des paramètres de ladite requête, chaque produit candidat étant associé à une valeur numérique courante définie par la valeur courante du produit candidat à la date de requête,
    -transmettre (1002) à destination du dispositif client (100), au moins une partie des produits candidats et leur valeur numérique courante respective, caractérisé en ce que le procédé comprend en outre les étapes consistant à :
    - sélectionner (1003) un des produits candidats transmis au dispositif client (100),
    -déterminer (1004), au moins une valeur numérique ultérieure du produit candidat sélectionné, égale à une estimation de la valeur numérique courante du produit candidat à une date postérieure à la date de requête,
    -transmettre (1005) au dispositif client (100) ladite au moins une valeur numérique ultérieure.
  9. 9. Procédé selon la revendication 8, dans lequel le produit candidat sélectionné est associé à au moins une classe de réservation, le procédé comprenant une étape de fermeture de classe consistant à affecter à la valeur numérique ultérieure la valeur numérique courante de la classe de réservation disponible qui est la plus proche de la valeur numérique courante de la classe de réservation du produit candidat sélectionné.
  10. 10. Procédé selon la revendication 9, dans lequel la classe de réservation du produit sélectionné est obtenue sous la forme d’un doublet de disponibilité fourni par un serveur de disponibilité (130) du dispositif serveur (90), l’étape de fermeture de classe comprenant une réinitialisation dudit doublet de disponibilité.
  11. 11. Procédé selon l’une des revendications 8 à 10, dans lequel le procédé comprend en outre :
    - une étape de détermination, pour le produit candidat sélectionné, de l’application d’une condition de durée restrictive, et
    - en cas d’application de ladite condition de durée restrictive, une étape consistant à modifier la date de requête, en affectant à la valeur numérique ultérieure la valeur numérique courante du même produit candidat sélectionné auquel la condition de durée restrictive ne s’applique pas,
    - en cas de non application de ladite condition de durée restrictive, une étape consistant à maintenir la date de requête.
  12. 12. Procédé selon la revendication précédente, dans lequel la date de requête modifiée New_time_stamp est déterminée par la formule suivante :
    New_time_stamp = travel_date - duration_ADVP + 1, où travel_date correspondant à la date du produit, et duration_ADVP correspond à la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique.
  13. 13. Procédé selon l’une des revendications 9 à 12, dans lequel la détermination de la valeur numérique ultérieure est effectuée à partir d’un facteur de probabilité, déterminé en fonction d’au moins un des paramètres d’un groupe comprenant la date de la requête, la date de produit, la durée précédant la date du produit pendant laquelle la condition de durée restrictive s’applique, et des valeurs observées de vitesse de fermeture de classes.
  14. 14. Procédé selon l’une des revendications 8 à 13, dans lequel un affichage de la valeur numérique ultérieure associée au produit est généré sur une interface graphique d’un site Internet et/ou d’une application dédiée.
  15. 15. Produit-programme d'ordinateur pour le traitement d’une requête, le produit-programme d'ordinateur comprenant un support durable de stockage de données lisibles par ordinateur et un code de programme enregistré sur le support durable de stockage lisible par ordinateur qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène le ou plusieurs processeurs à exécuter les étapes du procédé selon l’une des revendications 8 à 14.
FR1761466A 2017-11-30 2017-11-30 Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne Active FR3074338B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1761466A FR3074338B1 (fr) 2017-11-30 2017-11-30 Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne
US16/183,183 US20190164239A1 (en) 2017-11-30 2018-11-07 Method and device for query processing and determining a future numerical value of a selected product

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1761466A FR3074338B1 (fr) 2017-11-30 2017-11-30 Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne
FR1761466 2017-11-30

Publications (2)

Publication Number Publication Date
FR3074338A1 true FR3074338A1 (fr) 2019-05-31
FR3074338B1 FR3074338B1 (fr) 2023-04-07

Family

ID=61258399

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1761466A Active FR3074338B1 (fr) 2017-11-30 2017-11-30 Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne

Country Status (2)

Country Link
US (1) US20190164239A1 (fr)
FR (1) FR3074338B1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015087036A1 (fr) * 2013-12-11 2015-06-18 Skyscanner Limited Procédé et serveur pour fournir des disponibilités de tarif, telles que des disponibilités de tarif aérien

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015087036A1 (fr) * 2013-12-11 2015-06-18 Skyscanner Limited Procédé et serveur pour fournir des disponibilités de tarif, telles que des disponibilités de tarif aérien

Also Published As

Publication number Publication date
US20190164239A1 (en) 2019-05-30
FR3074338B1 (fr) 2023-04-07

Similar Documents

Publication Publication Date Title
EP2663951A1 (fr) Recherche de vols
US20140067439A1 (en) Travel data ingestion and sessionization in a multi-tenant cloud architecture
FR3021789A1 (fr)
US20140278614A1 (en) Alternative travel recommendations
KR102007995B1 (ko) 항공권 서비스 방법 및 이러한 항공권 서비스를 제공하는 장치
US20200160381A1 (en) Cognitive generation of dynamic promotions on unpurchased items and inventory associated with an upcoming event
CN108140027A (zh) 用于地图的访问点
US10152740B2 (en) Method, medium, and system for improving hardware efficiency in generating travel recommendations
US11681895B2 (en) Cognitive assistant with recommendation capability
FR3104296A1 (fr) Système de determination de produit optimisé
FR3074338A1 (fr) Procede et dispositif de traitement de requete et de determination d'une valeur numerique ulterieure d'un produit selectionne
KR20160086243A (ko) 검색결과 페이지를 통한 컨텐츠의 제공을 위한 시스템 및 방법
AU2015201731A1 (en) Media input reservation system
FR3046866A1 (fr)
FR3071340A1 (fr) Procede et dispositif de traitement de requete, de mise a jour et de fourniture de donnees extraites d'une memoire cache
Turrado Garcia et al. A comparison of learning methods over raw data: forecasting cab services market share in New York City
FR3105522A3 (fr) Système informatique de réservation de voyage
FR3079040A1 (fr) Systeme et procede de fourniture de produits
FR3078189A1 (fr) Echanges avec prise en compte automatique de facteurs associes aux echanges
WO2019177935A1 (fr) Optimisation de création de segment initié par un client
FR3080472A1 (fr) Controle de la generation des resultats de recherche a entrees multiples
FR3078806A1 (fr) Detection, surveillance et gestion des perturbations de voyage
US20120253951A1 (en) Scalable inventory protection and optimization in display advertising
US20230196250A1 (en) Automatic alternative route generation
FR3055056A1 (fr) Generation de recommandations pour des itineraires ayant deux ou plusieurs segments

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20190531

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7