Brevet FR3057084A1 — publié le 20180406

TRAITEMENT DES REQUÊTES DE RECHERCHE DOMAINE TECHNIQUE [0001] L'invention présente concerne de façon générale le traitement des requêtes de recherche et, plus précisément des systèmes, des procédés et des produits-programmes informatiques pour générer des notifications pour des requêtes de recherche soumises et enregistrées antérieurement. CONTEXTE [0002] Internet a permis un niveau d'accès à l'information jadis impossible à atteindre. Dans la société post Internet, par exemple, lorsqu'un utilisateur souhaite obtenir des informations liées à un sujet précis, tel que la disponibilité de vols d'avions entre une origine et une destination à des dates spécifiques, il lui suffit de soumettre une requête décrivant l'objet de la recherche sur un moteur de recherche Internet. En réponse à la réception de la requête de recherche, le moteur de recherche peut parcourir des sources de données diverses sur Internet à la recherche de données pertinentes pour la requête, traiter les données, et délivrer les données traitées à l'utilisateur. Alternativement, le moteur de recherche peut rechercher et mettre en antémémoire des données en provenance de sources de données diverses avant même de recevoir la requête de recherche puis fournir les données en antémémoire à l'utilisateur lorsque la requête de recherche est reçue. Quelle que soit l'approche, du point de vue de l'utilisateur, le moteur de recherche Internet apporte à l'utilisateur un accès presque instantané à plusieurs sources de données distantes via une passerelle unique. [0003] En dépit de ces avantages, certains problèmes surviennent lorsqu'Internet est utilisé pour explorer des sources de données distantes. Par exemple, bien que le volume de données disponibles sur Internet soit massif, la quantité de ressources informatiques et d'infrastructure Internet disponibles pour la communication, le stockage et le traitement de ces données est relativement limitée. Par conséquent, le rapport entre la vitesse du temps réponse et la livraison de résultats exhaustifs et corrects pour chaque requête de recherche est tendu. En outre, les sources de données Internet peuvent être affectées ou modifiées par des traitements informatiques provenant d'un certain nombre d'utilisateurs, en pratique de toute localisation géographique et à tout moment, les données renvoyées par un moteur de recherche Internet peuvent être désuètes ou le devenir. rapidement. [0004] Il existe par conséquent un besoin pour des systèmes, des procédés et des produits- programmes informatiques améliorés pour la mise à jour de requêtes de recherche soumises et enregistrées précédemment et pour générer des notifications sur cette base. 3057084 2 RÉSUMÉ [0005] Dans un mode de réalisation exemplaire, un procédé pour le traitement d'une requête de recherche inclut la réception d'une requête de recherche par un ou par plusieurs processeurs d'ordinateur et 5 l'enregistrement par un ou plusieurs processeurs d'ordinateur de la requête de recherche sur un ou plusieurs dispositifs de stockage permanents. Par la suite, et de façon périodique et automatique, un ou plusieurs processeurs récupèrent la requête de recherche dans un ou plusieurs dispositifs de stockage permanents, récupèrent à l'aide d'un algorithme d'optimisation itérative la donnée de source associée à la requête de recherche à partir d'une ou de plusieurs sources de données dorsales (backend data) et génèrent 10 des réponses pour la requête de recherche sur la base de la donnée de source récupérée. Le procédé inclut par ailleurs le fait de déterminer si chacune des réponses est éligible à la notification sur la base des critères de recherche inclus dans la requête de recherche, et de notifier à un utilisateur chaque réponse déterminée comme étant éligible à la notification. [0006] Dans certains modes de réalisation, la requête de recherche peut inclure un point 15 d'interruption et les opérations peuvent être effectuées de façon périodique et automatique jusqu'à ce que le point d'interruption soit atteint. Dans certains modes de réalisation, une ou plusieurs sources de données dorsales peuvent inclure de multiples sources de données dorsales ainsi que la récupération de la première donnée de source à partir d'une ou de plusieurs sources de données dorsales en utilisant l'algorithme d'optimisation itérative peut inclure de récupérer la première donnée dorsale à partir d'une ou de plusieurs 20 sources de données dorsales sur la base d'un premier critère parmi des critères de recherche. De plus, la récupération de la première donnée de source peut inclure le filtrage de la première donnée dorsale sur la base d'un premier seuil de satisfaction et d'une première portion des critères de recherche qui sont pertinents pour la première donnée dorsale, la récupération de la seconde donnée dorsale à partir d'une ou de plusieurs sources de données dorsales et le filtrage de la seconde donnée dorsale sur la base d'un second 25 seuil de satisfaction et d'une seconde portion de critères de recherche pertinents pour la seconde donnée dorsale. La première donnée de source peut être basée sur la première donnée dorsale filtrée et sur la seconde donnée dorsale filtrée. [0007] La première donnée dorsale peut inclure de multiples résultats, et le filtrage de la première donnée dorsale sur la base du premier seuil de satisfaction et de la première portion de critères de 30 recherche pertinents pour la première donnée dorsale peut inclure l'application d'une ou de plusieurs premières fonctions floues, dérivées de la première portion de critères de recherche, à chacun des premiers résultats pour calculer une première valeur de satisfaction pour chaque premier résultat. Le filtrage de la première donnée dorsale peut aussi inclure la comparaison de la première valeur de satisfaction pour 3057084 3 chaque premier résultat avec le premier seuil de satisfaction, et le filtrage des premiers résultats en déterminant, comme seconds résultats, chaque premier résultat dont la première valeur de satisfaction est supérieure au premier seuil de satisfaction. De plus, chacun des critères de recherche de la requête de recherche peut être associé à un poids, et chacune d'une ou de plusieurs premières fonctions floues peut 5 être associée avec un critère de la première portion de critères de recherche. Dans ce cas, l'application d'une ou de plusieurs premières fonctions floues à chacun des premiers résultats pour calculer la première valeur de satisfaction pour chaque premier résultat peut inclure la multiplication d'un résultat de chaque première fonction floue avec le poids associé au critère de recherche qui est associé à la première fonction floue respective. 10 [0008] Le filtrage de la première donnée dorsale peut par ailleurs inclure l'application d'une ou de plusieurs secondes fonctions floues, dérivées d'une troisième portion de critères de recherche pertinents pour la première donnée dorsale, à chacun des seconds résultats afin de calculer une seconde valeur de satisfaction pour chaque second résultat ; Le filtrage de la première donnée dorsale peut aussi inclure la comparaison de la seconde valeur de satisfaction pour chaque second résultat avec un troisième seuil de 15 satisfaction et le filtrage des seconds résultats en déterminant, comme troisièmes résultats, chaque second résultat dont la seconde valeur de satisfaction est supérieure au troisième seuil de satisfaction. La première donnée dorsale filtrée peut inclure les troisièmes résultats. [0009] De plus, la seconde donnée dorsale peut inclure de multiples résultats et le filtrage de la seconde donnée dorsale sur la base du second seuil de satisfaction et de la seconde portion de critères de 20 recherche pertinents pour la seconde donnée dorsale peut inclure l'application d'une ou de plusieurs fonctions floues, dérivées de la seconde portion des critères de recherche, à chacun des résultats pour calculer une valeur de satisfaction pour chaque résultat. Le filtrage de la seconde donnée dorsale peut aussi inclure la comparaison de la valeur de satisfaction pour chaque résultat avec le second seuil de satisfaction et le fait de déterminer chaque résultat dont la valeur de satisfaction est supérieure au second 25 seuil de satisfaction. La seconde donnée dorsale filtrée peut inclure chaque résultat déterminé. [0010] Dans certains modes de réalisation, la génération des réponses pour la requête de recherche sur la base de la première donnée de source peut inclure le calcul d'une valeur de satisfaction pour chaque réponse sur la base des critères de recherche. Dans ce cas, la détermination de l'éligibilité à la notification de chacune des réponses sur la base des critères de recherche peut inclure, pour chaque réponse, le fait de 30 déterminer si la valeur de satisfaction pour la réponse respective est supérieure au seuil de notification, et en réponse à la détermination selon laquelle la valeur de satisfaction pour la réponse respective est supérieure au seuil de notification, le fait de signaler que la réponse respective est éligible à une notification supplémentaire. En réponse à la détermination selon laquelle la valeur de satisfaction pour la 3057084 4 réponse respective est inférieure au seuil de notification, la détermination de l'éligibilité à la notification de la réponse respective peut inclure le fait de déterminer si la réponse respective fait partie d'un sous-ensemble de réponses. La valeur de satisfaction pour chacune des réponses dans le sous-ensemble de réponses peut être supérieure à la valeur de satisfaction pour chacune des réponses qui ne font pas partie 5 du sous-ensemble. En réponse à la détermination selon laquelle la réponse respective fait partie du sous- ensemble, la réponse respective peut être signalée comme étant éligible à une notification périodique. En réponse à la détermination selon laquelle la réponse respective ne fait pas partie du sous-ensemble, la réponse respective peut être définie comme n'étant pas éligible à une notification. [0011] Dans certains modes de réalisation, le procédé inclut par ailleurs l'enregistrement des 10 réponses dans un ou plusieurs dispositifs de stockage permanents, et après l'enregistrement des réponses, la réception automatique via un mécanisme de pousse, ou la récupération via un mécanisme de tirage, de la seconde donnée de source à partir d'une ou de plusieurs sources de données dorsales concernant au moins une des réponses. Le procédé peut par ailleurs inclure la récupération d'une ou de plusieurs des réponses dans un ou plusieurs dispositifs de stockage permanents, la mise à jour d'une ou de plusieurs des 15 réponses récupérées sur la base de la seconde donnée de source et la détermination de l'éligibilité à la notification de chacune d'une ou de plusieurs réponses actualisées. Le procédé peut aussi inclure la notification à l'utilisateur de chacune des réponses actualisées déterminées comme étant éligibles à la notification. [0012] De plus, la détermination de l'éligibilité à la notification de chacune d'une ou de plusieurs 20 réponses actualisées peut inclure, pour chaque réponse actualisée, le fait de déterminer si la réponse actualisée respective inclut un abonnement. En réponse à la détermination selon laquelle la réponse respective actualisée inclut l'abonnement, la réponse respective actualisée peut être ajoutée à une liste d'attente de priorité élevée. En réponse à la détermination selon laquelle la réponse respective actualisée n'inclut pas l'abonnement, la réponse respective actualisée peut être ajoutée à une file d'attente de faible 25 priorité. La méthode peut inclure par ailleurs la détermination de l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente de priorité élevée et, par la suite, la détermination à l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente de faible priorité. [0013] La détermination de l'éligibilité à la notification de chacune des réponses dans la file d'attente de priorité élevée peut inclure pour chacune des réponses actualisées dans la file d'attente de 30 priorité élevée, le fait de déterminer si la réponse actualisée respective satisfait le seuil de notification d'un abonnement pour la réponse respective. En réponse à la détermination selon laquelle la réponse respective actualisée satisfait le seuil de notification d'abonnement pour la réponse respective, la réponse respective actualisée peut faire l'objet d'un signalement d'éligibilité à une notification d'abonnement. 3057084 5 Alternativement, en réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification d'abonnement pour la réponse respective, le procédé peut inclure de déterminer si la réponse actualisée respective satisfait le seuil de notification supplémentaire pour la requête de recherche. En réponse à la détermination selon laquelle la réponse actualisée respective satisfait le seuil de 5 notification supplémentaire pour la requête de recherche, la réponse actualisée respective peut faire l'objet d'un signalement d'éligibilité à la notification supplémentaire. En réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification supplémentaire pour la requête de recherche, le procédé peut inclure le fait de déterminer si la réponse actualisée respective satisfait un seuil de notification périodique pour la requête de recherche. En réponse à la détermination 10 selon laquelle la réponse actualisée respective satisfait un seuil de notification périodique pour la requête de recherche, la réponse actualisée respective peut faire l'objet d'un signalement d'éligibilité à une notification périodique. En réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification périodique pour la requête de recherche, le procédé peut inclure de déterminer que la réponse actualisée respective n'est pas éligible à la notification. 15 [0014] De façon similaire, la détermination de l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente de faible priorité peut inclure, pour chaque réponse actualisée dans la file d'attente de faible priorité, le fait de déterminer si la réponse actualisée respective satisfait un seuil de notification supplémentaire pour la requête de recherche. En réponse à la détermination selon laquelle la réponse actualisée respective satisfait un seuil de notification supplémentaire pour la requête de recherche, 20 la réponse actualisée respective peut faire l'objet d'un signalement d'éligibilité à la notification supplémentaire. En réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification supplémentaire pour la requête de recherche, le procédé peut inclure de déterminer si la réponse actualisée respective satisfait un seuil de notification périodique pour la requête de recherche. En réponse à la détermination selon laquelle la réponse actualisée respective satisfait un 25 seuil de notification périodique pour la requête de recherche, la réponse actualisée respective faire l'objet d'un signalement d'éligibilité à une notification périodique. En réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification périodique pour la requête de recherche, le procédé peut inclure de déterminer que la réponse actualisée respective n'est pas éligible à la notification. 30 [0015] Dans un autre mode de réalisation exemplaire, un système pour le traitement d'une requête de recherche inclut un ou plusieurs processeurs d'ordinateur et une mémoire stockant des instructions qui lors de l'exécution par un ou plusieurs processeurs d'ordinateur amènent le système, en réponse à la réception de la requête de recherche, à enregistrer la requête de recherche dans un ou plusieurs dispositifs 3057084 6 de stockage permanents. Par la suite, de façon périodique et automatique, lors de l'exécution, les instructions amènent le système à récupérer la requête de recherche dans un ou plusieurs dispositifs de stockage permanents, à récupérer, à l'aide d'un algorithme d'optimisation itérative, une donnée de source concernant la requête de recherche à partir d'une ou de plusieurs sources de données dorsales et à générer 5 une pluralité de réponses pour la requête de recherche sur la base de la donnée de source récupérée. Les instructions lors de l'exécution amènent par ailleurs le système à déterminer l'éligibilité à la notification de chacune des réponses sur la base des critères de recherche dans la requête de recherche et de notifier à un utilisateur chaque réponse déterminée comme étant éligible à la notification. [0016] Dans des modes de réalisation supplémentaires, lors de l'exécution, les instructions 10 stockées dans la mémoire peuvent amener le système à mettre en oeuvre l'une quelconque ou plusieurs des fonctions et/ou à implémenter l'une quelconque ou plusieurs des caractéristiques décrites ci-dessus relatives au procédé exemplaire. [0017] Dans un autre mode de réalisation exemplaire, un produit-programme d'ordinateur pour le traitement d'une requête de recherche inclut un support durable lisible par ordinateur et des instructions 15 stockées sur le support durable lisible par ordinateur qui, lors de l'exécution par un ou plusieurs processeurs d'ordinateur et en réponse à la réception d'une requête de recherche, amènent un ou plusieurs processeurs d'ordinateur à enregistrer la requête de recherche sur un ou plusieurs dispositifs permanents de stockage. Par la suite, lors de l'exécution, les instructions amènent un ou plusieurs processeurs d'ordinateur, de façon périodique et automatique, à récupérer la requête de recherche dans un ou plusieurs 20 dispositifs de stockage permanents, à récupérer, en utilisant un algorithme d'optimisation itérative, la donnée de source concernant la requête de recherche à partir d'une ou de plusieurs sources de données dorsales, et à générer une pluralité de réponses pour la requête de recherche sur la base de la donnée de source. Les instructions, lors de l'exécution, amènent par ailleurs un ou plusieurs processeurs d'ordinateur à déterminer si chacune des réponses est éligible à la notification sur la base des critères de recherche 25 inclus dans la requête de recherche et à notifier à un utilisateur chaque réponse déterminée comme étant éligible à la notification. [0018] Dans des modes de réalisation supplémentaires, les instructions stockées sur le support durable lisible par ordinateur peuvent, lors de l'exécution, amener un ou plusieurs processeurs à effectuer l'une quelconque ou plusieurs des fonctions et/ou à implémenter l'une quelconque ou plusieurs des 30 caractéristiques décrites ci-dessus, relatives au procédé exemplaire. [0019] Le résumé ci-dessus présente une vue d'ensemble simplifiée de certains des modes de réalisation de l'invention afin d'apporter une compréhension basique de certains aspects de l'invention faisant l'objet d'une discussion dans les présentes. Le résumé ne prétend pas apporter une vue d'ensemble 3057084 7 exhaustive de l'invention et n'est pas destiné à identifier des éléments clés ou critiques quelconques ou à limiter la portée de l'invention. Le seul but du résumé est de simplement présenter quelques concepts sous une forme simplifiée comme préambule à la description détaillée présentée ci-dessous. 5 BRÈVE DESCRIPTION DES DESSINS [0020] Les dessins, qui font portion intégrante des spécifications, illustrent des modes variés de réalisation de l'invention et, avec la description générale de l'invention ci-dessus et la description détaillée des modes de réalisation donnée ci-après, servent à expliquer les modes de réalisation de l'invention. [0021] FIG. 1 est une vue schématique d'un environnement d'exploitation exemplaire pour le 10 traitement d'une requête de recherche incluant une pluralité de systèmes informatiques en communication via un réseau. [0022] FIG. 2 et une vue schématique d'un système informatique exemplaire de la FIG. 1. [0023] FIG. 3 est une vue schématique d'une architecture de traitement exemplaire qui peut être mise en oeuvre par un ou plusieurs des systèmes informatiques de la FIG. 1. 15 [0024] FIG. 4 est un diagramme séquentiel d'un processus exemplaire pouvant être mis en oeuvre par l'architecture de traitement de la FIG. 3. [0025] FIG. 5 est un diagramme séquentiel d'un processus exemplaire pouvant être mis en oeuvre par l'architecture de traitement de la FIG. 3 pour la récupération de données de source à partir d'une ou de plusieurs sources de données dorsales en utilisant un algorithme d'optimisation itérative. 20 [0026] FIG. 6 est un schéma exemplaire d'une fonction floue pouvant être utilisée dans le processus de la FIG. 5. [0027] FIG. 7 est un exemple illustrant le processus de la FIG. 5. [0028] FIG. 8 est un diagramme séquentiel d'un processus exemplaire pouvant être mis en oeuvre par l'architecture de traitement de la FIG. 3. pour la mise à jour de réponses générées et enregistrées 25 précédemment pour une requête de recherche. [0029] FIG. 9 est un diagramme séquentiel d'un processus exemplaire qui peut être mis en oeuvre par l'architecture de traitement de la FIG. 3 pour déterminer si les réponses générées pour une nouvelle requête de recherche sont éligibles à la notification. [0030] FIG. 10 est un diagramme séquentiel d'un processus exemplaire pouvant être mis en oeuvre 30 par l'architecture de la FIG. 3. pour déterminer si les réponses actualisées ou les nouvelles réponses générées pour des requêtes de recherche déjà traitées sont éligibles à la notification. [0031] FIG. 11 est un schéma d'une fonction exemplaire pouvant être utilisée pour déterminer le seuil d'abonnement dans le processus de la FIG. 10. 3057084 8 [0032] FIG. 12 est une illustration d'une échelle exemplaire pouvant être utilisée pour déterminer si une réponse est éligible à une notification supplémentaire ou une notification périodique dans le processus de la FIG. 10. 5 DESCRIPTION DÉTAILLÉE [0033] Les modes de réalisation décrits dans les présentes concernent généralement des systèmes, des procédés et des produits-programmes informatiques pour le traitement de requêtes de recherche soumises et enregistrées antérieurement et pour la génération de notifications sur la base de ce traitement. Par exemple, une requête de recherche soumise par un utilisateur peut être enregistrée de façon 10 permanente sur un dispositif de mémoire durable. La requête de recherche peut inclure des critères de recherche définissant les paramètres d'une recherche sur Internet dans des sources de données dorsales disponibles en ligne. Dans un mode de réalisation, la requête de recherche peut être un projet de voyage et le critère de recherche peut inclure des critères de voyage qui définissent les paramètres d'un projet de voyage. Des exemples non exhaustifs de tels critères de voyage peuvent inclure un ou plusieurs budgets, 15 une durée de voyage, des dates de voyages, des destinations, des enseignes, des activités, des évaluations, des services et autres. De plus, les critères de voyage ou le projet de voyage peuvent identifier un intérêt pour de multiples types de produits et/ou de multiples fournisseurs de services impliquant plusieurs sources de données dorsales. [0034] Une fois enregistrée, la requête de recherche peut être récupérée automatiquement, à 20 intervalles réguliers ou irréguliers, pour le traitement. Plus spécifiquement, une ou plusieurs sources de données dorsales pertinentes pour la requête de recherche peuvent être explorées sur la base des critères de recherche de la requête de recherche et des réponses à la requête de recherche, telles que des propositions de voyage, peuvent être générées sur la base des données récupérées. La recherche de données peut être optimisée en fonction des préférences de l'utilisateur, ce qui peut inclure à la fois des préférences 25 explicites (p. ex., les critères de recherche, les préférences sous le profil utilisateur) et des préférences implicites (p. ex., les données exploitées à partir de requêtes de recherche similaires et de données historiques). Par exemple, dans le cas d'un projet de voyage impliquant de multiples sources de données dorsales, la donnée dorsale initiale peut être récupérée à partir d'une des sources de données dorsales et par la suite peut être filtrée pour éliminer toute portion ne respectant pas un seuil de satisfaction basé sur les 30 préférences de l'utilisateur. La portion restante de la donnée dorsale initiale peut ensuite servir à limiter la recherche de données renvoyées à partir d'une autre source de données dorsales. De cette façon, la vitesse de construction des réponses pour une requête de recherche est améliorée, car moins de données sont utilisées pour générer les réponses en comparaison avec une recherche effectuée à partir de chaque source 3057084 9 de données dorsales sur la base des seuls critères de recherche. En outre, les données étant limitées à celles qui respectent un seuil de satisfaction, celui-ci pouvant être déterminé ou spécifié afin d'optimiser les réponses relatives aux critères de recherche pour la requête de recherche, l'ensemble des réponses générées est amélioré, car il omet les réponses susceptibles de présenter peu ou aucun d'intérêt pour 5 l'utilisateur. [0035] Une fois les réponses générées, une détermination de l'éligibilité à la notification pour chaque réponse générée peut être faite (c. -à. -d., si la réponse doit être notifiée à l'utilisateur ayant soumis la requête de recherche). Par exemple, chaque réponse générée peut être comparée à une ou à plusieurs réponses générées et enregistrées pour la requête de recherche. En général, si un changement survient dans 10 les sources de données dorsales explorées entre les réponses générées antérieurement et le moment où sont générées des réponses actuelles, une réponse générée pour une requête de recherche peut s'avérer différente des réponses générées précédemment. Si une réponse actuelle ne diffère pas des réponses précédentes ou si le changement est insignifiant, il est alors possible de déterminer que la réponse ne mérite pas d'être notifiée à l'utilisateur. Alternativement si une réponse actuelle présente un changement 15 important par rapport aux réponses précédentes (p. ex., la réponse actuelle inclut une nouvelle solution de voyage ou un changement de prix important par rapport à une solution de voyage générée antérieurement), il est alors possible de déterminer que la réponse actuelle doit être notifiée à l'utilisateur immédiatement ou doit être notifiée ultérieurement, par exemple, lors de la prochaine notification périodique. Chacune de ces déterminations peut être faite sur la base des préférences explicites et/ou implicites de l'utilisateur. 20 Ainsi, l'utilisateur est informé de changements importants ou de mises à jour dans les sources de données dorsales au moment voulu, et il ne sera pas importuné par des notifications de changements ou de mises à jour qui ne présentent pas suffisamment d'intérêt. [0036] De plus, ou alternativement, lorsqu'un changement ou une mise à jour survient dans une source de données dorsales en rapport avec une réponse enregistrée précédemment, une mise à jour de la 25 réponse enregistrée précédemment peut être automatiquement déclenchée. Comme auparavant, il est alors possible de déterminer si la réponse actualisée doit être notifiée à l'utilisateur, permettant ainsi à l'utilisateur d'être informé presque en temps réel de la mise à jour. Ces caractéristiques et d'autres sont décrites plus en détail par la suite. [0037] FIG. 1 illustre un environnement d'exploitation 10 qui peut inclure un ou plusieurs 30 systèmes d'utilisateur 12, un ou plusieurs systèmes de données dorsales 14, un ou plusieurs systèmes de tiers 16, et un ou plusieurs systèmes de requêtes de notification 18. Chacun de ces systèmes peut communiquer avec les autres via un réseau 24. De plus, deux ou plusieurs des systèmes peuvent être combinés les uns aux autres pour former un seul système. 3057084 10 [0038] Les systèmes d'utilisateur 12 peuvent inclure tout système informatique permettant à un utilisateur de saisir et de soumettre une requête de recherche, via Internet, à un des systèmes de données dorsales 14 ou à un des systèmes tiers 16. Des exemples non exhaustifs de systèmes d'utilisateur 12 peuvent inclure des dispositifs informatiques mobiles, des tablettes, des ordinateurs portables, des 5 ordinateurs de bureau et ainsi de suite. Comme autre exemple, un système d'utilisateur 12 peut être celui de tout voyageur ou client, ou celui de tout agent tel qu'un agent de voyage intervenant pour le compte d'un voyageur ou d'un client. Une requête de recherche, saisie via un système d'utilisateur 12, peut inclure des critères de recherche qui définissent des paramètres pour explorer des sources de données dorsales hébergées sur un ou plusieurs des systèmes de données dorsales 14 et/ou sur un ou plusieurs des systèmes 10 de tiers 16. Dans un mode de réalisation, la requête de recherche peut être un projet de voyage et peut inclure des critères de recherche spécifique au voyage, tels que des dates de voyage, un lieu de destination, un budget et ainsi de suite. [0039] Une fois soumise, la requête de recherche peut être transmise par exemple via le réseau 24 à l'un des systèmes de données dorsales 14 ou à l'un des systèmes de tiers 16. Plus particulièrement, un 15 utilisateur peut demander à un système d'utilisateur 12 d'accéder à une interface graphique d'utilisateur (p. ex., un site Web) hébergée par un système de données dorsales 14 ou par un système de tiers 16, et utiliser ensuite l'interface graphique d'utilisateur pour saisir et soumettre une requête de recherche au système hébergeur. [0040] Les systèmes de données dorsales 14 peuvent inclure tout système étant principalement 20 affilié avec et/ou géré par un fournisseur de données originales utilisées pour répondre à la requête de recherche. Plus particulièrement, chacun des systèmes de données dorsales 14 peut stocker les données dorsales du fournisseur de données originales avec lequel il est affilié, et peut être configuré pour faciliter les activités commerciales du fournisseur de données originales. Par exemple, dans le cas d'une requête de recherche pour un projet de voyage, chaque système de données dorsales 14 peut être affilié avec et/ou 25 géré par un fournisseur de voyage particulier tel qu'un hôtel, une compagnie aérienne, un loueur de voitures, une compagnie ferroviaire et ainsi de suite, et peut stocker les données d'inventaire et les données de réservation du fournisseur de voyage. Chaque système de données dorsales 14 peut par ailleurs être configuré pour permettre aux utilisateurs, par exemple via un système d'utilisateur 12, de rechercher les produits de voyage disponibles chez le fournisseur de voyage affilié et les produits de voyage disponibles 30 chez des partenaires du fournisseur de voyage, et peut par la suite acheter des produits de voyage directement au fournisseur de voyage ou par l'intermédiaire de celui-ci. [0041] Les systèmes de tiers 16 peuvent inclure tout système qui n'est pas principalement affilié avec et/ou géré par un fournisseur de données originales, mais permet malgré tout à un utilisateur de 3057084 11 rechercher les données dorsales d'un fournisseur de données originales. Plus particulièrement, les systèmes tiers 16 peuvent maintenir un lien vers chacun des systèmes de données dorsales 14 et peuvent être configurés pour récupérer et/ou mettre en antémémoire les données dorsales de ces derniers. De cette façon, un système de tiers 16 peut permettre aux utilisateurs de rechercher des données dorsales provenant 5 de multiples systèmes de données dorsales 14 via une simple requête de recherche soumise au système d'un tiers 16. Des exemples non exhaustifs de système de tiers 16 incluent les agences de voyages en ligne (Online Travel Agencies, OLTA's) et les systèmes de distribution globale (Global Distribution Systems, GDS's). [0042] Chacun de ces systèmes de données dorsales 14 et/ou de ces systèmes de tiers 16 peut être 10 configuré pour transmettre une requête de recherche reçue à l'un des systèmes de notification de requête 18. En réponse à la réception d'une requête de recherche, un système de notification de requête 18 peut être configuré pour enregistrer de façon permanente la requête de recherche. Par la suite, à intervalles réguliers ou irréguliers, le système de notification de requête 18 peut être configuré pour récupérer la requête de recherche à partir du stockage permanent afin de récupérer les données dorsales à partir d'un ou 15 de plusieurs systèmes de données dorsales 14 et/ou de systèmes de tiers 16 sur la base des critères de recherche pour la requête de recherche, et pour générer une ou plusieurs réponses pour la requête de recherche sur la base des données récupérées. Le système de notification de requête 18 peut par ailleurs être configuré pour déterminer l'éligibilité à la notification de chacune d'une ou de plusieurs réponses générées, de sorte que la réponse soit notifiée à l'utilisateur qui a soumis la requête de recherche. Dans ce 20 cas, le système de notification de requête 18 peut alors être configuré pour générer une notification qui informe l'utilisateur de la réponse, par exemple par un courriel, un texto, un message instantané, une notification de poussée et ainsi de suite. [0043] Par exemple, un utilisateur peut soumettre une requête de recherche pour un projet de voyage à l'un ou l'autre d'un système de données dorsales 14 ou d'un système de tiers 16 qui peut par la 25 suite transmettre le projet de voyage au système de notification de requête 18. En réponse à la réception du projet de voyage, le système de notification de requête 18 peut enregistrer de façon permanente le projet de voyage et interroger périodiquement un ou plusieurs des systèmes de données dorsales 14 et/ou des systèmes de tiers 16 pour obtenir des données indicatives des produits de voyage disponibles sur la base des critères de recherche pour le projet de voyage. À partir des données reçues, le système de 30 notification de requête 18 peut générer des solutions de voyage qui optimisent les critères de voyage du projet de voyage. Une fois que ces solutions de voyage sont générées, le système de notification de requête 18 peut au moins notifier à l'utilisateur les solutions de voyage fortement susceptible de l'intéresser. De cette façon, en soumettant un projet de voyage une fois, l'utilisateur est en mesure de 3057084 12 recevoir automatiquement des notifications de solutions de voyage pertinentes pour le voyage envisagé intégrant les changements importants pertinents pour le projet de voyage qui surviennent dans les sources de données dorsales après que le projet de voyage a été soumis, tels que l'ajout d'un nouveau produit de voyage par le fournisseur de services ou un changement concernant le prix d'un produit de voyage publié 5 précédemment. [0044] Faisant maintenant référence à la FIG. 2, les systèmes d'utilisateur 12, les systèmes de données dorsales 14, les systèmes de tiers 16, et les systèmes de notification de requête 18 de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs dispositifs informatiques ou systèmes tels que le système informatique exemplaire 26. Le système informatique 26 peut inclure un 10 processeur 28, une mémoire 30, un dispositif de stockage de mémoire de masse 32, une interface entrée/sortie (I/O) 34, et une interface homme-machine (HMI) 36. Le système informatique 26 peut aussi être couplé de façon fonctionnelle avec une ou plusieurs ressources externes 38 via le réseau 24 ou l'interface 1/0 34. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de 15 réseau cloud, ou tout autre ressource informatique appropriée pouvant être utilisée avec l'ordinateur 30. [0045] Le processeur 28 peut inclure un ou plusieurs dispositifs sélectionnés : microprocesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques ou tout autre dispositif, servant à 20 manipuler des signaux (analogues ou numériques, basé sur des instructions de fonctionnement stockées dans la mémoire 30. La mémoire 30 peut inclure un seul dispositif de mémoire ou une pluralité de dispositifs de mémoire comprenant, de façon non exhaustive, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache 25 memory), ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 32 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile, ou tout autre dispositif capable de stocker des informations. [0046] Le processeur 28 peut fonctionner sous le contrôle d'un système d'exploitation 40 qui réside 30 dans la mémoire 30. Le système d'exploitation 40 peut gérer les ressources de l'ordinateur de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application, telle que l'application 42 qui réside dans la mémoire 30, puisse disposer d'instructions exécutées par le processeur 28. Dans un autre mode de réalisation alternatif, le processeur 28 peut exécuter l'application 42 3057084 13 directement et dans ce cas, le système d'exploitation 40 peut être omis. Une ou plusieurs structures de données 44 peuvent aussi résider dans la mémoire 30, et peuvent être utilisées par le processeur 28, le système d'exploitation 40 ou l'application 42 pour stocker ou manipuler des données. [0047] L'interface 34 peut fournir une interface machine qui couple de façon fonctionnelle le 5 processeur 28 à d'autres dispositifs et systèmes, tels que le réseau 24 ou une ou plusieurs ressources externes 38. L'application 42 peut ainsi collaborer avec le réseau 24 et/ou les ressources externes 38 en communiquant par l'intermédiaire de l'interface I/O 34 pour fournir les divers éléments, fonctions, applications, processus, ou modules composant les modes de réalisation de l'invention. Le serveur d'application 42 peut aussi avoir un code de programme qui est exécuté par une ou plusieurs ressources 10 externes 38 ou sinon repose sur les fonctions ou signaux fournis par d'autres systèmes ou composants de réseau externe à l'ordinateur 26. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieurement à l'ordinateur 26, distribuées à des ordinateurs multiples et à d'autres ressources externes 38, ou apportées par des ressources informatiques 15 (matériel et logiciel) qui sont fournies comme services sur le réseau 24, par exemple un service d'informatique en nuage (cloud computing). [0048] Le HMI peut 36 peut être couplé de façon fonctionnelle avec le processeur 28 du système informatique 26 d'une manière connue pour permettre à un utilisateur d'interagir directement avec système informatique 26. Le HMI 36 peut inclure un affichage vidéo ou une unité d'affichage à caractères, un 20 écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. Le HMI 36 peut aussi inclure des dispositifs de saisie et des contrôles tels qù'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des saisies de l'utilisateur, et de les transmettre au processeur 28. 25 [0049] La base de données 46 peut résider sur le dispositif de stockage de mémoire de masse 32 et peut être utilisée pour collecter et organiser les données utilisées par les divers systèmes et modules décrits dans les présentes. La base de données 46 peut inclure des données et les structures de données qui les supportent pour stocker et organiser les données. En particulier, la base de données 46 peut-être arrangée selon toute organisation ou structure de base de données incluant, mais de façon non exhaustive, une base 30 de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, ou des combinaisons de celles-là. Un système de gestion de base de données, sous forme d'une application logicielle qui s'exécute sous forme d'instructions sur le processeur 28, peut être utilisé pour accéder à l'information ou aux données stockées dans les enregistrements de la base de données 46 en réponse à une 3057084 14 interrogation, dans lequel l'interrogation peut être déterminée de façon dynamique et peut être exécutée par le système d'exploitation 40, d'autres applications 42 ou un ou plusieurs modules. [0050] FIG. 3 illustre une architecture de traitement 50 pour le traitement d'une requête de recherche 60 permettant à un utilisateur d'être notifié lorsque des changements dans des sources de 5 données dorsales 58 affectent de façon significative la requête de recherche 60. L'architecture de traitement 50 peut aussi être fournie par un ou plusieurs des systèmes de l'environnement d'exploitation 10 et peut inclure un module de traitement de requête 52, une base de données de requêtes 54, une base de données des réponses 56, et une ou plusieurs sources de données dorsales 58. [0051] Au cours du fonctionnement, le module de traitement de requête 52 peut recevoir une 10 requête de recherche 60 soumise par un utilisateur, par exemple via un système d'utilisateur 12. Spécifiquement, un utilisateur peut accéder à une interface graphique d'utilisateur (GUI) 61, générée par le module de traitement de requête 52 via un système d'utilisateur 12, et peut utiliser la GUI 61 pour créer et soumettre la requête de recherche 60. En réponse à la réception de la requête de recherche 60, le module de traitement de requête 52 peut être configuré pour enregistrer la requête de recherche 60 dans la base de 15 données des requêtes 54. La base de données des requêtes 54 peut être hébergée sur un ou plusieurs dispositifs de stockage permanents, tels qu'un ou plusieurs dispositifs de stockage de mémoire de masse 32 (FIG. 2). [0052] Par la suite et de façon périodique, le module de traitement de requête 52 peut être configuré pour récupérer automatiquement la requête de recherche 60 à partir de la base de données des 20 requêtes 54, récupérer des données de source 58 et générer des réponses 62 pour la requête de recherche 60 sur la base de la donnée de source récupérée. Dans un mode de réalisation, le module de traitement de requête 52 peut être configuré pour récupérer la donnée de source en utilisant un algorithme d'optimisation itérative qui permet la génération de réponses 62 particulièrement pertinentes pour l'utilisateur tout en optimisant l'utilisation des ressources du système. Spécifiquement, l'algorithme 25 d'optimisation itérative peut minimiser le nombre de requêtes transmis aux sources de données dorsales 58 à partir du module de traitement 52, minimiser la quantité de données qui est renvoyée par les sources de données dorsales 58 au module de traitement de requête 52 et maximiser la pertinence des données renvoyées, permettant ainsi au module de traitement de requête 52 de générer plus rapidement de meilleures réponses 62. 30 [0053] Après avoir généré des réponses 62, le module de traitement de requête 52 peut être configuré pour déterminer l'éligibilité à la notification de chaque réponse 62. Plus particulièrement, le module de traitement de requête 52 peut déterminer si chaque réponse 62 mérite d'être partagée avec l'utilisateur via une notification 64, par exemple en fonction des préférences spécifiées par l'utilisateur et 3057084 15 en fonction des critères de recherche de la requête de recherche 60. De cette façon, après la soumission de la requête de recherche 60, si les données d'une source de données dorsales 58 changent, de sorte qu'une nouvelle réponse 62 pour la requête de recherche 60 est disponible (p. ex., un fournisseur de services ajoute un nouveau produit de voyage pertinent), ou qu'une réponse 62 générée antérieurement n'est plus 5 représentative des données dans la source de données dorsales 58, et doit être mise à jour (p. ex., un produit de voyage est annulé, le prix d'un produit de voyage a changé), le module de traitement de requête 52 peut déterminer si la réponse actualisée, ou la nouvelle réponse, doit être notifiée à l'utilisateur. [0054] Spécifiquement, le module de traitement de requête 52 peut être configuré pour déterminer si une réponse 62 présente un caractère exceptionnel justifiant la notification immédiate ou 10 supplémentaire 64 (p. ex., via un texto ou un courriel), si la réponse 62 présente suffisamment d'intérêt potentiel pour l'utilisateur de sorte qu'elle mérite d'être incluse lors de la prochaine notification périodique 64 ou si la réponse 62 n'a tout simplement pas besoin d'être notifiée à l'utilisateur. De cette façon, les ressources du système ne sont pas gaspillées par des notifications de réponses 62 présentant vraisemblablement peu ou aucun intérêt pour l'utilisateur. En outre, puisque les ressources du système sont 15 utilisées chaque fois qu'une notification 64 est générée et envoyée à l'utilisateur, la limitation du nombre de notifications 64 envoyées à l'utilisateur aux seules notifications pour lesquelles l'utilisateur est le plus susceptible d'être intéressé, et le groupement de multiples réponses éligibles à la notification 64, permet au module de traitement de requête 52 d'optimiser davantage l'utilisation des ressources du système. [0055] Dans un mode de réalisation, la requête de recherche 60 peut comprendre un projet de 20 voyage qui inclut des critères de voyage définissant les paramètres d'un voyage envisagé par l'utilisateur et chacune des sources de données dorsales 58 peut inclure des données de prix pour les produits de voyage disponibles chez un ou plusieurs fournisseurs de voyage. Par exemple, une des sources de données dorsales 58 peut inclure des données indiquant le prix des produits de voyage disponibles pour une ou plusieurs compagnies aériennes (p. ex., les vols disponibles), une autre source de données dorsales 58 peut 25 inclure les données indiquant le prix de produits de voyage disponibles pour une ou plusieurs entreprises ferroviaires (p. ex., les cabines de train disponibles) et encore une autre source de données dorsales 58 peut inclure des données indiquant le prix de produits disponibles dans un plusieurs hôtels (p. ex., les chambres disponibles). De façon générale, un produit de voyage d'un fournisseur de services peut inclure tout article ou service du fournisseur de services. 30 [0056] En poursuivant avec l'exemple du voyage envisagé, après l'enregistrement du projet de voyage dans la base de données des requêtes 54, le module de traitement de requête 52 peut être configuré pour récupérer le projet de voyage de façon périodique et automatique à partir de la base de données des requêtes 54, récupérer les données indiquant le prix des produits de voyage disponibles à partir des 3057084 16 sources de données dorsales 58 sur la base des critères de voyage du projet de voyage et construire une ou plusieurs solutions de voyage pour le voyage envisagé sur la base des données de source récupérées. Par la suite, le module de traitement de requête 52 peut déterminer pour chaque solution de voyage si elle est éligible à la notification et notifier l'utilisateur en conséquence. De cette façon, l'utilisateur est tenu 5 informé des nouvelles solutions de voyage qui sont particulièrement pertinentes pour le voyage envisagé et qui deviennent disponibles après l'envoi de la requête de recherche 60. [0057] Après la génération des réponses 62, le module de traitement de requête 52 peut être configuré pour enregistrer les réponses 62 dans la base de données des réponses 56, lesquelles peuvent être également sauvegardées sur un ou plusieurs dispositifs de stockage permanents. Par la suite et de 10 façon périodique, le module de traitement de requête 52 peut récupérer des données de source relatives aux réponses 62 à partir des sources de données dorsales 58. Alternativement, lorsqu'un changement, relatif à une ou plusieurs des réponses 62, survient dans une source de données dorsales 58, le module de traitement de requête 52 peut automatiquement recevoir les données de source indiquant le changement, par exemple via un mécanisme de pousse implémenté au niveau des sources de données dorsales 58. Quel 15 que soit le cas, une fois que la donnée de source est présente, le module de traitement de requête 52 peut récupérer les réponses enregistrées 62 qui sont pertinentes pour la donnée de source, mettre à jour chacune des réponses récupérées 62 qui ne sont plus correctes sur la base de la donnée de source récupérée et déterminer s'il faut aviser l'utilisateur de chaque réponse actualisée 62. [0058] Dans certains modes de réalisation, l'architecture de traitement 50 peut aussi différencier 20 entre deux types d'utilisateurs, les utilisateurs passifs et les utilisateurs VIP. La capacité d'utiliser des fonctionnalités basiques telles que la création d'une requête de recherche 60 et la réception de notifications 64 des réponses 62 peut être accordée à la fois aux utilisateurs passifs et aux utilisateurs VIP. Cependant, les utilisateurs VIP peuvent aussi accéder à des versions personnalisées de la GUI 61 qui permettent une interaction plus vaste avec l'architecture de traitement 50. Par ailleurs, les utilisateurs VIP 25 peuvent recevoir des traitements prioritaires relatifs aux requêtes de recherche 60 et aux notifications 64. En d'autres termes, lorsque le module de traitement de requête 52 traite les requêtes de recherche 60 et les notifications 64, il peut être configuré pour traiter celles provenant d'un utilisateur VIP avant celles des utilisateurs passifs. Les utilisateurs VIP peuvent aussi obtenir plus de capacité de données, ce qui peut augmenter le nombre de réponses 62 pouvant être enregistrées pour l'utilisateur ainsi que le nombre de 30 réponses 62 pouvant être notifié à l'utilisateur. [0059] La FIG. 4 illustre un processus 100 pour la génération de réponses 62 pour une requête de recherche soumise et enregistrée 60. Le processus 100 peut être effectué par l'architecture de traitement 50. 3057084 17 [0060] Dans le bloc 102, une requête de recherche 60 peut être reçue, par exemple par le module de traitement de requête 52. La requête de recherche 60 peut inclure des critères de recherche qui définissent les paramètres pour une recherche dans des sources de données dorsales 58. Dans certains modes de réalisation, la requête de recherche 60 peut être un projet de voyage et les critères de recherche 5 peuvent être des critères de voyage qui définissent les paramètres d'un voyage envisagé par l'utilisateur. En particulier, un utilisateur tel qu'un agent de voyage, un agent d'une compagnie aérienne, ou un voyageur peuvent utiliser un système d'utilisateur 12 pour accéder à la GUI 61 de l'architecture de traitement 50. L'utilisateur peut ensuite utiliser la GUI 61 pour créer un projet de voyage en définissant divers critères de voyage. 10 [0061] La GUI 61 peut présenter à la fois les critères de voyage obligatoires et optionnels devant être définis par l'utilisateur (c. -à.-d., en leur donnant une valeur). Les critères de voyage obligatoires, que l'utilisateur doit définir, peuvent inclure un lieu de départ et le budget disponible. Les critères de voyage optionnels que l'utilisateur peut définir, ou ne pas définir, peuvent inclure une date de départ, des types de produits de voyage (p. ex., avion, train, hôtel, voiture de location, taxi, navette, ferry, transport routier, 15 événements locaux), le nombre de personnes accompagnant le voyageur, l'âge de chaque personne accompagnant le voyageur, le lieu d'arrivée, la date d'arrivée, un nombre maximum de correspondances, et la flexibilité des dates. En outre, la GUI 61 peut permettre à un utilisateur de définir une période avec une durée de voyage et/ou un ou plusieurs jours de la semaine pour un projet de voyage (p. ex., un voyage du vendredi au dimanche envisageable sur une période de trois mois). En exigeant que seul un nombre de 20 critères de voyage minimum soit défini (c.-à-d., les critères de voyage obligatoires), la GUI 61 peut accorder à l'utilisateur de la flexibilité pour définir un projet de voyage de sorte qu'une grande variété de solutions de voyage lui seront notifiées lorsque le projet de voyage sera traité. Dans des modes de réalisation supplémentaires, un ou plusieurs des critères de voyage décrits ci-dessus comme étant optionnels peuvent être obligatoires et un ou plusieurs des critères de voyage décrits comme étant 25 obligatoires peuvent être optionnels. [0062] Dans certains modes de réalisation, la GUI 61 peut aussi présenter deux ou plusieurs modes de création d'un projet de voyage à un utilisateur. Un mode peut-être un mode basique permettant à l'utilisateur de saisir uniquement des critères de recherche de base tels qu'un lieu de départ, un budget disponible et/ou une date de départ. Le mode basique peut être utile pour les voyageurs qui n'ont pas une 30 vision précise du voyage qu'ils souhaitent effectuer. Un autre mode disponible peut être un mode avancé, généralement adapté aux voyageurs qui ont connaissance de détails plus spécifiques pour le projet de voyage. Le mode avancé peut permettre à l'utilisateur de saisir des critères de voyage du mode basique et un ou plusieurs des critères de voyage additionnels, décrits ci-dessus. 3057084 18 [0063] La GUI 61, lors d'une utilisation en mode avancé, peut aussi être adaptée aux voyageurs qui voyagent régulièrement. En particulier, la GUI 61 peut permettre à un utilisateur de créer un projet de voyage incluant de multiples sous-projets de voyage. Chaque sous-projet de voyage peut correspondre à un voyage différent lié au projet global de voyage, par exemple un voyageur souhaitant effectuer le même 5 voyage plusieurs fois par an. En d'autres termes, chaque sous-projet de voyage peut correspondre à la volonté d'un voyageur d'effectuer un même voyage à des dates multiples, ou d'effectuer un même voyage à divers moments (p. ex., une fois par mois). Lorsqu'un projet de voyage inclut des sous-projets de voyage, chaque sous-projet de voyage peut être traité séparément, pour les solutions de voyage et pour les notifications d'éligibilité, et l'utilisateur peut recevoir des notifications 64 distinctes pour chaque sous- 10 projet de voyage. [0064] En outre, en mode avancé la GUI 61 peut permettre à l'utilisateur de définir des critères de voyage additionnels spécifiques à chaque type de produit de voyage. Par exemple, concernant les produits hôteliers, l'utilisateur peut être capable de définir des critères de voyage additionnels, spécifiques aux hôtels tels que le type d'hôtel, l'enseigne, la note minimum, la distance radiale par rapport au centre-ville 15 et les services préférés (p. ex., le petit déjeuner, la piscine, le déjeuner, le ménage, l'accueil 24 heures sur 24, la salle de bains dans la chambre, la connexion Internet, la blanchisserie, le Spa). La GUI 61 peut être configurée pour présenter de façon dynamique à l'utilisateur des options additionnelles de critère de voyage selon le choix de l'utilisateur pour un type particulier de produit de voyage. Par exemple, en réponse au choix de l'utilisateur pour des produits de transport aérien pour un voyage envisagé, la GUI 61 20 peut être configurée pour afficher des critères de voyage spécifiques aux produits de transport aérien (p. ex., la classe, la place du siège, les heures de voyage, l'enseigne) que l'utilisateur peut définir. [0065] Outre la possibilité pour un utilisateur de définir les critères de voyage pour un projet de voyage, la GUI 61 peut permettre à l'utilisateur d'identifier d'autres paramètres à inclure dans le projet de voyage. Par exemple, la GUI 61 peut permettre à un utilisateur d'affecter un niveau de priorité ou un poids 25 à chacun ou à la plupart des critères de voyage définis. En général, le niveau de priorité ou le poids affecté à un critère de voyage défini indique le niveau d'importance de ce critère pour l'utilisateur. Comme décrit de façon plus détaillée ci-dessous, ces niveaux, ou poids, peuvent être utilisés par l'algorithme d'optimisation itérative pour optimiser la récupération de données de source et pour déterminer l'éligibilité à la notification d'une réponse 62 générée pour la requête de recherche 60. 30 [0066] Comme autre exemple de paramètre additionnel, la GUI 61 peut permettre à un utilisateur de spécifier les réglages pour les notifications 64, telles que les notifications périodiques 64, qui sont envoyées à l'utilisateur dans le cadre d'un projet de voyage. Par exemple, l'utilisateur peut définir la fréquence des notifications 64, telles que les notifications périodiques 64 qui sont envoyées à l'utilisateur 3057084 19 (p. ex., une fois toutes les deux semaines, une fois par semaine, deux fois par semaine) et le nombre maximum de réponses 62 qui peuvent être incluses dans la notification 64. [0067] La GUI 61 peut aussi permettre à l'utilisateur de définir un point d'interruption signalant que l'architecture de traitement 50 doit interrompre le traitement de la requête de recherche 60 soumise et 5 arrêter d'envoyer des notifications 64 à l'utilisateur. En d'autres termes, l'architecture de traitement 50 peut continuer à générer de nouvelles réponses 62 pour une requête de recherche 60, à actualiser les réponses 62 générées précédemment pour une requête de recherche 60 et à déterminer l'éligibilité à la notification des réponses 62 pour une requête de recherche 60 jusqu'à ce que le point d'interruption soit atteint. Dans le cas d'un projet de voyage, la GUI 61 peut permettre à l'utilisateur de fixer le point 10 d'interruption à une heure ou une date jusqu'au jour avant la date de départ définie pour le projet de voyage. Si aucun point d'interruption n'est défini par l'utilisateur, un point d'interruption par défaut, correspondant au jour avant la date de départ définie, peut être inféré. [0068] La notification 64 peut inclure les meilleures réponses 62 renvoyées pour la requête de recherche 60 qui peuvent être basées sur une valeur de satisfaction globale ou sur une valeur de 15 satisfaction de réponse (RSV ) calculée pour chaque réponse 62 générée pour la requête de recherche 60, pendant la durée de vie de la requête de recherche 60, le calcul de la valeur de satisfaction de la réponse est décrit plus en détail ci-dessous en référence à la FIG. 7. [0069] Dans le bloc 104, en réponse à la réception de la requête de recherche 60, la requête de recherche 60 peut être enregistrée dans un ou plusieurs dispositifs de stockage permanents tels qu'un ou 20 plusieurs dispositifs de stockage de mémoire de masse. Plus particulièrement, la requête de recherche 60 peut être enregistrée dans une base de données telle que la base de données des requêtes 54 qui est hébergée sur un ou plusieurs des dispositifs de stockage permanents. Dans le bloc 106, un message de confirmation, tel qu'un courriel, peut être envoyé à l'utilisateur résumant la requête de recherche 60, par exemple via un système d'utilisateur 12. Après l'enregistrement de la requête de recherche 60, la GUI 61 25 peut permettre à l'utilisateur de récupérer la requête de recherche 60 dans la base de données des requêtes 54, de visualiser la requête de recherche 60 et d'effectuer tout changement désiré. [0070] Dans le bloc 108, la requête de recherche 60 peut être récupérée dans les dispositifs de stockage permanents, par exemple par le module de traitement de requête 52. Plus particulièrement le module de traitement de requête 52 peut être configuré pour récupérer toute nouvelle requête de 30 recherche 60 soumise par des utilisateurs dans la base de données des requêtes 54 sur une base périodique, telle qu'une fois par jour. Ainsi, si une durée égale à la période fixée s'est écoulée depuis la dernière fois que des nouvelles requêtes de recherche 60 ont été récupérées et traitées, le module de traitement de requête 52 peut alors être configuré pour récupérer toutes les nouvelles requêtes de recherche 60 3057084 20 enregistrées dans la base de données des requêtes 54 incluant la requête de recherche 60 reçue dans le bloc 102. [0071] Dans le bloc 110, les données de source pour la requête de recherche 60 peuvent être récupérées en utilisant un algorithme d'optimisation itérative, par exemple par le module de traitement de 5 requête 52. En général, les données de sources peuvent être définies comme la donnée actuelle sur laquelle est basée la génération de réponses 62. En particulier, le module de traitement de requête 52 peut être configuré pour implémenter l'algorithme d'optimisation itérative afin de récupérer les données de source pertinentes pour la requête de recherche 60 à partir des sources de données dorsales 58. Par exemple, lorsque la requête de recherche 60 concerne un projet de voyage qui indique un intérêt pour des produits 10 de transport aérien, des produits hôteliers et des produits de transport ferroviaire le module de traitement de requête 52 peut interroger les sources de données dorsales 58 contenant des données relatives aux prix et à la disponibilité de chaque type de produit de voyage indiqué dans le projet de voyage. [0072] Comme décrit précédemment, l'algorithme d'optimisation itérative minimise l'utilisation des ressources du système et minimise la quantité de données renvoyée à partir des sources de données 15 dorsales 58 pendant le processus de récupération de la donnée de source, tout en assurant que la donnée de source inclut les résultats les plus susceptibles d'intéresser l'utilisateur. Spécifiquement, l'algorithme d'optimisation itérative est configuré de sorte que des données dorsales sont récupérées à partir des sources de données dorsales 58 au cours d'itérations multiples, dans lequel la donnée dorsale récupérée dans chaque itération contient une portion de la donnée de source. La donnée dorsale récupérée dans 20 chaque itération peut être filtrée sur la base d'un ou de plusieurs des critères de recherche pour déterminer une portion optimale de la donnée dorsale relative aux critères de recherche qui peut ensuite être utilisée pour récupérer des données dorsales lors d'une itération suivante et/ou former la donnée source. En particulier, la donnée de source peut inclure, au moins, une partie de la portion de donnée dorsale optimale déterminée pour chaque itération de données dorsale récupérées. L'algorithme d'optimisation itérative est 25 décrit de façon plus détaillée en référence à la FIG. 5. [0073] Dans le bloc 112, les réponses 62 de la requête de recherche 60 peuvent être générées sur la base de la donnée de source récupérée, par exemple par le module de traitement de requête 52. Plus particulièrement, après la récupération de la donnée de source, le module de traitement de requête 52 peut être configuré pour compiler la donnée de source dans les réponses 62. À cette fin, le module de 30 traitement de requête 52 peut agréger la donnée dorsale récupérée à partir de sources de données dorsales 58 différentes pour former les réponses 62 et peut calculer une RSV pour chaque réponse 62 qui peut être basée sur les poids affectés aux critères de recherche de la requête de recherche 60. 3057084 21 [0074] Dans le bloc 114, chacune des réponses générées 62 peut être enregistrée dans une base de données, telle que la base de données des réponses 56. En particulier, le module de traitement de requête 52 peut transmettre les réponses générées 62 à la base de données des réponses 56. La base de données des réponses 56 peut être hébergée sur un ou plusieurs dispositifs de stockage permanents, tels 5 qu'un ou plusieurs dispositifs de stockage de mémoire de masse 32 (FIG. 2). Les réponses 62 peuvent être enregistrées dans la base de données des réponses 56 de sorte que chaque réponse 62 est associée à LM horodatage de la création de la réponse 62 et de la RSV calculée pour la réponse 62. [0075] Dans le bloc 116, chaque réponse 62 peut être traitée pour l'éligibilité à la notification, par exemple par le module de traitement de requête 52. En particulier, le module de traitement de requête 52 10 peut déterminer l'éligibilité à la notification des réponses générées 62, à intervalles réguliers ou irréguliers, immédiatement après la génération et/ou l'enregistrement de la réponse 62. En réponse à la détermination indiquant qu'une réponse 62 est éligible à la notification, le module de traitement de requête peut être configuré pour notifier la réponse 62 à l'utilisateur via une notification 64. La détermination de l'éligibilité à la notification pour les réponses 62 générées pour de nouvelles requêtes de recherche 60 est décrite de 15 façon plus détaillée en référence à la FIG. 9. [0076] Après la génération et/ou l'enregistrement des réponses 62, un ou plusieurs des blocs 110 à 116 peuvent continuer à être implémentés de façon automatique et périodique, par exemple par le module de traitement de requête 52. Spécifiquement, le module de traitement de requête 52 peut être configuré pour mettre en oeuvre automatiquement un ou plusieurs des blocs 110 à 116 sur une base périodique 20 régulière ou irrégulière jusqu'à ce que le point d'interruption inclus dans la requête de recherche 60 soit atteint. Dans certains modes de réalisation, la ou les fréquences de répétition automatique pour la mise en oeuvre de chaque bloc par le module de traitement de requête 52 pour la requête de recherche 60 peuvent différer de la fréquence à laquelle le module de traitement de requête 52 récupère et traite les nouvelles requêtes de recherches 60. Par exemple, le module de traitement de requête 52 peut récupérer de nouvelles 25 requêtes de recherche 60 une fois par jour et récupérer les requêtes de recherche 60 précédemment traitées tous les trois jours. [0077] Si, lors de l'implémentation ultérieure d'un ou de plusieurs des blocs 110 à 114, de nouvelles réponses 62 sont générées ou qu'une détermination est faite qu'une réponse 62 générée précédemment ne reflète plus correctement la donnée enregistrée dans les sources de données dorsales 58 30 et doit être mise à jour, le module de traitement de requête 52 peut ajouter les nouvelles réponses ou les réponses actualisées, aux réponses 62 précédemment générées et enregistrées dans la base de données des réponses 56. De cette façon, lorsque la donnée d'une source de données dorsales 58 subit un changement pertinent pour la requête de recherche 60, le changement peut être notifié à l'utilisateur. Par ailleurs, l'ajout 3057084 22 de nouvelles réponses et de réponses actualisées 62 à la base de données des réponses 56, sans que les réponses générées précédemment 62 soient effacées, permet au module de traitement de requête 52 de suivre l'évolution des réponses 62 pendant la durée de vie de la requête de recherche 60, ce qui peut permettre au module de traitement de requête 52 de fournir des prévisions, concernant la probabilité de 5 changement d'une réponse 62, à un utilisateur. [0078] Une fois qu'une requête de recherche 60 est créée et qu'un ensemble de réponses 62 est généré et enregistré pour la requête de recherche 60, les utilisateurs peuvent utiliser la GUI 61 pour visualiser les réponses 62 pour la requête de recherche 60. L'utilisateur peut ensuite sélectionner une réponse 62 pour en voir les détails. Par exemple, lorsque chaque réponse 62 est une solution de voyage, 10 l'utilisateur peut sélectionner une des solutions de voyage pour voir les détails concernant les produits de voyage dans la solution sélectionnée. Dans le cas spécifique d'un produit hôtelier, l'utilisateur peut localiser l'hôtel sur une carte. De plus, la GUI 61 peut permettre à un utilisateur de sélectionner une réponse 62 et, par la suite, de consulter la tendance des prix associés à la réponse 62 afin de déterminer si la réponse 62 est susceptible de changer et dans quelle mesure. Dans certains modes de réalisation, cette 15 caractéristique peut n'être disponible que pour les utilisateurs VIP. [0079] Après la génération des réponses 62 pour une requête de recherche 60, un utilisateur peut aussi utiliser la GUI 61 pour consulter les réponses 62 et en sélectionner une manuellement pour une nouvelle élaboration. En réponse à la réception d'une requête d'un utilisateur pour recréer une réponse 62, le module de traitement de requête 52 peut interroger les sources de données dorsales 58 pour obtenir les 20 données qui correspondent à la réponse sélectionnée 62. Si de telles données sont trouvées et renvoyées par les sources de données dorsales 58, le module de traitement de requête 52 peut alors recréer la réponse sélectionnée 62 sur la base des données renvoyées. La réponse recréée 62 peut alors être présentée à l'utilisateur via la GUI 61. Si la réponse recréée 62 diffère de la réponse sélectionnée 62, ce qui peut survenir en raison d'un changement affectant la donnée sur laquelle la réponse 62 sélectionnée était basée 25 dans les sources de données dorsales 58 (p. ex., un changement de prix ou de disponibilité pour un vol particulier), alors la réponse sélectionnée 62 peut être actualisée dans la base de données des réponses 56 sur la base de la réponse recréée 62. Alternativement, la réponse recréée 62 peut être enregistrée avec la réponse sélectionnée 62 dans la base de données des réponses 56 de sorte qu'il est possible de suivre l'évolution de la réponse sélectionnée 62 et d'analyser la tendance des prix. Si le module de traitement de 30 requête 52 n'est pas capable de récupérer une donnée correspondant à la réponse sélectionnée 62 à partir des sources de données dorsales 58, par exemple si la donnée sur laquelle la réponse 62 était basée a été supprimée des sources de données dorsales 58, la GUI 61 peut alors notifier à l'utilisateur l'inexistence de 3057084 23 la réponse sélectionnée 62 et peut actualiser la base de données des réponses 56 en conséquence (p. ex., supprimer la réponse 62 sélectionnée ou indiquer que la réponse sélectionnée 62 n'est plus disponible). [0080] De plus, la GUI 61 peut permettre à un utilisateur de sélectionner une ou plusieurs réponses 62 qui l'intéressent et de demander un résumé de ces réponses sélectionnées 62 par courriel. En 5 réponse, le module de traitement de requête 52 peut générer et envoyer un courriel affichant les détails de chaque réponse sélectionnée 62. [0081] Par ailleurs, après la génération et l'enregistrement des réponses 62 pour une requête de recherche 60 dans la base de données des réponses 56, les utilisateurs peuvent utiliser la GUI 61 pour s'abonner à une ou à plusieurs des réponses 62. De cette façon, l'utilisateur peut désigner les réponses 62 10 qui présentent un intérêt particulier et peut demander des notifications 64 lorsque par la suite ces réponses 62 sont actualisées et qu'elles affichent un changement notable. Le traitement des réponses 62 incluant des souscriptions est décrit de façon plus détaillée ci-dessous, en référence aux FIGS. 10 et 11. [0082] La FIG. 5 illustre un processus 200 pour récupérer une donnée de source à partir des sources de données dorsales 58, comme indiqué dans le bloc 110 du processus 100 (FIG. 3). Plus 15 particulièrement, le processus 200 illustre un mode de réalisation de l'algorithme d'optimisation itérative pouvant être utilisé pour récupérer la donnée de source à partir des sources de données dorsales 58. Le processus 200 peut être mis en oeuvre par le module de traitement de requête 52 de l'architecture de traitement 50. [0083] Dans le bloc 202, les données dorsales initiales qui incluent une portion de la donnée de 20 source peut être récupérée à partir d'une ou de plusieurs sources de données dorsales 58, par exemple sur la base d'au moins un des critères de recherche de la requête de recherche 60. De façon générale, une ou plusieurs des sources de données dorsales 58 peuvent inclure de multiples sources de données dorsales 58, et chacune des sources de données dorsales 58 peut être associée à un fournisseur de services différents, tels qu'une compagnie aérienne ou un hôtel, ou à différents types de produits de voyage. De plus, chaque 25 source de données dorsales 58 peut inclure des données représentant des produits ou des résultats qui peuvent être inclus dans une réponse 62 générée par le module de traitement de requête 52. [0084] Une réponse 62 générée par le module de traitement de requête 52 pour une requête de recherche 60 inclut souvent des produits ou des résultats ayant une dépendance intrinsèque. Par exemple, une réponse 62 sous forme de solution de voyage incluant des produits de transport aérien qui sont 30 connectés implique, si les produits de la solution de voyage sont réservés, que le produit de transport aérien dont la date de départ est la plus lointaine ne pourra être utilisé qu'après utilisation du produit de voyage en avion dont la date de départ est la plus proche. De façon similaire, une réponse 62 sous forme de solution de voyage incluant un produit de transport aérien et un produit hôtelier implique, si la 3057084 24 réservation des produits de voyage est confirmée, que le produit hôtelier ne pourra être utilisé qu'après utilisation du produit de transport aérien. [0085] Ainsi plutôt que d'effectuer une simple recherche, dans les sources de données dorsales 58, parmi toutes les données enregistrées qui sont potentiellement pertinentes pour la requête de recherche 60 5 (p. ex., effectuer une simple recherche parmi toutes les sources de données dorsales 58 relatives aux produits de transport aérien et aux produits hôteliers pour un projet de voyage indiquant un intérêt pour des produits de transport aérien et pour des produits hôteliers), le module de traitement de requête 52 peut être configuré pour effectuer la recherche au cours d'itérations en limitant initialement la recherche à certaines des données pertinentes, telles que les données pertinentes pour un type de produit ou de résultat 10 dont dépendra un autre type de produit ou de résultat. De cette façon, et comme cela apparaitra évident ci- dessous, le module de traitement de requête 52 évite de récupérer des données pour des produits ou des résultats dépendants qui, par la suite, doivent être éliminés en raison de l'impossibilité de trouver des données pour des produits ou des résultats satisfaisants (p. ex., des produits ou des résultats présentant un intérêt pour l'utilisateur sur la base de critères de voyage et de poids qui leur sont affectés) qui permettront 15 l'utilisation des produits ou résultats qui en dépendent. Par conséquent, la quantité totale de données renvoyées, par le module de traitement de requête 52 à partir des sources de données dorsales 58 pour le traitement, est minimisée et réduit ainsi la pression globale sur les ressources du système lors de la génération de réponses 62. [0086] Par exemple, dans un mode de réalisation, la requête de recherche 60 peut être un projet de 20 voyage qui inclut des critères de voyage indiquant un intérêt pour des produits de transport (p. ex., avion et train) et des produits hôteliers, et inclut des critères de voyage additionnels pour chaque type de produit de voyage. Dans ce cas, du fait que l'utilisation de tout produit hôtelier peut dépendre de l'utilisation préalable d'un produit de transport pour le voyage, le module de traitement de requête 52 peut commencer à récupérer des données dorsales pour le projet de voyage en limitant initialement la recherche aux 25 données enregistrées dans des sources de données dorsales 58 concernant les moyens de transport. Par exemple le module de traitement de requête 52 peut limiter la recherche initiale à des données enregistrées dans les sources de données dorsales 58 qui sont associées à un fournisseur de services de transport (p. ex., une compagnie aérienne ou ferroviaire). Le module de traitement de requête 52 peut affiner la recherche par la suite en se basant sur un ou plusieurs des critères de voyage du projet de voyage, tel qu'un 30 ou plusieurs des critères de voyage qui sont particulièrement pertinents pour les produits de transport (p. ex., les dates, le budget, le lieu de départ, le lieu d'arrivée, la classe de réservation, l'enseigne préférée et le nombre de correspondances). Les limites appliquées par le module de traitement de requête 52 dans cette recherche initiale assureront que la donnée dorsale initiale reçue en provenance des sources de données 3057084 25 dorsales 58 inclut uniquement des résultats sous forme de produits de transport pertinents pour le projet de voyage. [0087] Dans le bloc 204, la donnée dorsale initiale peut être filtrée sur la base d'un ou de plusieurs seuils de satisfaction et d'un ou de plusieurs des critères de recherche qui sont pertinents pour la donnée 5 dorsale initiale. Plus particulièrement, la donnée dorsale initiale peut inclure des résultats multiples récupérés à partir des sources de données dorsales 58, tels que de multiples produits de transport. Le module de traitement de requête 52 peut comparer chaque résultat avec une ou plusieurs portions des critères de la recherche pour la requête de recherche 60 qui peuvent inclure un ou plusieurs des critères de recherche sur lesquels est basée la récupération de la donnée dorsale initiale et qui sont particulièrement 10 pertinents pour les résultats afin de déterminer un niveau de valeur de satisfaction (Layer Satisfaction Value, la « LSV ») ou valeur de satisfaction partielle. Par exemple, quand chaque résultat dans la donnée dorsale initiale est un produit de transport, le module de traitement de requête 52 peut comparer chaque produit de transport avec une ou plusieurs portions des critères de voyage pertinents pour le transport afin de déterminer une LSV pour chaque produit de transport. Par la suite, le module de traitement de 15 requête 52 peut comparer la LSV de chaque résultat avec un seuil de satisfaction déterminé ou spécifié, et filtrer les résultats en déterminant chaque résultat dont la LSV est supérieure ou égale au seuil de satisfaction. En d'autres termes, les résultats dont la LSV est inférieure au seuil de satisfaction peuvent être éliminés et les résultats dont la LSV est supérieure ou égale au seuil de satisfaction peuvent être retenus. La donnée dorsale initiale filtrée peut donc être considérée comme incluant les résultats filtrés ou retenus, 20 c'est-à-dire, les résultats de la donnée dorsale initiale dont la LSV est supérieure ou égale au seuil de satisfaction. [0088] Dans certains modes de réalisation, ce processus peut être répété de sorte que la donnée dorsale initiale est filtrée à des niveaux multiples. Par exemple, après le filtrage des résultats dans la donnée dorsale initiale au niveau initial, comme décrit dans le paragraphe précédent, le module de 25 traitement de requête 52 peut appliquer le processus à un autre niveau pour lequel les résultats retenus sont comparés avec d'autres critères de recherche pertinents pour les résultats pouvant inclure un ou plusieurs des critères de recherche qui ont été utilisés pour récupérer la donnée dorsale initiale et/ou qui n'ont pas été comparés au niveau initial. Comme pour le niveau initial, une autre LSV peut être déterminée pour chaque résultat retenu sur la base de la comparaison et les résultats retenus peuvent être filtrés en 30 déterminant chaque résultat retenu pour lequel la LSV est supérieure à un seuil de satisfaction déterminé ou spécifié pour le niveau actuel. Dans ce cas, on peut considérer que la donnée dorsale initiale filtrée inclut les résultats retenus ou filtrés restant après l'application du dernier niveau de filtrage à la donnée dorsale initiale. 3057084 26 [0089] Lorsque la donnée dorsale initiale est filtrée à des niveaux multiples, les critères de recherche comparés dans le niveau initial peuvent s'avérer relativement généraux et les critères de recherche comparés dans les niveaux suivants peuvent devenir de plus en plus spécifiques. Par exemple, lorsque chaque résultat dans la donnée dorsale initiale est un produit de transport, les résultats au niveau 5 initial peuvent être comparés avec les critères de voyage généraux du projet de voyage qui sont pertinents pour le transport, tels qu'une date, un prix, un et un lieu d'arrivée qui ont été définis pour le projet de voyage. Par la suite, au niveau suivant, les résultats retenus peuvent être comparés avec des critères de voyage de plus en plus spécifiques relatifs aux moyens de transport tels qu'une classe de réservation, une enseigne, le nombre de correspondances et un type de moyen de transport défini dans le projet de voyage. 10 Plusieurs niveaux peuvent être utilisés pour filtrer la donnée dorsale initiale en plus de que ceux qui sont décrits dans les présentes et plus ou moins de critères de recherche que ceux qui sont décrits dans les présentes peuvent être comparés à chaque niveau. [0090] Dans un mode de réalisation, la comparaison de résultats dans la donnée dorsale initiale avec un ou plusieurs critères de recherche peut inclure l'application d'une ou de plusieurs fonctions floues 15 à chaque résultat pour calculer une LSV pour chaque résultat. En particulier une fonction floue h (x1) peut être déterminée pour chaque critère de recherche faisant l'objet d'une comparaison, où h () est la fonction floue pour le eh critère en cours de comparaison, et xi représente la valeur du résultat pour le ith critère en cours de comparaison. La fonction floue déterminée pour un critère de recherche donné peut être dérivée à partir de la valeur définie par l'utilisateur pour le critère de recherche dans la requête de recherche 60. 20 Lorsqu'elle est appliquée à un résultat donné, chaque fonction floue peut produire une valeur pour le résultat relatif au critère associé à la fonction floue (c. -à.-d., le critère pour lequel la fonction floue est déterminée). Une LSV peut ensuite être déterminée pour le résultat sur la base des valeurs générées pour chaque fonction floue. [0091] Lorsque des utilisateurs créent des requêtes de recherche 60, telles qu'un projet de voyage, 25 ils demandent typiquement des réponses 62 qui satisfont autant que possible les critères de recherche de la requête de recherche 60. Comme décrit ci-dessus, pour affiner davantage une requête de recherche 60, un utilisateur peut avoir la possibilité de déclarer l'importance de chaque critère de recherche en affectant un poids à chaque critère, par exemple en utilisant la GUI 61, de sorte que chaque critère est associé à un poids. Par conséquent dans certains modes de réalisation, l'application d'une ou de plusieurs fonctions 30 floues à un résultat-pour calculer une LSV pour le résultat peut comprendre la multiplication de chaque fonction floue, ou de la valeur de résultat pour chaque fonction floue, avec le poids affecté au critère pour lequel la fonction floue est déterminée. Par la suite, la LSV pour un résultat peut être calculée en 3057084 27 additionnant chaque fonction floue ou valeur multipliée. Plus spécifiquement, la LSV pour un résultat peut être calculée en utilisant la formule suivante : LSV = ni= * wi =0 Wi où fiest une fonction floue pour le i th critère, xi est la valeur pour le ith critère pour le résultat donné, 5 et wiest le poids affecté au ith critère. Chaque LSV calculée pour un résultat peut appartenir à l'intervalle [0,1]. Bien qu'une formation exemplaire de LSV soit illustrée ci-dessus, d'autres formules de LSV peuvent être utilisées selon le type de résultat pour lequel la LSV est calculée (p. ex., les résultats relatifs à un hôtel, les résultats relatifs à un moyen de transport et ainsi de suite). [0092] La FIG. 6 illustre un graphe d'une fonction floue exemplaire pouvant être déterminée pour 10 un projet de voyage qui indique un intérêt pour des produits de transport pour le voyage et définit un budget de cinq cents euros. Selon le graphe illustré, si un produit de transport pour le voyage renvoyé à partir des sources de données dorsales 58 a un prix de cinq cents euros ou moins, la fonction floue attribuera une valeur un, indiquant que l'utilisateur sera très satisfait par le produit de transport par rapport à son budget. Alternativement, si le prix d'un produit de transport renvoyé est supérieur à cinq cents euros, 15 la fonction floue attribuera une valeur inférieure à un indiquant que, par rapport au budget, l'utilisateur ne sera pas complètement satisfait par le produit de transport. Plus le prix d'un produit de transport est élevé, au-delà des cinq cents euros, moins l'utilisateur sera satisfait par rapport à son budget. Selon le critère, des formes différentes (p. ex., des triangles, des trapèzes et des carrés) peuvent être utilisées pour les fonctions floues et ces formes peuvent être personnalisées par l'utilisateur via la GUI 61. 20 [0093] Faisant référence à nouveau à la FIG.5, dans le bloc 206, une autre itération de récupération de donnée peut être effectuée dans laquelle des données dorsales supplémentaires, pouvant également inclure une portion de la donnée de source, peut être récupérée à partir d'une ou de plusieurs des sources de données dorsales 58 sur la base de la donnée dorsale initiale filtrée, et/ou sur la base d'un ou de plusieurs des critères de recherche de la requête de recherche 60. De cette façon, la donnée dorsale 25 supplémentaire peut inclure des résultats compatibles avec les résultats restants de la donnée dorsale initiale filtrée, et/ou qui sont pertinents pour un ou plusieurs critères de recherche utilisés pour récupérer la donnée dorsale supplémentaire. En d'autres termes, après l'utilisation d'un ou de plusieurs des résultats de la donnée dorsale initiale filtrée, chaque résultat de la donnée dorsale supplémentaire peut être utilisé. Dans certains modes de réalisation, une ou plusieurs sources de données dorsales 58, à partir desquelles la 30 donnée dorsale supplémentaire est récupérée, peuvent différer des sources de données dorsales 58 à partir desquelles la donnée dorsale initiale a été récupérée, et les critères de recherche sur lesquels la 3057084 28 récupération de la donnée dorsale supplémentaire est basée peuvent différer des critères de recherche sur lesquels la donnée dorsale initiale est basée. [0094] Par exemple, lorsque la requête de recherche 60 est un projet de voyage qui inclut des critères de voyage indiquant un intérêt pour des produits de transport et pour des produits hôteliers, et qu'il 5 inclut des critères de voyage supplémentaires pour chaque type de produit de voyage, la donnée dorsale initiale filtrée peut inclure de multiples produits de transport susceptibles d'intéresser l'utilisateur qui ont été récupérés à partir d'une ou de plusieurs sources de données dorsales 58 incluant les informations relatives aux produits de transport. Après la détermination de la donnée dorsale initiale filtrée, le module de traitement de requête 52 peut interroger une ou plusieurs sources de données dorsales différentes 58 10 incluant des informations relatives aux produits hôteliers qui sont compatibles avec les produits de transport dans la donnée dorsale initiale filtrée et/ou qui sont pertinents pour un ou plusieurs des critères de voyage relatifs aux produits hôteliers définis dans le projet de voyage. Le fait d'affiner la recherche des sources de données dorsales suivantes 58 sur la base de la donnée dorsale initiale filtrée et/ou d'un ou de plusieurs critères de voyage relatifs aux hôtels réduit la quantité de données renvoyées à partir des sources 15 de données dorsales suivantes 58. Par conséquent, moins de données ont besoin d'être traitées par le module de traitement de requête 52 pour générer les solutions de voyage pour le projet de voyage, ce qui entraîne un temps de traitement plus rapide et minimise la pression sur les ressources du système. [0095] Dans le bloc 208, la donnée dorsale supplémentaire peut être filtrée sur la base d'un ou de plusieurs seuils de satisfaction qui peuvent différer ou ne pas différer d'un ou de plusieurs seuils de 20 satisfaction utilisés pour filtrer la donnée dorsale initiale et une ou plusieurs portions des critères de recherche pertinents pour la donnée dorsale supplémentaire. Plus spécifiquement, un ou plusieurs niveaux additionnels de filtrage peuvent être appliqués à la donnée dorsale supplémentaire dans lesquels les résultats de la donnée dorsale supplémentaire sont comparés avec une ou plusieurs portions de critères de recherche pertinents pour la donnée dorsale supplémentaire de la requête de recherche 60. L'application de 25 chacun de ces niveaux additionnels peut être effectuée de la même façon ou de façon similaire à ce qui a été décrit ci-dessus pour la donnée dorsale initiale récupérée à partir des sources de données dorsales 58. Par conséquent, on peut considérer que la donnée dorsale supplémentaire filtrée inclut les résultats filtrés ou retenus de la donnée dorsale supplémentaire restante après l'application du dernier niveau de filtrage à la donnée dorsale supplémentaire. 30 [0096] Dans certains modes de réalisation, une ou plusieurs itérations supplémentaires peuvent être effectuées pour récupérer et/ou filtrer des données à partir des sources de données dorsales 58, par exemple lorsqu'un projet de voyage indique trois ou plusieurs types de produits de voyage, d'enseignes, etc. À cette fin, après la mise en oeuvre du bloc 208, le processus 200 peut retourner au bloc 206 pour 3057084 29 récupérer d'autres données à partir des sources de données dorsales 58 sur la base d'autres portions de critères de recherche et des données filtrées précédemment. Dans certains modes de réalisation, chaque itération qui suit pour récupérer une donnée peut impliquer une ou plusieurs sources de données dorsales différentes 58 spécifiques au type de donnée en cours de récupération lors de l'itération (p. ex., des 5 produits hôteliers, des produits de transport pour le voyage, un mode de transport tel que l'avion, une enseigne particulière et ainsi de suite). [0097] La donnée de source récupérée à partir d'une ou de plusieurs sources de données dorsales 58 peut inclure ou être basée sur au moins une portion de chacune des données récupérées filtrées à partir des sources de données dorsales 58, telle qu'au moins une portion de la données initiale filtrée et 10 au moins une portion de la donnée supplémentaire filtrée. Par conséquent, la génération des réponses 62 pour une requête de recherche 60 basée sur la donnée de source récupérée à partir des sources de données dorsales 58 peut comprendre la génération de réponses 62 basées sur la donnée dorsale initiale filtrée, la donnée dorsale supplémentaire filtrée et toutes autre donnée filtrée récupérée à partir des sources de données dorsales 58. Par exemple, chaque réponse 62 peut inclure et/ou agréger un résultat ou un produit 15 provenant de la donnée dorsale initiale filtrée et un résultat ou produit provenant de la donnée dorsale supplémentaire filtrée. [0098] La FIG. 7 illustre un exemple spécifique de l'algorithme d'optimisation itérative décrit dans la FIG. 6. Plus spécifiquement, l'exemple inclut un total de trois niveaux de filtrage qui sont appliqués aux données récupérées à partir des sources de données dorsales 58 pour un projet de voyage indiquant un 20 intérêt pour des produits de transport, ou plus particulièrement un intérêt pour les produits de transport aérien et les produits de transport ferroviaire, ainsi que des produits hôteliers, et qui définit des critères de voyage pour chacun d'entre eux. Les trois niveaux peuvent inclure un niveau général LI, un niveau pour les transports L2 et un niveau pour la destination L3. [0099] Pour commencer, du fait que l'utilisation d'un produit hôtelier peut dépendre de l'utilisation 25 préalable d'un produit de transport, le module de traitement de requête 52 peut initialement interroger les sources de données dorsales 58 concernant les données relatives aux produits de transport basés sur un ou plusieurs des critères de voyage du projet de voyage qui sont pertinents pour les moyens de transport. En particulier, le module de traitement de requête 52 peut limiter cette recherche aux sources de données dorsales 58 qui incluent des données indicatives du prix et de la disponibilité des produits de transport 30 pertinents. Par conséquent en réponse à l'émission de la requête, le module de traitement de requête 52 peut recevoir des données dorsales initiales à partir des sources de données dorsales 58 qui indiquent le prix et la disponibilité de multiples produits de transport. Dans cet exemple, les multiples produits de transport incluent le vol 1, le vol 2, le train 1, le train 2 et le train 3. 3057084 30 [0100] Par la suite, le module de traitement de requête 52 peut commencer à filtrer la donnée dorsal initiale en appliquant le niveau général LI. Au niveau général LI, les produits de transport peuvent être comparés à des critères de voyages généraux pertinents pour les transports et qui sont définis dans le projet de voyage, tels que la date, le budget, le lieu de départ, et le lieu d'arrivée. Le module de traitement 5 de requête 52 peut ensuite déterminer une LSV pour chaque produit de transport sur la base de ces comparaisons, et peut comparer la LSV de chaque produit de transport à un seuil de satisfaction déterminé ou spécifié pour le niveau général LI. Les produits de transport qui ne sont pas supérieurs ou égaux au seuil de satisfaction peuvent être éliminés et les autres peuvent être retenus. Dans cet exemple, le vol 1, le vol 2, le train I et le train 2 sont retenus après l'application de niveau général Ll, et le train 3 est éliminé. 10 [0101] Par la suite, le module de traitement de requête 52 peut appliquer le niveau pour les transports L2 aux produits de transport retenus après le niveau général L I . Au niveau des transports L2, les produits de transport retenus qui sont aussi plus spécifiques que ceux qui ont été comparés au niveau général LI, peuvent être comparés aux critères de voyage pertinents pour les transports et définis dans le projet de voyage, et. De tels critères de voyage peuvent inclure la classe, l'enseigne, le nombre de 15 correspondances et le mode de transport (p. ex., avion ou train). Le module de traitement de requête 52 peut à nouveau déterminer une LSV pour chaque produit de transport retenu sur la base de ces comparaisons et, afin de déterminer quels produits de transport retenus doivent continuer à le rester, il peut comparer la LSV de chaque produit de transport retenu à un seuil de satisfaction déterminé ou spécifié pour le niveau des transports L2. Dans cet exemple, le vol 1, le vol 2 et le train I continuent à être 20 retenus après l'application du niveau des transports L2 et le train 2 est éliminé. [0102] À ce stade, le module de traitement de requête 52 peut interroger les sources de données dorsales 58 pour obtenir une donnée dorsale supplémentaire indicative de produits hôteliers sur la base des produits de transport restant après l'application du niveau de transport L2, et peut aussi se baser sur un ou plusieurs des critères de voyage définis dans le projet de voyage pour les hôtels. Plus spécifiquement, le 25 module de traitement de requête 52 peut limiter la recherche aux sources de données dorsales 58 qui incluent les données de prix et de disponibilité pour les produits hôteliers, et affiner la recherche sur la base des détails des produits de transport restants, tels que la date, l'heure de départ, l'heure d'arrivée et le lieu d'arrivée qui sont associés à chaque produit de transport restant. En d'autres termes, pour chaque produit de transport restant, le module de traitement de requête 52 peut explorer les sources de données 30 dorsales 58 pour rechercher des produits hôteliers qui s'accorderont ou seront compatibles avec le produit de transport et qui peuvent être pertinents pour un ou plusieurs des critères spécifiques aux hôtels définis dans le projet de voyage. 3057084 31 [0103] Du fait que le nombre de produits de transport restants peut être minimisé, de sorte qu'il n'inclut que les produits le plus susceptibles d'être satisfaisants par rapport aux critères de voyage du projet de voyage, le nombre de produits hôteliers renvoyé à partir des sources de données dorsales 58 est également minimisé, se limitant aux produits hôteliers qui, lorsqu'ils sont combinés aux produits de 5 transport restant, sont le plus susceptibles d'intéresser l'utilisateur. Par conséquent, la quantité de données qui est renvoyée au module de traitement de requête à partir des sources de données dorsales 58 est réduite alors que la qualité globale des données reçues relative à la satisfaction de l'utilisateur est améliorée. Il en résulte que le module de traitement de requête 52 peut générer de meilleures solutions de voyage plus rapidement. Dans cet exemple, les produits hôteliers renvoyés à partir des sources de données dorsales 58 10 incluent l'hôtel 1, l'hôtel 2, l'hôtel 3, l'hôtel 4 et l'hôtel 5. [0104] Après la réception des produits de voyage hôteliers, le module de traitement de requête peut appliquer le niveau de destination L3 aux produits hôteliers. Au niveau L3, les produits hôteliers peuvent être comparés aux critères de voyage spécifiques à la destination/hôtel qui ont été définis dans le projet de voyage, tels que la localisation dans une zone, la distance par rapport à un aéroport, la note 15 d'évaluation, les aménagements et les manifestations. Comme auparavant, le module de traitement de requête 52 peut alors déterminer une LSV pour chaque produit hôtelier sur la base de ces comparaisons, et peut comparer la LSV de chaque produit hôtelier à un seuil de satisfaction déterminé ou spécifié pour le niveau de destination L3. Les produits qui ne sont pas supérieurs ou égaux au seuil de satisfaction peuvent être éliminés et les autres peuvent être retenus. Dans cet exemple, les hôtels 1, 2 et 4 sont retenus et les 20 hôtels 3 et 5 sont éliminés. [0105] Après le filtrage des produits hôteliers pour inclure uniquement ceux qui sont les plus susceptibles de satisfaire l'utilisateur, on peut estimer que les données de source pour le projet de voyage sont récupérées (bloc 110 de la FIG. 4), et les réponses 62 (c. -à.-d., les solutions de voyage) pour le projet de voyage peuvent être générées sur la base de la donnée de source récupérée (bloc 112, FIG. 4). 25 Spécifiquement, le module de traitement de requête 52 peut combiner les produits de transport restants dans la donnée dorsale initiale filtrée avec les produits hôteliers restants dans la donnée dorsale supplémentaire filtrée en fonction de leur compatibilité. En d'autres termes, chaque produit de transport peut être assorti aux produits hôteliers renvoyés en fonction du produit de transport. Dans ce cas, le vol 1 est assorti à l'hôtel 1 et à l'hôtel 2, le vol 2 est assorti à l'hôtel 1 et le train 1 est assorti à l'hôtel 1. Chacune 30 de ces combinaisons peut être enregistrée comme solution de voyage pour le projet de voyage, par exemple dans la base de données de voyage 56, et peut être incluse dans une notification 64 envoyée à l'utilisateur si elle est déterminée comme étant éligible à la notification. 3057084 32 [0106] Ainsi, l'algorithme d'optimisation itérative permet au module de traitement de requête 52 d'analyser les données récupérées à partir des sources de données dorsales 58, niveau par niveau, et d'éliminer par filtrage les produits ou résultats qui ne sont pas intéressants par rapport aux critères de recherche définis par l'utilisateur. De cette façon, lorsque une donnée dorsale supplémentaire est 5 récupérée à partir des sources de données dorsales 58, la quantité de données renvoyée, sur la base des données récupérées filtrées précédemment à partir des sources de données dorsales 58, est limitée. Par conséquent, l'algorithme d'optimisation itérative réduit la quantité de données globales renvoyée à partir des sources de données dorsales 58 tout en améliorant la qualité des données renvoyées relatives à une requête de recherche 60 soumise par un utilisateur, ce qui permet de générer de meilleures réponses 62 10 plus rapidement. [0107] Comme décrit précédemment, la génération de réponses 62 à partir des données de sources récupérées pour une requête de recherche 60 peut inclure le calcul d'une RSV pour chaque réponse 62. Dans certains modes de réalisation, la RSV pour une réponse 62 donnée peut être égale à la multiplication des LSV, normalisées ou non normalisées, calculée pour chaque résultat sur lequel est basée la 15 réponse 62. Par exemple, en référence aux trois niveaux exemplaires ci-dessus, la valeur de satisfaction pour chaque solution de voyage peut être égale à la multiplication de chaque LSV non normalisée, notamment : RSV =fi(xi) * Vin W-I1 (X.1) * p k=0 Wk fk(Xk) 0 j=0 où n est égal au nombre de critères de recherche comparés au niveau général L I, m est égal au nombre de 20 critères de recherche comparés au niveau des transports L2, et p est égal au nombre de critères de recherche comparés au niveau de la destination L3. Dans cette formule, les résultats issus des sources de données dorsales 58 prises en compte aux niveaux traités ultérieurement affectent en amont les résultats pris en compte aux niveaux traités antérieurement par rapport à la RSV. De cette façon, si une réponse 62 inclut la combinaison d'un très bon résultat, par rapport aux critères de recherche, pris en compte à un 25 niveau traité antérieurement avec un moins bon résultat, par rapport aux critères de recherche, pris en compte à un niveau traité ultérieurement, le résultat pris en compte le plus tardivement aura un effet négatif sur le résultat pris en compte antérieurement par rapport à la RSV de la réponse 62. Chaque RSV peut être normalisée de façon à être dans l'intervalle de [0,100]. [0108] La FIG. 8 illustre un processus 300 pour actualiser les réponses 62 générées antérieurement 30 et enregistrées pour une requête de recherche 60. Le processus 300 peut être mis en oeuvre par le moteur de traitement de requête 52 de l'architecture de traitement 50. 3057084 33 [01091 Dans le bloc 302, les données de source relatives aux réponses antérieures 62 peuvent être récupérée ou reçues automatiquement à partir des sources de données dorsales 58. Concernant la réception automatique des données, chaque fois qu'un changement relatif à une ou plusieurs des réponses antérieures 62 survient dans les sources de données dorsales 58 (p. ex., un changement de prix pour un 5 résultat ou un produit enregistré précédemment dans les sources de données dorsales 58 et sur lequel était basée une réponse 62 générée précédemment), les sources de données dorsales 58 ou un module d'extension qui leur est associé peuvent automatiquement activer un mécanisme de pousse pour pousser les données indicatives du changement vers le module de traitement de requête 52. Par exemple, les données peuvent être poussées à partir de la source spécifique de données dorsales 58 dans laquelle est 10 survenu le changement. Alternativement, au lieu de pousser les données pour des changements qui affectent spécifiquement une ou plusieurs des réponses enregistrées 62, chaque source de données dorsales 58, ou le module d'extension qui leur est associé, peut automatiquement pousser les données indicatives de tout changement survenant, indifféremment de l'effet éventuel dudit changement sur une réponse antérieure 62. L'utilisation d'un module d'extension permet à chaque source de données 15 dorsales 58 d'être adaptée avec la capacité de fournir au module de traitement de requête 52 des notifications en temps réel pour des changements de données sans qu'il soit nécessaire de les reconfigurer complètement. Ces notifications de changement en temps réel pour des produits ou des résultats enregistrés précédemment dans les sources de données dorsales 58 produisent une forte cohésion entre les sources de données dorsales 58 et l'architecture de traitement 50, permettant à l'architecture de 20 traitement 50 de notifier plus rapidement les réponses intéressantes 62 à l'utilisateur. [0110] Concernant la récupération automatique des données, le module de traitement de requête 52 peut être configuré pour activer un mécanisme de tirage pour tirer, ou tout moins essayer de tirer, à intervalles réguliers ou irréguliers (p. ex., deux fois par semaine) des données relatives aux réponses antérieures 62 à partir des sources de données dorsales 62. Plus spécifiquement, le module de 25 traitement de requête 52 peut interroger les sources de données dorsales 58 pour obtenir des résultats et des produits sur lesquels étaient basées les réponses 62 enregistrées précédemment. De cette façon, le module de traitement de requête 52 peut récupérer toute modification, survenue dans les sources de données dorsales 58, pouvant affecter les réponses antérieures 62. [0111] Dans le bloc 304, les réponses antérieures 62 relatives à la donnée de source reçue ou 30 récupérée peuvent être récupérées, par exemple à partir de la base de données des réponses 56. Lorsque les données indicatives de changement sont automatiquement poussées à partir des sources de données dorsales 58, le module de traitement de requête 52 peut récupérer les réponses 62 de la façon illustrée dans le processus 200 (c. -à.-d., après et/ou en réponse à la réception des données). Cependant, lorsque les 3057084 34 données relatives aux réponses 62 sont récupérées à partir des sources de données dorsales 58, à intervalles réguliers ou irréguliers, le module de traitement de requête peut récupérer les réponses associées 62 avant d'interroger les sources de données dorsales 58. De cette façon, le module de traitement de requête 52 sait quelles données il doit récupérer, ou tout au moins essayer de récupérer, à partir des 5 sources de données dorsales 58 via le mécanisme de pousse. [0112] Dans le bloc 306, une ou plusieurs des réponses récupérées 62 peuvent être actualisées sur la base de la donnée de source reçue ou récupérée. Dans le cas d'une donnée reçue, le bloc 306 peut inclure un nouveau calcul de la RSV pour une ou plusieurs des réponses récupérées 62 sur la base de la donnée reçue. Dans le cas d'une donnée récupérée, le bloc 306 peut inclure la comparaison de la donnée 10 récupérée avec les réponses récupérées 62, déterminer quelles réponses récupérées 62 ne sont plus pertinentes sur la base de la comparaison et mettre à jour les réponses 62 en conséquence, ce qui peut également inclure un nouveau calcul de la RSV pour chaque réponse 62. [0113] Le bloc 306 peut aussi inclure la détermination des réponses 62 récupérées qui ne sont plus disponibles sur la base de la donnée de source récupérée. Par exemple, la donnée de source reçue ou 15 récupérée peut indiquer qu'un vol inclus dans une solution de voyage générée antérieurement est maintenant complet ou annulé. Comme autre exemple pour de donnée récupérée, si une des réponses 62 ne correspond pas complètement à la donnée récupérée, de sorte qu'aucune donnée dans les sources de données dorsales 58 n'est renvoyée pour un résultat ou un produit de la réponse 62, il se peut alors que la réponse 62 n'est plus disponible. Ces réponses 62 peuvent être actualisées en étant signalées ou encore on 20 indiquant qu'elles ne sont plus disponibles. [0114] Dans le bloc 308, la base de données des réponses 56 peut être mise à jour sur la base des réponses actualisées 62. Plus spécifiquement, chaque réponse récupérée 62 quia été modifiée ou actualisée dans le bloc 306 peut être actualisée dans la base de données des réponses 56. Alternativement, les réponses modifiées ou actualisées 62 peuvent être ajoutées dans la base de données des réponses 56 25 avec leur version précédente, ce qui permet le suivi de l'évolution des réponses 62. Par ailleurs, les réponses 62 dont il a été déterminé qu'elles ne sont plus disponibles peuvent être supprimées de la base de données des réponses 56. Alternativement, il est possible d'ajouter, dans la base de données des réponses 56, une note indiquant que la réponse 62 n'est plus disponible et/ou compatible avec les données dans les sources de données dorsales 58. 30 [0115] Dans le bloc 310, des notifications 64 peuvent être traitées pour chacune des réponses actualisées 62 modifiées ou mises à jour. Plus particulièrement, il est possible de déterminer si chacune des réponses actualisées 62 est éligible à la notification. En réponse à une détermination indiquant qu'une 3057084 réponse 62 modifiée ou mise à jour est éligible à la notification, la réponse 62 actualisée peut être notifiée à l'utilisateur. [0116] La FIG. 9 illustre un processus 400 pour déterminer si les réponses 62 générées pour une nouvelle requête de recherche 60 sont éligibles à la notification. Plus spécifiquement, la première fois que 5 les réponses 62 sont générées pour une requête de recherche 60 (désignées par la suite comme eréponses initiales », le processus 400 peut déterminer, pour chaque réponse initiale 62, si la notification à un utilisateur doit être faite immédiatement ou peu de temps après, lors de la prochaine notification périodique 64, ou décider qu'aucune notification n'est nécessaire. Le processus 400 peut être implémenté par le module de traitement de requêtes 52 de l'architecture de traitement 50 et peut être mis en oeuvre 10 après la génération des réponses 62 pour une nouvelle requête de recherche 60 (p. ex., dans le bloc 116 de la FIG. 4). [0117] Dans le bloc 402, les réponses initiales 62 qui n'ont pas été générées pour une nouvelle requête de recherche 60 peuvent être récupérées, par exemple à partir de la base de données des réponses 56. Plus spécifiquement, le module de traitement de requête 52 peut être configuré pour 15 récupérer, à intervalles réguliers ou irréguliers, les réponses initiales 62 qui ont été générées pour une nouvelle requête de recherche 60, telles que les réponses 62 générées la première fois dans les blocs 108 à 114 sont effectuées imipour une requête de recherche 60 dans la FIG. 4. Alternativement, le module de traitement de requête 52 peut commencer le traitement de l'éligibilité à la notification pour les réponses initiales 62 générées pour une nouvelle requête de recherche 60 immédiatement après la génération et/ou 20 l'enregistrement des réponses initiales 62. [0118] Dans le bloc 404, pour chaque réponse initiale 62, il est possible de déterminer si la RSV pour la réponse initiale 62 est supérieure ou égale au seuil, spécifié ou déterminé de notification. Ce seuil peut être spécifié par l'utilisateur lors de la création de la requête de recherche 60, il peut aussi être préprogrammé dans le module de traitement de requête 52, par exemple par un administrateur du système 25 ou un autre utilisateur, ou il est possible de le déterminer de façon empirique en fonction des réponses initiales 62 elles-mêmes (p. ex., la limite la plus basse d'une fenêtre supérieure 604 sur une échelle de confiance 600 peut représenter le seuil de notification, comme illustré dans la FIG. 12). En réponse à la détermination indiquant que la RSV pour une réponse initiale récupérée 62 est supérieure ou égale au seuil de notification (branche « oui » du bloc de 404), dans le bloc 406, la réponse initiale 62 peut alors être 30 signalée comme étant éligible à une notification supplémentaire 64, ce qui peut indiquer au module de traitement de requête 52 que la réponse initiale 62 doit être immédiatement notifiée à l'utilisateur, ou doit être notifiée dans la mesure du possible avant la prochaine notification périodique 64. Cependant, en réponse à la détermination indiquant que la RSV pour la réponse initiale 62 est inférieure au seuil, spécifié 3057084 36 ou déterminé, de notification (branche « non » du bloc 404), dans le bloc 408, il est alors possible de déterminer si la réponse initiale 62 est l'une des meilleures réponses initiales 62 générées pour la nouvelle requête de recherche 60. [0119] Plus spécifiquement, pour chaque réponse initiale 62 générée pour une nouvelle requête de 5 recherche 60, le module de traitement de requête 52 peut être configuré pour déterminer si la réponse 62 fait partie d'un sous-ensemble des réponses initiales 62, où la RSV pour chaque réponse initiale 62 dans le sous-ensemble est supérieure à la RSV pour chaque réponse initiale 62 ne faisant pas partie du sous-ensemble. En d'autres termes, le module de traitement de requête 52 peut déterminer les meilleures réponses initiales 62 N, en fonction de la RSV calculée pour chaque réponse initiale 62, où N peut être 10 calculé par l'utilisateur lors de la création de la requête de recherche 60, ou peut être déterminé de façon empirique par le module de traitement de requête 52. En réponse à la détermination qu'une réponse initiale 62 est une des N meilleures réponses initiales 62 (branche « oui » du bloc 408) la réponse initiale 62 peut alors, au bloc 410, faire l'objet d'un signalement d'éligibilité à la prochaine notification périodique 64 envoyée à l'utilisateur. Alternativement, en réponse à la détermination qu'une réponse initiale 62 n'est pas 15 l'une des N meilleures réponses initiales 62 (branche « non » du bloc 408), il est alors possible de déterminer au bloc 412 que la réponse initiale 62 n'est pas éligible à la notification. [0120] En général, le but des notifications périodiques 64 est d'informer l'utilisateur des nouvelles réponses 62, actualisées ou trouvées récemment pour une requête de recherche donnée 60, qui peuvent vraisemblablement intéresser l'utilisateur. Dans ce but, la fréquence des notifications périodiques 20 souhaitées par l'utilisateur, telle qu'une fois par mois ou deux fois par mois, peut être définie par l'utilisateur via la GUI 61, et faire partie de la requête de recherche 60. La GUI 61 peut aussi permettre à un utilisateur de changer ces réglages, ou d'autres réglages, après la création de la requête de recherche 60. Le nombre de réponses 62 par notification périodique 64, ou toute autre notification 64 générée par le module de traitement de requête 62, peut être limité, par exemple par un administrateur du système ou par 25 l'utilisateur via la GUI 61. Par conséquent, si au cours de la génération d'une notification périodique 64 le nombre de réponses 62 signalées pour notification périodique 64 dépasse une limite, seules les meilleures d'entre elles (sur la base de la RSV) peuvent être incluses dans la notification périodique 64. Pour celles qui ne sont pas incluses, la notification périodique 64 peut inclure une notice indiquant que des réponses intéressantes 62 supplémentaires pour la requête de recherche 60 peuvent être consultées via la GUI 61. 30 Dans certains modes de réalisation, seuls les utilisateurs VIP peuvent avoir accès à cette fonctionnalité pour consulter de telles réponses intéressantes supplémentaires 62 via la GUI 61. [0121] La FIG. 10 illustre un processus 500 pour déterminer si des réponses 62 actualisées ou de nouvelles réponses 62 générées pour une requête de recherche 60 déjà traitée, c'est-à-dire que les 3057084 37 réponses 62 générées lors de la mise en oeuvre successive d'un ou de plusieurs des blocs 110 à 114 du processus 100 sont éligibles à la notification. Le processus 500 peut être effectué par le module de traitement de requête 52 de l'architecture de traitement 50 et peut survenir au bloc 116 du processus 100 et au bloc 310 du processus 300. 5 [0122] Dans le bloc 502, chaque nouvelle réponse ou chaque réponse actualisée 62 peut être récupérée, par exemple à partir de la base de données des réponses 56. Plus particulièrement, le module de traitement de requête 52 peut, à intervalles réguliers ou irréguliers, interroger la base de données des réponses 56 pour obtenir de nouvelles réponses ou des réponses actualisées 62 qui ont été générées pour des requêtes de recherche 60 déjà traitées. Au bloc 504, il est possible de déterminer pour chaque réponse 10 récupérée 62 si la réponse 62 inclut un abonnement. Alternativement, dès qu'une nouvelle réponse ou une réponse actualisée 62 est générée, le module de traitement de requête 52 peut être configuré pour faire cette détermination. Quel que soit le cas, en réponse à la détermination indiquant que la réponse 62 n'inclut pas d'abonnement (branche « non » du bloc 504), la réponse 62 peut alors être ajoutée au bloc 506 à une file d'attente de « faible priorité ». En réponse à une détermination indiquant que la réponse 62 inclut 15 un abonnement (branche « oui » du bloc 504), la réponse 62 peut alors être placée au bloc 508 dans une file d'attente de « priorité élevée ». Par conséquent, toutes les réponses 62 enregistrées dans la file d'attente de priorité élevée peuvent inclure des abonnements et aucune des réponses 62 enregistrées dans la file d'attente de faible priorité ne peut inclure d'abonnement. [0123] Après le placement des réponses 62 dans les files d'attente, les réponses 62 peuvent être 20 récupérées au bloc 510 dans les files d'attente en commençant par celles de la file d'attente de priorité intervalles réguliers ou irréguliers, pour récupérer et déterminer l'éligibilité à la notification de chaque réponse 62 placée dans la file d'attente de priorité élevée et, une fois que la file d'attente de priorité élevée est vide, peut par la suite récupérer et déterminer l'éligibilité à la notification de chaque réponse 62 placée 25 dans la file d'attente de faible priorité. De cette façon, les réponses 62 auxquelles l'utilisateur s'est abonné peuvent être traitées pour l'éligibilité à la notification avant toute autre nouvelle réponse ou réponse actualisée 62. [0124] Au bloc 512, pour chaque réponse 62 récupérée dans les files d'attente, il est possible de déterminer si la réponse 62 provient de la file d'attente de priorité élevée ou de la file d'attente de faible 30 priorité. Si la réponse 62 provient de la file d'attente de priorité élevée (branche « élevée » du bloc 512), la réponse 62 inclut alors un abonnement. Par conséquent au bloc 514 il est possible de déterminer si la réponse 62 satisfait un seuil de notification d'abonnement. Alternativement si une réponse 62 provient de la file d'attente de faible priorité (branche « faible » du bloc 512) alors l'utilisateur ne s'est pas abonné à la II - III - - - élevée. Plus s e nfiguré, par exemple à - - e - - 3057084 38 réponse 62. Dans ce cas, il est possible de déterminer au bloc 516 si la réponse 62 satisfait un seuil de notification supplémentaire. [0125] Dans certains modes de réalisation, le seuil d'abonnement peut inclure un intervalle associé à un critère particulier, tel que le prix, calculé pour chaque réponse 62 comportant un abonnement avant 5 que la réponse 62 ne soit actualisée. Plus spécifiquement, chaque réponse 62, comportant un abonnement, peut être associée à un prix et à un intervalle de prix calculé. Si au cours de la mise à jour, le prix associé à une réponse 62 comportant un abonnement dépasse la limite supérieure ou la limite inférieure d'un intervalle de prix associé à la réponse 62, il est alors possible de déterminer que la réponse 62 actualisée satisfait le seuil de notification d'abonnement (branche « oui » du bloc 514) et en réponse, la réponse 62 10 peut être signalée au bloc 518 comme étant éligible à une notification d'abonnement 64, ce qui peut indiquer que la réponse 62 doit être notifiée à l'utilisateur immédiatement ou autant que possible avant la prochaine notification périodique 64. Alternativement, si le prix associé à la réponse 62 comportant un abonnement ne dépasse pas la limite supérieure ou la limite inférieure de l'intervalle de prix associé à la réponse 62 lors de la mise à jour, il est alors possible de déterminer que la réponse actualisée 62 ne 15 satisfait pas le seuil d'abonnement (branche « non » du bloc 514) et il est ensuite possible de déterminer au bloc 516 si la réponse 62 provenant de la file d'attente de priorité élevée satisfait le seuil de notification supplémentaire. [0126] L'intervalle de prix calculé pour chaque réponse 62 comportant un abonnement peut être basé sur un prix actuel associé à la réponse 62 après la souscription à la réponse 62, mais avant la mise à 20 jour de la réponse 62. Plus spécifiquement, quand un utilisateur s'abonne à une réponse 62, l'intervalle de - I I - 11^- 18 de prix peut être calculé en utilisant la formule suivante : 25 [prix actuel - y% * prix actuel; prix actuel + y% * prix actuel] où y% est une proportion du prix actuel. Dans certains modes de réalisation, y% peut être déterminé en utilisant la formule suivante : b * eo- vfx où x est le prix actuel associé à la réponse 62 comportant l'abonnement, et b est une valeur de largeur (c.30 à-d., y%) pour un prix particulier a. Cette formule peut donc être configurée avec un seul point de et b , qui peut être basé sur les critères de la requête de recherche 60. Après le calcul de l'intervalle de prix, si la réponse 62 est mise à jour, il est possible de déterminer si la mise à jour affecte le prix associé à la 3057084 39 réponse 62 en le faisant sortir de l'intervalle de prix calculé précédemment. Dans ce cas la réponse 62 peut alors faire l'objet d'un signalement pour une notification d'abonnement 64. [0127] La FIG. 11 illustre une courbe pouvant représenter la valeur de y% lors d'un changement du prix, actuellement associé à une réponse 62. Dans le mode de réalisation illustré, lorsque le prix actuel 5 associé à une réponse 62 comportant un abonnement est deux cent cinquante euros, la valeur de y% est 20 %. Par conséquent pour qu'une version actualisée de la réponse 62 puisse satisfaire le seuil d'abonnement, le prix de la réponse 62 devra, soit dépasser trois cent cinquante euros, soit descendre en dessous de deux cents euros, qui sont les limites supérieures et inférieures respectives de l'intervalle de prix. Alternativement, si le prix actuel associé à une réponse 62 comportant un abonnement est cinq cents 10 euros, alors la valeur de y% est 10 %. Par conséquent, il faut un changement moins important du prix associé à la réponse 62 comportant un abonnement pour satisfaire le seuil d'abonnement de la réponse 62. L'intervalle de prix pour une réponse 62 ne peut être reconstruit, par exemple en utilisant les formules ci-dessus, que si la limite supérieure ou inférieure de l'intervalle de prix de la réponse 62 est dépassée. Dans ce cas un nouvel intervalle de prix peut alors être calculé pour la réponse 62 sur la base du prix actuel 15 associé à la version actualisée de la réponse 62. [0128] Faisant à nouveau référence à la FIG.10, en réponse à la détermination qu'une réponse 62 provenant de la file d'attente de faible priorité, ou en réponse à la détermination qu'une réponse 62 comportant un abonnement, ne satisfait pas le seuil de notification d'abonnement, il est alors possible au bloc 516 de déterminer si la réponse 62 satisfait un seuil de notification supplémentaire. Le but de la 20 notification supplémentaire 64 peut être de notifier immédiatement les réponses 62 à l'utilisateur - II - - 1" très élevée, ou substantiellement meilleure, que celle d'autres réponses 62), ou de notifier ces réponses 62 à l'utilisateur au moins avant la prochaine notification périodique 64. [0129] Dans c-ertains modes de réalisation, le fait de satisfaire un seuil de notification 25 supplémentaire peut être basé sur une échelle de confiance générée pour la requête de recherche pour laquelle la réponse 62 est générée. En particulier, après la génération d'un ensemble initial de réponses 62 pour une requête de recherche 60, ou après le traitement pour l'éligibilité à la notification de nouvelles réponses 62 ou de réponses 62 actualisées pour une requête de recherche 60 déjà traitée, le module de traitement de requête 52 peut être configuré pour générer une échelle de confiance pour la requête de 30 recherche 60 sur la base des réponses 62 actuelles pour la requête de recherche 60. L'échelle de confiance peut varier de 0 % à 100 % et chaque réponse initiale peut être comparée à l'échelle de confiance en fonction de sa RSV. 3057084 [0130] La FIG. 12 illustre une échelle de confiance 600 générée pour une requête de recherche 60. L'échelle de confiance 600 peut inclure plusieurs seuils 602, chacun étant associé à une RSV différente. En général, le module de traitement de requête 52 peut utiliser les seuils 602 pour déterminer si une réponse 62 doit être notifiée à un utilisateur par une notification supplémentaire 64 et/ou par une 5 notification périodique 64. Le nombre et le placement des seuils 602 sur l'échelle de confiance 600 peuvent être basés sur la stratégie utilisée pour calculer la RSV de chaque réponse 62 et peut tenir compte de la densité et de la répartition des RSV des réponses 62 générées pour la requête de recherche 60, et du changement dans une réponse 62 devant être exigé avant que la réponse 62 ne soit notifiée à un utilisateur. Comme le montrent les modes de réalisation illustrés, la fréquence des seuils 602 sur l'échelle de 10 confiance 600 augmente au fur et à mesure que la RSV augmente. Par conséquent, la distance entre deux seuils consécutifs 602 situés dans les portions supérieures de l'échelle de confiance 600 peut être plus petite que la distance entre deux seuils consécutifs 602 situés dans les portions inférieures de l'échelle de confiance 600, ce qui permet d'augmenter les notifications 64 d'un plus grand nombre de réponses intéressantes 62 par rapport aux réponses moins intéressantes 62 (c. -à.-d., les réponses 62 dont les RSV 15 sont plus basses). [0131] L'échelle de confiance 600 peut par ailleurs inclure une fenêtre supérieure 604 représentant un intervalle commençant à un certain seuil 602 sur l'échelle de confiance 600 jusqu'à la valeur maximum sur l'échelle de confiance 600 (p. ex., 100 %). Lorsque la RSV calculée pour une réponse 62 se situe dans la fenêtre supérieure 604, on peut considérer que la réponse est très intéressante pour l'utilisateur. Par 20 conséquent, si la RSV d'une réponse 62 générée précédemment passe dans la fenêtre supérieure 604 au cours de la mise à jour, ou si la RSV pour une nouvelle réponse générée 62 est située dans la fenêtre supérieure 604, le module de traitement de requête 52 peut alors être configuré pour déterminer si la réponse 62 satisfait un seuil de notification supplémentaire (branche « oui » du bloc 516 dans la FIG. 9) et, en réponse, peut signaler la réponse 62 comme étant éligible à une notification supplémentaire 64 25 (bloc 520 de la FIG. 9). Alternativement, si la RSV pour une réponse 62 générée précédemment ne passe pas dans la fenêtre supérieure 604 au cours de la mise à jour, ou que la RSV pour une nouvelle réponse générée 62 n'est pas située dans la fenêtre supérieure 604, le module de traitement de requête 52 peut être configuré pour détérthiner que la réponse 62 ne satisfait pas un seuil de notification supplémentaire (branche « non » du bloc 516 dans la FIG. 9). 30 [0132] L'échelle de confiance 600, et plus particulièrement la fenêtre supérieure 604, peut être définie selon la requête de recherche 60 et peut être dynamique, de sorte que la limite inférieure de la fenêtre supérieure 604 est recalculée après la génération et/ou le traitement pour l'éligibilité à la notification des nouvelles réponses ou des réponses actualisées qui sont générées. Spécifiquement, la 3057084 41 fenêtre supérieure 604 peut être calculée sur la base des RSV des réponses 62, actuelles ou générées le plus récemment, et non sur la base des réponses historiques 62, puisque le but de la fenêtre supérieure 604 est de mettre en valeur les très bonnes réponses 62 dans le contexte actuel. En général, l'échelle de confiance 600 doit être compatible avec le contexte des réponses actuelles 62 pour la requête de 5 recherche 60 afin de révéler les « rares » réponses 62 qui sont le plus susceptibles d'intéresser l'utilisateur. Par exemple, une requête de recherche 60 ayant des réponses 62 pour lesquelles les RSV sont typiquement autour de 60 % peut avoir une fenêtre supérieure 604 qui commence aux alentours de 80 %. De cette façon, si périodiquement, une réponse 62 dont la RSV est supérieure à 80 % est générée, la réponse 62 peut être considérée comme étant très intéressante pour l'utilisateur et peut ensuite être notifiée à 10 l'utilisateur par une notification supplémentaire 64. Si de meilleures réponses 62 commencent à être générées de façon régulière, de sorte que la moyenne générale des RSV des réponses actuelles 62 s'élève aux alentours de 70 %, la limite inférieure de la fenêtre supérieure 604 peut alors être recalculée et élevée à 90 %. [0133] Lors du calcul de la limite inférieure de la fenêtre supérieure 604 pour une requête de 15 recherche 60, la moyenne et l'écart type de la RSV des réponses actuelles 62 pour la requête de recherche 60 peuvent être pris en compte. On peut considérer que les réponses actuelles 62 pour une requête de recherche 60 incluent toute réponse 62 générée et stockée pour la requête de recherche 60 qui est supposée refléter correctement les données actuelles dans les sources de données dorsales 58. Par exemple, des versions précédentes de réponses 62 actualisées et de réponses 62 signalées comme n'étant 20 plus disponibles peuvent être exclues de la signification de « réponses actuelles » 62. Dans certains modes de réalisatin la limite inférieure de la fenêtre supérieure 604 peut être calculée pour une requête de recherche 60 en utilisant la formule suivante relative aux réponses actuelles 62 de la requête de recherche 60. 25 Limite inférieure = Coef * Avg RSV + o où Avg RSV est la moyenne des RSV des réponses actuelles 62, et o est l'écart type des RSV des réponses factuelles 62. En général Coef peut être une valeur variable basée sur la Avg RSV des réponses actuelles 62 et d'autres contraintes universelles préprogrammées dans le module de traitement de 30 requête 52, par exemple par un administrateur du système ou un autre utilisateur. En particulier, Coef peut être une fonction des contraintes universelles applicables à toute et/ou toutes réponses 62 et de l'Avg RSV des réponses actuelles 62. Le fait de baser le Coef sur de telles contraintes universelles, et sur l'Avg RSV des réponses actuelles 62 peut permettre à un administrateur ou à un autre utilisateur de 3057084 42 manipuler la fenêtre supérieure 604 pour chacune et/ou un ensemble de réponses actuelles 62 sur la base des préférences de l'administrateur ou de l'utilisateur (c. -à.-d., les contraintes universelles). Par exemple, dans certains modes de réalisation, la valeur du Coef peut être calculée via la formule suivante 5 Coef = avg2 - avgl* avg RSV + yl Y2 - y1 y2- yl avg2 - avgl* avgl 15 où y1 est un Coef donné qui serait souhaité, par un administrateur de système ou autre utilisateur, pour une Avg RSV donnée (qui est la valeur de avgl), et y2 est un Coef donné qui serait souhaité, par exemple par un administrateur du système ou autre utilisateur, pour une Avg RSV donnée (qui est la valeur de avg2). Par exemple, en supposant que o est zéro, (avg1, y1) peut être fixé à (60 %, 1,33), 10 signifiant que lorsque Avg RSV est à 60 %, il est souhaitable que le Coef soit de 1,33. Cependant, la valeur du Coef ne fonctionnerait pas pour une Avg RSV de 90 %, car en supposant que a est zéro,. 9 x 1.33 résulterait en une limite inférieure de 1,20 ou 120 %, ce qui serait trop important et ne ferait aucun sens pour une limite inférieure. Par conséquent, (avg2, y2) peut être fixé à (90 %, 1,06), ce qui signifie que lorsque Avg RSV est 90 %, le Coef souhaité est 1,06. [0134] Faisant référence à nouveau à la FIG. 10, en réponse à la détermination indiquant que la réponse 62 ne satisfait pas un seuil de notification supplémentaire (branche « non » du bloc 516), il est alors possible au bloc 522 de déterminer si la réponse 62 satisfait un seuil de notification périodique. De nouveau, le module de traitement de requête 52 peut être configuré pour faire cette détermination sur la 20 base de ' . 8110 réponse 62. Spécifiquement, si au cours de la mise à jour, une réponse 62 passe un seuil 602 sur l'échelle de confiance 600, le module de traitement de requête 52 peut alors être configuré pour déterminer que la réponse 62 satisfait un seuil de notification périodique. Dans le cas contraire, le module de traitement de requête 52 peut être configuré pour déterminer que la réponse 62 ne satisfait pas un seuil de notification 25 périodique. [0135] Si dans le bloc 522 il est déterminé que la réponse 62 ne satisfait pas un seuil de notification périodique (branche « non » du bloc 522), alors en réponse, une détermination peut être faite au bloc 524 indiquant que la réponse 62 n'est pas éligible à la notification. Alternativement, si une détermination est faite indiquant que la réponse 62 satisfait un seuil de notification périodique (branche 30 « oui » du bloc 522); alors en réponse, au bloc 526, la réponse 62 peut être signalée comme étant éligible à une notification périodique 64. - a- si 1111 .11 et, - - .1 3057084 43 [0136] Au bloc 528, les notifications 64 peuvent être générées pour les réponses 62 signalées pour notifications d'abonnement 64, notifications supplémentaires 64 et/ou notifications périodiques 64, et peuvent être transmises à l'utilisateur. Le moment choisi pour la mise en oeuvre du bloc 528 peut dépendre du type de notification 64. Par exemple, après le signalement qu'une réponse 62 comporte une notification 5 d'abonnement 64 ou demande une notification supplémentaire 64, le bloc 528 peut être mis en oeuvre immédiatement pour la réponse 62 signalée afin de notifier la réponse 62 à l'utilisateur dès que possible. Alternativement, le bloc 528 peut être effectué pour les réponses 62 signalées pour une notification supplémentaire 64 ou une notification d'abonnement 64 après le traitement de l'éligibilité à la notification d'une portion des réponses 62 récupérées dans le bloc 502, ou après le traitement de l'éligibilité de toutes 10 les réponses 62 récupérées dans le bloc 502. [0137] Dans d'autres modes de réalisation, le bloc 528 peut être effectué à un intervalle de temps après un premier signalement de la réponse 62 pour une notification d'abonnement 64 ou une notification supplémentaire 64. Plus particulièrement, une fois qu'un certain délai est écoulé après le signalement d'une première réponse 62 pour une notification d'abonnement 64 ou une notification supplémentaire 64, le 15 module de traitement de requête 52 peut générer une notification 64 pour toutes les réponses 62 n'ayant pas encore été signalées pour un abonnement ou une notification supplémentaire 64 et n'ayant pas encore été notifiées, sous réserve de toute limite placée sur le nombre de réponses 62 pouvant être inclus dans une notification 64 donnée et le nombre de notifications 64 qu'un utilisateur souhaite recevoir, ce qui peut être configuré par l'utilisateur via la GUI 61. 20 [0138] Par exemple, plutôt que d'envoyer une notification 64 pour chaque réponse 62 signalée our une n tif . - ... peuvent être regroupées en utilisant une fenêtre de temps. Plus spécifiquement, quand une réponse 62 pour une requête de recherche 60 est signalée pour une notification d'abonnement 64, le module de traitement de requête 52 peut effectuer une vérification pour déterminer s'il existe déjà une fenêtre de temps pour la 25 requête de recherche 60. Si ce n'est pas le cas, le module de traitement de requête 52 peut créer une nouvelle fenêtre de temps pour la requête de recherche 60. Lorsque la fenêtre de temps prend fin, le module de traitement de requête 52 peut générer et transmettre une seule notification 64 à l'utilisateur qui inclut chaque réponse 62 n'ayant pas été signalée pour une notification d'abonnement 64 pendant l'ouverture de la fenêtre de temps. La même procédure peut être utilisée pour les réponses 62 signalées 30 pour des notifications supplémentaires 64. Alternativement, lorsque la fenêtre de temps prend fin, le module de traitement de requête 52 peut générer et transmettre une seule notification 64 à l'utilisateur incluant chaque réponse 62 n'ayant pas été signalée pour une notification d'abonnement 64 ou pour une - 3057084 44 notification supplémentaire 64 pendant l'ouverture de la fenêtre de temps. De cette façon, le nombre de notifications 64 générées et envoyées à l'utilisateur est davantage réduit. [0139] Les notifications supplémentaires 64 et les notifications d'abonnement 64 peuvent être en supplément des notifications périodiques 64 qui sont des notifications 64 générées et transmises à 5 l'utilisateur sur une base périodique, éventuellement selon des réglages saisis par l'utilisateur via la GUI 61. Quand il est temps d'envoyer une notification périodique 64 pour une requête de recherche 60, le module de traitement de requête 52 peut être configuré pour générer automatiquement une notification 64 incluant chaque réponse 62 pour une requête de recherche 60 signalée pour une notification 64, qu'il s'agisse d'une notification d'abonnement 64, d'une notification supplémentaire 64, ou d'une notification 10 périodique 64, sous réserve des limites placées sur le nombre de réponses 62 pouvant être inclus dans une notification 64. Dès qu'une réponse 62 est incluse dans toute notification 64 envoyée à l'utilisateur, le signalement est supprimé. De cette façon, si une réponse 62 signalée pour une notification d'abonnement 64 ou une notification supplémentaire 64 est incluse dans une notification périodique régulière planifiée 64, la réponse 62 ne sera pas envoyée à nouveau dans une notification d'abonnement 64 15 ou une notification supplémentaire 64 ce qui évite des redondances et réduit par ailleurs le nombre de notifications 64 générées par le module de traitement de requête 52. En réduisant le nombre de notifications 64 qui sont générées par le module de traitement de requête 52, la pression sur les ressources du système est davantage réduite davantage. [0140] L'utilisateur peut choisir d'activer ou de désactiver les notifications supplémentaires 64 et 20 les notifications d'abonnement 64 pour une requête de recherche 60 via la GUI 61. L'utilisateur peut aussi restreindre . . 5 5 par période. Par exemple, l'utilisateur peut définir la requête de recherche 60 de telle façon qu'une seule notification supplémentaire 64 et/ou notification d'abonnement 64 peut être envoyée par semaine, ou un nombre illimité de notifications supplémentaires 64 et/ou de notifications d'abonnement 64 peuvent être 25 envoyées chaque semaine. [0141] L'architecture de traitement 50 peut inclure des caractéristiques additionnelles autres que celles qui ont été décrites ci-dessus. Dans un mode de réalisation, l'architecture de traitement 50 peut inclure une caractéristique de prédiction de prix. Plus particulièrement, le module de traitement de requête 52 peut être configuré pour calculer avec un pourcentage de confiance une prédiction du prix 30 associé à une réponse 62 ou un produit de voyage en utilisant les données historiques telles que les réponses 62 enregistrées dans la base de données des réponses 56. De cette façon, le module de traitement de requête 52 peut prédire la variation de prix pour une future réponse 62. I - 11 - - " 11 - 3057084 [0142] De plus, l'architecture de traitement 50 peut être associée avec un système de profils qui inclut les profils d'utilisateurs multiples. Dans le temps, par exemple lorsqu'un utilisateur soumet des requêtes de recherche 60 pour traitement, l'architecture de traitement 50 peut être configurée pour mettre à jour le profil de l'utilisateur sur la base des requêtes de recherche 60 soumises par l'utilisateur. 5 Spécifiquement, l'architecture de traitement 50 peut être configurée pour suivre les requêtes de recherche 60 soumises par un utilisateur et suivre par la suite les réponses 62 générées pour la requête de recherche 60, telles que des solutions de voyage, qui sont utilisées ou réservées par l'utilisateur, et déterminer ainsi les préférences de l'utilisateur en mesurant la relation entre les requêtes de recherche 60 de l'utilisateur et les réponses 62 que l'utilisateur utilise ou pour lesquelles il confirme la réservation. En 10 outre, plutôt que de laisser le soin à un utilisateur d'affecter des poids manuellement à chaque critère de recherche d'une requête de recherche 60 soumise via la GUI 61, le module de traitement de requête 52 peut utiliser les données historiques et le profil de l'utilisateur actualisé en continu pour calculer ces poids automatiquement. Le module de traitement de requête 52 peut aussi utiliser les données historiques et le profil actualisé de l'utilisateur pour adapter les fonctions floues appliquées dans l'algorithme 15 d'optimisation itérative et pour ajouter des informations inférées ou des valeurs aux LSV décrites ci- dessus. [0143] Par ailleurs, l'architecture de traitement 50 peut aussi être associée à un système de recommandations permettant à l'architecture de traitement 50 d'inférer les préférences d'un utilisateur sur la base des critères de recherche définis par l'utilisateur dans une requête de recherche 60 et/ou en fonction 20 du profil de l'utilisateur, et qui permettent à l'architecture de traitement 50 de fournir des suggestions pour une requête de recherche 60 ou de fournir de meilleures réponses 62 basées sur les préférences de l'utilisateur. Par exemple, si un utilisateur crée un projet de voyage indiquant le désir de visiter Paris pendant un weekend dans les quatre mois à venir, l'architecture de traitement 50 peut suggérer un weekend dédié, en fonction des manifestations prévues pour cette destination (p. ex., un concert, un match 25 de football, des réductions offertes par des voyagistes) et des préférences de l'utilisateur. L'architecture de traitement 50 peut par ailleurs être intégrée avec des programmes de fidélisation et peut-être capable de fournir des suggestions pour la requête de recherche 60 d'un utilisateur ou de personnaliser des réponses 62 pour une requête de recherche 60 en fonction du profil de l'utilisateur et d'un ou de plusieurs programmes de fidélisation (p. ex., certaines solutions de voyage peuvent être suggérées en fonction du 30 nombre de points [miles] disponibles sur les comptes de fidélité de l'utilisateur). [0144] En général, les routines exécutées pour mettre en oeuvre les modes de réalisation de l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou 3057084 46 même un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme « code de programme informatique » ou simplement « code de programme ». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à divers moments dans des dispositifs divers de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou 5 plusieurs processeurs dans un ordinateur, amènent l'ordinateur à mettre en oeuvre les opérations nécessaires pour réaliser les opérations et/ou les éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un programme informatique lisibles par ordinateur pour accomplir les opérations des modes de réalisation de l'invention peuvent être, par exemple : le langage d'assemblage ou, un code source ou un code objet, écrit en combinaison avec un ou plusieurs langages de 10 programmation. [0145] Divers codes de programme décrits dans les présentes peuvent être identifiés, selon l'application dans laquelle ils sont implémentés dans des modes de réalisation spécifiques de l'invention. Cependant, on remarquera que toute nomenclature, d'un programme particulier suivant, est utilisée uniquement par commodité ; ainsi l'invention ne peut être limitée à un seul usage dans toute application 15 spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme entre diverses couches de logiciels qui résident dans un ordinateur typique (par ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de 20 programme [API], les applications, les applets, etc.), on remarquera que les modes de réalisation de 11 veres e programme telles qu'elles sont décrites dans les présentes. [0146] Le code de programme mis en oeuvre dans toutes les applications/modules décrits dans les présentes peut être distribué individuellement ou collectivement comme un produit-programme 25 informatique, sous une variété de formes. En particulier, le code de programme peut-être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur en amenant un processeur à exécuter des aspects des modes de réalisation de l'invention. [0147] Les supports de stockage de données lisibles par ordinateur et qui sont intrinsèquement durables, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, 30 implémentés dans toute méthode ou technologie de stockage de données, telles que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent par ailleurs inclure la mémoire aléatoire (RAM), la mémoire morte (ROM), la mémoire à lecture seule, programmable et effaçable (EPROM), la 3057084 47 mémoire à lecture seule, programmable et effaçable électriquement (EEPROM), la mémoire flash, ou toute technologie de support solide de mémoire, le disque compact portable doté d'une mémoire à lecture seule (CD-ROM), ou tout autre stockage optique, les bandes d'enregistrement magnétique, la mémoire à disque magnétique, ou tout autre médium pouvant être utilisé pour stocker l'information désirée et pouvant 5 être déchiffré par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (par exemple, des ondes radio ou toutes autres ondes électromagnétiques se propageant à travers un support de transmission telle qu'un guide d'ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout 10 autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau. [0148] Les instructions de programme lisibles par ordinateur, stockées dans un support lisible par ordinateur, peuvent être utilisées pour instruire un ordinateur, d'autres types d'appareils programmables de traitement ou d'autres dispositifs pour fonctionner d'une façon particulière, de sorte que les instructions 15 stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies par un ou plusieurs processeurs sur un ordinateur à usage général, un ordinateur à usage spécial, ou tout autre appareil programmable de traitement de données pour produire 20 une machine telle que les instructions qui s'exécutent par l'intermédiaire d'un ou de plusieurs processeurs rovo - uen , ac ions e operations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs. [0149] Dans certains modes de réalisation alternatifs, les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagramme séquentiel et/ou diagrammes blocs peuvent inclure plus ou 25 moins de blocs que ceux qui sont illustrés tout en restant conformes avec les modes de réalisation de l'invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés conformément à des modes de réalisation de l'invention. [0150] La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n'est pas destinée à limiter les modes de réalisation de l'invention. Les formes 30 singulières des articles indéfinis « un », « une », « le » et « la » tels qu'ils sont utilisés dans les présentes sous-entend également les formes plurielles, sauf s'il en est indiqué autrement et clairement par le contexte. On comprendra par ailleurs que les formes verbales « comprend » et/ou « comprenant », lorsqu'elles sont utilisées dans cette spécification, précisent la présence de caractéristiques, de nombres 3057084 48 entiers, d'étapes, d'opérations, d'éléments, et/ou de composants, mais n'excluent pas la présence ou l'ajout d'un ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes, en cela. De plus, dans la mesure où les termes « inclure », « ayant », «a », « avec », « composé de » ou des variantes de ceux-là, sont utilisés dans la description détaillée et les revendications, ces termes sont censés 5 être inclusifs de façon similaire à la forme verbale « comprenant ». [0151] Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il, n'est pas de l'intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, l'étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles apparaitront aisément aux hommes 10 de métier. L'invention sous un angle plus large n'est donc pas limitée aux détails spécifiques, aux procédés et aux appareils représentatifs, et aux illustrations montrées et décrites à titre d'exemple. Par conséquent, il est possible de s'éloigner de ces détails sans s'éloigner de l'esprit et de la portée du concept inventif général de l'appliquant. REVENDICATIONS1. Un procédé pour le traitement d'une requête de recherche, le procédé comprenant : la réception, au niveau d'un ou de plusieurs processeurs d'ordinateur, de la requête de recherche, la requête de recherche comprenant des critères de recherche ; l'enregistrement de la requête de recherche, par un ou plusieurs processeurs d'ordinateur, dans un ou plusieurs dispositifs de stockage permanents, et la mise en oeuvre de façon périodique et automatique, par un ou plusieurs processeurs d'ordinateur, des actions suivantes : la récupération de la requête de recherche dans un ou plusieurs dispositifs de stockage permanents, la récupération, à l'aide d'un algorithme d'optimisation itérative, de la première donnée de source liée à la requête de recherche à partir d'une ou de plusieurs sources de données dorsales, la génération d'une pluralité de réponses pour la requête de recherche sur la base de la première donnée de source, la détermination de l'éligibilité à la notification de chacune des réponses sur la base des critères de recherche, et la notification à un utilisateur de chaque réponse déterminée comme étant éligible à la notification. d'interruption, et les opérations sont effectuées périodiquement et automatiquement jusqu'à ce que le point d'interruption soit atteint. 3. Le procédé selon la revendication 1 ou la revendication 2, dans lequel une ou plusieurs des sources de données dorsales comprennent une pluralité de sources de données dorsales, et la récupération de la première donnée de source à partir d'une ou de plusieurs des sources de données dorsales en utilisant l'algorithme d'optimisation itérative comprend : la récupération de la première donnée dorsale à partir d'une ou de plusieurs des sources de données dorsales sur la base d'un premier critère parmi les critères de recherche ; le filtrage de la première donnée dorsale sur la base d'un premier seuil de satisfaction et d'une première portion des critères de recherche qui sont pertinents pour la première donnée dorsale ; 3057084 50 la récupération de la seconde donnée dorsale à partir d'une seconde source parmi la ou plusieurs sources de données dorsales sur la base d'un second critère parmi les critères de recherche et de la première donnée dorsale filtrée ; et le filtrage de la seconde donnée dorsale sur la base d'un second seuil de satisfaction et d'une 5 seconde portion des critères de recherche qui sont pertinents pour la seconde donnée dorsale, dans lequel la première donnée de source est basée sur la première donnée dorsale filtrée et sur la seconde donnée dorsale filtrée. 4. Le procédé selon la revendication 3, dans lequel la première donnée dorsale comprend une pluralité de 10 premiers résultats, et le filtrage de la première donnée dorsale sur la basé du premier seuil de satisfaction et de la première portion des critères de recherche pertinents pour la seconde donnée dorsale, comprend : l'application d'une ou de plusieurs premières fonctions floues, dérivées de la première portion des critères de recherche pour chacun des premiers résultats, afin de calculer une première valeur de satisfaction pour chaque premier résultat ; 15 la comparaison de la première valeur de satisfaction pour chaque premier résultat avec le premier seuil de satisfaction ; et le filtrage des premiers résultats en déterminant, comme pluralité de seconds résultats, chaque premier résultat pour lequel la première valeur de satisfaction est supérieure au premier seuil de satisfaction. 20 5 1.e procédé selon la revendication 4, dans lequel le filtrage de la première donnée dorsale comprend en outre : l'application d'une ou de plusieurs secondes fonctions floues, dérivées d'une troisième portion de critères de recherche pertinents pour la première donnée dorsale, à chacun des seconds résultats afin de 25 calculer une seconde valeur de satisfaction pour chaque second résultat ; la comparaison de la seconde valeur de satisfaction pour chaque second résultat avec un troisième seuil de satisfaction ; et le filtrage des seconds résultats en déterminant, comme pluralité de troisièmes résultats, chaque second résultat pour lequel la seconde valeur de satisfaction est supérieure au troisième seuil de 30 satisfaction, dans lequel la première donnée dorsale filtrée comprend les troisièmes résultats. 3057084 51 6. Le procédé, selon la revendication 4 ou la revendication 5, dans lequel chacun des critères de recherche de la requête de recherche est associé à un poids, chacune de la première ou de plusieurs des premières fonctions floues est associée à un critère de la première portion de critères de recherche, et l'application de l'une ou de plusieurs des fonctions floues à chaque premier résultat pour calculer la première valeur de 5 satisfaction pour chaque premier résultat comprend : la multiplication d'un résultat de chaque première fonction floue avec le poids associé au critère de recherche qui est associé à la première fonction floue respective. 7. Le procédé selon la revendication 3, dans lequel la seconde donnée dorsale comprend une pluralité de 10 résultats, et le filtrage de la seconde donnée dorsale, sur la base du second seuil de satisfaction et de la seconde portion de critères de recherche pertinents pour la seconde donnée dorsale, comprend : l'application d'une ou de plusieurs fonctions floues dérivées de la seconde portion des critères de recherche à chacun des résultats pour calculer une valeur de satisfaction pour chaque résultat ; la comparaison de la valeur de satisfaction pour chaque résultat avec le second seuil de 15 satisfaction ; et la détermination de chaque résultat dont la valeur de satisfaction est supérieure au second seuil de satisfaction, dans lequel la seconde donnée dorsale filtrée comprend chaque résultat déterminé. 20 8. Le procédé selon l'une quelconque des revendications 1 à 3, dans lequel la génération des réponses pour . -. ' -- e - - satisfaction pour chaque réponse basée sur les critères de recherche et la détermination de l'éligibilité à la notification pour chacune des réponses sur la base des critères de recherche comprend, pour chaque réponse : 25 le fait de déterminer si la valeur de satisfaction pour la réponse respective est supérieure à un seuil de notification ; en réponse à la détermination selon laquelle la valeur de satisfaction pour la réponse respective est supérieure au seuil de notification, le fait de signaler que la réponse respective est éligible à une notification supplémentaire, et 30 en réponse à la détermination selon laquelle la valeur de satisfaction pour la réponse respective est inférieure au seuil de notification : le fait de déterminer si la réponse respective fait partie d'un sous-ensemble des réponses, dans lequel la valeur de satisfaction pour chacune des réponses dans le sous-ensemble est 3057084 52 supérieure à la valeur de satisfaction pour chacune des réponses qui ne font pas partie du sous-ensemble, en réponse à la détermination selon laquelle la réponse respective fait partie du sous- ensemble, le fait de signaler que la réponse respective est éligible à une notification périodique, 5 et en réponse à la détermination selon laquelle la réponse respective ne fait pas partie du sous-ensemble, le fait de déterminer que la réponse respective n'est pas éligible à une notification. 9. Le procédé selon l'une quelconque des revendications 1 à 8, comprenant par ailleurs : 10 L'enregistrement des réponses dans un ou plusieurs dispositifs de stockage permanents, après l'enregistrement des réponses, la réception automatique, via un mécanisme de pousse, ou la récupération, via un mécanisme de tirage, de la seconde donnée de source à partir d'une ou de plusieurs sources de données dorsales associées à au moins une des réponses ; la récupération d'au moins une des réponses à partir d'un ou de plusieurs dispositifs de stockage 15 permanents ; la mise à jour d'une ou de plusieurs des réponses récupérées sur la base de la seconde donnée de source. la détermination de l'éligibilité à la notification d'une ou de plusieurs des réponses actualisées ; et la notification à l'utilisateur de chaque réponse éligible actualisée. 20 10. Le procédé selon la revendication 9, dans lequel la détermination de à la notification chacune d'une ou de plusieurs réponses actualisées comprend : pour chaque réponse actualisée : le fait de déterminer si la réponse actualisée respective inclut un abonnement, 25 en réponse à la détermination selon laquelle la réponse respective actualisée inclut un abonnement, l'ajout de la réponse respective actualisée à une liste d'attente de priorité élevée, et en réponse à la détermination selon laquelle la réponse respective actualisée n'inclut pas l'abonnement, l'ajout de la réponse respective actualisée,à une file d'attente de faible priorité ; le fait de déterminer l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente 30 de priorité élevée, et après détermination de l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente de priorité élevée, le fait de déterminer l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente de faible priorité. e 3057084 53 11. Le procédé selon la revendication 10, dans lequel la détermination de l'éligibilité à la notification de chaque réponse actualisée dans la file d'attente de priorité élevée comprend, pour chaque réponse etualiSée de la file d'attente de priorité élevée : 5 le fait de déterminer si la réponse actualisée respective satisfait un seuil de notification d'abonnement pour la réponse respective ; en réponse à la détermination selon laquelle la réponse respective actualisée satisfait le seuil de notification d'abonnement pour la réponse respective, le signalement de la réponse respective actualisée comme étant éligible à une notification d'abonnement ; et 10 en réponse à la détermination selon laquelle la réponse respective actualisée ne satisfait pas le seuil de notification d'abonnement pour la réponse respective : le fait de déterminer si la réponse respective actualisée satisfait un seuil de notification supplémentaire pour la requête de recherche, en réponse à la détermination selon laquelle la réponse actualisée respective satisfait le 15 seuil de notification supplémentaire pour la requête de recherche, le fait de signaler la réponse actualisée respective comme étant éligible à la notification supplémentaire, et en réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification supplémentaire pour la requête de recherche : le fait de déterminer si la réponse actualisée respective satisfait un seuil de 20 notification périodique pour la requête de recherche, .11 II nse ac ua isee respective satisfait un seuil de notification périodique pour la requête de recherche, le fait de signaler que la réponse actualisée respective est éligible à une notification périodique, et 25 en réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification périodique pour la requête de recherche, le fait de déterminer que la réponse actualisée respective n'est pas éligible à la notification. 12. Le procédé selon la revendication 10, dans lequel la détermination de l'éligibilité à la notification de 30 chaque réponse actualisée dans la file d'attente de faible priorité comprend, pour chaque réponse actualisée dans la file d'attente de faible priorité : le fait de déterminer si la réponse actualisée respective satisfait la condition d'un seuil de notification supplémentaire pour la requête de recherche ; 3057084 54 en réponse à la détermination selon laquelle la réponse actualisée respective satisfait le seuil de notification supplémentaire, le fait de signaler que la réponse actualisée respective est éligible à une notification supplémentaire ; et en réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil 5 de notification supplémentaire pour la requête de recherche : le fait de déterminer si la réponse actualisée respective satisfait un seuil de notification périodique pour la requête de recherche, en réponse à la détermination selon laquelle la réponse actualisée respective satisfait un seuil de notification périodique pour la requête de recherche, le fait de signaler que la réponse 10 actualisée respective est éligible à une notification périodique, et en réponse à la détermination selon laquelle la réponse actualisée respective ne satisfait pas le seuil de notification périodique pour la requête de recherche, le fait de déterminer que la réponse actualisée respective n'est pas éligible à la notification. 15 13. Un système de traitement de requêtes de recherche, le système comprenant : un ou plusieurs processeurs d'ordinateur ; et une mémoire stockant des instructions qui, lors de l'exécution par le ou plusieurs des processeurs d'ordinateur, amènent le système à : en réponse à la réception de la requête de recherche, la requête de recherche comprenant 20 des critères de recherche : eller »I - 11 - e s oc age permanents ; et effectuer périodiquement et automatiquement les opérations suivantes : la récupération de la requête de recherche à partir d'un ou de plusieurs 25 dispositifs de stockage permanent, la récupération, à l'aide d'un algorithme d'optimisation itérative, de la première donnée de source liée à la requête de recherche à partir d'une ou de plusieurs sources de données dorsales, la génération d'une pluralité de réponses pour la requête de recherche sur la 30 base de la première donnée de source, la détermination de l'éligibilité à la notification de chacune des réponses sur la base des critères de recherche, et 3057084 55 la notification à un utilisateur de chaque réponse déterminée comme étant éligible à la notification. 14. Le système selon la revendication 13, dans lequel les instructions lors de l'exécution amènent le 5 système à mettre en oeuvre le procédé selon l'une quelconque des revendications 2 à 12. 15. Un produit-programme informatique comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé conformément aux revendications 1 à 12 lorsque ledit programme fonctionne sur un ordinateur.