FR3079040A1 - Systeme et procede de fourniture de produits - Google Patents

Abstract

Il est fourni un système serveur (10) pour déterminer une liste de produits en réponse à une requête client provenant d'un dispositif client lors d'une session de requête/réponse, la requête client comprenant un ou plusieurs paramètres de requête, le système comprenant un estimateur de produit configuré pour déterminer une liste de produits principaux, ladite liste des produits principaux comprenant une estimation de l'un ou plusieurs des produits principaux correspondant à la requête client. Le système coopère par ailleurs avec une base de données d'estimation de produits auxiliaires stockant des données historiques associées à des ensembles de produits auxiliaires, les données historiques étant représentées par une structure de données en arbre (8) composée de nœuds. Le système serveur comprend un estimateur de produit auxiliaire (102) pour déterminer, à partir de la structure de données en arbre, une fréquence d'occurrence et une information de valeur du produit auxiliaire pour chaque ensemble de produits auxiliaires dans une liste d'ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires. Le système serveur fournit une liste de produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client, en utilisant de la fréquence d'occurrence et l'information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de ladite liste d'ensembles de produits auxiliaires.

Description

SYSTÈME ET PROCÉDÉ DE FOURNITURE DE PRODUITS

DOMAINE TECHNIQUE

L’invention se rapporte généralement aux architectures client/serveur et, en particulier, aux systèmes, procédés et systèmes informatiques pour fournir des produits à un dispositif client en réponse à une requête client.

CONTEXTE

Au cours de ces dernières décennies, Internet a considérablement révolutionné l’architecture des systèmes informatisés. En particulier, Internet a transformé les systèmes conventionnels de fournisseurs de contenu en des systèmes en ligne dynamiques et extrêmement interactifs utilisant des architectures client/serveur.

Les systèmes modernes de fournisseurs de contenu utilisent un ou plusieurs dispositifs serveurs informatiques (appelés aussi dispositifs serveurs ou serveurs) qui reçoivent des requêtes client provenant de dispositifs informatiques clients (appelés aussi dispositifs client) par l’intermédiaire d’une interface utilisateur dédiée via un réseau de communication. Un utilisateur peut par conséquent soumettre directement une requête pour du contenu (également appelée une interrogation) en utilisant un dispositif client via l’interface utilisateur dédiée pour accéder au contenu tel qu’un produit. Le dispositif du serveur peut rechercher un ou plusieurs produits candidats qui répondent à la requête de l’utilisateur, à l’aide d’un moteur de recherche, et renvoyer une réponse au dispositif client via l’interface dédiée. La réponse peut comporter la liste des produits candidats (appelés aussi propositions de produits ou solutions) déterminée par le moteur de recherche et diverses informations se rapportant à chaque produit candidat. L’utilisateur peut alors sélectionner un produit parmi les produits candidats et initier une transaction d’achat pour acheter le produit.

Certains systèmes de fournisseurs de contenu existants fournissent aussi des produits auxiliaires appelés aussi « produits complémentaires » ou « services » en relation avec les produits fournis. Ces services auxiliaires peuvent être fournis directement par le système du fournisseur de contenu ou fournis par un autre système fournisseur de contenu indirect.

Par exemple, le système du fournisseur de contenu peut être un système fournisseur de voyage qui détermine les meilleures options de voyage en réponse à une requête de l’utilisateur pour un voyage, l’utilisateur spécifiant sur une interface utilisateur un ensemble de paramètres tels qu’une date, un lieu de départ géographique et un lieu d’arrivée géographique, et les préférences supplémentaires éventuelles de l’utilisateur (p. ex. critères de prix, correspondances, etc.) L’utilisateur peut ainsi accéder à l’interface utilisateur dédiée du système de gestion des voyages et soumettre une requête de voyage pour obtenir des renseignements sur le voyage et/ou acheter un produit de voyage (réservation de voyage) tel qu’un produit de vol pour un itinéraire donné, à une date donnée. Dans certaines situations, l’utilisateur peut avoir besoin de services supplémentaires liés au produit de voyage tels que des services optionnels liés au voyage (p. ex. service de repas, services associés au siège, service de transport d’animaux de compagnie, etc.)

Le moteur de recherche des systèmes de fournisseurs de contenu classiques utilise d’importantes ressources pour traiter chaque requête utilisateur, ce traitement nécessitant un nombre élevé d’accès aux données stockées dans plusieurs bases de données ou des ressources de mémoire-cache, et pour déterminer les produits candidats, donnant ainsi lieu à des coûts de calcul élevés.

Pour optimiser les coûts de calcul du moteur de recherche, différentes approches ont été proposées. Une première approche repose sur une limitation du domaine de recherche dans lequel le moteur de recherche détermine la solution candidate en utilisant un algorithme de recherche optimisé ou un préfiltrage.

Une autre approche existante consiste à utiliser des données précalculées pour limiter les calculs requis afin de traiter chaque requête.

Pour optimiser les ressources du système du fournisseur de contenu (système de réservation ou d’achat par exemple), une autre approche existante a été proposée, qui repose sur l’utilisation d’un système « pré-transactionnel » de fournisseur de contenu (appelé aussi système de «pré-réservation», «préachat», ou de «pré-finalisation d’achat» par exemple) connecté au système de transactions pour fournir des recommandations de produit dans une phase pré-transactionnelle (appelée aussi une « recommandation » ou phase de « prétraitement »). Le système pré-transactionnel du fournisseur de contenu (appelé aussi un système pré-transactionnel ci-après) fournit des informations sur le produit à un dispositif client dérivées de données statistiques en réponse à une requête utilisateur. Plus précisément, au lieu de calculer la réponse à chaque requête en temps réel à partir de bases de données à jour, le système pré-transactionnel du fournisseur de contenu utilise des données statistiques liées à des produits déjà achetés sur une période antérieure. De même pour le système de transactions du fournisseur de contenu, le système pré-transactionnel du fournisseur de contenu renvoie les produits candidats (par exemple, les propositions de voyage) au dispositif client, les informations associées aux produits (comme le prix du produit par exemple) étant ainsi déterminées à partir de transactions antérieures. Par ailleurs, le système pré-transactionnel du fournisseur de contenu peut traiter une requête, même si un nombre limité de paramètres de requête est saisi par l’utilisateur. L’utilisateur a ainsi accès à des informations statistiques sur les produits disponibles, sans recourir au moteur de recherche pour traiter les requêtes en temps réel, ainsi que l’accès à plusieurs bases de données. Si l’utilisateur souhaite effectuer une transaction (acheter ou réserver un produit), il peut sélectionner un produit dans l’interface dédiée au système pré-transactionnel du fournisseur de contenu pour être redirigé vers le système du fournisseur de contenu ou il peut accéder directement au système du fournisseur de contenu.

Actuellement, ces systèmes pré-transactionnels ne peuvent fournir que des informations sur les produits directs (produits principaux) envoyées par le système du fournisseur de contenu parce qu’ils traitent un volume conséquent de données liées aux produits. Les systèmes conventionnels pré-transactionnels ne fournissent généralement pas d’information sur les produits complémentaires (c.-à-d. les services) associés à un produit (par exemple la disponibilité du service en rapport à un prix de produit et de service). Dans certains cas, ils peuvent au plus fournir des informations très limitées et pas tout à fait exactes sur les services auxiliaires. Du fait de la relation entre un produit et un service auxiliaire, fixer les valeurs pour un service (les valeurs du service ou les prix) nécessite de corréler ces valeurs à la valeur du produit (prix du produit), ce qui implique une complexité de traitement exponentielle.

Toutefois, dans certaines situations, un utilisateur validera/finalisera une transaction (p. ex. l’achat d’un produit) uniquement si certains services sont disponibles. Des services exemplaires dans le domaine des voyages incluent par exemple une chambre supplémentaire, la disponibilité d’un repas végétarien, la disponibilité de la vidéo à la demande durant un vol, les options de voyage pour les animaux, etc. Par conséquent, après avoir accédé au système prétransactionnel, un utilisateur peut soumettre plusieurs requêtes de transaction au système du fournisseur de contenu de transactions, accéder aux propositions de produit et vérifier les options de service. L’utilisateur peut enfin décider de ne pas procéder à la transaction en raison de l’indisponibilité du(des) service(s) spécifique(s), ou soumettre des requêtes supplémentaires au système du fournisseur de contenu de transactions avec des paramètres différents pour essayer de trouver des produits avec le(s) service(s) souhaité(s) au meilleur prix. Cela se traduit par un coût de calcul supplémentaire au niveau du système de transaction. Ce coût supplémentaire est d’autant plus important, qu’une l’association de la sorte à des services à des produits nécessite des ressources de calcul importantes avec plusieurs accès à différentes bases de données du côté du serveur. Cette surcharge du système de transactions peut limiter ses performances, le délai de traitement des requêtes et sa qualité de service. L’expérience de l’utilisateur peut être profondément affectée par une vitesse de traitement aussi lente, dissuadant ainsi les utilisateurs d’effectuer la transaction, ou les incitant à se tourner vers un autre système fournisseur de contenu.

Des systèmes améliorés et des procédés pour fournir des services et des produits associés aux produits qui limitent la surcharge du système fournisseur de contenu sont par conséquent requis.

RÉSUMÉ

Afin de répondre à ces problèmes et à d’autres, il est fourni un système serveur configuré pour déterminer une liste de produits en réponse à une requête client provenant d’un dispositif client lors d’une session de requête/réponse, la requête client comprenant un ou plusieurs paramètres de requête. Le système serveur comprend un estimateur de produit configuré pour déterminer une liste des principaux produits, la liste des produits principaux comprenant une estimation de l’un ou de plusieurs des produits principaux correspondant à la requête client. Le système serveur coopère par ailleurs avec une base de données d’estimation de produits auxiliaires configurée pour stocker des données historiques associées aux ensembles de produits auxiliaires, les données historiques étant représentées par une structure de données en arbre composée de nœuds. Le système serveur comprend par ailleurs un estimateur de produits auxiliaires configuré pour déterminer à partir de la structure de données en arbre une fréquence d’occurrence et une information de valeur des produits auxiliaires pour chaque produit auxiliaire figurant sur une liste d’ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires, le système serveur étant configuré pour fournir par ailleurs une liste de produits auxiliaires candidats pour chaque produit principal déterminée en réponse à la requête client en utilisant la fréquence d’occurrence et de l’information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires.

Dans certains modes de réalisation, la requête client est reçue à un instant de traitement donné, chaque ensemble de produits auxiliaires identifiant un ou plusieurs produits auxiliaires associés à un produit principal. Les données historiques peuvent ensuite comporter les données collectées à partir des sessions de requête/réponse précédentes, chaque session de requête/réponse précédente étant implémentée entre un dispositif client et un système fournisseur de produits liés à la base de données d’estimation des produits auxiliaires pendant une période de temps prédéfinie avant le délai de traitement.

La structure de données en arbre peut comprendre un nœud racine et une pluralité de niveaux, chaque niveau de la structure de données en arbre correspondant à un paramètre dérivé d’un ou de plusieurs paramètres de requête. Chaque nœud d’un niveau donné de la structure de données en arbre peut alors comporter une valeur de nœud représentant une valeur du paramètre correspondant au niveau, la valeur étant attribuée au paramètre de la requête dans l’une ou plusieurs des sessions de requête/réponse précédentes au fil du temps. Le dernier niveau de chaque branche de l’arbre peut comporter des nœuds-feuilles, avec chaque nœud-feuille correspondant à un ensemble donné de produits auxiliaires.

Dans certains modes de réalisation, chaque nœud-feuille de la structure de données en arbre correspondant à un ensemble de produits auxiliaires comprend par ailleurs une valeur de compteur et une information de valeur, ladite valeur de compteur indiquant le nombre d’occurrences de l’ensemble de produits auxiliaires dans les sessions précédentes de requête/réponse, l’estimateur de produit auxiliaire étant configuré pour déterminer la fréquence d’occurrence de chaque ensemble de produits auxiliaires de la liste d’ensembles de produits auxiliaires en utilisant la valeur de compteur du nœud-feuille correspondant audit ensemble de produits auxiliaires dans la structure de données structure de données en arbre, l’estimateur de produit auxiliaire étant par ailleurs configuré pour déterminer I’ information de valeur du produit auxiliaire pour chaque ensemble de produits auxiliaires de ladite liste des ensembles de produits auxiliaires à partir des informations de la valeur du nœud-feuille correspondant à l’ensemble de produits auxiliaires dans la structure de données structure de données en arbre.

Dans un mode de réalisation, l’information de valeur comprise dans chaque nœudfeuille correspondant à un ensemble donné de produits auxiliaires comprend une fourchette de valeurs définie par un seuil inférieur et un seuil supérieur, le seuil inférieur représentant la valeur inférieure attribuée à l’ensemble des produits auxiliaires dans une session de requête/réponse précédente au cours de la période de temps prédéfinie et le seuil supérieur représentant la valeur la plus élevée attribuée à l’ensemble de produits auxiliaires dans une session de requête/réponse précédente au cours de ladite période de temps prédéfinie.

Si la requête client comporte un paramètre de requête spécifiant un ensemble donné de produits auxiliaires, la liste des ensembles de produits auxiliaires peut comprendre l’ensemble de produits auxiliaires, l’estimateur de produit auxiliaire étant configuré pour parcourir la structure de données structure de données en arbre selon un algorithme de recherche d’arbre pour déterminer un nœud correspondant ayant un chemin dans l’arbre correspondant aux paramètres de requête de la requête client, l’estimateur de produit auxiliaire étant par ailleurs configuré pour rechercher un nœud-feuille dans un sous-arbre du nœud correspondant qui correspond à l’ensemble donné de produits auxiliaires et une condition de seuil associée à la fréquence d’occurrence du nœud-feuille, la fréquence d’occurrence et l’information de valeur du produit auxiliaire de l’unique ensemble de produits auxiliaires étant retirées du nœud-feuille.

Si la requête client ne comprend pas un paramètre de requête spécifiant un ensemble de produits auxiliaires défini, l’estimateur de produit auxiliaire est configuré pour parcourir la structure de données structure de données en arbre selon un algorithme de recherche d’arbre pour déterminer un nœud correspondant ayant un chemin dans l’arbre correspondant aux paramètres de requête client, l’estimateur de produit auxiliaire étant par ailleurs configuré pour rechercher tous les nœuds-feuilles dans un sous-arbre du nœud correspondant, l’estimateur de produit auxiliaire étant configuré pour déterminer un indicateur de popularité de l’ensemble du produit auxiliaire associé à chaque nœud-feuille trouvé, et choisir un ou plusieurs ensembles de produits auxiliaires parmi les ensembles de produits auxiliaires associés aux nœuds-feuilles en fonction des indicateurs de popularité, les ensembles de produits auxiliaires étant ajoutés dans la liste des ensembles de produits auxiliaires, la fréquence d’occurrence et les informations de valeur de chaque ensemble de produits auxiliaires dans la liste des ensembles de produits auxiliaires étant retirées du nœud-feuille correspondant.

Dans certains modes de réalisation, le système comprend un calculateur de popularité de produit auxiliaire configuré pour déterminer l’indicateur de la popularité de chaque ensemble de produits auxiliaires d’un nœud-feuille en utilisant de la fréquence d’occurrence associée au nœud-feuille.

Le système peut comprendre par ailleurs un coordinateur de prétraitement configuré pour mettre à jour les informations de valeur estimées par l’estimateur de produit auxiliaire pour chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires à partir de données en temps réel.

Dans un mode de réalisation, le système peut comprendre un corrélateur de produits auxiliaires configuré pour intégrer les informations de valeur de produit auxiliaire de chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires à la valeur d’un produit principal déterminé par l’estimateur de produit, en fonction d’un indicateur d’applicabilité.

Le système peut comprendre par ailleurs un moteur d’apprentissage de produit auxiliaire configuré pour recueillir des métadonnées d’apprentissage au cours d’une période d’apprentissage prédéfinie, le système comprenant par ailleurs un gestionnaire d’arbre pour gérer la structure de données structure de données en arbre à l’aide des métadonnées d’apprentissage recueillies.

Le gestionnaire d’arbre peut être configuré pour créer un nœud dans la structure de données structure de données en arbre en réponse à la spécification d’une nouvelle valeur d’un paramètre correspondant à un niveau de l’arbre, dans une session de requête/réponse en temps réel, et pour régler la valeur de compteur dudit nœud sur la valeur 1.

Le gestionnaire d’arbre peut être configuré pour mettre à jour un nœud dans la structure des données d’arbre chaque fois que la valeur associée audit nœud est spécifiée dans une session de requête/réponse pour le paramètre correspondant au niveau des nœuds, et pour incrémenter la valeur de compteur dudit nœud.

Le gestionnaire d’arbre peut être configuré pour vérifier périodiquement la configuration de la structure de données d’arbre et pour appliquer un algorithme d’équilibrage à la structure de données d’arbre si la structure de données d’arbre est déséquilibrée.

Par ailleurs, un procédé est fourni pour déterminer une liste de produits en réponse à une requête client provenant d’un dispositif client lors d’une session de requête/réponse, la requête client comprenant un ou plusieurs paramètres de requête, le procédé comprenant une phase de détermination d’une liste de produits principaux, la liste des produits principaux comprenant une estimation de l’un ou de plusieurs des produits principaux correspondant à la requête client. Le procédé consiste par ailleurs à déterminer une fréquence d’occurrence et une information de valeur de produit auxiliaire pour un ensemble de produits auxiliaires dans une liste d’ensembles de produits auxiliaires, à partir d’un arbre de données représentant les données historiques liées aux ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires, la structure de données en arbre étant composée de nœuds.

Le procédé comprend par ailleurs une étape consistant à fournir une liste de produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client à l’aide de la fréquence d’occurrence et de l'information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires.

Par ailleurs, un produit-programme d’ordinateur est fourni pour déterminer une liste de produits en réponse à une requête client provenant d’un dispositif client lors d’une session de requête/réponse, la requête client comprenant un ou plusieurs paramètres de requête, le produit-programme d’ordinateur comprenant :

un support non transitoire de stockage de données lisibles par ordinateur; et un code de programme enregistré sur le support non transitoire de stockage lisible par ordinateur qui, lorsqu’il est exécuté par un ou plusieurs des processeurs, amène le ou les plusieurs processeurs à :

-déterminer une liste des produits principaux, la liste des produits principaux comprenant une estimation de l’un ou de plusieurs des produits principaux correspondant à la requête client.

L’un ou plusieurs des processeurs sont par ailleurs amenés à :

-déterminer une fréquence d’occurrence et une information de valeur de produits auxiliaire pour chaque ensemble de produits auxiliaires dans une liste d’ensembles de produits auxiliaires, à partir d’une structure de données en arbre représentant les données historiques liées aux ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires, la structure de données en arbre étant composée de nœuds.

L’un ou plusieurs processeurs sont par ailleurs amenés à fournir une liste des produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client à partir de la fréquence d’occurrence et de l’information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires.

BRÈVE DESCRIPTION DES DESSINS

Les dessins accompagnant qui sont incorporés et constituent une partie de cette spécification, illustrent des modes variés de réalisation de l’invention et, avec la description générale de l’invention ci-dessus et la description détaillée des modes de réalisation donnée ciaprès, servent à expliquer les modes de réalisation de l’invention.

- La figure 1 décrit un exemple d’un environnement d’exploitation d’un système fournisseur de contenu pré-transactionnel 10, selon certains modes de réalisation.

- La Figure 2 représente un environnement d’exploitation du système prétransactionnel 10 d’un fournisseur de voyage (appelé ci-après «système de préréservation»), selon une application exemplaire de l’invention dans l’industrie du voyage.

- La figure 3 représente une implémentation exemplaire d’un système prétransactionnel, selon certains modes de réalisation.

- La figure 4 est un diagramme décrivant une plateforme de recherche en masse exemplaire.

- La figure 5 décrit de façon schématique une structure de données en arbre conforme à certains modes de réalisation.

- La figure 6 est un organigramme séquentiel décrivant le processus de détermination d’un ensemble de services, selon un mode de réalisation en mode ‘pull’.

- La figure 7 est un organigramme séquentiel décrivant le processus de détermination d’une liste d’ensembles de services, conforme à un mode de réalisation en mode ‘push’.

- La figure 8 est un organigramme séquentiel décrivant le processus de commutation d’un mode d’estimation de service, conforme à certains modes de réalisation.

- La figure 9 est un organigramme séquentiel décrivant le processus de détermination d’ensembles de services, selon certains modes de réalisation.

- La figure 10 est un organigramme séquentiel décrivant le processus de corrélation des services selon certains modes de réalisation.

- La figure 11 représente un environnement d’exploitation exemplaire dans lequel un ou plusieurs composants d’un système pré-transactionnel peuvent être implémentés selon un mode de réalisation.

DESCRIPTION DÉTAILLÉE

Les modes de réalisation de l’invention fournissent un système serveur et un procédé pour déterminer une liste de produits en réponse à une requête client reçue d’un dispositif client, dans un environnement informatique, au cours d’une session de requête/réponse, la liste des produits (appelée aussi recommandations de produits) comprenant une liste des produits candidats principaux qui satisfont la requête client et, pour au moins un produit principal, un ou plusieurs produits auxiliaires (aussi dénommés ci-après «services» ou «services auxiliaires») associés au produit principal proposé au dispositif client. Les modes de réalisation de l’invention ont des avantages particuliers lorsque la session de requête/réponse correspond à une phase pré-transactionnelle, l’invention permettant l’intégration de recommandations de services associées à chaque recommandation de produit déterminée en réponse à la requête client, au cours de cette phase pré-transactionnelle.

Tel qu’il est utilisé, le terme « pré-transactionnel » fait référence à une phase antérieure à un flux de transactions implémenté dans un système de transaction, un flux de transaction débutant à partir d’une requête d’utilisateur reçue par le système de transaction pour un produit spécifié par les paramètres de la requête et s’achevant par une opération d’achat d’un produit par l’entremise du système de transaction (le terme « transaction » fait aussi référence à un « achat », une «finalisation d’achat» ou une «réservation»). Dans une architecture de serveur client, une «transaction » correspond à une session de requête/réponse initiée par une requête client et finalisée par l’achat d’un produit (sélection d’un produit principal par l’utilisateur et validation de la sélection par le paiement de la valeur du prix associée au produit). La transaction du produit peut comprendre un ensemble comprenant un produit principal et un produit auxiliaire associé (ensemble de services) comprenant un ou plusieurs produits auxiliaires (les services) associés au produit principal, la valeur globale (prix total) de la transaction comprenant la valeur du produit principal ajoutée à la valeur de l’ensemble de services.

Tel qu’il est utilisé, une phase pré-transactionnelle est déclenchée par une ou plusieurs requêtes d’utilisateur (qui peuvent être des requêtes « ouvertes ») et elle renvoie une liste des produits estimés être des produits candidats (également appelés « recommandations » de produits), fournie par le système de transaction en utilisant des données variées pouvant inclure des données statistiques. Ces données statistiques peuvent être utilisées pour fournir plus d’informations au cas où un ensemble donné de services n’aurait pas été précalculé. Une phase pré-transactionnelle renvoie ainsi des informations statistiques sur les produits.

Faisant référence à la figure 1, il est montré un environnement d’exploitation exemplaire 100 du système d’un fournisseur de contenu pré-transactionnel 10, selon certains modes de réalisation.

Le système 10 du fournisseur de contenu pré-transactionnel (également dénommé ciaprès système pré-transactionnel ou «système serveur») peut être configuré pour déterminer un ensemble de recommandations de produits candidats pour un dispositif d’utilisateur 2 en réponse à une requête d’utilisateur (dénommée requête pré-transactionnelle) identifiant un ou plusieurs paramètres de requête parmi un ensemble de paramètres de requête prédéfinis par un format de requête au cours d’une phase pré-transactionnelle.

Dans un mode de réalisation, le système du fournisseur de contenu prétransactionnel 10 peut héberger un ou plusieurs sites Web et/ou avoir un service d’hébergement qui héberge un ou plusieurs sites Web.

Tel qu’il est utilisé, le terme « contenu » fait référence à tout contenu qui peut être fourni à un dispositif d’utilisateur par l’entremise d’une interface d’utilisateur sous la forme de produits, chaque produit étant potentiellement associé à un ou à plusieurs services («services auxiliaires») associés aux produits. Chaque produit peut être défini par un ensemble de paramètres dépendant du champ d’application de l’invention, et par une valeur (le prix). Une représentation de ce contenu peut être générée sur une interface graphique d’utilisateur utilisant des éléments de représentation variés tels que du texte électronique, des images, des photos, des enregistrements audio et d’autres formes de données qui peuvent être traitées, stockées et retournées.

Chaque dispositif client 2 (également dénommé « dispositif d’utilisateur » peut être un dispositif informatique personnel, une tablette informatique, un terminal client léger (thin client), un smartphone et/ou un autre dispositif informatique de ce genre. Chaque dispositif client 2 peut héberger des navigateurs Web et/ou un logiciel d’applications personnalisées (p. ex. un système client), et peut inclure une interface d’utilisateur client.

Chaque dispositif d’utilisateur 2 peut par ailleurs inclure une application de navigateur Web qui communique avec une application de serveur Web hébergée par le système prétransactionnel 10.

Le système pré-transactionnel 10 peut communiquer avec un ou plusieurs systèmes de « transaction » de fournisseurs de contenu 12 (également appelé « système de transaction » 12) par l’entremise d’un réseau dédié 21 pour permettre au système pré-transactionnel 10 d’accéder à des données historiques conservées par chaque système de transaction 12.

Chaque système de transaction 12 peut être configuré pour traiter en temps réel les requêtes d’utilisateurs (également appelées requêtes de « transaction ») en utilisant un moteur de recherche configuré pour accéder en temps réel à un ou à plusieurs contenus de bases de données. Il est par ailleurs adapté pour mettre en œuvre des transactions avec un utilisateur (telles que la réservation ou l’achat d’un produit et potentiellement de services associés au produit). Une transaction pour un produit est finalisée lorsqu’un utilisateur procède au paiement du produit et des services optionnels. Dans certains modes de réalisation, le système de transaction 12 peut être configuré pour ne traiter que les requêtes d’utilisateur qui comprennent un ensemble de paramètres de recherche obligatoires.

Un utilisateur faisant fonctionner un des dispositifs d’utilisateur 2 peut faire interface directement avec le système pré-transactionnel 10 en utilisant une interface d’utilisateur prétransactionnelle dédiée au cours d’une session client/serveur. Dans certains modes de réalisation, le système pré-transactionnel 10 peut être configuré pour rediriger un dispositif d’utilisateur 2 vers une interface dédiée du système de transaction 12, en réponse à une sélection d’un produit par un utilisateur. L’utilisateur peut par ailleurs faire interface directement avec le système du fournisseur de contenu de transaction 12 en utilisant l’interface d’utilisateur pré-transactionnelle dédiée.

Le système du fournisseur de contenu de transaction 12 peut stocker un compte d’utilisateur si l’utilisateur est déjà enregistré ou peut autrement ne comprendre aucune donnée liée à l’utilisateur si l’utilisateur n’a pas créé un compte d’utilisateur précédemment.

Le système pré-transactionnel 10 et le système de transaction 12 sont dédiés au même domaine d’application (par exemple, l’industrie du voyage). Le système pré-transactionnel 10 et le système transactionnel 12 peuvent être configurés pour déterminer des produits candidats du même type. Cependant, ils font référence à des phases de transaction différentes. Par ailleurs, alors que le système du fournisseur de contenu de transaction 12 peut comprendre un moteur de recherche qui implémente un algorithme de recherche pour rechercher des produits correspondants à une requête dans une ou plusieurs bases de données de contenu, le système pré-transactionnel 10 peut comprendre un estimateur de produit 101 configuré pour estimer les solutions de produits (les produits candidats) pour une requête d’utilisateur en recherchant des données statistiques liées à des transactions passées, réalisées par le système de transaction 12, sans avoir besoin d’accéder à de multiples bases de données de contenu. Par conséquent, alors que les réponses retournées par le système pré-transactionnel 10 peuvent être basées sur des données historiques, les réponses retournées par le système du fournisseur de contenu de transaction 12 peuvent être basées sur des données en temps réel récupérées à partir des bases de données de contenu. Le système pré-transactionnel 10 limite ainsi la charge du système du fournisseur de contenu de transaction 12, un utilisateur désirant avoir une vue des options de produits possibles étant capable de soumettre une requête ouverte au système pré-transactionnel 10, d’affiner sa requête en fonction des résultats retournés par le système pré-transactionnel 10 et de soumettre la requête affinée au système du fournisseur de contenu de transaction 12 si l’utilisateur décide de poursuivre avec une transaction.

Dans certains modes de réalisation, le système pré-transactionnel 10 (système serveur) peut comprendre un moteur d’estimation de service 1 (aussi dénommé « moteur d’estimation de produit auxiliaire ») configuré pour estimer les recommandations de services en réponse à une requête pré-transactionnelle. Le moteur d’estimation de services 1 peut comprendre une base de données d’estimation de services 103 configurés pour stocker des données historiques liées aux ensembles de services (aussi dénommés « produits auxiliaires » ou « produits complémentaires »), les données historiques étant représentées par une structure de données en arbre comprenant des nœuds. Le moteur d’estimation de services 1 peut par ailleurs comprendre un estimateur de service 102 (également dénommé « estimateur de produit auxiliaire») configuré pour déterminer à partir de la structure de données en arbre une fréquence d’occurrence et une information de valeur d’un produit auxiliaire pour chaque ensemble de services dans une liste d’ensembles de produits auxiliaires, en réponse à la requête client. La liste d’ensembles de service peut comprendre au moins un ensemble de services (un ensemble de services peut aussi être dénommé ci-après « ensemble de produits auxiliaires»), le système pré-transactionnel 10 étant configuré pour fournir par ailleurs une liste des produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client en utilisant la fréquence d’occurrence et la valeur du service déterminée pour chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires.

Le système pré-transactionnel 10 peut être configuré pour fournir des recommandations de services pour chaque produit candidat en utilisant la fréquence d’occurrence et la valeur de service déterminée pour chaque ensemble de services de la liste des ensembles de services.

Dans un mode de réalisation, la requête client peut être reçue par le système prétransactionnel 10 à un instant de traitement donné et chaque ensemble de services peut identifier un ou plusieurs produits auxiliaires associés à un produit principal. Dans ce mode de réalisation, les données historiques comprennent des données collectées à partir de sessions de requête/réponse antérieures (transactions antérieures), chaque transaction antérieure étant implémentée entre un dispositif client et un système fournisseur d’un produit connecté à la base de données d’estimation de service 103 au cours d’une période prédéfinie avant l’instant du traitement.

Dans une application exemplaire de l’invention dans l’industrie du voyage, le système de préréservation 10 peut être configuré pour fournir des recommandations de voyage pour des produits de voyage (les produits de voyage candidats), tels que les produits de voyage d’une compagnie aérienne.

Une requête de voyage a un format prédéfini définissant un ensemble de paramètres de requête incluant :

- des paramètres d’heure/date/lieu de départ ;

- des paramètres d’heure/date/lieu d’arrivée ;

- des paramètres additionnels relatifs au voyage.

Les paramètres de requête pour le système du système de transaction du fournisseur de voyage 12 (également appelé ci-après «système de “réservation » ou système de «finalisation d’achat») peuvent inclure des paramètres de requête « optionnels » et/ou « obligatoires », les paramètres de requête obligatoires étant requis par le système de « réservation » pour être capables de traiter la requête. Les paramètres optionnels de requête peuvent inclure par exemple la langue préférée de l’utilisateur, ou des paramètres d’affinage (p. ex. l’heure du jour, la compagnie préférée). Généralement, le système pré-transactionnel du fournisseur de voyage 10 (également appelé ci-après système de « préréservation » ou système de « préachat » peut lancer une requête sans aucune exigence concernant les paramètres obligatoires de requête. Par exemple, le traitement d’une requête peut être déclenché par toute requête comprenant au moins un paramètre de requête.

Un paramètre de requête de voyage peut avoir une typologie (par exemple « le lieu de départ», «lieu d’arrivée»), une catégorie de données (p. ex. lieu, date), un type de donnée (p. ex., caractère) et/ou un format de donnée (défini par exemple par la norme IATA, IATA étant « l’association internationale de transport aérien »).

Les modes de réalisation de l’invention peuvent être mis en œuvre sur un ou plusieurs systèmes informatiques comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Les systèmes informatiques peuvent fournir le traitement et les fonctions de base de données pour les systèmes de pré-transaction et de fournisseur de contenu de transaction 10 et 12.

Le système pré-transactionnel 10 et le système du fournisseur de contenu de transaction 12 peuvent héberger un ou plusieurs sites Web et/ou avoir un service d’hébergement hébergeant un ou plusieurs sites Web.

Chaque réseau de communication 21 peut inclure un ou plusieurs réseaux privés et/ou publics (p. ex. Internet) qui permettent l’échange de données, tels qu’internet, un réseau de zone locale (LAN), un réseau de zone étendue (WAN), un réseau cellulaire voix/données, une ou plusieurs connexions par bus à haute vitesse et/ou d’autres types de réseaux de communication de ce genre. Chaque réseau de communication 21, 22 peut utiliser des technologies de communication normales et/ou des protocoles tels que 4G, Ethernet, 802.11, TCP/IP (Protocole de contrôle de transmission/Protocole Internet), HTTP (Protocole de transport hypertexte), FTP (Protocole de transfert de fichier), etc. Les données peuvent être échangées sur chaque réseau 21, 22 selon des technologies d’échange de données différentes et/ou des formats tels que le langage de balisage hypertexte (HTML), le modèle JSON et le langage de balisage étendu (XML).

Le système pré-transactionnel 10 peut comprendre une fonction de redirection pour rediriger l’utilisateur vers le domaine Internet du système de transaction 12 en utilisant une URL associée, en réponse à une sélection faite par l’utilisateur pour un produit candidat afin de lui permettre de finaliser une transaction. Dans certains modes de réalisation, le dispositif de système pré-transactionnel 10 peut envoyer une requête correspondant à la sélection de l’utilisateur au système de transaction 12 en utilisant une URL d’un type prédéfini qui peut comprendre un ensemble de champs tel qu’un Corps, le champ d’identifiant de système fournisseur de contenu tel qu’un champ de Chaîne, des champs additionnels liés aux paramètres de la requête (nom/paires de valeurs) ainsi que sélectionnés par l’utilisateur. L’homme de métier comprendra aisément que l’invention n’est pas limitée à ces champs spécifiques dans la requête URL et peut inclure des champs différents selon l’application de l’invention.

La figure 2 représente l’environnement opérationnel du système pré-transactionnel d’un fournisseur de voyage 10 (dénommé ci-après «système de préréservation») conforme à une application exemplaire de l’invention pour l’industrie du voyage. L’environnement peut inclure un système de distribution globale (GDS) 200, un ou plusieurs systèmes de fournisseurs indirects de produits 20, tels que les systèmes des transporteurs 201, un ou plusieurs systèmes de vendeurs indirects ou de préachat de voyage (systèmes de fournisseurs de contenu auxiliaire), tels qu’un système d’agence de voyages 202, un système pré-transactionnel d’un fournisseur 10, un système d’un fournisseur de transaction 12 et un ou plusieurs dispositifs clients 2. Chacun d’eux, le GDS 200, les systèmes des transporteurs 201, le système du vendeur indirect 202, le système pré-transactionnel 10 et le système de transaction 12 ainsi que le dispositif d’utilisateur 2 peuvent communiquer par l’entremise du réseau 21. Les systèmes des transporteurs 201 peuvent chacun inclure un système de réservation informatique (CRS) et/ou un système de facturation pour la compagnie aérienne respective qui permet au GDS 200 et/ou au système du vendeur indirect 202 de réserver et de payer des billets d’avion. Les systèmes des transporteurs 201 peuvent aussi interagir les uns avec les autres ou via le GDS 200, afin de permettre au transporteur émetteur de vendre des sièges fournis par le transporteur de fait. Le transporteur de fait peut ensuite facturer le transporteur émetteur pour les services fournis.

Le GDS 200 peut être configuré pour faciliter la communication entre les systèmes des transporteurs 201 et les systèmes des vendeurs indirects 202 en permettant aux agents de voyage, aux transporteurs émetteurs, ou à d’autres vendeurs indirects de rechercher des segments disponibles et de finaliser des réservations sur un ou plusieurs systèmes de transporteur 21, via le GDS 200. Dans ce but, le GDS 200 peut entretenir des liens avec chacun des systèmes des transporteurs 201 via le réseau 62. Ces liens peuvent permettre au GDS 200 d’obtenir des données de planification et de disponibilité pour des segments à partir des systèmes des transporteurs 201, et des requêtes de réservation de propositions de voyage aux systèmes des transporteurs 201. Les systèmes des transporteurs et des agences de voyages

201, 202 peuvent ainsi réserver des vols auprès de multiples transporteurs via une seule connexion au GDS 200. Le GDS 200 peut stocker et/ou conserver un enregistrement de nom de passager (PNR) qui inclut un ensemble complet des données pour l’itinéraire d’un voyage, incluant les segments de multiples transporteurs et/ou d’autres services de voyage comprenant le voyage, tels que les réservations d’hôtel et de voiture de location.

Un système d’agence de voyages 202 peut inclure un serveur Web qui fournit un site Web accessible au grand public. Ce site Web peut être configuré pour fournir un accès à des éléments de planification de voyage, tels que la capacité à rechercher des produits de voyage correspondant à une requête de voyage. Dans ce but, le système de l’agence de voyages 202 peut fournir au voyageur un accès à des données à partir d’une ou de plusieurs bases de données hébergées par le GDS 200, les systèmes des transporteurs 201 et le système de l’agence de voyages 202. Dans un autre mode de réalisation de l’invention, le système de l’agence de voyages 202 peut être un système propriétaire qui limite l’accès aux fournisseurs de services de voyage ou aux agents de voyage, dans ce cas l’accès peut être fourni par l’entremise d’un site Web privé ou une autre application.

Le système de transaction du fournisseur de voyage 12 peut être en communication avec le système de l’agence de voyages 202 via le réseau 62 ou une autre connexion adaptée. Dans d’autres modes de réalisation de l’invention, tout le système du fournisseur de voyage 2 ou une portion, peut être intégré dans un ou plusieurs des autres systèmes 200, 201, 202. Les voyageurs les agents de voyage peuvent utiliser le système de l’agence de voyages 202 pour générer et/ou rechercher des propositions de voyage qui satisfont une requête de voyage reçue de la part du voyageur en utilisant le système du fournisseur de voyage 2.

Le GDS 200, les systèmes des transporteurs 201, le système de l’agence de voyages 202, le système du fournisseur de voyage 12 et les dispositifs d’utilisateur 2 de l’environnement d’exploitation peuvent être implémentés sur un ou plusieurs dispositifs informatiques ou systèmes, dénommés collectivement un ordinateur.

La figure 3 représente une implémentation exemplaire du système prétransactionnel 10. Comme le montre la figure 3, le système pré-transactionnel 10 peut comprendre, ou être connecté à, une plateforme de recherche distribuée MSP 11 (MSP est l’acronyme de Massive Search Platform) configurée pour stocker des valeurs précalculées de produits. La plateforme MSP 11 peut comprendre une ou plusieurs machines distribuées, chaque machine comprenant un ou plusieurs systèmes informatiques. La figure 3 décrit seulement une vue logique de la plateforme alors que la plateforme MSP peut être physiquement répartie sur un ensemble de machines distribuées. La plateforme MSP 11 peut être configurée pour stocker les meilleures valeurs de produits d’un ensemble de systèmes de fournisseurs de contenu 12 fournissant des produits pour tous les jours de l’année à venir, ce qui peut inclure plusieurs valeurs de produits possibles par jour.

La figure 4 montre une plateforme exemplaire MSP 11 dans l’industrie du voyage. Dans cet exemple, la plateforme MSP 11 peut être configurée pour stocker et rechercher des recommandations de voyage, chaque recommandation de voyage identifiant un produit candidat (p. ex. un vol), le produit candidat étant associé à une valeur de produit (ou « prix » du produit) selon un mode de réalisation exemplaire de la présente invention. Les recommandations de voyage stockées peuvent être réparties sur toutes les machines qui sont connectées à la plateforme MSP. La plateforme MSP 11 peut comprendre une ou plusieurs bases de données 113 pour stocker des recommandations de transport aérien qui peuvent logiquement être groupées en groupes de recommandations. Bien qu’une vue statique soit montrée dans la figure 4, l’homme de métier comprendra aisément que les bases de données 113 peuvent être physiquement stockées entre les différentes machines.

La plateforme MSP 11 peut par ailleurs comprendre un moteur de chargement 115 configurée pour indexer les groupes de recommandations précalculées de transport aérien (par exemple, les voyages correspondant à un même itinéraire défini par une paire de villes) et pour les stocker dans une des machines dans le système distribué.

La plateforme MSP 11 peut aussi comprendre un moteur de recherche 117 configuré pour localiser des groupes de données parmi les machines physiques et fournir des informations de recherche indexées pour traiter les requêtes provenant des dispositifs d’utilisateurs 2.

Dans certains modes de réalisation, la plateforme MSP 11 peut comprendre un ensemble de moteurs d’analyse orientés-commerce 108. Chaque moteur d’analyse orientécommerce108 peut être configuré pour optimiser les coûts matériels de la plateforme en déterminant le nombre optimal de recommandations pour recalculer chaque jour, avec autant d’exactitude que possible, les prix précalculés en utilisant des processus variés tels qu’une analyse d’opération de chargement et de recherche, diverses données telles que des métriques générées sur la volatilité et la qualité des données stockées dans le système. Une implémentation exemplaire d’une MSP 11 est décrite dans la demande du brevet US20130073586 A1.

Revenant à la figure 3, dans certains modes de réalisation, l’environnement peut par ailleurs comprendre une plateforme de calcul massive 13 ou MCP. Les moteurs d’analyse de la MSP 11 peuvent transmettre des données à la MCP 13. Le système pré-transactionnel 10 peut être connecté à la MCP 13, ou peut la comprendre. La MCP 13 peut être configurée pour calculer les produits candidats (p. ex. des vols) et des informations de valeurs de produits, telles que des prix, à une échelle massive. Plus spécifiquement, la MCP 13 peut être configurée pour traiter les requêtes pré-transactionnelles même si le nombre de paramètres fournis dans la requête est limité. Dans une application exemplaire de l’invention pour l’industrie du voyage, la MCP 13 peut interagir avec d’autres services internes fournis par un GDS 200. La MCP 13 peut traiter une requête avec un degré de liberté élevé, même si aucun paramètre obligatoire de requête n’est spécifié (p. ex. le paramètre de date de voyage ou le lieu d’origine et/ou de destination, ou le transporteur de fait dans une application exemplaire de l’invention pour l’industrie du voyage). La MCP 13 peut effectuer une optimisation de traitement de données sur la base d’une analyse globale de requête.

La MCP 13 peut être organisée selon un modèle comprenant des ressources qui peuvent être instanciées de façon dynamique. Le sous-système effectue l’optimisation de traitement de données sur la base d’une analyse globale des interrogations.

Dans un exemple d’application de l’invention pour l’industrie du voyage, la MCP 13 peut inclure un ou plusieurs Maîtres Massifs (‘Massive Master’) et une pluralité de Moteurs de travail Massifs (‘Massive Working Engines’). Les maîtres massifs peuvent être configurés pour analyser les requêtes globalement lesquelles sont ensuite décomposées en requêtes optimisées. Les requêtes optimisées obtenues ainsi peuvent ensuite être traitées par un ou plusieurs des Moteurs de travail Massif. Chaque Moteur de travail Massif peut renvoyer le résultat du traitement de la requête optimisée au(x) Maître(s) Massif(s) qui assemble(nt) les résultats en produits candidats (tels que des solutions de voyage), chaque produit candidat incluant une valeur de produit (p. ex. le prix du voyage).

La MCP 13 peut par ailleurs être configurée pour effectuer une analyse globale afin d’identifier les redondances (redondances de requêtes) entre les requêtes reçues afin d’éviter un retraitement inutile. Ceci peut inclure le fusionnement de parties d’interrogations redondantes en fonction d’exigences de performance prédéfinies.

La MSP 11 et la MCP 13 peuvent faire partie d’une plateforme de recherche distribuée, connectée à un ensemble du système de transaction du fournisseur de voyage 12 (tel que les systèmes de compagnies aériennes, les systèmes d’agences de voyages, etc.). Chaque système de transaction de fournisseur de voyage 12 peut définir quelle partie de son secteur de produits doit être intégrée dans la plateforme de recherche. Dans une application exemplaire pour l’industrie du voyage, chaque système de transaction de fournisseur de voyage 12 peut ensuite envoyer à la MCP 11 une interrogation «massive» comprenant une série d’ordres de calculs, chaque ordre définissant les marchés pris en compte (tels qu’une liste de paires de villes pour tous les jours de l’année à venir dans l’industrie du voyage) et le type de recommandation de produits à générer (p. ex. pour chaque jour, les meilleures recommandations pour des voyages d’une durée de 1 à 20 jours). Ces ordres peuvent être mis à jour par le système de transaction du fournisseur de voyage 12 ou peuvent servir comme base pour un calcul périodique. La MCP 13 peut utiliser des fonctions internes du GDS 200 pour calculer les recommandations demandées, telles que la fonction de récupération d’un voyage pour récupérer une liste de vols existants, une fonction de prix pour trouver la meilleure combinaison de tarifs et de produits (p. ex. des vols), une fonction de disponibilité pour déterminer les produits disponibles à réserver ou à acheter.

Puisque les recommandations sont générées pour le système de transaction du fournisseur de voyage 12, les recommandations peuvent être stockées dans une mémoirecache globale (le Référentiel Massif 113) de recommandations de voyage précalculées devenant ainsi disponibles pour de futures requêtes de recherche de la part des utilisateurs. Le Référentiel Massif 113 peut être utilisé pour stocker les recommandations calculées par la MCP 13. La recherche parmi les solutions possibles est réalisée par la MSP 11.

Le système pré-transactionnel 10 permet à un utilisateur de soumettre des requêtes ouvertes à partir d’une interface d’utilisateur dédiée, affichée sur un dispositif d’utilisateur. Une requête ouverte de pré-transaction soumise par un utilisateur au système pré-transactionnel de voyage peut, par exemple, être « Où puis-je aller ? », « Que puis-je faire pour ce que je veux dépenser?». Tel qu’il est utilisé, une requête « ouverte » fait référence à une requête définie par un ensemble de paramètres de requête, une valeur de paramètre de requête étant spécifiée par l’utilisateur seulement pour un sous-ensemble limité de paramètres de requête qui peut ne comprendre qu’un seul paramètre de requête. Le système pré-transactionnel 10 peut ensuite renvoyer une réponse sous forme de produits candidats qui satisfont la requête ouverte. L’utilisateur peut sélectionner un produit candidat sur la même page de recherche, sans avoir besoin de se connecter directement au système de transaction du fournisseur de voyage et de spécifier tous les paramètres de requête obligatoires (p. ex. le lieu de destination, la date de départ, etc.).

Le système pré-transactionnel 10, selon certains modes de réalisation de l’invention, rend possible la sélection d’un produit par un utilisateur en fonction de la disponibilité estimée et du prix associé au(x) service(s) donné(s) au cours d’une phase de pré-transaction.

Dans un mode de réalisation, l’utilisateur peut spécifier les services désirés dans la requête de pré-transaction soumise en mode « pull » (signifiant « mode tiré »). Autrement, des recommandations de services (aussi dénommées « recommandations » de services) peuvent être retournées à l’utilisateur de façon dynamique, lesquelles sont associées à un produit, sans qu’un ensemble de services soit spécifié par l’utilisateur, sur la base d’indicateurs de popularité précalculés associés à chaque service (« mode ‘push’ » signifiant « mode poussé »).

Un produit (appelé aussi « produit principal ») peut être associé à des informations de produits identifiant le produit (par exemple, un produit de transport aérien est associé à une paire de villes, une date de départ/d’arrivée, une heure de départ/d’arrivée) et à une valeur de produits représentant le prix d’un produit disponible pour achat. Un produit peut être par ailleurs associé à un ensemble de services comprenant au moins un service.

Un service ou un « service auxiliaire » (appelé aussi « produit auxiliaire » ou « produit complémentaire ») lié à un produit principal donné peut être associé à des informations de service identifiant le service, des informations de disponibilité indiquant si le service est disponible pour le produit et une valeur de service représentant le prix du service.

Un «ensemble de services» fait référence à une pluralité de services qui peuvent être achetés ou réservés ensemble avec un produit par un utilisateur au cours d’une transaction entre le dispositif client de l’utilisateur et un système de transaction 12.

La valeur du service (prix du service) associé à un service auxiliaire lié à un produit donné peut être dépendante du produit. Par exemple, le prix d’un service auxiliaire lié à un produit de voyage peut dépendre de plusieurs paramètres tels que :

- la complexité initiale du nombre de résultats de prix de produits dans le système de préréservation 10 ; par exemple, considérant pour un client, 500 destinations, 300 dates, 10 durées de séjour, le nombre de prix de produits est égal à :

destinations x 300 dates x 10 durées de séjour = 1.500.000 prix ;

la dimension du service auxiliaire ; par exemple, considérant la recherche d’une compagnie aérienne proposant 20 services différents et considérant que le client peut être intéressé par tout ensemble de services parmi ces 20 services, la dimension du service auxiliaire correspondant peut être égale à 2²⁰ = 10⁶ services auxiliaires ; la combinaison de la dimension des résultats de prix (1.500.000) avec la dimension des services auxiliaires (10⁶) donne 1,5 x 10¹² prix, dans cet exemple.

On notera que d’autres paramètres liés aux produits de voyage, associés à un service auxiliaire, peuvent influencer le prix du service auxiliaire de sorte que par exemple :

- le type de produit auquel le service auxiliaire est lié (p. ex. l’équipement, le type d’aéronef) ;

- l’information de localisation du produit (les informations de localisation d’un produit peuvent impacter le prix) ;

- la stratégie de vente du fournisseur du produit (campagne de promotion par exemple) ;

- La catégorie du produit (une catégorie peut inclure par exemple des vols long-courriers, une classe affaires, une classe économique).

Calculer tous les prix possibles conformément aux approches conventionnelles exige un nombre immense de ressources avec un traitement long dû à la volatilité des données.

Le système pré-transactionnel 10, selon certains modes de réalisation de l’invention, fournit des recommandations de services dans le flux pré-transactionnel tout en limitant le nombre de résultats de prix devant être traités afin de calquer les contraintes opérationnelles.

Dans certains modes de réalisation, le moteur d’estimation de service 1 peut être configuré pour déterminer des recommandations de services auxiliaires pour chaque produit candidat retourné en réponse à une requête de recommandation de produit.

Dans certains modes de réalisation, l’estimateur de service 102 du moteur de service 1 peut être configuré pour précalculer les informations associées au service telles que la disponibilité du service et le prix du service en utilisant l’information conservée dans la base de données d’expériences de services 103. L’estimateur de service 102 peut recevoir le contexte d’une requête de pré-transaction (p. ex. définie par un paramètre de destination et un paramètre de date pour une requête de prétraitement d’un voyage) et utiliser une structure de recherche en arbre pour déterminer une fréquence d’occurrence et une information de valeur d’un service (information de prix) pour un ensemble de services spécifiés si la requête de pré-transaction comprend une spécification d’un ensemble de services (mode «tirer»), ou pour une liste d’ensembles de services (l’ensemble de services les plus populaires) si la requête de prétransaction ne comprend aucun ensemble de services spécifié (mode « push »).

Dans un mode de réalisation préféré, le système de pré-transaction 10 peut aussi comprendre un dispositif de commutation de détermination de services 104 (également appelé « dispositif de commutation » en réponse à une requête pré-transactionnelle d’un utilisateur. Les modes de détermination de services auxiliaires peuvent inclure un des modes suivants :

- Un mode d’extraction d’informations du service, cette sélection de mode par le dispositif de commutation de détermination de service 104 déclenche la récupération d’informations prétraitées liées à un ensemble de services tel qu’il peut être stocké dans une base de données 113 par le MSP 11 ;

- Un mode de détermination de services, ce mode de sélection par le dispositif de commutation 104 déclenche le traitement d’une requête pré-transactionnelle par l’estimateur de service 102.

Le dispositif de commutation 104 permet une optimisation du coût de calcul d’un traitement de requête en identifiant les valeurs de service (prix du service) devant être calculées par rapport aux valeurs de service qui peuvent être estimées en utilisant le trafic réel. Dans certains modes de réalisation, le dispositif de commutation de détermination de services 104 peut être activé en réponse à une requête de recommandation reçue par le système prétransactionnel 10 pour déterminer un mode d’estimation de service. Le dispositif de commutation de détermination de services 104 peut être configuré pour transmettre des données contextuelles dérivées d’une requête de recommandation reçue, soit par le MCP 11, ou par l’estimateur de service 102, selon le mode d’estimation de service déterminé. Le dispositif de commutation de détermination de services 104 peut recevoir en retour des informations liées aux services auxiliaires à la MCP 11 ou à l’estimateur de service 102, ces informations étant utilisées pour générer des recommandations de services auxiliaires pour chaque produit candidat, les recommandations de produits candidats étant déterminées par la Plateforme de Recherche Massive (MSP pour ‘Massive Search Plateform’) 13.

Dans un mode de réalisation, la Plateforme de Recherche Massive (MSP) 13 peut comprendre un coordinateur de prétraitement 130 configuré pour calculer des requêtes provenant de données de trafic réel afin d’alimenter le Référentiel Massif, pour toutes les origines/destinations et ensembles de services, à un coût minimum.

Le moteur d’estimation de service 1 peut par ailleurs comprendre une unité d’apprentissage 105 (également dénommée unité d’« apprentissage d’expériences de service ou “SEL”) configurée pour collecter des données de méta-apprentissage liées à la disponibilité et à la valeur (prix) des services auxiliaires provenant de transactions en temps réel.

Dans certains modes de réalisation, la base de données d’expériences de service 103 peut être organisée selon une structure de données en arbre. L’estimateur de service 102 peut utiliser cette structure de données en arbre pour rechercher des services auxiliaires devant être recommandés à un utilisateur en association à un produit candidat satisfaisant la requête. L’estimateur de service 102 peut implémenter un algorithme de recherche basé sur cette structure de données en arbre, l’algorithme de recherche étant tel qu’il optimise les coûts de calcul de la recherche. L’estimateur de service 102 peut comprendre un gestionnaire d'arbre 800 configuré pour gérer de façon dynamique la structure de données en arbre 8. L’homme de métier comprendra aisément que même si le gestionnaire d’arbre 800 est implémenté dans l’estimateur de service 102 de la figure 3, dans d’autres modes de réalisation, le gestionnaire d’arbre 800 peut être implémenté comme un bloc séparé du moteur d’estimation de service 1 ou être implémenté dans un autre bloc du moteur d’estimation de service 1.

La figure 5 décrit de façon schématique une structure de données en arbre 8 selon certains modes de réalisation.

La structure de données en arbre 8 (appelée également « arbre ») peut comprendre une pluralité de nœuds 80 (appelés également « couches ») à chaque niveau de l’arbre, correspondant à un paramètre lié à l'un ou à plusieurs des paramètres de requête prédéfinis par le format de la requête tel qu’il est pris en charge par les systèmes des fournisseurs de contenu de transaction 12. La structure de données en arbre 8 modélise ainsi les différentes dimensions d’une requête de client.

Plus spécifiquement, chaque niveau de l’arbre pouvant être associé à une combinaison de paramètres qui peuvent correspondre :

- exactement à un paramètre de requête, ou

- à plusieurs paramètres de requête, ou à un sous-ensemble d’un paramètre de requête, ou

- à un sous-ensemble de plusieurs paramètres de requête.

Chaque nœud à un niveau donné de l'arbre, le niveau étant associé à une combinaison donnée de paramètres de requête, peut ainsi correspondre à une valeur (« valeur de nœud ») de la combinaison de paramètres de requête et peut être associé à la valeur d’un nombre entier (« une valeur de compteur ») représentant le nombre d’occurrences de la valeur de combinaison de paramètres de requête parmi les requêtes reçues par le système de transaction 12 au cours d’une période passée prédéfinie T par rapport à un temps de traitement. Le premier nœud de l’arbre 80-0- est également appelé nœud racine. Un nœud qui n’a pas de nœud-fils est appelé nœud-feuille (par exemple 80-N). Chaque nœud a au plus un nœud-parent situé au-dessus de lui dans l’arbre (c.-à-d. au niveau précédent du nœud). Le nœud racine étant le nœud le plus élevé dans l'arbre, il n’a pas de nœud-parent. La profondeur (également appelée dimension) d’un nœud donné désigne la longueur du chemin à partir du nœud considéré jusqu’au nœud racine de l’arbre. Chaque chemin du nœud racine à un nœud-feuille représente un ensemble de valeurs correspondant aux critères (ou aux paramètres) d’une requête et représente ainsi une requête dans le passé pour le produit. La profondeur du nœud-feuille est inférieure ou égale au nombre maximal de paramètres de requête qui peuvent être spécifiés dans une requête d’utilisateur selon le format de la requête défini par les systèmes de transaction 12. Un nœud peut être désigné par sa valeur de nœud (valeurs de combinaison de paramètres d’une requête). Un nœud 80 peut aussi être dénommé ci-après par n/,-avec i représentant le niveau de l’arbre (i = 0 correspondant au nœud-racine) et k représentant le fc-è nœud du niveau i. La valeur de compteur d’un nœud sera n/ dénotée c_n.k Ainsi, la valeur du nœud n/ a été spécifiée c_n.k fois au cours de la période passée. Selon les notations utilisées, les nœuds-fils d’un nœud n_t ^k sont désignés par les nœuds ni+1¹,ni+1², ...,n_i+1 ^p , avecp représentant un nombre de valeurs spécifiées par les utilisateurs au cours de la période passée T pour la combinaison de paramètres de requête correspondant au niveau i — 1.

Une requête de client exemplaire pour les systèmes des fournisseurs de produits dans l’industrie du voyage peut par exemple être :

« de fournir toutes les recommandations d'aller-retour pour le Canada, pour un passager de niveau tiers or, partant un samedi ou un dimanche avec un séjour de 2 semaines, avec une température mensuelle moyenne à destination supérieure à 25°, avec les services={animal en cabine, repas végétarien}»

En réponse à la finalisation de la transaction déclenchée par cette requête d’un client, le gestionnaire d’arbre 800 peut mettre à jour la structure de données en arbre. Pour mettre à jour la structure de données en arbre, le gestionnaire d’arbre 800 peut être configuré par exemple pour diviser la requête client reçue en unités lexicales suivantes :

A- «Aller-retour»

B- «un passager de niveau tiers or»

C- « Départ un samedi ou un dimanche »

D- «Séjour de 2 semaines»

E- «destination Amérique du Nord»

F- «destination Canada»

G- «destination Canada avec une température > 20 degrés»

H- «Température > 2 5 degrés»

I- «Services = {animal de compagnie en cabine, repas végétarien}».

Le gestionnaire d’arbre 800 peut ensuite mettre à jour les valeurs des différents niveaux à partir de ces unités lexicales.

Comme le montre cet exemple, les niveaux de l’arbre peuvent correspondre exactement à un critère de recherche [A, C, D, E, H, I], correspondre à plusieurs critères de requête [B], correspondre à un sous-ensemble d’un critère de requête [F], ou correspondre à un sousensemble de plusieurs critères de requête [G],

La structure de données en arbre 8 capture ainsi le contexte de la transaction des requêtes d’utilisateur du trafic réel [appelé également trafic « en temps réel »] au niveau du système de transaction 12 à l’intérieur des nœuds et des branches de l’arbre. La structure de données en arbre 8 peut être par ailleurs configurée de sorte que les nœuds-feuilles de l’arbre sont associés au paramètre de l’ensemble de services représentant un ensemble de services acheté en association au produit défini par les niveaux supérieurs. Chaque nœud de l’arbre peut aussi correspondre à un ensemble de services [comprenant un ou plusieurs services] acheté au cours de la période passée T ensemble avec le produit défini par le chemin du nœud racine au nœud précédant le nœud-feuille considéré. L’ensemble de services peut être défini par une combinaison de services {[service 1] et [service 2] et... [service p]}.

L’estimation de services auxiliaires peut être encore plus exacte au fur et à mesure que la profondeur de l’arbre s'accroît.

Dans certains modes de réalisation, des informations supplémentaires peuvent être associées à chaque nœud. Ces informations supplémentaires peuvent être utilisées pour maximiser la factorisation et par conséquent le temps requis pour effectuer une recherche en utilisant l’arbre.

Dans un mode de réalisation, un ensemble de critères d’arbre peut être ajouté ou supprimé de façon dynamique sur la base du nombre de nœuds-fils.

La structure de données en arbre 8 peut être configurée de sorte que plus le niveau de l’arbre est élevé, plus le paramètre de requête associé au niveau est discriminatoire. Cela limite le coût de calcul d’une recherche en utilisant l’arbre.

Par exemple, dans une application de l’invention pour la livraison de produits de voyage, la structure de données en arbre peut par exemple comprendre :

- Un premier niveau (i = 1) correspondant à la paire continentale d’une requête de voyage définie par une « origine continentale » et une « destination continentale » [p. ex. une valeur de la paire continentale peut être « Europe, Europe »] ;

- Un second niveau (i = 2) correspondant au [x] transporteur [x] contrôlant le paramètre de voyage [p. ex. une valeur du transporteur contrôlant le voyage peut être « LH », nom standard pour Lufthansa] ;

- Un troisième niveau (i = 3) correspondant à la paire de points géographiques d’une requête de voyage définie par un « point d’origine » et un « point de destination » [p. ex. une valeur de la paire de pays peut être » BER » - France, BER étant le nom standard pour Berlin] ;

- Un quatrième niveau (i = 4) correspondant à l’ensemble des services associés avec un produit défini par les valeurs de nœuds du niveau précédent [p. ex. une valeur de l’ensemble de services peut être le service [« animal en cabine »] et le service [« repas végétarien »].

Dans certains modes de réalisation, chaque nœud-feuille n_L ^k de la structure de données en arbre correspondant à un ensemble de services demandés précédemment peut comprendre en plus :

- un compteur c_n^ définissant le nombre de fois que la valeur de l’ensemble de services a été demandée au système du fournisseur de contenu de transaction 12 par un utilisateur au cours d’une période passée T; et/ou

- Une pluralité de valeurs d’ensembles de services ; chaque valeur d’ensemble de services [aussi appelée « prix de l’ensemble de services »] peut comprendre une information tarifaire liée au prix auquel l’ensemble de services correspondant, dénoté {[service 1] et [service 2] et ... [service p]} a été acheté au cours d’une transaction d’achat liée au produit défini par le chemin du nœud racine au nœud-feuille n_N ^k au cours de la période passée?; dans un mode de réalisation, chaque valeur d’ensemble de services [prix de l’ensemble de services] peut comprendre une liste de valeurs des prix auxquels l’ensemble de services a été acheté au cours de la période passée ; dans un autre mode de réalisation, chaque valeur d’ensemble de services [prix de l’ensemble de services] peut comprendre une liste de fourchettes des prix auxquels la valeur d’ensemble de services a été achetée au cours de la période passée, la fourchette des prix étant définie par un seuil inférieur représentant le prix d’achat le plus bas de l’ensemble de services et un seuil supérieur représentant le prix d’achat le plus élevé de l’ensemble de services.

La description suivante de certains modes de réalisation sera faite en référence aux I nœuds-feuille comprenant chacun une valeur d’ensemble de services sous la forme d’une fourchette de valeurs [ou fourchette de prix].

Chaque nœud-feuille n_L ^k de la structure de données en arbre, correspondant à un ensemble donné de services, peut par ailleurs comprendre un horodatage représentant l’instant de la dernière mise à jour du nœud-feuille qui est la dernière date à laquelle un prix a été déterminé pour l’ensemble de services associé au nœud-feuille [l’horodatage peut inclure la date et l’heure de la mise à jour].

La figure 5 montre, à titre d’exemple, des données 81 comprises à chaque nœud-feuille qui sont associées à un ensemble de services exemplaire A = {animal en cabine, repas végétarien} incluant :

Une fréquence d’occurrence : 6 % [une requête pour un ensemble de services 6 % du temps pour la requête définie par le chemin du nœud-feuille]

- Une fourchette de prix : [34 euros ; 41 euros]

- Un horodatage Ts : 09/31/2017.

Dans certains modes de réalisation, chaque nœud 80 de la structure de données en arbre [différent des nœuds-feuilles] peut par ailleurs être associé à des données agrégées de nœudsfeuilles 82 qui peuvent être stockées localement au niveau du nœud ou stockées dans une unité de stockage connectée au gestionnaire d’arbre 800. Bien que la figure 5 montre, à titre d’exemple, des données de nœuds-feuilles 82 pour seulement deux nœuds 80, par souci de simplification, l’homme de métier comprendra aisément que des données similaires peuvent être comprises au niveau d’autres nœuds de l’arbre [différents des nœuds-feuilles]. Les données de nœud-feuille comprennent des données agrégées provenant de nœuds-feuilles situés dans le sous-arbre défini par le nœud 80 [en dessous du nœud 80], Les données du nœud-feuille comprennent ainsi des données agrégées liées à l’ensemble des services associés au sousarbre défini par le nœud 80, telles que les données suivantes pour chaque ensemble de services :

- une fréquence d’occurrence agrégée Occ.

- une information de valeurs agrégées V (appelée également « information de prix agrégés »), par exemple une fourchette de valeurs agrégées et potentiellement

- un horodatage agrégé représentant la dernière mise à jour de l’ensemble de services.

Pour un ensemble donné de services, la fréquence d’occurrence agrégée fait référence à la somme des fréquences d’occurrence associées à l’ensemble de services pour tous les nœuds-feuilles situés en dessous du nœud 80.

Dans un mode de réalisation, les informations agrégées de valeurs V comprises dans un nœud-feuille peuvent être une fourchette de valeurs agrégées [également dénommée «fourchette de prix agrégés»] dénotée [Pmin, Pmax], définie pour l’ensemble des services associés au nœud-feuille. La fourchette de prix peut être définie par un seuil plus bas Pmin et un seuil plus élevé Pmax, le seuil le plus bas Pmin représentant la plus basse valeur [prix] attribuée à l’ensemble de services parmi les valeurs [prix] associées à l’ensemble de services dans les nœuds-feuilles situés en dessous du nœud 80 et le seuil le plus élevé Pmax représentant la valeur la plus élevée attribuée à l’ensemble de services parmi les valeurs [les prix] associées à l’ensemble de services dans les nœuds-feuilles situés en dessous du nœud 80.

On notera que l’invention n’est pas limitée à une information de valeurs agrégées V implémentée comme fourchette de valeurs agrégées [Pmin, Pmax], Autrement, l’information de valeurs agrégées V peut être :

une valeur moyenne [également dénommée « moyenne de prix »], ou une valeur médiane [également dénommée « prix médian »], ou

- une fourchette basée sur des valeurs unitaires [également dénommées « prix unitaires »] dans laquelle les valeurs extrêmes sont retirées [par exemple, les percentiles 0-10 et 90100 peuvent être retirés] ou une liste ordonnée de valeurs [prix] comprenant des valeurs classées par fréquences d’occurrence décroissantes.

Dans un autre mode de réalisation, l’information de valeurs agrégées V stockée par un nœud-feuille peut comprendre toutes les valeurs possibles [ou « prix »] en association à leur nombre d’occurrences

La description suivante de certains modes de réalisation de l’invention sera faite en référence à l’information de valeurs agrégées V implémentée comme une fourchette de valeurs agrégées [Pmin, Pmax], uniquement à titre d’illustration.

Pour un ensemble donné de services, la valeur d’horodatages agrégés fait référence aux horodatages les plus récents parmi les horodatages associés aux ensembles de services qui correspondent aux nœuds-feuilles en dessous du nœud 80.

En agrégeant à chaque nœud de l’arbre les données liées aux ensembles de services associés aux nœuds-feuilles situés en dessous du nœud, les coûts de calcul de l’estimation de services auxiliaires peuvent être réduits.

Dans un mode de réalisation, en réponse à une requête de pré-transaction spécifiant un ensemble donné de services, l’estimateur de service 102 peut être configuré pour explorer la structure de données en arbre 8 selon un algorithme de recherche [par exemple un algorithme de recherche meilleur-premier [Best-First]] pour déterminer un nœud correspondant ayant un chemin dans l'arbre qui correspond aux paramètres d’une requête de pré-transaction et pour rechercher un nœud-feuille dans le sous-arbre du nœud correspondant qui correspond à l’ensemble donné de services et qui a une fréquence d’occurrence satisfaisant une condition de seuil au niveau le plus bas possible de la structure de données en arbre. Le produit associé à l’ensemble donné de services est ainsi défini par le chemin partant du nœud racine jusqu’au nœud correspondant. L’estimateur de service 102 peut déterminer l’information de valeur de service à partir des données comprises dans le nœud-feuille déterminé. Dans un mode de réalisation, la fréquence d’occurrence d’un nœud-feuille peut être déterminée pour satisfaire le seuil. Si la fréquence d’occurrence est supérieure ou égale à un seuil prédéfini.

Plus spécifiquement, l’estimateur de service 102 peut être configuré pour rechercher un nœud-feuille n_L ^k dans le sous-arbre du nœud correspondant qui correspond au service donné au dernier niveau possible L de la structure de données en arbre et ayant assez d’occurrences [c.-à-d. que le nœud-feuille a une fréquence d’occurrence qui satisfait la condition de seuil].

Dans un mode de réalisation, pour déterminer l’information de valeur de service, s’il est déterminé qu’une feuille d'arbre n_L ^k à un niveau L (avec L> N) correspond à l’ensemble donné de services {[service 1] et [service 2] et... [service p]}, l’estimateur de service 102 peut être configuré pour déterminer la fourchette de valeurs de l’ensemble de services (prix de l’ensemble des services) associée à l’ensemble des services {[service 1] et [service 2] et... [service p]} dans la feuille de l’arbre n^k au cours de la période passée T.

La fourchette de valeur de l’ensemble de services peut ainsi correspondre à la fourchette de prix payés par les utilisateurs pour ce produit au cours de la période passée T.

Par exemple, une fourchette de prix de [34 euros - 41 euros] peut être associée à l’ensemble de services {[service animal en cabine »] et [service repas végétarien]}.

Dans certains modes de réalisation, le compteurc_U[k associé à un nœud-feuille de l’arbre peut être utilisé par l’estimateur de service 102 pour dériver une valeur statistique représentant la fréquence d’occurrence d’un ensemble de services au cours de la période passée?. Par exemple, une fréquence d’occurrence de l’ensemble de services {[service animal en cabine »] et [service repas végétarien]} peut être égale à 6 % du temps.

Dans un mode de réalisation, un algorithme de reconstruction d’un arbre [également dénommé « algorithme d’équilibrage »] peut être appliqué à la structure de données en arbre 8 pour obtenir une structure de données en arbre aussi équilibrée que possible en commençant à partir d’un nœud quelconque. Un arbre est équilibré ici :

- Pour chaque nœud de l’arbre, les hauteurs du sous-arbre de gauche et les hauteurs du sous-arbre de droite diffèrent au plus d’un, et

- le sous-arbre de gauche est équilibré, et

- le sous-arbre de droite est équilibré.

Pour en revenir à la figure 3, l’unité d’apprentissage d’expériences de service 105 peut être configurée pour capturer la valeur de service et le statut de disponibilité de chaque service auxiliaire associé aux produits offerts par le système de transaction 12 en utilisant des données transactionnelles en temps réel. L’unité d’apprentissage d’expériences de service 105 peut stocker les informations collectées sous la forme de structure de données en arbre de la base de données d’expériences de service 103. Dans certains modes de réalisation, l’unité d’apprentissage d’expériences de service 105 peut être configurée pour collecter des données sur les requêtes de service, lorsque la MSP 11 ne parvient pas à fournir des informations.

L’unité d’apprentissage d’expériences de service 105 peut être programmée pour autoréorganiser la base de données d’expériences de service 103 selon une période prédéfinie ou automatiquement en réponse à la détection d’une condition de mise à jour.

Dans un mode de réalisation, l’unité d’apprentissage d’expériences de service 105 peut collecter des informations à partir d’une phase de révision tarifaire du flux de transactions, exécutée par le système de transaction 12. Tel qu’utilisé dans les présentes, la révision tarifaire fait référence à la phase qui précède la validation d’une transaction par un utilisateur au cours de laquelle il est demandé à un utilisateur de réviser les informations tarifaires liées à un achat de produit (avant l’étape au cours de laquelle il est demandé à un utilisateur de saisir des informations personnelles d’utilisateur). Dans cette phase, le contexte d’une requête de transaction est connu au niveau du système de transaction 12, permettant ainsi d’utiliser le paramètre de la requête pour mettre à jour la structure de données en arbre dans la base de données d’expériences de service 103. Cela permet par ailleurs de recueillir des informations suffisamment tard dans le flux de transaction pour obtenir un produit suffisamment spécifié (par exemple un itinéraire fixe pour un produit de voyage) et recueillir ainsi des informations de service précises. Par ailleurs, cela permet de recueillir des informations suffisamment tôt dans le flux de transaction pour obtenir un trafic de transactions maximum.

Pour chaque requête de transaction soumise au système de transaction 12, l’unité d’apprentissage d’expériences de service 105 peut être configuré pour parcourir l’arbre de la base de données d’expériences de services 103 du nœud racine jusqu’au nœud-feuille, pour déterminer si les paramètres de la requête correspondent à une valeur de nœud à chaque niveau jusqu’à ce que le dernier nœud avant les feuilles soit atteint i = N -1), l’unité d’apprentissage d’expériences de service 105 étant configurée pour mettre à jour un nœud si une correspondance est trouvée ou pour créer un nouveau nœud si les valeurs des paramètres ne sont pas créées dans l’arbre.

En particulier, l’unité d’apprentissage d’expériences de service 105 peut être configurée pour incrémenter le compteur associé à une valeur de nœud de l’arbre, en réponse à la recherche d’une correspondance entre un paramètre (p. ex., le site Web d’une compagnie aérienne, le transporteur régulateur, la paire de lieux, etc.) de la requête et la valeur de nœud, permettant ainsi le stockage du contexte intégral dans l’arbre.

Dans un mode de réalisation, pour déterminer si une correspondance existe dans l’arbre pour un paramètre (p. ex., le site web d’une compagnie aérienne, le transporteur régulateur, la paire d’emplacements, etc.) d’une requête de transaction donnée soumise au système de transaction 12 spécifiant un produit donné et un ensemble donné de services, l’unité d’apprentissage d’expériences de service 105 peut déterminer si une feuille existe déjà pour l’ensemble donné de services dans l’arbre qui possède un chemin d’accès associé correspondant aux paramètres de la requête se rapportant au produit. Si une correspondance est trouvée, le nœud correspondant à la feuille peut être mis à jour en incrémentant le compteur associé à la feuille. L’unité d’apprentissage d’expériences de service 105 peut être également configurée pour stocker les données supplémentaires associées à l’ensemble de services telles que le contexte intégral et une ou plusieurs valeurs d’ensemble de services (p. ex., le prix élémentaire pour chaque service [service k] de l’ensemble de services). Si aucune correspondance n’a été trouvée entre une feuille de l’arbre et l’ensemble de services spécifié dans la requête de transaction, l’unité d’apprentissage d’expériences de service 105 peut créer une nouvelle feuille (nouveau nœud) pour l’ensemble de services de la requête de transaction, régler le compteur du nœud créé sur 1. Il peut par ailleurs stocker dans le fil nouvellement créé des données supplémentaires se rapportant à l’ensemble de services telles que le contexte intégral et une ou plusieurs valeurs d’ensembles de services (p. ex., le prix élémentaire pour chaque service [service k] de l’ensemble de services).

Dans un mode de réalisation, l’unité d’apprentissage d’expériences de service 105 peut lancer un processus de vérification de l’arbre pour vérifier la configuration de l’arbre et identifier si l’arbre est déséquilibré, selon une période de vérification prédéfinie, comme à chaque M mise à jour de l’arbre. Le processus de vérification échoue lorsqu’un déséquilibre de l’arbre est détecté. Dans certains modes de réalisation, un algorithme de reconstruction de l’arbre peut être appliqué pour équilibrer l’arbre.

Dans un mode de réalisation, la période de vérification de l’arbre peut être prédéfinie par un administrateur système. Dans certains modes de réalisation, la période de vérification de l’arbre peut être mise à jour pendant le fonctionnement de l’unité d’apprentissage d’expériences de service 105 ou ajustée dynamiquement en fonction des critères de mise à jour. Si l’unité d’apprentissage d’expériences de service 105 détecte que l’arbre est déséquilibré, il peut appliquer un algorithme d’équilibrage pour réorganiser l’arbre.

Dans certaines applications de l’invention, la plateforme classique de calcul massif MCP 13 ne peut pas prétraiter toutes les possibilités de services auxiliaires en raison de la complexité du calcul. Afin de limiter les coûts de calcul des informations de services auxiliaires (disponibilité du service, prix du service), le moteur 1 d’estimation du service, selon certains modes de réalisation, peut comporter un calculateur de popularité de service 108. Le calculateur de popularité de service 108 peut être configuré pour calculer uniquement des recommandations destinées aux services auxiliaires associés à chaque produit candidat parmi un sous-ensemble de services (« sous-ensemble de services populaires »), chaque service du sous-ensemble populaire étant sélectionné à partir de un indicateur de popularité calculé pour le service qui représente la probabilité de requête de service par les utilisateurs.

Le calculateur de popularité de service 108 peut être configuré pour recevoir le contexte de la requête de prétraitement (également désignée par « recommandation » ou requête « pré transactionnelle»), et pour utiliser la structure de données en arbre afin de déterminer les ensembles de services les plus demandés sur une période écoulée (services les plus populaires).

Le calculateur de popularité de service 108 peut utiliser la base de données d’expériences de service 103 pour déterminer les indicateurs de popularité associés à chaque service. Dans certains modes de réalisation, le calculateur de popularité de service 108 peut appliquer des critères (également désignés par « contexte d’entrée » pour le calculateur de popularité de service 108) associés aux produits spécifiés pour chaque système de transaction 12 afin de déterminer les indicateurs de popularité (p. ex., critères associés aux dates et/ou durée du séjour, et/ou compagnie aérienne, ou paire de villes, etc. pour un produit de voyage). En conséquence, l’indicateur de popularité d’un service peut être réglé sur une valeur élevée si le produit associé est fréquemment demandé sur une période de temps donnée.

Dans un mode de réalisation, considérant n types t1 de transactions possibles..., tn pour demander un ensemble de services S, l’indicateur de popularité peut être déterminé à partir du paramètre de popularité (S) défini comme étant :

Popularité (S) = Σ-Ξ” Wjocci (1 )

Dans la formule (1), désigne le poids associé à ti, occ, désigne la fréquence d’occurrence des requêtes ayant le type de transaction ti et ayant demandé S sur la période de temps.

Par exemple, si l’on considère un système fournisseur de voyage, les types de transactions peuvent inclure :

- un type T₄ de requête avant la phase de préachat ;

un type T₂ de requête de préachat ;

un type T₃ de requête de prix ;

Tel qu’il est utilisé dans les présentes, un «contexte-nœud» pour un nœud donné fait référence aux informations définissant le chemin d’accès du nœud depuis le nœud racine jusqu’au nœud donné.

Pour chaque contexte d’entrée défini par les critères de requête d’une requête reçue de l’utilisateur, le calculateur de popularité de service 108 peut parcourir la structure de données en arbre 8 de l’arbre de la base de données d’expériences de service 103 en commençant par le nœud racine selon un algorithme de recherche d’arbre pour trouver un nœud Nd (« nœud actuel ») au dernier niveau possible de l’arbre :

- ayant un nœud-fils correspondant aux critères de requête (première condition) et un nœud-feuille au-dessous du nœud-fils associé à un ensemble de services ayant une fréquence d’occurrence qui est au moins égale à un seuil prédéfini Q (deuxième condition).

Le calculateur jde popularité de service 108 peut être configuré pour déterminer ensuite les fréquences d’occurrence c_n.k de tous les ensembles de services (mode ‘pull’) ou de l’ensemble des services spécifié (mode ‘push’) à partir du nœud Nd actuel sélectionné. Dans certains modes de réalisation, le calculateur de popularité de service 108 peut envoyer les fréquences d’occurrence du ou des ensemble(s) de services ainsi déterminé(s) à la MCP 11.

La MCP 11 peut être configurée pour affiner le contexte d’entrée en ajoutant les ensembles de services déterminés par le calculateur de popularité de service 108 et la fréquence d’occurrence associée à chaque ensemble de services déterminé.

L’estimateur de service 102 peut être configuré afin de déterminer les services auxiliaires en utilisant les données historiques stockées dans la base de données d’expériences de service 103 pour chaque produit recommandé (ou candidat) fourni par un système de traitement de contenu de transaction 12.

L’estimateur de service 102 peut recevoir du dispositif de commutation de détermination de services 104 une entrée, en réponse à un mode d’estimation de service activé par le dispositif de commutation de détermination de services 104. L’entrée envoyée par de détermination de services 104 à l’estimateur de service 102 peut comporter des données contextuelles (p. ex., ID Office, marché pour une application exemplaire de l’invention de fourniture de voyage) provenant d’une demande de recommandation soumise au système prétransactionnel 10, et les informations potentielles associées à un ensemble de services auxiliaires comprenant au moins un service, si un « mode ‘pull’ » est activé par l’utilisateur (l’utilisateur spécifie ainsi dans la requête de recommandation qu’il souhaite des recommandations pour le produit candidat associé à l'ensemble de services auxiliaires). Alternativement, le traitement de l’estimateur de service 102 peut être déclenché dynamiquement en mode ‘push’, sans que l’utilisateur spécifie un ensemble de services.

La figure 6 est un organigramme illustrant le processus de détermination de recommandation d’un ensemble de services candidats, qui peut être implémenté par l’estimateur de service 102, selon un mode de réalisation en mode ‘pull’.

À l’étape 600, une entrée est reçue du dispositif de commutation de détermination de services 104 comprenant des données contextuelles définissant les paramètres d’un produit demandé et la spécification d’un ensemble de services provenant d’une demande de recommandation soumise par un dispositif utilisateur à un dispositif de traitement prétransactionnel 10.

À l’étape 602, la structure de données en arbre 8 de la base de données d'expériences de service 103 est parcourue en utilisant un algorithme de recherche d’arbre à partir du nœud racine jusqu’à ce qu’un nœud Nd ait été atteint qui satisfasse l’ensemble des conditions de nœuds (bloc 603) comprenant :

- la première condition qui est remplie si un nœud-fils du nœud Nd possède un contexte correspondant au contexte d’entrée, ou en d’autres termes, si ce nœud-fils correspond aux critères de la requête reçue de l’utilisateur (requête d’entrée) ; et

- la deuxième condition qui est remplie si le nœud-fils du nœud Nd actuel possède l’ensemble de services spécifié, et si l’ensemble de services est associé à une fréquence d’occurrence supérieure ou égale à un nombre minimal Q.

Dans une réalisation en mode ‘PULL’, les critères de requête utilisés pour évaluer la condition première comprennent l’ensemble de services spécifié par l’utilisateur.

Le paramètre Q désigne le nombre minimal d’occurrences. Le paramètre Q peut être prédéfini, configurable par un administrateur, ou mis à jour dynamiquement.

Dans un mode de réalisation, pour tester la première condition, les données des nœudsfeuilles associées à chaque nœud peuvent être utilisées pour optimiser le coût de la recherche, les données des nœuds-feuilles 82 fournissant des données relatives à chaque ensemble de services associés à un nœud-feuille dans le sous-arbre défini par un nœud donné dans l’arbre (p. ex., pour chaque ensemble de services associé à un nœud-feuille dans un sous-arbre du nœud, la fréquence d’occurrence Occ, fourchette de prix V, horodatage Ts). Dans ce mode de réalisation, chaque nœud-parent agrège les données de l’ensemble de services stockées dans les nœuds-feuilles situés au-dessous du nœud-parent.

Si le nœud N_d actuel satisfait les première et deuxième conditions, le parcours dans l’arbre se poursuit (étape 604).

Dans le cas contraire, si les première et deuxième conditions ne sont pas remplies, le dernier nœud Nd parcouru est sélectionné, et à l’étape 606, la fourchette de prix unitaires [Pmin; Pmax] de l’ensemble des services demandé peut être déterminée à partir des informations de valeur de service associées à l’ensemble de services dans les données agrégées associées au nœud N_d ou récupérées à partir d’une mémoire de stockage si la fourchette a été précalculée. Chaque fourchette de prix unitaires [Pmin-, Pmax] peut comporter une limite inférieure Pmin représentant le prix minimal des services élémentaires qui constituent l’ensemble de services demandé et une limite supérieure Pmax représentant le prix maximum des services élémentaires qui constituent l’ensemble de services.

À l’étape 608, la fourchette de prix unitaires [Pmin; Pmax] déterminée pour l’ensemble de services demandé, à partir de la structure de données en arbre 8, peut être retournée au dispositif de commutation de détermination de service 104.

Le procédé peut comprendre par ailleurs l’étape 610 d’incrémentation de la fréquence d’occurrence associée à l’ensemble de services dans le nœud-feuille correspondant, et de mise à jour en conséquence des données agrégées associées aux nœuds dans les niveaux supérieurs de l’arbre de ce nœud-feuille.

La figure 7 est un organigramme illustrant le processus de détermination d’une liste d’ensembles de services candidats, qui peut être implémentée par l’estimateur de services 102, selon un mode de réalisation en mode ‘push’.

En mode ‘push’, aucun ensemble de service n’est spécifié dans la requête de recommandation soumise au système pré-transactionnel 10.

Les paramètres des modes ‘push’ peuvent être prédéfinis tels que le nombre maximal d’ensembles de services retournés à l’utilisateur.

À l’étape 700, une entrée est reçue du dispositif de commutation de détermination de service 104 comprenant des données contextuelles définissant les paramètres d’un produit demandé provenant d’une requête de recommandation soumise par un dispositif d’utilisateur à un dispositif de traitement pré-transactionnel 10, sans que soit spécifié un quelconque ensemble de services (MODE ‘PUSH’). L’entrée peut comporter par ailleurs le nombre escompté N d’ensembles de services devant être poussés.

Les étapes 702 à 704 sont similaires aux étapes 602 à 604 de la figure 6. Cependant, comme aucun ensemble de services n’est spécifié dans la requête d’entrée en mode ‘push’, les critères de la requête utilisés pour déterminer un nœud-fils à l’étape 702 (première condition) n’incluent pas un ensemble de services spécifié.

En conséquence, à l’étape 702, la structure de données en arbre 8 de la base de données d’expériences de service 103 est parcourue en utilisant un algorithme de recherche d’arbre à partir du nœud racine jusqu’à ce qu’un nœud Nd ait été atteint qui satisfasse l’ensemble des conditions de nœuds (bloc 703) comprenant :

- la première condition qui est remplie si un nœud-fils du nœud Nd possède un contexte correspondant au contexte d’entrée, ou en d’autres termes, si ce nœud-fils correspond aux critères de la requête reçue de l’utilisateur (requête d’entrée) ; et

- la deuxième condition, qui est remplie si le nœud-fils du nœud actuel Nd possède au moins N des ensembles de services associés à une fréquence d’occurrence supérieure ou égale à un nombre minimal Q.

Cela permet de sélectionner le nœud Nd qui satisfait les première et deuxième conditions au niveau le plus bas possible de l’arbre.

Si les première et deuxième conditions ne sont pas remplies, le dernier nœud Nd parcouru satisfaisant les deux conditions est sélectionné.

À l’étape 706, les fréquences d’occurrence des ensembles de services associés aux nœuds-feuilles situés sous le nœud Nd sélectionné peuvent être déterminées, en utilisant par exemple les données du nœud-feuille 82 associées au nœud Nd. Dans certains modes de réalisation, si deux ensembles de services différents possèdent la même fréquence d’occurrence, l’horodatage associé aux ensembles de services peut être utilisé pour sélectionner l’ensemble de services ayant le dernier horodatage (pour lequel une valeur tarifaire a été déterminée plus récemment).

À l’étape 708, un ou plusieurs ensembles de services peuvent être sélectionnés selon la fréquence d’occurrence associée aux ensembles de services. Ceci fournit une liste filtrée des ensembles de services (les ensembles de services les plus populaires). Dans un mode de réalisation, l’étape 708 peut comprendre de sélectionner les ensembles de services associés à une fréquence d’occurrence supérieure ou égale à un seuil prédéfini.

À l’étape 710, la fourchette des prix unitaires [Pmin; Pmax] associée à chaque ensemble de services sélectionné à l’étape 708 peut être déterminée, par exemple à partir des données des nœuds-feuilles 82. Chaque fourchette de prix unitaires [Pmin; Pmax] comporte une limite inférieure Pmin représentant le prix minimal de l’ensemble de services et une limite supérieure Pmax représentant le prix maximum de l’ensemble de services sur la période T révolue.

Au lieu de déterminer les fréquences d’occurrence et les fourchettes de prix des étapes 706 à 710 à partir des données de nœud-feuille 82 associées au nœud Nd actuel, dans certains modes de réalisation, l’arbre peut être parcouru plusieurs fois, en particulier pour chaque ensemble de services, pour déterminer avec plus de précision ces informations directement à partir des nœuds-feuilles.

À l’étape 712, les fréquences d’occurrence et la fourchette de prix unitaires [Pmin; Pmax] déterminée pour chaque ensemble de services de la liste des ensembles de services sélectionnée peut être retournée au dispositif de commutation de détermination de service 104. Les services auxiliaires les plus populaires et les estimations de prix des services associés à ces services auxiliaires sont donc déterminés dans le contexte d’entrée.

Alors que dans le mode de réalisation du mode ‘pull’ de la figure 6, la fréquence d’occurrence et la fourchette de prix sont retournées pour un seul ensemble de services correspondant à l’ensemble demandé, dans le mode de réalisation du mode ‘push’ représentée à la figure 7, la fréquence d’occurrence et la fourchette des prix sont déterminées pour la liste des ensembles de services sélectionnés.

La figure 8 est un diagramme illustrant le processus du mode d’échange d’estimation de service qui peut être implémenté par le dispositif de commutation de détermination de service 104, selon certains modes de réalisation.

À l’étape 800, une requête client (également désignée par « pré-transaction » ou une requête de «recommandation») est reçue par le système pré-transactionnel 10 d’un dispositif utilisateur 2.

Si la requête client est reçue en mode ‘pull’ (bloc 801), c’est-à-dire que la requête de recommandation spécifie un ensemble de services particulier, à l’étape 802, il est déterminé si l’ensemble des services spécifié a déjà été traité pour des produits similaires en utilisant des paramètres liés par la requête de recommandation (p. ex., dans une application de l’invention au produit de voyage, il peut être déterminé si l’ensemble des services spécifié a déjà été traité pour un même itinéraire [défini par une origine/destination]). Dans un mode de réalisation, cette étape peut être effectuée par un coordinateur de prétraitement 130 fourni dans la MCP 11 en réponse à un appel du dispositif de commutation de détermination de service 104.

S’il est déterminé qu’une requête pour l’ensemble de services a déjà été faite, à l’étape 804, les données relatives à l’ensemble de services peuvent être récupérées à partir des données prétraitées (ou précalculées) en utilisant la plateforme de recherche massive (MSP) 13 ou depuis l’estimateur de service 102.

Dans le cas contraire, les données contextuelles de service liées à la requête de recommandation et l’ensemble de services spécifié peuvent être envoyées à l’estimateur de service à l’étape 806.

Si la requête de recommandation est reçue en mode ‘push’ (bloc 801 ), c’est-à-dire la requête de recommandation ne spécifie aucun ensemble de services en particulier, à l’étape 806, l’estimateur de service 102 peut être appelé. Cela inclut la transmission des données contextuelles de service associées à la requête de recommandation et l’ensemble de services spécifié à l’estimateur de service 102. L’estimateur de service 102 peut déterminer les services auxiliaires les plus populaires et les prix estimés de service associés aux services auxiliaires, comme décrit en relation avec la figure 6.

Dans un mode de réalisation, il est par ailleurs possible de faire appel au coordinateur de prétraitement 130 pour déterminer si les ensembles de services retournés par l’estimateur de service 102 (les services auxiliaires les plus populaires) ont déjà été prétraités en utilisant des données en temps réel (par la MCP 13) dans l’exemple d’un produit de voyage. Si oui, les prix estimatifs associés aux ensembles de services retournés par l’estimateur de service 102 peuvent être remplacés par ces prix prétraités (prix de service précis).

La figure 9 est un diagramme illustrant le processus de prédétermination des ensembles de services qui peut être implémenté par le coordinateur de prétraitement 130 de la MCP 13 pour alimenter le référentiel massif 113, pour tous les points d’origine/de destination et l’ensemble de services, à un coût minimal, selon certains modes de réalisation.

À l’étape 900, une requête de transaction (requête client) est reçue par un système de transaction 12. L’ensemble des j paramètres de requête obligatoires prédéfinis pour le format de la requête de transaction (p. ex., itinéraire, date de départ, durée du séjour pour une demande de voyage) et défini par un j - uplet est supposé être connu (il peut être rempli par l’utilisateur ou le système de transaction 12). La requête client peut comprendre par ailleurs des ensembles de services auxiliaires devant être prétraités, pour chacun des j paramètres de la requête.

Dans un mode de réalisation, un prétraitement des K ensembles de services les plus populaires peut être déterminé par le calculateur de popularité de service 108 en utilisant les indicateurs de popularité déterminés pour chaque ensemble de services, pour tout ce qui précède j - uplet à l’étape 902. Par ailleurs, le prétraitement peut être effectué pour un ensemble de services auxiliaires spécifiques spécifié dans la requête de la transaction par un client.

Afin de minimiser le coût du calcul, le prétraitement peut comprendre les étapes suivantes :

-À l’étape 904, la plate-forme de recherche massive (MSP) 13 peut être appelée pour récupérer la valeur du produit (prix) associée aux produits (p. ex. les itinéraires pour une demande de voyage) identifiée par la requête client, sans tenir compte des valeurs de service (prix du service) ;

- À l’étape 906, le service de la MCP 16 peut être appelé pour calculer le prix des services pour tous les services spécifiés dans la requête client, en mode indépendant (indépendamment du produit) ;

- À l’étape 908, pour le prix de chaque produit et pour chaque service demandé par la requête client, une étape de corrélation de service peut être effectuée afin de déterminer si les services tarifés en mode indépendant peuvent être ajoutés au prix du produit. Dans l’affirmative, le prix total du produit (qui comprend le principal produit et le service défini) peut être retourné à l’étape 910. Dans un mode de réalisation, le montant ainsi déterminé peut être stocké dans le référentiel massif 113, à l’étape 912 ;

- À l’étape 909, si les services tarifés en mode indépendant ne peuvent être ajoutés au prix du produit (prix de service applicable au prix du produit), il peut être déterminé un prix corrélé (pour le produit et le service défini) par le produit MCP 13. Le résultat ainsi obtenu peut être conservé dans le référentiel massif 13 à l’étape 912.

Le processus de l’exécution de corrélation de service peut être effectué par un Service corrélateur 18 (présenté dans la figure 3). Le corrélateur de service 18 peut être configuré pour déterminer si un prix de service indépendant peut être attaché à un prix de produit (p. ex., prix d’itinéraire). Le corrélateur de service 18 peut fournir un service de corrélation au coordinateur du prétraitement 130.

La figure 10 est un diagramme illustrant le processus de corrélation entre les services implémentés par le Service corrélateur 18, selon certains modes de réalisation.

À l’étape 950, une entrée est reçue qui comprend des informations associées à un produit (p. ex., itinéraire complet) et un service à associer aux prix des produits.

À l’étape 952, le résultat de la MCP 16 de services est utilisé pour extraire (ou récupérer), pour le service demandé, le prix indépendant du service et des données supplémentaires associées au service.

À l’étape 954, il est déterminé si le prix associé au service est applicable aux prix des produits (c’est-à-dire valable) en utilisant un indicateur d’applicabilité précalculé pour le service (l’indicateur d’applicabilité peut être aussi appelé « indicateur de validité »). Dans l’affirmative, le prix du service est retourné au coordinateur de prétraitement 130 à l’étape 956. Sinon, s’il est déterminé que le service n’est pas applicable au prix du produit, aucun prix n’est retourné au coordinateur de prétraitement 130.

La MCP 16 de services peut être configurée pour déterminer un indicateur d’applicabilité en association avec chaque service dans une phase de prétraitement, dans un mode de fonctionnement « indépendant » (indépendamment de toute demande de recommandation et donc indépendamment de tout contexte de produit). Le service corrélateur 18 peut utiliser cet indicateur d’applicabilité pour déterminer l’applicabilité d’un prix de service à un prix de produit (comme décrit dans le cadre de la Figure 9).

Dans un mode de réalisation, la MCP 16 de services peut comporter une base de données de prix pour stocker le prix de service indépendant et les indicateurs d’applicabilité associés aux services.

Pour chaque prix indépendant de service demandé par le coordinateur de prétraitement 130, la MCP 16 de service peut être configurée pour calculer le prix du service, en utilisant des règles prédéfinies et/ou des hypothèses. La MCP 16 de service peut stocker le prix indépendant déterminé pour le service en association avec le service dans la base de données de prix de service de la MCP 16 de services, et éventuellement d’autres contraintes liées au service (par exemple « géographie », » cabine », « prix », « restriction de vols » dans une application de l’invention à la fourniture de voyage). Ces contraintes supplémentaires peuvent servir à déterminer une correspondance avec les prix des produits.

Le système pré-transactionnel 10 selon les modes de réalisation de l’invention permet de fournir des recommandations de services auxiliaires aux dispositifs clients, dans une phase prétransactionnelle, tout en limitant les coûts de calcul nécessaires pour produire ces recommandations de service. Cela permet ainsi une réduction des demandes des utilisateurs soumis au système de transaction 12, l’utilisateur recueillant suffisamment d’informations au cours de la phase pré-transactionnelle pour mieux définir les requêtes à soumettre au système de transaction 12. En conséquence, l’utilisateur final n’a pas besoin d’aller et venir dans le flux de transaction implémenté par le système de transaction pour détecter si un service souhaité est disponible et/ou si un service souhaité est trop cher. La charge du système de transaction 12 peut être ainsi considérablement réduite. Par ailleurs, le système pré-transactionnel 10 selon les modes de réalisation de l’invention est capable de fournir des informations exactes à l’utilisateur lors de la phase pré-transactionnelle.

En se référant maintenant à la figure 11, les différents blocs du système prétransactionnel 10 et les dispositifs 2 de l’utilisateur de l’environnement d’exploitation peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, appelés collectivement ordinateur, tel que l’ordinateur 30. L’ordinateur 30 peut comprendre un processeur 32, une mémoire 34, un dispositif de mémoire de stockage de masse 36, une interface 38 entrée/sortie (I/O), et une interface homme machine (IHM) 39. L’ordinateur 30 peut aussi être couplé de façon opérationnelle à une ou plusieurs ressources externes 42 par l’intermédiaire du réseau 6 (qui peut être le réseau 21 par exemple) et/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 en masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée pouvant être utilisée avec l’ordinateur 30.

Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés à partir de microprocesseurs, de microcontrôleurs, de processeurs de signal numérique, de microordinateurs, d’unités centrales de traitement, de réseaux de portes programmables, de dispositifs logiques programmables, de machines à état défini, de circuits logiques, de circuits analogiques, de circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) à partir des instructions de fonctionnement qui sont enregistrées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais sans s’y limiter, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (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, la mémoire-cache 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. Une base de données 44 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.

Le processeur 32 peut fonctionner sous le contrôle d’un système d’exploitation 46 qui réside dans la mémoire 34. Le système d’exploitation 46 peut gérer les ressources de l’ordinateur de telle façon que le code de programme de l’ordinateur, intégré sous forme d’un ou plusieurs logiciels d’application, tels que l’application 48 qui réside dans la mémoire 34, puissent disposer d’instructions exécutées par lé processeur 32. Dans un mode de réalisation alternatif, le processeur 32 peut exécuter directement l’application 48 ; dans ce cas le système d’exploitation 46 peut être omis. Une ou plusieurs structures de donnée 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, ou l’application 48 pour stocker ou manipuler des données.

L’interface I/O 38 peut fournir une interface machine qui couple le processeur 32 de façon fonctionnelle avec d’autres dispositifs et systèmes, tels que le réseau 6 ou la ressource externe 42. Le serveur d’application 48 peut ainsi collaborer avec le réseau 6 et/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 48peut aussi comporter un code de programme qui est exécuté par une ou plusieurs ressources externes 42, ou repose autrement sur les fonctions et/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, les hommes de métier comprendront 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 6.

Le HMI 39 (tel que le HMI 30 dans l’implémentation de la figure 1 du dispositif client 3) peut être couplé de façon fonctionnelle au processeur 32 de l’ordinateur 30 d’une façon connue pour permettre un utilisateur de l’ordinateur 30 d’interagir directement avec l’ordinateur 30. Le HMI 39 peut inclure un affichage vidéo et/ou alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l’utilisateur. Le HMI 39 peut aussi inclure des dispositifs d'entrée et des contrôles tels qu’un clavier alphanumérique, un dispositif de pointage, des claviers, des boutons-poussoirs, des boutons de commande, des microphones, etc., capables d’accepter des commandes ou des saisies de l’utilisateur, et de les transmettre au processeur 32.

Une base de données 44 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 44 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 44 peut être aménagée avec toute organisation ou structure de base de données, notamment, mais de façon non restrictive, 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à. Un système de gestion de base de données sous forme de logiciel informatique d’application qui s’exécute sous la forme d’instructions sur le processeur 32 peut être utilisé pour accéder à l’information ou aux données stockées dans des fichiers de la base de données 44 en réponse à une interrogation, lorsqu’une interrogation peut être déterminée de façon dynamique et exécutée par le système d’exploitation 46, les autres applications 48, 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 de gestion de base de données approprié, et ne sont pas limités à tout type particulier de base de données.

Alors que l’invention a des avantages particuliers pour les systèmes fournisseurs de contenus prenant en charge les requêtes comportant au moins certains paramètres de requête associés à une date, une heure et/ou un emplacement, tel qu’un système fournisseur de voyages, l’homme du métier comprendra facilement que l’invention n’est pas limitée à ces systèmes fournisseurs de contenus et qu’elle peut être appliquée à divers systèmes de fournisseurs de contenus.

En général 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 instants 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 d’opérations 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.

Divers codes de programme décrits dans les présentes peuvent être identifiés, selon l’application dans laquelle ils sont implémentés, dans des modes de réalisation spécifiques de l’invention. Cependant, on notera qu’une quelconque nomenclature d’un programme particulier dans les présentes est utilisée uniquement par commodité ; ainsi l’invention ne peut être limitée à 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 sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d’affecter les fonctionnalités d’un programme parmi diverses couches de logiciels qui sont résidents dans un ordinateur typique [p. ex., les systèmes d’exploitation, les bibliothèques, les interfaces d’application de programme (API), les applications, les petites applications « (applets)], etc.; on notera que les modes de réalisation de l’invention ne sont pas limités à l’organisation spécifique et à l’affectation spécifique des fonctionnalités de programme telles qu’elles sont décrites dans les présentes.

Le code de programme mis en œuvre dans toute application/module décrit dans les présentes peut être distribué individuellement ou collectivement comme un produit programme d’ordinateur, 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 soi, permettant à un processeur de mettre en œuvre des aspects des modes de réalisation de l’invention.

Les supports de stockage lisibles par ordinateur, étant intrinsèquement non transitoires, peuvent inclure des supports tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage d’information, tels que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre une mémoire à accès aléatoire (RAM), une mémoire à lecture seule (ROM), une mémoire à lecture exclusivement, programmable et effaçable (EPROM), une mémoire à lecture exclusivement, programmable et effaçable électriquement (EEPROM), une mémoire flash, ou toute technologie de support solide de mémoire, (un disque compact portable doté d’une mémoire à lecture seule (CD-ROM), ou tout autre stockage optique, cassettes magnétiques, bandes d’enregistrement magnétique, disque de stockage magnétique, autres dispositifs de stockage 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 signaux transitoires en soi (p. ex., des ondes radio ou toutes autres ondes électromagnétiques se propageant, des ondes électromagnétiques se propageant par l’entremise d’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 ordinateur, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau.

Les instructions de programme lisibles par ordinateur, enregistrées sur un support lisible par ordinateur, peuvent être utilisées pour amener un ordinateur, d’autres types d’appareils programmables de traitement de données, ou d’autres dispositifs, à fonctionner d’une façon particulière, de sorte que les instructions stockées sur le support lisible par ordinateur produisent un article de fabrication incluant les instructions qui mettent en œuvre les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou 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 en utilisant le ou les processeurs, accomplissent une série de calculs pour mettre en œuvre les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.

Bien que l’invention ait été illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation aient été décrits de façon très détaillée, il n’est pas de l'intention du demandeur 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. Tandis que les modes de réalisation des figures 6 à 10 ont été décrits selon un ordre de traitement particulier, l’homme du métier comprendra facilement que l’invention n’est pas limitée à une telle succession d’étapes et que des mesures peuvent être appliquées dans un ordre différent. Plus généralement, dans certains autres modes de réalisation, les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou des diagrammes blocs peuvent être réordonnées, traitées en série, et/ou traitées en même temps en collaboration avec des modes de réalisation de l’invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés, tout en restant conformes avec les modes de réalisation de l’invention.

Claims (16)

1. REVENDICATIONS

   1. Un système serveur (10) configuré pour déterminer une liste de produits en réponse à une requête client provenant d’un dispositif client lors d’une session de requête/réponse, la requête client comprenant un ou plusieurs paramètres de requête, ledit système serveur comprenant un estimateur de produit (11) configuré pour déterminer une liste de produits principaux, ladite liste de produits principaux comprenant une estimation d’un ou plusieurs produits principaux correspondant à la requête client, dans lequel le système serveur (10) coopère par ailleurs avec une base de données d’estimation de produits auxiliaires (103) configurée pour stocker des données historiques relatives à des ensembles de produits auxiliaires, lesdites données historiques étant représentées par une structure de données en arbre (8) composée de nœuds, le système serveur comprenant par ailleurs un estimateur de produit auxiliaire (102) configuré pour déterminer à partir de la structure de données en en arbre une fréquence d’occurrence et une information de valeur du produit auxiliaire pour chaque ensemble de produits auxiliaires dans une liste d’ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires, le système serveur étant configuré pour fournir par ailleurs une liste de produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client en utilisant la fréquence d’occurrence et l’information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de ladite liste d’ensembles de produits auxiliaires.
2. 2. Système serveur selon la revendication 1, dans lequel ladite requête est reçue à un instant de traitement donné, et dans lequel chaque ensemble de produits auxiliaires identifie un ou plusieurs produits auxiliaires associés à un produit principal, lesdites données historiques comprenant des données collectées à partir de sessions précédentes de requête/réponse, chaque session précédente de requête/réponse étant implémentée entre un dispositif client et un système fournisseur de produit relié à ladite base de données d’estimation de produit auxiliaire sur une période de temps prédéfinie avant ledit temps de traitement.
3. 3. Système serveur selon l’une quelconque des revendications précédentes 1 et 2, dans lequel la structure de données en en arbre (8) comprend un nœud racine et une pluralité de niveaux, chaque niveau de la structure de données en arbre correspondant à un paramètre dérivé d’un ou plusieurs paramètres de requête, chaque nœud d’un niveau donné de la structure de données en arbre comportant une valeur de nœud représentant une valeur du paramètre correspondant au dit niveau, ladite valeur étant attribuée au paramètre de requête dans lesdites une ou plusieurs sessions de requête/réponse précédentes dans ladite période de temps, le dernier niveau de chaque branche de l’arbre comprenant les nœuds-feuilles, chaque nœud-feuille correspondant à un ensemble donné de produits auxiliaires.
4. 4. Système serveur selon la revendication 3, dans lequel chaque nœud-feuille de la structure de données en arbre correspondant à un ensemble de produits auxiliaires comprend par ailleurs une valeur de compteur et des informations de valeur, ladite valeur de compteur indiquant le nombre d’occurrences dudit ensemble de produits auxiliaires dans lesdites sessions précédentes de requête/réponse, l’estimateur de produit auxiliaire (102) étant configuré pour déterminer la fréquence d’occurrence de chaque ensemble de produits auxiliaires de ladite liste d’ensembles de produits auxiliaires en utilisant la valeur de compteur du nœud-feuille correspondant audit ensemble de produits auxiliaires dans ladite structure de données en arbre, l’estimateur de produit auxiliaire (102) étant par ailleurs configuré pour déterminer l’information de valeur du produit auxiliaire pour chaque ensemble de produits auxiliaires de ladite liste des ensembles de produits auxiliaires à partir de l’information de valeur du nœud-feuille correspondant au dit ensemble de produits auxiliaires dans la structure de données en arbre.
5. 5. Système serveur selon la revendication 4, dans lequel ladite information de valeur comprise dans chaque nœud-feuille correspondant à un ensemble donné de produits auxiliaires comprend une fourchette de valeurs définies par un seuil inférieur et un seuil supérieur, le seuil inférieur représentant la valeur inférieure attribuée à l’ensemble des produits auxiliaires dans une session de requête/réponse précédente au cours de ladite période de temps prédéfinie et le seuil supérieur représentant la valeur la plus élevée attribuée à l’ensemble de produits auxiliaires dans une session de requête/réponse précédente au cours de ladite période de temps prédéfinie.
6. 6. Système serveur selon la revendication 5, dans lequel, si la requête client comporte un paramètre de requête spécifiant un ensemble donné de produits auxiliaires, ladite liste des ensembles de produits auxiliaires comprend ledit ensemble de produits auxiliaires, l’estimateur de produit auxiliaire (102) étant configuré pour parcourir la structure de données en arbre selon un algorithme de recherche d’arbre pour déterminer un nœud correspondant ayant un chemin dans l’arbre correspondant aux paramètres de requête de la requête client, l’estimateur de produit auxiliaire (102) étant par ailleurs configuré pour rechercher un nœud-feuille dans un sous-arbre du nœud correspondant qui correspond audit ensemble donné de produits auxiliaires et une condition de seuil liée à la fréquence d’occurrence du nœud-feuille, la fréquence d’occurrence et l’information de valeur du produit auxiliaire de l’unique ensemble de produits auxiliaires étant retirées dudit nœud-feuille.
7. 7. Système serveur selon la revendication 5, dans lequel, si la requête client ne comprend pas un paramètre de requête spécifiant un ensemble de produits auxiliaires défini, l’estimateur de produit auxiliaire (102) est configuré pour parcourir la structure de données en arbre selon un algorithme de recherche d’arbre pour déterminer un nœud correspondant ayant un chemin dans l’arbre correspondant aux paramètres de requête client, l’estimateur de produit auxiliaire (102) étant par ailleurs configuré pour rechercher tous les nœuds-feuilles dans un sous-arbre du nœud correspondant, l’estimateur de produit auxiliaire (102) étant configuré pour déterminer un indicateur de popularité de l’ensemble de produits auxiliaires associé à chaque nœud-feuille trouvé et pour choisir un ou plusieurs ensembles de produits auxiliaires parmi les ensembles de produits auxiliaires associés aux dits nœuds-feuilles trouvés en fonction desdits indicateurs de popularité, lesdits ensembles sélectionnés de produits auxiliaires étant ajoutés dans ladite liste des ensembles de produits auxiliaires, la fréquence d’occurrence et l’information de valeur de chaque ensemble de produits auxiliaires dans ladite liste des ensembles de produits auxiliaires étant retirées du nœud-feuille correspondant.
8. 8. Système serveur selon la revendication 7, dans lequel le système comprend un calculateur de popularité de produits auxiliaires (108) configuré pour déterminer l’indicateur de popularité de chaque ensemble de produits auxiliaires d’un nœud-feuille en utilisant la fréquence d’occurrence associée au nœud-feuille.
9. 9. Système serveur selon l’une quelconque des revendications précédentes, dans lequel le système comprend un coordinateur de prétraitement (130) configuré pour mettre à jour les informations de valeur estimées par l’estimateur de produit auxiliaire (102) pour chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires à partir de données en temps réel.
10. 10. Système serveur selon l’une quelconque des revendications précédentes, dans lequel le système comprend un corrélateur de produit auxiliaire (8) configuré pour intégrer l’information de valeur de produit auxiliaire de chaque ensemble de produits auxiliaires de la liste des ensembles de produits auxiliaires à la valeur d’un produit principal déterminé par l’estimateur de produit (11), en fonction d’un indicateur d’applicabilité.
11. 11. Système serveur selon l’une quelconque des revendications précédentes, dans lequel par ailleurs le système comprend un moteur d’apprentissage de produits auxiliaires (105) configuré pour recueillir des métadonnées d’apprentissage au cours d’une période d’apprentissage prédéfinie, le système comprenant par ailleurs un gestionnaire d’arbre (800) pour gérer la structure de données en arbre en utilisant des métadonnées d'apprentissage recueillies.
12. 12. Système serveur selon la revendication 11, dans lequel le gestionnaire d’arbre (800) est configuré pour créer un nœud dans la structure des données d’arbre en réponse à la spécification d’une nouvelle valeur d’un paramètre correspondant à un niveau de l’arbre, dans une session de requête/réponse en temps réel, et pour régler la valeur de compteur dudit nœud sur la valeur 1.
13. 13. Système serveur selon la revendication 11, dans lequel le gestionnaire d’arbre est configuré pour mettre à jour un nœud dans la structure des données d’arbre chaque fois que la valeur associée au dit nœud est spécifiée dans une session de requête/réponse pour le paramètre correspondant au niveau des nœuds, et pour incrémenter la valeur de compteur dudit nœud.
14. 14. Système serveur selon l’une quelconque des revendications précédentes 11 à 13, dans lequel le gestionnaire d’arbre est configuré pour vérifier périodiquement la configuration de la structure de données en arbre et pour appliquer un algorithme d’équilibrage à la structure de données en arbre, si la structure de données en arbre est déséquilibrée.
15. 15. Procédé de détermination d’une liste de produits en réponse à une requête client provenant d’un dispositif client lors d’une session de requête/réponse, ladite requête client comprenant un ou plusieurs paramètres de requête, ledit procédé comprenant une * étape de détermination d’une liste de produits principaux, ladite liste des produits principaux comprenant une estimation de l’un ou plus des produits principaux correspondant à ladite requête client, dans laquelle le procédé comprend par ailleurs la détermination d’une fréquence d’occurrence et d’une information de valeur des produits auxiliaires pour chaque ensemble de produits auxiliaires dans une liste d’ensembles de produits auxiliaires, à partir d'une structure de données d’arbre représentant des données historiques associées à des ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires, ladite structure de données d’arbre comprenant des nœuds, le procédé comprenant par ailleurs la fourniture d’une liste de produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client en utilisant la fréquence d’occurrence et l’information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de ladite liste des ensembles de produits auxiliaires.
16. 16. Programme informatique pour déterminer une liste de produits en réponse à une requête client provenant d’un dispositif client lors d’une session de requête/réponse, ladite requête client comprenant un ou plusieurs paramètres de requête, le produit de programme informatique comprenant :

    un support non transitoire de stockage de données lisibles par ordinateur; et un code de programme enregistré sur le support non transitoire de stockage lisible par ordinateur qui, lorsqu’il est exécuté par un ou plusieurs processeurs, amène le ou plusieurs processeurs à :

    -déterminer une liste des produits principaux, ladite liste de produits principaux comprenant une estimation de l’un ou plusieurs des produits principaux correspondant à ladite requête client, dans laquelle lesdits un ou plusieurs processeurs sont par ailleurs amenés à :

    - déterminer une fréquence d’occurrence et une information de valeur des produits auxiliaires pour chaque ensemble de produits auxiliaires dans une liste d’ensembles de produits auxiliaires, à partir d’une structure de données en arbre représentant les données historiques associées aux ensembles de produits auxiliaires, en réponse à la requête client, la liste des ensembles de produits auxiliaires comprenant au moins un ensemble de produits auxiliaires, ladite structure de données en arbre comprenant des nœuds,

    Lesdits un ou plusieurs processeurs étant amenés à fournir une liste de produits auxiliaires candidats pour chaque produit principal déterminé en réponse à la requête client en utilisant la fréquence d’occurrence et l’information de valeur de produit auxiliaire déterminée pour chaque ensemble de produits auxiliaires de ladite liste des ensembles de produits auxiliaires.