FR3079040A1 - SYSTEM AND METHOD FOR PROVIDING PRODUCTS - Google Patents

Abstract

A server system (10) is provided for determining a list of products in response to a client request from a client device during a request / response session, the client request including one or more request parameters, the system comprising a product estimator configured to determine a list of main products, said list of main products including an estimate of one or more of the main products corresponding to the customer request. The system also cooperates with an ancillary product estimation database storing historical data associated with sets of auxiliary products, the historical data being represented by a tree data structure (8) composed of nodes. The server system includes an auxiliary product estimator (102) for determining, from the tree data structure, an occurrence frequency and auxiliary product value information for each set of ancillary products in a list of sets. of auxiliary products, in response to the customer request, the list of auxiliary product sets comprising at least one set of auxiliary products. The server system provides a list of candidate ancillary products for each main product determined in response to the client request, using the occurrence frequency and the auxiliary product value information determined for each set of ancillary products of said list of auxiliary products. sets of auxiliary products.

Description

SYSTEM AND METHOD FOR PROVIDING PRODUCTS

TECHNICAL AREA

The invention generally relates to client / server architectures and, in particular, to computer systems, methods, and systems for delivering products to a client device in response to a client request.

CONTEXT

In recent decades, the Internet has revolutionized the architecture of computer systems considerably. In particular, the Internet has transformed conventional content provider systems into dynamic and highly interactive online systems using client / server architectures.

Modern content provider systems use one or more computer server devices (also called server devices or servers) that receive client requests from client computer devices (also called client devices) through a dedicated user interface via a communication network. A user can therefore directly submit a request for content (also called a query) using a client device via the dedicated user interface to access content such as a product. The server device can search for one or more candidate products that respond to the user's request, using a search engine, and return a response to the client device via the dedicated interface. The response may include the list of product candidates (also called product proposals or solutions) determined by the search engine and various information relating to each product candidate. The user can then select a product from among the candidate products and initiate a purchase transaction to purchase the product.

Certain systems of existing content providers also provide ancillary products also called “complementary products” or “services” in relation to the products supplied. These ancillary services may be provided directly by the content provider's system or provided by another indirect content provider system.

For example, the content provider system may be a travel provider system which determines the best travel options in response to a user request for a trip, the user specifying on a user interface a set of parameters such as '' a date, a place of geographic departure and a place of geographic arrival, and any additional preferences of the user (e.g. price criteria, connections, etc.) The user can thus access the interface dedicated user of the travel management system and submit a travel request to obtain travel information and / or purchase a travel product (travel reservation) such as a flight product for a given route, on a given date . In some situations, the user may need additional travel product related services such as optional travel related services (e.g. meal service, seat related services, pet transportation service, etc. .)

The search engine of conventional content provider systems uses significant resources to process each user request, this processing requiring a large number of accesses to data stored in several databases or cache resources, and to determine product candidates, thus giving rise to high calculation costs.

To optimize the search engine calculation costs, different approaches have been proposed. A first approach is based on a limitation of the search area in which the search engine determines the candidate solution using an optimized search algorithm or pre-filtering.

Another existing approach consists in using precalculated data to limit the calculations required in order to process each request.

To optimize the resources of the content provider system (reservation or purchase system for example), another existing approach has been proposed, which is based on the use of a “pre-transactional” content provider system ( also called “pre-reservation”, “pre-purchase”, or “pre-finalization of purchase” system, for example) connected to the transaction system to provide product recommendations in a pre-transactional phase (also called a “recommendation” ”Or“ pre-treatment ”phase). The content provider's pre-transaction system (also called a pre-transaction system below) provides product information to a client device derived from statistical data in response to a user request. More specifically, instead of calculating the response to each request in real time from up-to-date databases, the content provider's pre-transaction system uses statistical data related to products already purchased in a previous period. Likewise for the content provider's transaction system, the content provider's pre-transaction system returns the candidate products (for example, travel offers) to the client device, the information associated with the products (such as the price of the product by example) thus being determined from previous transactions. In addition, the content provider’s pre-transaction system can process a request, even if a limited number of request parameters are entered by the user. The user thus has access to statistical information on the products available, without using the search engine to process queries in real time, as well as access to several databases. If the user wishes to make a transaction (buy or reserve a product), he can select a product in the interface dedicated to the pre-transaction system of the content provider to be redirected to the system of the content provider or he can directly access to the content provider's system.

Currently, these pre-transaction systems can only provide direct product information (main products) sent by the content provider's system because they process a large amount of product-related data. Conventional pre-transaction systems generally do not provide information on complementary products (i.e., services) associated with a product (e.g. availability of service in relation to product and service price) . In some cases, they can at most provide very limited and not entirely accurate information on ancillary services. Because of the relationship between a product and an auxiliary service, fixing the values for a service (the values of the service or the prices) requires correlating these values with the value of the product (price of the product), which implies a complexity of exponential processing.

However, in certain situations, a user will validate / finalize a transaction (e.g. the purchase of a product) only if certain services are available. Exemplary travel services include, for example, an extra bedroom, the availability of a vegetarian meal, the availability of video on demand during a flight, travel options for animals, etc. Therefore, after accessing the pre-transaction system, a user can submit multiple transaction requests to the transaction content provider system, access product proposals, and check service options. The user can finally decide not to proceed with the transaction due to the unavailability of the specific service (s), or submit additional requests to the system of the transaction content provider with different parameters for try to find products with the desired service (s) at the best price. This results in an additional calculation cost at the transaction system level. This additional cost is all the more important, since associating it in this way with services to products requires significant computing resources with several accesses to different databases on the server side. This overload of the transaction system can limit its performance, the time taken to process requests and its quality of service. The user experience can be deeply affected by such a slow processing speed, dissuading users from completing the transaction, or enticing them to switch to another content provider system.

Improved systems and methods for providing services and products associated with the products which limit the overload of the content provider system are therefore required.

ABSTRACT

In order to address these and other problems, there is provided a server system configured to determine a list of products in response to a client request from a client device during a request / response session, the client request. including one or more query parameters. The server system includes a product estimator configured to determine a list of main products, the list of main products including an estimate of one or more of the main products corresponding to the customer request. The server system also cooperates with an auxiliary product estimation database configured to store historical data associated with the sets of auxiliary products, the historical data being represented by a tree data structure composed of nodes. The server system further includes an auxiliary product estimator configured to determine from the tree data structure an occurrence frequency and value information of the auxiliary products for each auxiliary product appearing on a list of sets of auxiliary products. , in response to the customer request, the list of sets of auxiliary products comprising at least one set of auxiliary products, the server system being configured to supply in addition a list of candidate auxiliary products for each main product determined in response to the customer request using the frequency of occurrence and the auxiliary product value information determined for each set of auxiliary products from the list of sets of auxiliary products.

In certain embodiments, the client request is received at a given processing time, each set of auxiliary products identifying one or more auxiliary products associated with a main product. The historical data can then include the data collected from the previous request / response sessions, each previous request / response session being implemented between a client device and a product supplier system linked to the auxiliary products estimation database. for a predefined period of time before the processing time.

The tree data structure may include a root node and a plurality of levels, each level of the tree data structure corresponding to a parameter derived from one or more query parameters. Each node of a given level of the tree data structure can then comprise a node value representing a value of the parameter corresponding to the level, the value being assigned to the parameter of the request in one or more of the request sessions / previous responses over time. The last level of each branch of the tree can have leaf nodes, with each leaf node corresponding to a given set of auxiliary products.

In certain embodiments, each leaf node of the tree data structure corresponding to a set of auxiliary products also includes a counter value and value information, said counter value indicating the number of occurrences of the set of auxiliary products in previous request / response sessions, the auxiliary product estimator being configured to determine the frequency of occurrence of each set of auxiliary products in the list of sets of auxiliary products using the counter value of the leaf node corresponding to said set of auxiliary products in the data structure of the tree data structure, the auxiliary product estimator being further configured to determine the value information of the auxiliary product for each set of auxiliary products from said list of sets of ancillary products from information of the value of the leaf node corresponding to the set of auxiliary products in the tree structure data structure.

In one embodiment, the value information included in each leaf node corresponding to a given set of auxiliary products comprises a range of values defined by a lower threshold and an upper threshold, the lower threshold representing the lower value assigned to the set ancillary products in a previous request / response session during the predefined period of time and the upper threshold representing the highest value assigned to the set of auxiliary products in a previous request / response session during said period predefined time.

If the customer request includes a request parameter specifying a given set of auxiliary products, the list of sets of auxiliary products can include the set of auxiliary products, the estimator of auxiliary product being configured to browse the data structure data structure in a tree according to a tree search algorithm to determine a corresponding node having a path in the tree corresponding to the request parameters of the customer request, the auxiliary product estimator being also configured to search for a leaf node in a sub-tree of the corresponding node which corresponds to the given set of auxiliary products and a threshold condition associated with the frequency of occurrence of the leaf node, the frequency of occurrence and the value information of the auxiliary product of the single set of auxiliary products being removed from the leaf node.

If the customer request does not include a request parameter specifying a defined set of auxiliary products, the auxiliary product estimator is configured to browse the data structure data structure in tree according to a tree search algorithm to determine a node correspondent having a path in the tree corresponding to the client request parameters, the auxiliary product estimator being furthermore configured to search all the leaf nodes in a sub-tree of the corresponding node, the auxiliary product estimator being configured for determine a popularity indicator of the set of auxiliary product associated with each leaf node found, and choose one or more sets of auxiliary product from the sets of auxiliary product associated with the leaf nodes according to the popularity indicators, the sets of auxiliary products being added to the list of sets s of auxiliary products, the frequency of occurrence and the value information of each set of auxiliary products in the list of sets of auxiliary products being removed from the corresponding leaf node.

In some embodiments, the system includes an auxiliary product popularity calculator configured to determine the indicator of the popularity of each set of auxiliary products of a leaf node using the frequency of occurrence associated with the leaf node .

The system may further include a preprocessing coordinator configured to update the value information estimated by the auxiliary product estimator for each set of auxiliary products from the list of sets of auxiliary products from real-time data.

In one embodiment, the system may include an auxiliary product correlator configured to integrate the auxiliary product value information of each set of auxiliary products from the list of sets of auxiliary products to the value of a main product determined by l product estimator, based on an applicability indicator.

The system may further comprise an auxiliary product learning engine configured to collect learning metadata during a predefined learning period, the system further comprising a tree manager for managing the structure data structure. tree data using the collected learning metadata.

The tree manager can be configured to create a node in the data structure tree data structure in response to the specification of a new value of a parameter corresponding to a level of the tree, in a query session / response in real time, and to set the counter value of said node to the value 1.

The tree manager can be configured to update a node in the tree data structure each time the value associated with said node is specified in a request / response session for the parameter corresponding to the node level, and for increment the counter value of said node.

The tree manager can be configured to periodically check the configuration of the tree data structure and to apply a balancing algorithm to the tree data structure if the tree data structure is unbalanced.

Furthermore, a method is provided for determining a list of products in response to a client request coming from a client device during a request / response session, the client request comprising one or more request parameters, the method comprising a phase of determining a list of main products, the list of main products comprising an estimate of one or more of the main products corresponding to the customer request. The method further comprises determining an occurrence frequency and an auxiliary product value information for a set of auxiliary products in a list of sets of auxiliary products, from a data tree representing the historical data linked to the sets of auxiliary products, in response to the customer request, the list of sets of auxiliary products comprising at least one set of auxiliary products, the tree data structure being composed of nodes.

The method further comprises a step consisting in providing a list of candidate auxiliary products for each main product determined in response to the customer request using the frequency of occurrence and the auxiliary product value information determined for each set of auxiliary products from the list of sets of auxiliary products.

Furthermore, a computer program product is provided to determine a list of products in response to a client request from a client device during a request / response session, the client request comprising one or more request parameters. , the computer program product comprising:

a non-transient storage medium for computer-readable data; and a program code recorded on the non-transient computer-readable storage medium which, when executed by one or more of the processors, causes the one or more processors to:

-determine a list of main products, the list of main products including an estimate of one or more of the main products corresponding to the customer request.

One or more of the processors are also required to:

-determine a frequency of occurrence and information of value of auxiliary products for each set of auxiliary products in a list of sets of auxiliary products, from a tree data structure representing the historical data linked to the sets of products auxiliaries, in response to the customer request, the list of sets of auxiliary products comprising at least one set of auxiliary products, the tree data structure being composed of nodes.

One or more processors are also required to provide a list of candidate auxiliary products for each main product determined in response to the customer request based on the frequency of occurrence and the auxiliary product value information determined for each set of auxiliary products from the list of sets of auxiliary products.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings which are incorporated and constitute a part of this specification, illustrate various embodiments of the invention and, with the general description of the invention above and the detailed description of the embodiments given below, serve to explain the embodiments of the invention.

FIG. 1 describes an example of an operating environment for a pre-transactional content provider system 10, according to certain embodiments.

- Figure 2 shows an operating environment of the pre-transaction system 10 of a travel supplier (hereinafter called "pre-booking system"), according to an exemplary application of the invention in the travel industry.

- Figure 3 shows an exemplary implementation of a pre-transaction system, according to some embodiments.

- Figure 4 is a diagram describing an exemplary mass research platform.

- Figure 5 schematically describes a tree data structure in accordance with certain embodiments.

- Figure 6 is a sequential flowchart describing the process of determining a set of services, according to an embodiment in ‘pull’ mode.

- Figure 7 is a sequential flowchart describing the process of determining a list of service sets, according to an embodiment in ‘push’ mode.

- Figure 8 is a sequential flowchart describing the process of switching a service estimation mode, in accordance with certain embodiments.

- Figure 9 is a sequential flowchart describing the process of determining service sets, according to certain embodiments.

- Figure 10 is a sequential flowchart describing the process of correlation of services according to certain embodiments.

- Figure 11 shows an exemplary operating environment in which one or more components of a pre-transaction system can be implemented according to one embodiment.

DETAILED DESCRIPTION

The embodiments of the invention provide a server system and a method for determining a list of products in response to a client request received from a client device, in an IT environment, during a request / response session, the list of products (also called product recommendations) including a list of main candidate products which satisfy the customer request and, for at least one main product, one or more auxiliary products (also referred to below as "services" or "auxiliary services ») Associated with the main product offered to the client system. The embodiments of the invention have particular advantages when the request / response session corresponds to a pre-transaction phase, the invention allowing the integration of service recommendations associated with each product recommendation determined in response to the request. client, during this pre-transaction phase.

As used, the term "pre-transactional" refers to a phase prior to a transaction flow implemented in a transaction system, a transaction flow starting from a user request received by the system transaction for a product specified by the request parameters and ending with a purchase operation of a product through the transaction system (the term "transaction" also refers to a "purchase", a "Finalization of purchase" or "reservation"). In a client server architecture, a "transaction" corresponds to a request / response session initiated by a client request and finalized by the purchase of a product (selection of a main product by the user and validation of the selection by paying the price value associated with the product). The transaction of the product may include a set comprising a main product and an associated auxiliary product (set of services) comprising one or more auxiliary products (the services) associated with the main product, the overall value (total price) of the transaction comprising the value of the main product added to the value of the service package.

As used, a pre-transaction phase is triggered by one or more user requests (which may be “open” requests) and it returns a list of products estimated to be candidate products (also called “recommendations”) of products), provided by the transaction system using various data which may include statistical data. This statistical data can be used to provide more information in case a given set of services has not been pre-calculated. A pre-transaction phase thus returns statistical information on the products.

Referring to Figure 1, an exemplary operating environment 100 of the system of a pre-transactional content provider 10 is shown, according to some embodiments.

The pre-transactional content provider system 10 (also referred to as the pre-transactional system or "server system") may be configured to determine a set of product candidate recommendations for a user device 2 in response to a request for user (called pre-transactional request) identifying one or more request parameters from a set of request parameters predefined by a request format during a pre-transactional phase.

In one embodiment, the pre-transactional content provider system 10 can host one or more websites and / or have a hosting service that hosts one or more websites.

As used, the term "content" refers to any content that can be provided to a user device through a user interface in the form of products, each product being potentially associated with one or more services ("ancillary services") associated with the products. Each product can be defined by a set of parameters depending on the field of application of the invention, and by a value (the price). A representation of this content can be generated on a graphical user interface using various elements of representation such as electronic text, images, photos, audio recordings and other forms of data which can be processed, stored and returned.

Each client device 2 (also known as a “user device” can be a personal computing device, a tablet computer, a thin client terminal, a smartphone and / or another such computing device. Each client device 2 may host web browsers and / or custom application software (eg client system), and may include a client user interface.

Each user device 2 can also include a web browser application which communicates with a web server application hosted by the pre-transaction system 10.

The pre-transaction system 10 can communicate with one or more content provider "transaction" systems 12 (also called "transaction system" 12) through a dedicated network 21 to enable the pre-transaction system 10 access historical data kept by each transaction system 12.

Each transaction system 12 can be configured to process user requests in real time (also called "transaction" requests) using a search engine configured to access one or more database contents in real time. It is also suitable for implementing transactions with a user (such as booking or purchasing a product and potentially services associated with the product). A transaction for a product is finalized when a user pays for the product and optional services. In some embodiments, the transaction system 12 can be configured to process only user requests that include a set of mandatory search parameters.

A user operating one of the user devices 2 can interface directly with the pre-transaction system 10 using a dedicated pre-transaction user interface during a client / server session. In certain embodiments, the pre-transaction system 10 can be configured to redirect a user device 2 to a dedicated interface of the transaction system 12, in response to a selection of a product by a user. The user can also interface directly with the transaction content provider system 12 using the dedicated pre-transactional user interface.

The transaction content provider system 12 can store a user account if the user is already registered or may otherwise not understand any user related data if the user has not previously created a user account .

The pre-transaction system 10 and the transaction system 12 are dedicated to the same field of application (for example, the travel industry). The pre-transaction system 10 and the transaction system 12 can be configured to determine candidate products of the same type. However, they refer to different transaction phases. Furthermore, while the transaction content provider system 12 may include a search engine which implements a search algorithm to search for products corresponding to a query in one or more content databases, the pre-transaction system 10 may include a product estimator 101 configured to estimate product solutions (product candidates) for a user query by searching for statistical data related to past transactions, performed by the transaction system 12, without the need to access to multiple content databases. Therefore, while the responses returned by the pre-transaction system 10 may be based on historical data, the responses returned by the transaction content provider system 12 may be based on real-time data retrieved from the databases. content data. The pre-transaction system 10 thus limits the load on the system of the transaction content provider 12, a user wishing to have a view of the possible product options being able to submit an open request to the pre-transaction system 10, to refine his request based on the results returned by the pre-transaction system 10 and submitting the refined request to the transaction content provider system 12 if the user decides to proceed with a transaction.

In certain embodiments, the pre-transaction system 10 (server system) may include a service estimation engine 1 (also called “auxiliary product estimation engine”) configured to estimate the service recommendations in response to a pre-transaction request. The service estimation engine 1 can comprise a service estimation database 103 configured to store historical data linked to the sets of services (also called “auxiliary products” or “complementary products”), the historical data being represented. by a tree data structure comprising nodes. The service estimation engine 1 can moreover comprise a service estimator 102 (also called “auxiliary product estimator”) configured to determine from the tree data structure an frequency of occurrence and information of value d 'an auxiliary product for each set of services in a list of sets of auxiliary products, in response to the customer request. The list of service packages may include at least one service package (a service package may also be referred to hereinafter as "ancillary product package"), the pre-transaction system 10 being configured to further provide a list of the Auxiliary products candidates for each main product determined in response to the customer request using the frequency of occurrence and the value of the service determined for each set of auxiliary products from the list of sets of auxiliary products.

The pre-transaction system 10 can be configured to provide service recommendations for each product candidate using the frequency of occurrence and the service value determined for each set of services from the list of service sets.

In one embodiment, the client request can be received by the pre-transaction system 10 at a given processing time and each set of services can identify one or more auxiliary products associated with a main product. In this embodiment, the historical data includes data collected from previous request / response sessions (previous transactions), each previous transaction being implemented between a client device and a system supplying a product connected to the database. service estimate 103 during a predefined period before the time of processing.

In an exemplary application of the invention in the travel industry, the pre-booking system 10 can be configured to provide travel recommendations for travel products (candidate travel products), such as travel products. airline company.

A travel request has a predefined format defining a set of request parameters including:

- parameters of time / date / place of departure;

- time / date / place of arrival parameters;

- additional parameters relating to the trip.

Request parameters for the travel provider transaction system 12 system (also referred to hereinafter as "reservation" system or "finalize purchase" system) may include "optional" and / or request parameters "Mandatory", the mandatory request parameters being required by the "reservation" system to be able to process the request. Optional query parameters can include, for example, the user's preferred language, or refinement parameters (e.g. time of day, preferred company). Generally, the pre-transaction system of the travel provider 10 (also called hereinafter "pre-reservation" or "pre-purchase" system can initiate a request without any requirement regarding the mandatory request parameters. For example, processing a request can be triggered by any request comprising at least one request parameter.

A travel request parameter can have a typology (for example “the place of departure”, “place of arrival”), a category of data (eg place, date), a type of data (eg ., character) and / or a data format (defined for example by the IATA standard, IATA being "the international air transport association").

The embodiments of the invention can be implemented on one or more computer systems comprising one or more networked computers or servers. Computer systems can provide processing and database functions for pre-transaction and transaction content provider systems 10 and 12.

The pre-transaction system 10 and the transaction content provider system 12 can host one or more websites and / or have a hosting service hosting one or more websites.

Each communication network 21 can include one or more private and / or public networks (eg Internet) which allow the exchange of data, such as the Internet, a local area network (LAN), a wide area network (WAN), a cellular voice / data network, one or more high speed bus connections and / or other types of such communication networks. Each communication network 21, 22 can use normal communication technologies and / or protocols such as 4G, Ethernet, 802.11, TCP / IP (Transmission control protocol / Internet protocol), HTTP (Hypertext transport protocol), FTP (File Transfer Protocol), etc. Data can be exchanged on each network 21, 22 according to different data exchange technologies and / or formats such as the hypertext markup language (HTML), the JSON model and the extended markup language (XML).

The pre-transaction system 10 may include a redirection function to redirect the user to the Internet domain of the transaction system 12 using an associated URL, in response to a selection made by the user for a product candidate in order to allow him to to finalize a transaction. In certain embodiments, the pre-transactional system device 10 can send a request corresponding to the user's selection to the transaction system 12 using a URL of a predefined type which can include a set of fields such as a Body, the content provider system identifier field such as a String field, additional fields linked to the request parameters (name / value pairs) as well as selected by the user. Those skilled in the art will readily understand that the invention is not limited to these specific fields in the URL request and may include different fields depending on the application of the invention.

FIG. 2 represents the operational environment of the pre-transaction system of a travel supplier 10 (hereinafter referred to as “pre-reservation system”) conforming to an exemplary application of the invention for the travel industry. The environment may include a global distribution system (GDS) 200, one or more systems of indirect product suppliers 20, such as carrier systems 201, one or more systems of indirect sellers or travel pre-purchase (supplier systems auxiliary content), such as a travel agency system 202, a pre-transaction system of a provider 10, a system of a transaction provider 12, and one or more client devices 2. Each of them, GDS 200, carrier systems 201, indirect seller system 202, pre-transaction system 10 and transaction system 12 as well as user device 2 can communicate through network 21. carriers 201 may each include a computer reservation system (CRS) and / or a billing system for the respective airline that allows the GDS 200 and / or the air system indirect provider 202 to book and pay for airline tickets. Carrier 201 systems can also interact with each other or via the GDS 200 to allow the transmitting carrier to sell seats supplied by the actual carrier. The de facto carrier can then bill the originating carrier for the services provided.

The GDS 200 can be configured to facilitate communication between carrier 201 systems and indirect seller systems 202 by allowing travel agents, originating carriers, or other indirect sellers to search for available segments and finalize reservations on one or more conveyor systems 21, via the GDS 200. For this purpose, the GDS 200 can maintain links with each of the conveyor systems 201 via the network 62. These links can enable the GDS 200 to obtain data Planning and Availability for Segments from Carrier Systems 201, and Travel Proposal Reservation Requests to Carrier Systems 201. Carrier and Travel Agency Systems

201, 202 can thus book flights with multiple carriers via a single connection to the GDS 200. The GDS 200 can store and / or keep a passenger name record (PNR) which includes a complete set of data for the itinerary of a trip, including segments of multiple carriers and / or other travel services including travel, such as hotel and rental car reservations.

A travel agency system 202 may include a web server that provides a website accessible to the general public. This website can be configured to provide access to travel planning elements, such as the ability to search for travel products that match a travel request. For this purpose, the travel agency system 202 can provide the traveler with access to data from one or more databases hosted by the GDS 200, the carrier systems 201 and the carrier system. travel agency 202. In another embodiment of the invention, the travel agency system 202 may be a proprietary system that limits access to travel service providers or travel agents, in this case access can be provided through a private website or other application.

The travel provider 12 transaction system may be in communication with the travel agency 202 system via network 62 or other suitable connection. In other embodiments of the invention, the entire system of the travel supplier 2 or a portion thereof, can be integrated into one or more of the other systems 200, 201, 202. Travelers, travel agents, can use the system from the travel agency 202 to generate and / or search for travel proposals that satisfy a travel request received from the traveler using the travel provider system 2.

GDS 200, carrier systems 201, travel agency system 202, travel provider system 12 and user devices 2 of the operating environment can be implemented on one or more computing devices or systems, collectively referred to as a computer.

FIG. 3 represents an exemplary implementation of the pre-transactional system 10. As shown in FIG. 3, the pre-transactional system 10 can comprise, or be connected to, a distributed search platform MSP 11 (MSP is the acronym for Massive Search Platform ) configured to store pre-calculated product values. The MSP platform 11 may include one or more distributed machines, each machine comprising one or more computer systems. Figure 3 only describes a logical view of the platform while the MSP platform can be physically distributed over a set of distributed machines. The MSP platform 11 can be configured to store the best product values of a set of content provider systems 12 supplying products for every day of the coming year, which may include several possible product values per day .

Figure 4 shows an exemplary MSP 11 platform in the travel industry. In this example, the MSP platform 11 can be configured to store and search for travel recommendations, each travel recommendation identifying a candidate product (eg a flight), the candidate product being associated with a product value (or " price "of the product) according to an exemplary embodiment of the present invention. The stored travel recommendations can be distributed over all the machines that are connected to the MSP platform. The MSP platform 11 can include one or more databases 113 for storing air transport recommendations which can logically be grouped into groups of recommendations. Although a static view is shown in Figure 4, those skilled in the art will readily understand that the databases 113 can be physically stored between the different machines.

The MSP platform 11 can moreover comprise a loading engine 115 configured to index the groups of pre-calculated recommendations for air transport (for example, journeys corresponding to the same route defined by a pair of cities) and to store them in one of the machines. in the distributed system.

The MSP platform 11 can also include a search engine 117 configured to locate groups of data among the physical machines and provide indexed search information to process requests coming from user devices 2.

In certain embodiments, the MSP platform 11 can comprise a set of trade-oriented analysis engines 108. Each trade-oriented analysis engine 108 can be configured to optimize the hardware costs of the platform by determining the optimal number of recommendations for recalculating every day, with as much accuracy as possible, the prices precalculated using various processes such as an analysis of loading and search operations, various data such as metrics generated on the volatility and quality of the data stored in the system. An exemplary implementation of an MSP 11 is described in the patent application US20130073586 A1.

Returning to FIG. 3, in certain embodiments, the environment can moreover comprise a massive computing platform 13 or MCP. The MSP 11 analysis engines can transmit data to the MCP 13. The pre-transaction system 10 can be connected to the MCP 13, or can understand it. MCP 13 can be configured to calculate product candidates (eg flights) and product value information, such as prices, on a massive scale. More specifically, the MCP 13 can be configured to process pre-transactional requests even if the number of parameters supplied in the request is limited. In an exemplary application of the invention for the travel industry, the MCP 13 can interact with other internal services provided by a GDS 200. The MCP 13 can process a request with a high degree of freedom, even if no parameters Mandatory request is not specified (eg the travel date parameter or the place of origin and / or destination, or the carrier in fact in an exemplary application of the invention for the travel industry) . MCP 13 can perform data processing optimization based on global query analysis.

MCP 13 can be organized according to a model comprising resources which can be instantiated dynamically. The subsystem performs data processing optimization based on a global analysis of the queries.

In an example application of the invention for the travel industry, MCP 13 can include one or more Massive Masters (et Massive Master ’) and a plurality of Massive Working Engines. The massive masters can be configured to analyze the queries globally which are then broken down into optimized queries. The optimized queries obtained in this way can then be processed by one or more of the Massive Work Engines. Each Massive Work Engine can send the result of the processing of the optimized request to the Massive Master (s) who assemble the results into candidate products (such as travel solutions), each candidate product including a product value (eg the price of the trip).

MCP 13 can also be configured to perform a global analysis in order to identify redundancies (request redundancies) between received requests in order to avoid unnecessary reprocessing. This may include merging redundant query parts based on predefined performance requirements.

The MSP 11 and MCP 13 can be part of a distributed search platform, connected to an entire transaction system of the travel provider 12 (such as airline systems, travel agency systems, etc. ). Each travel supplier transaction system 12 can define which part of its product sector is to be integrated into the search platform. In an exemplary application for the travel industry, each travel supplier transaction system 12 can then send to the MCP 11 a “massive” interrogation comprising a series of calculation orders, each order defining the markets taken into account ( such as a list of city pairs for every day of the year to come in the travel industry) and the type of product recommendation to generate (e.g. for each day, the best recommendations for travel from 1 to 20 days). These orders can be updated by the transaction system of the travel supplier 12 or can serve as a basis for a periodic calculation. MCP 13 can use internal functions of the GDS 200 to calculate the recommendations requested, such as the trip retrieval function to retrieve a list of existing flights, a price function to find the best combination of fares and products ( e.g. flights), an availability function to determine which products are available to book or buy.

Since the recommendations are generated for the travel provider's transaction system 12, the recommendations can be stored in a global cache memory (Massive Repository 113) of precalculated travel recommendations thus becoming available for future search queries from the users. . The Massive Repository 113 can be used to store the recommendations calculated by the MCP 13. The search among the possible solutions is carried out by the MSP 11.

The pre-transaction system 10 allows a user to submit open requests from a dedicated user interface, displayed on a user device. An open pre-transaction request submitted by a user to the pre-transaction travel system could, for example, be "Where can I go?" "," What can I do for what I want to spend? ". As used, an "open" query refers to a query defined by a set of query parameters, a query parameter value being specified by the user only for a limited subset of query parameters that may include only one query parameter. The pre-transaction system 10 can then return a response in the form of candidate products which satisfy the open request. The user can select a product candidate on the same search page, without the need to connect directly to the travel provider's transaction system and to specify all the mandatory query parameters (e.g. place of destination, departure date, etc.).

The pre-transaction system 10, according to certain embodiments of the invention, makes it possible to select a product by a user according to the estimated availability and the price associated with the given service (s). during a pre-transaction phase.

In one embodiment, the user can specify the desired services in the pre-transaction request submitted in "pull" mode (meaning "pulled mode"). Alternatively, service recommendations (also referred to as "service recommendations") may be dynamically returned to the user, which are associated with a product, without a set of services being specified by the user, based on precalculated popularity indicators associated with each service (“push mode” meaning “pushed mode”).

A product (also called “main product”) can be associated with product information identifying the product (for example, an air transport product is associated with a city pair, a departure / arrival date, a time of departure / arrival) and a product value representing the price of a product available for purchase. A product can also be associated with a set of services comprising at least one service.

A service or “ancillary service” (also called “ancillary product” or “complementary product”) linked to a given main product can be associated with service information identifying the service, availability information indicating whether the service is available for the product and a service value representing the price of the service.

A "service package" refers to a plurality of services that can be purchased or reserved together with a product by a user during a transaction between the user's client device and a transaction system 12.

The value of the service (price of the service) associated with an auxiliary service linked to a given product may be dependent on the product. For example, the price of an auxiliary service linked to a travel product may depend on several parameters such as:

- the initial complexity of the number of product price results in the pre-reservation system 10; for example, considering for a client, 500 destinations, 300 dates, 10 lengths of stay, the number of product prices is equal to:

destinations x 300 dates x 10 length of stay = 1,500,000 prices;

the size of the auxiliary service; for example, considering the search for an airline offering 20 different services and considering that the customer can be interested in any set of services among these 20 services, the dimension of the corresponding auxiliary service can be equal to 2 ²⁰ = 10 ⁶ auxiliary services ; the combination of the dimension of the price results (1,500,000) with the dimension of the auxiliary services (10 ⁶ ) gives 1.5 x 10 ¹² prices, in this example.

It should be noted that other parameters linked to travel products, associated with an auxiliary service, can influence the price of the auxiliary service so that for example:

- the type of product to which the auxiliary service is linked (eg equipment, type of aircraft);

- product location information (product location information can affect the price);

- the sales strategy of the product supplier (promotion campaign for example);

- The product category (a category can include, for example, long-haul flights, business class, economy class).

Calculating all possible prices according to conventional approaches requires an immense number of resources with long processing due to the volatility of the data.

The pre-transaction system 10, according to certain embodiments of the invention, provides recommendations for services in the pre-transaction flow while limiting the number of price results to be processed in order to match the operational constraints.

In some embodiments, the service estimation engine 1 can be configured to determine ancillary service recommendations for each product candidate returned in response to a product recommendation request.

In certain embodiments, the service estimator 102 of the service engine 1 can be configured to precalculate the information associated with the service such as the availability of the service and the price of the service using the information stored in the database d service experiences 103. The service estimator 102 can receive the context of a pre-transaction request (eg defined by a destination parameter and a date parameter for a trip pre-processing request) and using a tree search structure to determine a frequency of occurrence and value information of a service (price information) for a set of specified services if the pre-transaction request includes a specification of a set of services (“pull” mode), or for a list of service packages (the most popular service package) if the pre-transaction request does not include a specified set of services (push mode).

In a preferred embodiment, the pre-transaction system 10 may also include a service determination switching device 104 (also called a “switching device” in response to a pre-transactional request from a user. determination of ancillary services may include one of the following modes:

A service information extraction mode, this mode selection by the service determination switching device 104 triggers the recovery of preprocessed information linked to a set of services as it can be stored in a database. data 113 by the MSP 11;

- A service determination mode, this selection mode by the switching device 104 triggers the processing of a pre-transactional request by the service estimator 102.

The switching device 104 allows the cost of calculating a request processing to be optimized by identifying the service values (price of the service) to be calculated relative to the service values which can be estimated using real traffic. In some embodiments, the service determination switching device 104 may be activated in response to a recommendation request received by the pre-transaction system 10 to determine a service estimation mode. The service determination switching device 104 can be configured to transmit contextual data derived from a recommendation request received, either by the MCP 11, or by the service estimator 102, according to the determined service estimation mode. . The service determination switching device 104 can receive in return information related to the auxiliary services to the MCP 11 or to the service estimator 102, this information being used to generate recommendations of auxiliary services for each candidate product, the recommendations of product candidates being determined by the Massive Search Platform (MSP) 13.

In one embodiment, the Massive Search Platform (MSP) 13 can comprise a preprocessing coordinator 130 configured to calculate requests coming from real traffic data in order to supply the Massive Repository, for all the origins / destinations and sets of services, at minimum cost.

The service estimation engine 1 can also comprise a learning unit 105 (also called a “service experience learning or“ SEL ”unit) configured to collect meta-learning data related to availability and the value (price) of ancillary services from real-time transactions.

In some embodiments, the service experience database 103 can be organized according to a tree data structure. The service estimator 102 can use this tree data structure to search for auxiliary services to be recommended to a user in association with a product candidate satisfying the request. The service estimator 102 can implement a search algorithm based on this tree data structure, the search algorithm being such that it optimizes the calculation costs of the search. The service estimator 102 can include a tree manager 800 configured to dynamically manage the data structure in tree 8. Those skilled in the art will easily understand that even if the tree manager 800 is implemented in the estimator service 102 of FIG. 3, in other embodiments, the tree manager 800 can be implemented as a separate block from the service estimation engine 1 or can be implemented in another block from the service estimation engine service 1.

FIG. 5 schematically describes a tree data structure 8 according to certain embodiments.

The tree data structure 8 (also called “tree”) can comprise a plurality of nodes 80 (also called “layers”) at each level of the tree, corresponding to a parameter linked to one or more of the parameters of query predefined by the format of the query as it is supported by the systems of transaction content providers 12. The data structure in tree 8 thus models the different dimensions of a client query.

More specifically, each level of the tree can be associated with a combination of parameters which may correspond:

- exactly one request parameter, or

- to several query parameters, or to a subset of a query parameter, or

- a subset of several request parameters.

Each node at a given level of the tree, the level being associated with a given combination of query parameters, can thus correspond to a value ("node value") of the combination of query parameters and can be associated with the value of an integer ("a counter value") representing the number of occurrences of the value of combination of request parameters among the requests received by the transaction system 12 during a predefined past period T with respect to at a processing time. The first node in the 80-0- tree is also called the root node. A node that does not have a child node is called a leaf node (for example 80-N). Each node has at most one parent node located above it in the tree (i.e. at the previous level of the node). Since the root node is the highest node in the tree, it has no parent node. The depth (also called dimension) of a given node designates the length of the path from the node considered to the root node of the tree. Each path from the root node to a leaf node represents a set of values corresponding to the criteria (or parameters) of a query and thus represents a query in the past for the product. The depth of the leaf node is less than or equal to the maximum number of request parameters that can be specified in a user request according to the request format defined by transaction systems 12. A node can be designated by its value of node (combination values of parameters of a query). A node 80 can also be named below by n /, - with i representing the level of the tree (i = 0 corresponding to the root node) and k representing the fc-è node of level i. The counter value of a node will be n / denoted c _n .k Thus, the value of the node n / has been specified c _n .k times during the past period. According to the notations used, the child nodes of a node n _t ^k are designated by the nodes ni + 1 ¹ , ni + 1 ² , ..., n _{i + 1} ^p , with ^p representing a number of values specified by the users during the past period T for the combination of query parameters corresponding to level i - 1.

An exemplary customer request for the systems of product suppliers in the travel industry can for example be:

"To provide all round trip recommendations for Canada, for a passenger of a third or gold level, departing on a Saturday or Sunday with a stay of 2 weeks, with an average monthly temperature at destination greater than 25 °, with the services = {animal in cabin, vegetarian meal} "

In response to the finalization of the transaction triggered by this client request, the tree manager 800 can update the tree data structure. To update the tree data structure, the tree manager 800 can be configured for example to divide the customer request received into the following lexical units:

A- "Round trip"

B- "a passenger of third gold level"

C- "Departure on a Saturday or a Sunday"

D- "2 weeks stay"

E- "destination North America"

F- “destination Canada”

G- "destination Canada with a temperature> 20 degrees"

H- "Temperature> 2 5 degrees"

I- "Services = {pet in cabin, vegetarian meal}".

The tree manager 800 can then update the values of the different levels from these lexical units.

As this example shows, the levels of the tree can correspond exactly to a search criterion [A, C, D, E, H, I], correspond to several query criteria [B], correspond to a subset of a query criterion [F], or correspond to a subset of several query criteria [G],

The tree data structure 8 thus captures the context of the transaction of user requests for real traffic [also called “real time” traffic] at the transaction system 12 inside the nodes and branches of the 'tree. The data structure in tree 8 can also be configured so that the leaf nodes of the tree are associated with the parameter of the set of services representing a set of services purchased in association with the product defined by the upper levels. Each node of the tree can also correspond to a set of services [comprising one or more services] purchased during the period spent T together with the product defined by the path from the root node to the node preceding the leaf node considered. The set of services can be defined by a combination of services {[service 1] and [service 2] and ... [service p]}.

The estimate of ancillary services may be even more accurate as the depth of the tree increases.

In some embodiments, additional information may be associated with each node. This additional information can be used to maximize factorization and therefore the time required to perform a search using the tree.

In one embodiment, a set of tree criteria can be dynamically added or removed based on the number of child nodes.

The data structure in tree 8 can be configured so that the higher the level of the tree, the more the query parameter associated with the level is discriminatory. This limits the cost of calculating a search using the tree.

For example, in an application of the invention for the delivery of travel products, the tree data structure may for example include:

- A first level (i = 1) corresponding to the continental pair of a travel request defined by a "continental origin" and a "continental destination" [p. ex. a value of the continental pair can be "Europe, Europe"];

- A second level (i = 2) corresponding to the [x] transporter [x] controlling the travel parameter [p. ex. a value of the carrier controlling the journey can be “LH”, standard name for Lufthansa];

- A third level (i = 3) corresponding to the pair of geographic points of a travel request defined by a "point of origin" and a "destination point" [p. ex. a country pair value can be "BER" - France, BER being the standard name for Berlin];

- A fourth level (i = 4) corresponding to all of the services associated with a product defined by the node values of the previous level [p. ex. a value of the set of services can be the service [“animal in cabin”] and the service [“vegetarian meal”].

In certain embodiments, each leaf node n _L ^k of the tree data structure corresponding to a set of services previously requested can also comprise:

- a counter c _n ^ defining the number of times that the value of the set of services has been requested from the system of the transaction content provider 12 by a user during a past period T; and or

- A plurality of values of service packages; each service bundle value [also called “service bundle price”] may include price information linked to the price at which the corresponding service bundle, denoted {[service 1] and [service 2] and .. . [service p]} was purchased during a purchase transaction linked to the product defined by the path from the root node to the leaf node n _N ^k in the past period ?; in one embodiment, each set of services value [price of the set of services] may include a list of values of the prices at which the set of services was purchased during the past period; in another embodiment, each service bundle value [service bundle price] may include a list of price ranges at which the service bundle value was purchased in the past period, the price range being defined by a lower threshold representing the lowest purchase price of the set of services and an upper threshold representing the highest purchase price of the set of services.

The following description of certain embodiments will be made with reference to the I leaf nodes each comprising a value of set of services in the form of a range of values [or price range].

Each leaf node n _L ^k of the tree data structure, corresponding to a given set of services, can moreover include a time stamp representing the time of the last update of the leaf node which is the last date on which a price has been determined for the set of services associated with the leaf node [the time stamp can include the date and time of the update].

FIG. 5 shows, by way of example, data 81 included in each leaf node which are associated with an exemplary set of services A = {animal in cabin, vegetarian meal} including:

Frequency of occurrence: 6% [a request for a set of services 6% of the time for the request defined by the path of the leaf node]

- A price range: [34 euros; 41 euros]

- A time stamp Ts: 09/31/2017.

In certain embodiments, each node 80 of the tree data structure [different from leaf nodes] can moreover be associated with aggregated data of leaf nodes 82 which can be stored locally at the level of the node or stored in a unit of storage connected to the tree manager 800. Although FIG. 5 shows, by way of example, leaf node data 82 for only two nodes 80, for the sake of simplification, the skilled person will easily understand that data similar can be understood at other tree nodes [different from leaf nodes]. Leaf node data includes aggregated data from leaf nodes located in the subtree defined by node 80 [below node 80], Leaf node data thus includes aggregated data related to the set services associated with the subtree defined by node 80, such as the following data for each set of services:

- an aggregated frequency of occurrence Occ.

- information on aggregated values V (also called “information on aggregated prices”), for example a range of aggregated values and potentially

- an aggregated timestamp representing the last update of the set of services.

For a given set of services, the aggregated frequency of occurrence refers to the sum of the frequencies of occurrence associated with the set of services for all leaf nodes located below node 80.

In one embodiment, the aggregated information of values V included in a leaf node can be a range of aggregated values [also called “range of aggregated prices”] denoted [Pmin, Pmax], defined for all of the associated services at the leaf node. The price range can be defined by a lower threshold Pmin and a higher threshold Pmax, the lowest threshold Pmin representing the lowest value [price] attributed to the set of services among the values [price] associated with the set of services in the leaf nodes located below node 80 and the highest threshold Pmax representing the highest value assigned to the set of services among the values [prices] associated with the set of services in leaf nodes located below node 80.

Note that the invention is not limited to information on aggregated values V implemented as a range of aggregated values [Pmin, Pmax], Otherwise, the information on aggregated values V can be:

an average value [also known as a "price average"], or a median value [also known as a "median price"], or

- a range based on unit values [also known as “unit prices”] from which extreme values are removed [eg percentiles 0-10 and 90100 can be removed] or an ordered list of values [price] including values classified by decreasing frequencies of occurrence.

In another embodiment, the information of aggregated values V stored by a leaf node can include all the possible values [or “price”] in association with their number of occurrences

The following description of certain embodiments of the invention will be made with reference to the information of aggregated values V implemented as a range of aggregated values [Pmin, Pmax], only by way of illustration.

For a given set of services, the aggregated timestamp value refers to the most recent timestamps among the timestamps associated with the service sets that correspond to leaf nodes below node 80.

By aggregating at each node of the tree the data related to the service sets associated with the leaf nodes located below the node, the costs of calculating the estimate of ancillary services can be reduced.

In one embodiment, in response to a pre-transaction request specifying a given set of services, the service estimator 102 can be configured to explore the data structure in tree 8 according to a search algorithm [for example an algorithm best-first search to determine a corresponding node having a path in the tree that corresponds to the parameters of a pre-transaction request and to search for a leaf node in the sub-tree of the corresponding node which corresponds to the given set of services and which has a frequency of occurrence satisfying a threshold condition at the lowest possible level of the tree data structure. The product associated with the given set of services is thus defined by the path from the root node to the corresponding node. The service estimator 102 can determine the service value information from the data included in the determined leaf node. In one embodiment, the frequency of occurrence of a leaf node can be determined to satisfy the threshold. If the frequency of occurrence is greater than or equal to a predefined threshold.

More specifically, the service estimator 102 can be configured to search for a leaf node n _L ^k in the sub-tree of the corresponding node which corresponds to the service given at the last possible level L of the tree data structure and having enough d 'occurrences [i.e. that the leaf node has a frequency of occurrence that satisfies the threshold condition].

In one embodiment, to determine the service value information, if it is determined that a tree leaf n _L ^k at a level L (with L> N) corresponds to the given set of services { [service 1] and [service 2] and ... [service p]}, the service estimator 102 can be configured to determine the range of values of the set of services (price of the set of services) associated to the set of services {[service 1] and [service 2] and ... [service p]} in the leaf of the tree n ^k during the past period T.

The value range of the set of services can therefore correspond to the price range paid by users for this product during the past period T.

For example, a price range of [34 euros - 41 euros] can be associated with the set of services {[animal service in cabin "] and [vegetarian meal service]}.

In some embodiments, the counterc _{U [} k associated with a leaf node of the tree can be used by the service estimator 102 to derive a statistical value representing the frequency of occurrence of a set of services during of the past period ?. For example, a frequency of occurrence of the set of services {[animal service in the cabin »] and [vegetarian meal service]} can be equal to 6% of the time.

In one embodiment, a tree reconstruction algorithm [also known as a “balancing algorithm”] can be applied to the tree data structure 8 to obtain a tree data structure as balanced as possible by starting at from any node. A tree is balanced here:

- For each node of the tree, the heights of the left subtree and the heights of the right subtree differ by more than one, and

- the subtree on the left is balanced, and

- the subtree on the right is balanced.

Returning to FIG. 3, the service experience learning unit 105 can be configured to capture the service value and the availability status of each auxiliary service associated with the products offered by the transaction system 12 using transactional data in real time. The service experience learning unit 105 can store the information collected in the form of a tree data structure of the service experience database 103. In some embodiments, the learning unit Service Experiments 105 can be configured to collect data on service requests when the MSP 11 fails to provide information.

The service experience learning unit 105 can be programmed to auto-organize the service experience database 103 according to a predefined period or automatically in response to the detection of an update condition.

In one embodiment, the service experience learning unit 105 can collect information from a tariff revision phase of the transaction flow, executed by the transaction system 12. As used in the present, the tariff revision refers to the phase preceding the validation of a transaction by a user during which a user is asked to revise the tariff information linked to a product purchase (before the step during which a user is asked to enter personal user information). In this phase, the context of a transaction request is known at the transaction system 12 level, thus making it possible to use the request parameter to update the tree data structure in the experience database. 103. This also makes it possible to collect information sufficiently late in the transaction flow to obtain a sufficiently specified product (for example a fixed route for a travel product) and thus collect precise service information. In addition, this allows information to be gathered early enough in the transaction flow to obtain maximum transaction traffic.

For each transaction request submitted to the transaction system 12, the service experience learning unit 105 can be configured to browse the tree of the service experience database 103 from the root node to the node -sheet, to determine if the parameters of the query correspond to a node value at each level until the last node before the leaves is reached i = N -1), the learning unit of experiences of service 105 being configured to update a node if a match is found or to create a new node if the parameter values are not created in the tree.

In particular, the service experience learning unit 105 can be configured to increment the counter associated with a node value of the tree, in response to the search for a correspondence between a parameter (e.g. , the website of an airline, the regulator carrier, the pair of places, etc.) of the request and the node value, thus allowing the storage of the full context in the tree.

In one embodiment, to determine if a match exists in the tree for a parameter (eg, an airline's website, the regulator, the pair of locations, etc.) of a given transaction request submitted to the transaction system 12 specifying a given product and a given set of services, the service experience learning unit 105 can determine if a sheet already exists for the given set of services in the tree which has an associated path corresponding to the parameters of the query relating to the product. If a match is found, the node corresponding to the sheet can be updated by incrementing the counter associated with the sheet. The service experience learning unit 105 can also be configured to store additional data associated with the service set such as the full context and one or more service set values (e.g., the elementary price for each service [service k] of the set of services). If no correspondence has been found between a sheet of the tree and the set of services specified in the transaction request, the service experience learning unit 105 can create a new sheet (new node) for the set of services of the transaction request, set the counter of the created node to 1. It can also store in the newly created thread additional data relating to the set of services such as the full context and one or more service bundle values (eg, the elementary price for each service [service k] in the service bundle).

In one embodiment, the service experience learning unit 105 can initiate a tree verification process to verify the tree configuration and identify if the tree is unbalanced, according to a verification period predefined, as with each M tree update. The verification process fails when an imbalance of the tree is detected. In some embodiments, a tree reconstruction algorithm can be applied to balance the tree.

In one embodiment, the tree verification period can be predefined by a system administrator. In some embodiments, the tree verification period can be updated during operation of the service experience learning unit 105 or dynamically adjusted according to the update criteria. If the service learning unit 105 detects that the tree is unbalanced, it can apply a balancing algorithm to rearrange the tree.

In certain applications of the invention, the conventional massive computing platform MCP 13 cannot pre-process all the possibilities of auxiliary services because of the complexity of the computation. In order to limit the costs of calculating the auxiliary service information (availability of the service, price of the service), the engine 1 for estimating the service, according to certain embodiments, may include a service popularity calculator 108. The service calculator service popularity 108 can be configured to calculate only recommendations for ancillary services associated with each product candidate among a subset of services ("popular service subset"), each service of the popular subset being selected from a popularity indicator calculated for the service that represents the probability of users requesting a service.

The service popularity calculator 108 can be configured to receive the context of the preprocessing request (also referred to as "recommendation" or "pre-transactional" request), and to use the tree data structure to determine the service sets most requested over a period of time (most popular services).

The service popularity calculator 108 can use the service experience database 103 to determine the popularity indicators associated with each service. In some embodiments, the service popularity calculator 108 may apply criteria (also referred to as "input context" for the service popularity calculator 108) associated with the products specified for each transaction system 12 to determine the popularity indicators (e.g. criteria associated with dates and / or length of stay, and / or airline, or city pair, etc. for a travel product). Consequently, the popularity indicator of a service can be set to a high value if the associated product is frequently requested over a given period of time.

In one embodiment, considering n types t1 of possible transactions ..., tn to request a set of services S, the popularity indicator can be determined from the popularity parameter (S) defined as:

Popularity (S) = Σ-Ξ ”Wjocci (1)

In formula (1), designate the weight associated with ti, occ, designate the frequency of occurrence of requests having the transaction type ti and having requested S over the period of time.

For example, when considering a travel supplier system, transaction types may include:

- a type T ₄ of request before the pre-purchase phase;

a type T ₂ of pre-purchase request;

a type T ₃ of price request;

As used herein, a "node context" for a given node refers to information defining the path to the node from the root node to the given node.

For each input context defined by the request criteria of a request received from the user, the service popularity calculator 108 can browse the data structure in tree 8 of the tree of the experience database. service 103 starting with the root node according to a tree search algorithm to find a node Nd ("current node") at the last possible level of the tree:

- having a child node corresponding to the request criteria (first condition) and a leaf node below the child node associated with a set of services having an frequency of occurrence which is at least equal to a predefined threshold Q ( second condition).

The service popularity calculator 108 can be configured to then determine the frequencies of occurrence c _n .k of all the sets of services ('pull' mode) or of the set of specified services ('push' mode) from of the currently selected Nd node. In certain embodiments, the service popularity calculator 108 can send the frequencies of occurrence of the set or sets of services thus determined to the MCP 11.

The MCP 11 can be configured to refine the input context by adding the sets of services determined by the service popularity calculator 108 and the frequency of occurrence associated with each set of services determined.

The service estimator 102 can be configured to determine ancillary services using historical data stored in the service experience database 103 for each recommended product (or candidate) provided by a transaction content processing system 12.

The service estimator 102 may receive an input from the service determination switching device 104 in response to a service estimation mode activated by the service determination switching device 104. The input sent by service determination services 104 to the service estimator 102 may include contextual data (e.g., ID Office, market for an exemplary application of the travel supply invention) from a request for recommendation submitted to the pre-transaction system 10, and the potential information associated with a set of auxiliary services comprising at least one service, if a “pull mode” is activated by the user (the user thus specifies in the recommendation request that he wishes recommendations for the product candidate associated with the set of auxiliary services). Alternatively, the processing of the service estimator 102 can be triggered dynamically in push mode, without the user specifying a set of services.

FIG. 6 is a flow diagram illustrating the process for determining the recommendation of a set of candidate services, which can be implemented by the service estimator 102, according to an embodiment in "pull" mode.

In step 600, an input is received from the service determination switching device 104 comprising contextual data defining the parameters of a requested product and the specification of a set of services originating from a recommendation request submitted by a user device to a pre-transaction processing device 10.

In step 602, the tree data structure 8 of the service experience database 103 is traversed using a tree search algorithm from the root node until a node Nd has been reached which satisfies all the node conditions (block 603) including:

- the first condition which is fulfilled if a child node of the node Nd has a context corresponding to the input context, or in other words, if this child node corresponds to the criteria of the request received from the user (request input); and

- the second condition which is fulfilled if the child node of the current node Nd has the specified set of services, and if the set of services is associated with an occurrence frequency greater than or equal to a minimum number Q.

In an implementation in ‘PULL’ mode, the query criteria used to evaluate the first condition include the set of services specified by the user.

The Q parameter designates the minimum number of occurrences. The Q parameter can be predefined, configurable by an administrator, or updated dynamically.

In one embodiment, to test the first condition, the data of the leaf nodes associated with each node can be used to optimize the cost of the search, the data of the leaf nodes 82 providing data relating to each set of services associated with a leaf-node in the sub-tree defined by a given node in the tree (e.g., for each set of services associated with a leaf-node in a sub-tree of the node, the frequency of occurrence Occ, range of price V, time stamp Ts). In this embodiment, each parent node aggregates the data of the set of services stored in the leaf nodes located below the parent node.

If the current node N _d satisfies the first and second conditions, the search in the tree continues (step 604).

Otherwise, if the first and second conditions are not met, the last node Nd traversed is selected, and in step 606, the range of unit prices [Pmin; Pmax] of the set of services requested can be determined from the service value information associated with the set of services in the aggregated data associated with the node N _d or retrieved from a storage memory if the range has been pre-calculated. Each unit price range [Pmin-, Pmax] may include a lower limit Pmin representing the minimum price of the elementary services which constitute the set of services requested and an upper limit Pmax representing the maximum price of the elementary services which constitute the set of services.

In step 608, the unit price range [Pmin; Pmax] determined for the requested set of services, from the data structure in tree 8, can be returned to the service determination switching device 104.

The method may also comprise step 610 of incrementing the frequency of occurrence associated with the set of services in the corresponding leaf node, and updating accordingly the aggregated data associated with the nodes in the upper levels of the tree of this leaf node.

FIG. 7 is a flow diagram illustrating the process for determining a list of candidate service sets, which can be implemented by the service estimator 102, according to an embodiment in "push" mode.

In push mode, no service set is specified in the recommendation request submitted to the pre-transaction system 10.

The parameters of the push modes can be predefined such as the maximum number of service sets returned to the user.

In step 700, an input is received from the service determination switching device 104 comprising contextual data defining the parameters of a requested product originating from a recommendation request submitted by a user device to a processing device pre-transaction 10, without specifying any set of services (MODE 'PUSH'). The entry may also include the expected number N of service packages to be pushed.

The steps 702 to 704 are similar to the steps 602 to 604 of FIG. 6. However, since no set of services is specified in the entry request in 'push' mode, the criteria of the request used to determine a node -wires in step 702 (first condition) do not include a specified set of services.

Consequently, in step 702, the tree data structure 8 of the service experience database 103 is traversed using a tree search algorithm from the root node until a node Nd has been reached which satisfies all the node conditions (block 703) including:

- the first condition which is fulfilled if a child node of the node Nd has a context corresponding to the input context, or in other words, if this child node corresponds to the criteria of the request received from the user (request input); and

- the second condition, which is fulfilled if the child node of the current node Nd has at least N sets of services associated with an occurrence frequency greater than or equal to a minimum number Q.

This makes it possible to select the node Nd which satisfies the first and second conditions at the lowest possible level of the tree.

If the first and second conditions are not fulfilled, the last node Nd traversed satisfying the two conditions is selected.

In step 706, the frequencies of occurrence of the sets of services associated with the leaf nodes located under the selected node Nd can be determined, using for example the data of the leaf node 82 associated with the node Nd. In some embodiments, if two different service sets have the same frequency of occurrence, the time stamp associated with the service sets can be used to select the service set having the last time stamp (for which a tariff value has been determined more recently).

In step 708, one or more sets of services can be selected according to the frequency of occurrence associated with the sets of services. This provides a filtered list of service sets (the most popular service sets). In one embodiment, step 708 may include selecting the sets of services associated with an occurrence frequency greater than or equal to a predefined threshold.

In step 710, the unit price range [Pmin; Pmax] associated with each set of services selected in step 708 can be determined, for example from the data of the leaf nodes 82. Each unit price range [Pmin; Pmax] has a lower limit Pmin representing the minimum price of the set of services and an upper limit Pmax representing the maximum price of the set of services over the completed period T.

Instead of determining the frequencies of occurrence and the price ranges of steps 706 to 710 from the leaf node data 82 associated with the current node Nd, in some embodiments, the tree can be traversed multiple times, particular for each set of services, to determine more precisely this information directly from the leaf nodes.

In step 712, the frequencies of occurrence and the unit price range [Pmin; Pmax] determined for each set of services in the list of selected service sets can be returned to the service determination switching device 104. The most popular ancillary services and the price estimates of the services associated with these ancillary services are therefore determined in the input context.

While in the embodiment of the 'pull' mode of Figure 6, the frequency of occurrence and the price range are returned for a single set of services corresponding to the set requested, in the embodiment of the mode ' push 'shown in Figure 7, the frequency of occurrence and the price range are determined for the list of selected service packages.

FIG. 8 is a diagram illustrating the process of the service estimation exchange mode which can be implemented by the service determination switching device 104, according to certain embodiments.

In step 800, a client request (also known as a “pre-transaction” or a “recommendation” request) is received by the pre-transaction system 10 of a user device 2.

If the client request is received in 'pull' mode (block 801), that is to say that the recommendation request specifies a particular set of services, in step 802, it is determined whether the set of services specified has already been processed for similar products using parameters linked by the recommendation request (e.g., in an application of the invention to the travel product, it can be determined whether the specified set of services has already been processed for the same route [defined by an origin / destination]). In one embodiment, this step can be carried out by a preprocessing coordinator 130 provided in the MCP 11 in response to a call from the service determination switching device 104.

If it is determined that a request for the service set has already been made, in step 804, the data relating to the service set can be retrieved from the preprocessed (or precomputed) data using the massive search platform (MSP) 13 or from the service estimator 102.

Otherwise, the contextual service data linked to the recommendation request and the specified set of services can be sent to the service estimator in step 806.

If the recommendation request is received in 'push' mode (block 801), that is to say the recommendation request does not specify any set of services in particular, in step 806, the service estimator 102 can to be called. This includes transmitting contextual service data associated with the recommendation request and the specified set of services to the service estimator 102. The service estimator 102 can determine the most popular ancillary services and the estimated service prices. associated with auxiliary services, as described in relation to Figure 6.

In one embodiment, it is also possible to call on the preprocessing coordinator 130 to determine whether the sets of services returned by the service estimator 102 (the most popular auxiliary services) have already been pretreated using data. in real time (by MCP 13) in the example of a travel product. If so, the estimated prices associated with the service packages returned by the service estimator 102 can be replaced by these pretreated prices (precise service price).

FIG. 9 is a diagram illustrating the process of predetermining the service sets which can be implemented by the preprocessing coordinator 130 of the MCP 13 to supply the massive repository 113, for all the origin / destination points and the set of services, at minimum cost, according to certain embodiments.

In step 900, a transaction request (client request) is received by a transaction system 12. All of the j mandatory request parameters predefined for the format of the transaction request (eg route, date departure, length of stay for a travel request) and defined by a tuple is assumed to be known (it can be filled in by the user or the transaction system 12). The client request can also comprise sets of auxiliary services to be preprocessed, for each of the j parameters of the request.

In one embodiment, a preprocessing of the K most popular service sets can be determined by the service popularity calculator 108 using the popularity indicators determined for each service set, for all of the above j - tuple to l step 902. Furthermore, the preprocessing can be carried out for a set of specific auxiliary services specified in the request for the transaction by a client.

In order to minimize the cost of the calculation, the preprocessing can include the following steps:

-In step 904, the massive search platform (MSP) 13 can be called to retrieve the value of the product (price) associated with the products (eg the itineraries for a travel request) identified by the request customer, regardless of service values (price of service);

- In step 906, the MCP 16 service can be called to calculate the price of the services for all the services specified in the customer request, in independent mode (regardless of the product);

- In step 908, for the price of each product and for each service requested by the customer request, a service correlation step can be performed to determine if the services priced in independent mode can be added to the price of the product. If so, the total price of the product (which includes the main product and the defined service) can be returned to step 910. In one embodiment, the amount thus determined can be stored in the massive repository 113, at step 912;

- In step 909, if the services priced in independent mode cannot be added to the price of the product (service price applicable to the price of the product), a correlated price can be determined (for the product and the defined service) by the MCP product 13. The result thus obtained can be kept in the massive repository 13 in step 912.

The process of performing service correlation can be performed by a Correlator Service 18 (shown in Figure 3). The service correlator 18 can be configured to determine whether an independent service price can be attached to a product price (e.g., route price). The service correlator 18 can provide a correlation service to the preprocessing coordinator 130.

FIG. 10 is a diagram illustrating the correlation process between the services implemented by the correlator Service 18, according to certain embodiments.

In step 950, an input is received which includes information associated with a product (eg, complete itinerary) and a service to be associated with product prices.

In step 952, the result of the MCP 16 of services is used to extract (or recover), for the requested service, the independent price of the service and additional data associated with the service.

In step 954, it is determined whether the price associated with the service is applicable to the prices of the products (that is to say valid) by using a precalculated applicability indicator for the service (the applicability indicator can also be called "validity indicator"). If so, the price of the service is returned to the pretreatment coordinator 130 in step 956. Otherwise, if it is determined that the service is not applicable to the price of the product, no price is returned to the coordinator pretreatment 130.

The MCP 16 of services can be configured to determine an applicability indicator in association with each service in a preprocessing phase, in an “independent” operating mode (independently of any request for recommendation and therefore independently of any product context) . The correlating service 18 can use this applicability indicator to determine the applicability of a service price to a product price (as described in the context of Figure 9).

In one embodiment, the service MCP 16 may include a price database for storing the independent service price and the applicability indicators associated with the services.

For each independent service price requested by the preprocessing coordinator 130, the service MCP 16 can be configured to calculate the service price, using predefined rules and / or assumptions. The service MCP 16 may store the independent price determined for the service in association with the service in the service price database of the service MCP 16, and possibly other constraints related to the service (eg "geography" , "Cabin", "price", "flight restriction" in an application of the invention to the supply of travel). These additional constraints can be used to determine a correspondence with product prices.

The pre-transaction system 10 according to the embodiments of the invention makes it possible to provide recommendations for auxiliary services to client devices, in a pre-transaction phase, while limiting the computation costs necessary to produce these service recommendations. This thus allows a reduction in the requests from users subjected to the transaction system 12, the user collecting sufficient information during the pre-transaction phase to better define the requests to be submitted to the transaction system 12. Consequently, the end user does not need to go back and forth in the transaction flow implemented by the transaction system to detect if a desired service is available and / or if a desired service is too expensive. The load of the transaction system 12 can thus be considerably reduced. Furthermore, the pre-transaction system 10 according to the embodiments of the invention is capable of providing exact information to the user during the pre-transaction phase.

Referring now to FIG. 11, the different blocks of the pre-transaction system 10 and the devices 2 of the user of the operating environment can be implemented on one or more computer devices or systems, collectively called computer, such as the computer 30. The computer 30 may include a processor 32, a memory 34, a mass storage memory device 36, an input / output interface (I / O), and a man-machine interface (HMI) 39. The computer 30 can also be operatively coupled to one or more external resources 42 via the network 6 (which may be the network 21 for example) and / or the I / O interface 38. The external resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud network services (cloud), or any other computing resource suitable for use with computer 30.

Processor 32 may include one or more devices selected from microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, programmable door networks, programmable logic devices, state machines , logic circuits, analog circuits, digital circuits, or any other device used to manipulate signals (analog or digital) from operating instructions which are stored in memory 34. Memory 34 can include a single device or a plurality of memory devices, including, but not limited to, read only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM) , dynamic random access memory (DRAM), flash memory, cache memory or any other device capable of storing information rmation. The mass memory device 36 can include data storage devices such as a hard disk, an optical disk, a magnetic tape drive, a volatile or non-volatile solid state circuit, or any other device capable of store information. A database 44 can reside on the mass memory device 36, and can be used to collect and organize the data used by the various systems and modules described herein.

The processor 32 can operate under the control of an operating system 46 which resides in the memory 34. The operating system 46 can manage the resources of the computer in such a way that the program code of the computer, integrated in the form of one or more application software, such as the application 48 which resides in the memory 34, can have instructions executed by the processor 32. In an alternative embodiment, the processor 32 can execute directly application 48; in this case the operating system 46 can be omitted. One or more data structures 50 can also reside in memory 34, and can be used by processor 32, operating system 46, or application 48 to store or manipulate data.

The I / O interface 38 can provide a machine interface which couples the processor 32 functionally with other devices and systems, such as the network 6 or the external resource 42. The application server 48 can thus collaborate with the network 6 and / or with the external resource 42 by communicating via the I / O interface 38 to provide the various elements, functions, applications, processes, modules making up the embodiments of the invention. The application 48 can also include a program code which is executed by one or more external resources 42, or is otherwise based on the functions and / or signals provided by other system or network components external to the computer 30. In Indeed, in view of the almost infinite configurations of possible computer hardware and software, those skilled in the art will understand that the embodiments of the invention can include applications located outside of computer 30, distributed to multiple computers. or to other external resources 42 or supplied by IT resources (hardware and software) which are supplied by a service such as a cloud IT service, via the network 6.

The HMI 39 (such as the HMI 30 in the implementation of FIG. 1 of the client device 3) can be operatively coupled to the processor 32 of the computer 30 in a known manner to allow a user of the computer 30 interact directly with the computer 30. The HMI 39 can include a video and / or alphanumeric display, a touch screen, a loudspeaker and any other visual and audio indicator capable of communicating data to the user. The HMI 39 can also include input devices and controls such as an alphanumeric keyboard, pointing device, keyboards, push buttons, control buttons, microphones, etc., capable of accepting user commands or input, and pass them to processor 32.

A database 44 can reside on the mass memory device 36, and can be used to collect and organize the data used by the various systems and modules described herein. The database 44 can include data and accommodate the associated data structures that store and organize the data. In particular, the database 44 can be set up with any database organization or structure, in particular, but not limited to, a relational database, a hierarchical type database, a networked database, an object-oriented database, or combinations thereof. A database management system in the form of application computer software which is executed in the form of instructions on the processor 32 can be used to access information or data stored in files of the database. data 44 in response to a query, when a query can be dynamically determined and executed by the operating system 46, other applications 48, or one or more modules. Although embodiments of the invention may be described herein using relational, hierarchical, network, object-oriented, or other terminology in specific cases, those skilled in the art will understand that Embodiments of the invention may use any suitable database management model, and are not limited to any particular type of database.

While the invention has particular advantages for content provider systems supporting queries with at least some query parameters associated with a date, time and / or location, such as a travel provider system, Those skilled in the art will readily understand that the invention is not limited to these content provider systems and that it can be applied to various content provider systems.

In general, the routines executed to implement the embodiments of the invention, whether they are implemented within the framework of a specific operating system or application, of a component, of a program, of an object, module, or sequence of instructions, or even a subset of them, may be referred to herein as "computer program code" or simply "program code". Program code typically includes computer readable instructions which reside at various times in various memory and storage devices in a computer and which, when read and executed by one or more processors in a computer, bring the computer to perform operations necessary for the execution of operations and / or elements specific to the implementation of the various aspects of the embodiments of the invention. The instructions of a program, readable by computer, to carry out the operations of the embodiments of the invention can be, for example, the assembly language, or even a source code or an object code written in combination with one or several programming languages.

Various program codes described herein can be identified, depending on the application in which they are implemented, in specific embodiments of the invention. However, it should be noted that any nomenclature of a particular program herein is used only for convenience; thus the invention cannot be limited to a single use in any specific application identified and / or implied by said nomenclature. Furthermore, in view of the generally infinite number of means by which computer programs can be organized according to subroutines, procedures, processes, modules, objects, and so on, as well as the various ways of affecting the functionality of a program among various layers of software that are resident on a typical computer [p. eg, operating systems, libraries, program application interfaces (APIs), applications, small applications "(applets)], etc .; it will be noted that the embodiments of the invention are not limited to the specific organization and to the specific allocation of the program functionalities as described herein.

The program code implemented in any application / module described herein may be distributed individually or collectively as a computer program product, in a variety of forms. In particular, the program code can be distributed using a computer-readable storage medium, having computer-readable program instructions per se, allowing a processor to implement aspects of the embodiments of the invention .

The computer-readable storage media, being intrinsically non-transitory, can include volatile and non-volatile, removable and non-removable tangible media, implemented in any process or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer readable storage media may also include random access memory (RAM), read only memory (ROM), read only, programmable and erasable memory (EPROM), read only memory, programmable and erasable electrically (EEPROM), flash memory, or any solid memory support technology, (a portable compact disc with read-only memory (CD-ROM), or any other optical storage, magnetic tapes, recording tapes magnetic disk, magnetic storage disk, other magnetic storage devices, or any other medium which can be used to store the desired information and which can be read by a computer A computer-readable storage medium cannot be interpreted as transient signals in self (e.g. radio waves or other propagating electromagnetic waves, electromagnetic waves propagating p through a transmission medium such as a waveguide, or electrical signals transmitted by cable). Computer-readable program instructions can be downloaded to a computer, another type of programmable data processor, or any other computer-readable storage medium, or to an external computer or to an external storage device through a network.

Computer readable program instructions, recorded on computer readable media, can be used to cause a computer, other types of programmable data processing devices, or other devices, to operate in a particular way , so that the instructions stored on the computer-readable medium produce an article of manufacture including the instructions that implement the functions, actions and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams. The computer program instructions may be supplied to one or more processors of a general purpose computer, a dedicated computer or other programmable data processing apparatus to produce a machine, so that the instructions, when executed in using the processor (s), perform a series of calculations to implement the functions, actions, and / or operations specified in the flowcharts, sequential diagrams and / or block diagrams.

Although the invention has been illustrated by a description of various embodiments and although these embodiments have been described in great detail, it is not the intention of the applicant to restrict or limit, in any way however, the scope of the claims herein to these details. Additional advantages and possible modifications will be readily apparent to those skilled in the art. While the embodiments of FIGS. 6 to 10 have been described according to a particular order of treatment, those skilled in the art will readily understand that the invention is not limited to such a succession of steps and that measurements can be taken. applied in a different order. More generally, in certain other embodiments, the functions, actions and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams can be reordered, processed in series, and / or processed at the same time. in collaboration with embodiments of the invention. In addition, any flowchart, sequential diagram, and / or block diagram can include more or less blocks than those which are illustrated, while remaining consistent with the embodiments of the invention.

Claims (16)

1. A server system (10) configured to determine a list of products in response to a client request from a client device during a request / response session, the client request comprising one or more request parameters, said system server comprising a product estimator (11) configured to determine a list of main products, said list of main products comprising an estimate of one or more main products corresponding to the customer request, in which the server system (10) also cooperates with an auxiliary product estimation database (103) configured to store historical data relating to sets of auxiliary products, said historical data being represented by a tree data structure (8) composed of nodes, the server system further comprising an auxiliary product estimator (102) configured to determine from e the tree structure of a frequency of occurrence and information of value of the auxiliary product for each set of auxiliary products in a list of sets of auxiliary products, in response to the customer request, the list of sets of products auxiliaries comprising at least one set of auxiliary products, the server system being configured to also provide a list of candidate auxiliary products for each main product determined in response to the customer request using the frequency of occurrence and the value information of auxiliary product determined for each set of auxiliary products from said list of sets of auxiliary products. 2. Server system according to claim 1, in which said request is received at a given processing time, and in which each set of auxiliary products identifies one or more auxiliary products associated with a main product, said historical data comprising data collected from starting from previous request / response sessions, each previous request / response session being implemented between a client device and a product supplier system linked to said auxiliary product estimation database over a predefined period of time before said treatment. 3. Server system according to claim 1, in which the tree data structure (8) comprises a root node and a plurality of levels, each level of the tree data structure corresponding to a parameter derived from one or more request parameters, each node of a given level of the tree data structure comprising a node value representing a value of the parameter corresponding to said level, said value being assigned to the request parameter in said one or more previous request / response sessions in said period of time, the last level of each branch of the tree comprising leaf nodes, each leaf node corresponding to a given set of auxiliary products. 4. Server system according to claim 3, in which each leaf node of the tree data structure corresponding to a set of auxiliary products also comprises a counter value and value information, said counter value indicating the number of occurrences of said set of auxiliary products in said previous request / response sessions, the auxiliary product estimator (102) being configured to determine the frequency of occurrence of each set of auxiliary products from said list of sets of auxiliary products in using the counter value of the leaf node corresponding to said set of auxiliary products in said tree data structure, the auxiliary product estimator (102) being further configured to determine the value information of the auxiliary product for each set of auxiliary products from said list of sets of auxiliary products to p from the value information of the leaf node corresponding to the said set of auxiliary products in the tree data structure. 5. Server system according to claim 4, wherein said value information included in each leaf node corresponding to a given set of auxiliary products comprises a range of values defined by a lower threshold and an upper threshold, the lower threshold representing the value assigned to the set of auxiliary products in a previous request / response session during said predefined period of time and the upper threshold representing the highest value assigned to the set of auxiliary products in a request / response session previous during said predefined time period. The server system according to claim 5, in which, if the client request includes a request parameter specifying a given set of auxiliary products, said list of sets of auxiliary products comprises said set of auxiliary products, the estimator of auxiliary product ( 102) being configured to browse the data structure in a tree according to a tree search algorithm to determine a corresponding node having a path in the tree corresponding to the query parameters of the client query, the auxiliary product estimator (102 ) being further configured to search for a leaf node in a sub-tree of the corresponding node which corresponds to said given set of auxiliary products and a threshold condition related to the frequency of occurrence of the leaf node, the frequency of occurrence and the auxiliary product value information of the single set of auxiliary products being removed from the said leaf node. The server system of claim 5, wherein, if the client request does not include a request parameter specifying a defined set of auxiliary products, the auxiliary product estimator (102) is configured to traverse the data structure in a tree. according to a tree search algorithm to determine a corresponding node having a path in the tree corresponding to the customer request parameters, the auxiliary product estimator (102) being further configured to search all the leaf nodes in a sub - tree of the corresponding node, the auxiliary product estimator (102) being configured to determine a popularity indicator of the set of auxiliary products associated with each leaf node found and to choose one or more sets of auxiliary products from the sets ancillary products associated with said leaf nodes found according to said popularity indicators, the Said selected sets of auxiliary products being added to said list of sets of auxiliary products, the frequency of occurrence and the value information of each set of auxiliary products in said list of sets of auxiliary products being removed from the corresponding leaf node. The server system of claim 7, wherein the system includes an auxiliary product popularity calculator (108) configured to determine the popularity indicator of each set of auxiliary products of a leaf node using the frequency of occurrence associated with the leaf node. The server system according to any of the preceding claims, wherein the system includes a preprocessing coordinator (130) configured to update the value information estimated by the auxiliary product estimator (102) for each set of products. auxiliaries from the list of auxiliary product sets based on real-time data. 10. Server system according to any one of the preceding claims, in which the system comprises an auxiliary product correlator (8) configured to integrate the auxiliary product value information of each set of auxiliary products from the list of sets of products. auxiliary to the value of a main product determined by the product estimator (11), according to an applicability indicator. 11. Server system according to any one of the preceding claims, in which the system further comprises an auxiliary product learning engine (105) configured to collect learning metadata during a predefined learning period, the system further comprising a tree manager (800) for managing the tree data structure using collected training metadata. The server system of claim 11, wherein the tree manager (800) is configured to create a node in the tree data structure in response to the specification of a new value of a parameter corresponding to a level of the tree, in a request / response session in real time, and to set the counter value of said node to the value 1. 13. The server system of claim 11, wherein the tree manager is configured to update a node in the tree data structure each time the value associated with said node is specified in a request / response session. for the parameter corresponding to the level of the nodes, and to increment the counter value of said node. 14. Server system according to any one of the preceding claims 11 to 13, in which the tree manager is configured to periodically check the configuration of the tree data structure and to apply a balancing algorithm to the data structure in tree, if the data structure in tree is unbalanced. 15. Method for determining a list of products in response to a client request from a client device during a request / response session, said client request comprising one or more request parameters, said method comprising a * step determining a list of main products, said list of main products comprising an estimate of one or more of the main products corresponding to said customer request, in which the method also comprises determining a frequency of occurrence and auxiliary product value information for each set of auxiliary products in a list of sets of auxiliary products, from a tree data structure representing historical data associated with sets of auxiliary products, in response at customer request, the list of sets of auxiliary products comprising at least one set of auxiliary products, said tree data structure comprising nodes, the method further comprising providing a list of candidate auxiliary products for each main product determined in response to the customer request using the frequency of occurrence and l auxiliary product value information determined for each set of auxiliary products from said list of sets of auxiliary products. 16. Computer program for determining a list of products in response to a customer request from a client device during a request / response session, said customer request comprising one or more request parameters, the computer program product comprising: a non-transient storage medium for computer-readable data; and a program code recorded on the non-transient computer-readable storage medium which, when executed by one or more processors, causes the processor (s) to: -determine a list of main products, said list of main products comprising an estimate of one or more of the main products corresponding to said customer request, in which said one or more processors are also required to: - determine a frequency of occurrence and value information of the auxiliary products for each set of auxiliary products in a list of sets of auxiliary products, from a tree data structure representing the historical data associated with the sets of products auxiliaries, in response to the client request, the list of sets of auxiliary products comprising at least one set of auxiliary products, said tree data structure comprising nodes, Said one or more processors being led to supply a list of candidate auxiliary products for each main product determined in response to the customer request using the frequency of occurrence and the auxiliary product value information determined for each set of auxiliary products of said list of sets of auxiliary products.