FR 3062942 A1 20180817 FR 1751209 A 20170215 3062942 MÉTAMOTEUR DE RECHERCHE AMÉLIORÉ DOMAINE TECHNIQUE [0001] L'invention présente concerne de façon générale des métamoteurs de recherche et plus particulièrement, des systèmes, des procédés, et des produits-programmes d'ordinateur pour améliorer les métamoteurs de recherche. CONTEXTE [0002] Les métamoteurs de recherche conventionnels utilisent les moteurs de recherche d'autres systèmes distants pour récupérer et afficher des résultats consolidés via Internet. Par 10 exemple, dans le contexte d'achat de produits via Internet, lorsqu'un utilisateur soumet une interrogation concernant la disponibilité d'un produit à un métamoteur de recherche conventionnel, le métamoteur de recherche interroge les moteurs de recherche de plusieurs des systèmes en ligne qui vendent des produits à des utilisateurs sur la base de l'interrogation concernant la disponibilité. En réponse, le métamoteur de recherche reçoit des données incluant 15 une information concernant les produits disponibles à la vente en provenance des systèmes en ligne et génère puis affiche une liste de résultats à l'utilisateur qui inclut les produits disponibles. Par la suite, si l'utilisateur sélectionne un des produits affichés par le métamoteur de recherche pour achat, le système de l'utilisateur est redirigé vers le système en ligne qui vend le produit afin de finaliser l'achat. En d'autres termes, l'utilisateur quitte le système du métamoteur de 20 recherche et est redirigé vers le système en ligne qui collecte le paiement de l'utilisateur et finalise la transaction en ligne. [0003] Les métamoteurs de recherche conventionnels sont généralement limités à la recherche de produits disponibles et ne fournissent aucun mécanisme permettant à un utilisateur d'acheter un produit affiché directement avec le métamoteur de recherche sans être redirigé vers 25 le système distant qui vend le produit. Par conséquent, les métamoteurs de recherche conventionnels sont incapables de surveiller et de suivre de façon précise les taux de conversation (conversion) lorsque l'utilisateur est redirigé vers un autre système pour finaliser l'achat. En outre. les systèmes qui traitent des transactions d'achat sont typiquement configurés avec des interfaces complexes et une programmation pour la collection de paiement et la 30 conservation d'enregistrements électroniques qui facilitent la distribution des produits achetés. Les métamoteurs de recherche conventionnels manquent de certaines caractéristiques et modifier des métamoteurs de recherche conventionnels pour implémenter ces caractéristiques 2 3062942 augmenterait substantiellement la complexité technique des métamoteurs de recherche conventionnels. Par exemple, de telles modifications augmenteraient les temps de réponse aux recherches tout en épuisant les ressources du système, créant ainsi un besoin de ressources de traitement supplémentaires et une élévation des niveaux de maintenance. [0004] Par conséquent, il existe un besoin de fonctionnalité supplémentaire pour des systèmes, des procédés et des produits-programmes d'ordinateur permettant d'optimiser les métamoteurs de recherche tout en réduisant l'impact technique sur les systèmes existants. RÉSUMÉ [0005] Dans un mode de réalisation exemplaire un système pour améliorer un métamoteur de 10 recherche, exploité par un méta et configure pour générer des résultats en réponse à une interrogation de recherche, inclut un ou plusieurs processeurs géographiquement distants du métamoteur de recherche et une mémoire, dans lequel chacun des résultats inclut un produit offert à la vente par un système de vendeur de produits exploité par un vendeur et ayant un nom de domaine qui diffère du nom de domaine du métamoteur de recherche. La mémoire inclut des 15 instructions qui, lorsqu'elles sont exécutées par ledit ou plusieurs processeurs, amènent le système à effectuer les opérations suivantes : en réponse à la sélection par l'acheteur de l'un des résultats générés par le métamoteur de recherche pour achat et à une demande de réalisation reçue par le métamoteur de recherche pour le résultat sélectionné, la demande de réalisation incluant une première donnée de paiement associée à la première forme de paiement de 20 l'utilisateur et des données de résultat associées au résultat sélectionné, le système sélectionne le méta ou le vendeur qui exploite le système de vendeur de produits pour le produit inclus dans le résultat sélectionné comme commerçant pour la demande de réalisation sur la base de la demande de réalisation. Le système détermine par ailleurs un bureau de règlement associé au système de vendeur de produits pour le produit inclus dans le résultat sélectionné sur la base de 25 la demande de réalisation, dans lequel le bureau de règlement est distant du métamoteur de recherche. Par la suite, le système se connecte au bureau de règlement et pendant la connexion au bureau de règlement, génère un enregistrement électronique au bureau de règlement basé sur les données de résultat et sur la détermination du commerçant. L'enregistrement électronique inclut une seconde donnée de paiement associée à la demande de réalisation et un ou plusieurs 30 éléments financiers qui modélisent une vente du produit inclus dans le résultat sélectionné. Le système traite par ailleurs la première forme de paiement de l'utilisateur sur la base de la détermination du commerçant, et après que la première forme de paiement a été traitée, génère 3 3062942 ux de données incluant ledit ou plusieurs éléments financiers et transmet le flux de données au méta. [0006] Dans certains modes de réalisation, les résultats générés par le métamoteur de recherche peuvent être associés à un ID d'offre unique et peuvent être stockés dans une base de données, de sorte que chaque résultat est lié à l'ID d'offre associé au résultat sélectionné dans la base de données. Les données de résultat peuvent inclure l'ID d'offre associé au résultat sélectionné et en réponse à la réception de la demande de réalisation, les instructions peuvent amener le système à déterminer, à partir de la base de données, le résultat sélectionné sur la base de l'ID d'offre inclus dans les données de résultat. [0007] En outre, en réponse au résultat sélectionné par l'utilisateur pour achat, l'utilisateur peut être redirigé vers une page de collecte de paiement fournie par le système permettant à l'utilisateur de saisir la première forme de paiement. Dans ce cas les instructions, lors de l'exécution, peuvent amener le système, en réponse à la réception de la première forme de paiement de l'utilisateur via la page de collecte de paiement, à générer un jeton de paiement pour la première forme de paiement. Le système peut stocker la première forme de paiement et le jeton de paiement dans une base de données qui est accessible par le métasvstème de recherche, mais qui n'est pas accessible par le métamoteur de recherche, de sorte que la première forme de paiement est liée au jeton de paiement dans la base de données, et transmet le jeton de paiement au métamoteur de recherche. Dans ce but, la première donnée de paiement peut inclure le jeton de paiement. Par conséquent, en réponse à réception de la demande de réalisation, les instructions peuvent amener le système à déterminer, à partir de la base de données, la première forme de paiement sur la base du jeton de paiement inclus dans la première donnée de paiement. [0008] Par ailleurs, les instructions peuvent amener le système à générer l'enregistrement électronique au bureau de règlement sur la base des données de résultat et de la détermination du commerçant en amenant le système, en réponse à la sélection du méta comme commerçant, à générer une carte de crédit virtuelle comme seconde donnée de paiement et, en réponse à la détermination que le vendeur qui exploite le système de vendeur de produits pour le produit du résultat sélectionné est le commerçant, à insérer la première forme de paiement dans l'enregistrement électronique comme seconde donnée de paiement. 30 [0009] De plus, le système peut inclure un ou plusieurs dispositifs de mémoire qui stockent des bases de données accessibles par le système, mais non accessibles par le métamoteur de recherche, Spécifiquement, le système peut inclure une première hase de données et une seconde 4 3062942 base de données. La première base de données peut inclure les résultats générés par le métamoteur de recherche, dans laquelle chacun des résultats est lié à un ID d'offre unique dans la première base de données. Dans ce but, les données de résultat incluses dans la demande de réalisation peuvent inclure ID d'offre lié au résultat sélectionné dans la première base de données. La seconde base de données peut inclure les secondes formes de paiement des utilisateurs, dans laquelle les secondes formes de paiement incluent la première forme de paiement de l'utilisateur qui a sélectionné le résultat. Chacune des secondes formes de paiement peut être liée à un jeton de paiement unique dans la seconde base de données et la première donnée de paiement peut inclure le jeton de paiement lié à la première forme de paiement dans la 10 seconde base de données. Dans ce cas, les instructions, lorsqu'elles sont exécutées, peuvent, en réponse à la réception de la demande de réalisation, amener le système à stocker le jeton de paiement de la première donnée de paiement et l'ID d'offre dans les données de résultat dans une troisième base de données qui est accessible par le système et n'est pas accessible par le métamoteur de recherche. Les instructions peuvent aussi amener le système à récupérer le 15 résultat sélectionné dans la première base de données sur la base de l'ID d'offre des données de résultat et récupérer la première forme de paiement dans la seconde base de données sur la base du jeton de paiement de la première donnée de paiement. [0010] En outre, en réponse à une perturbation du système lorsque la demande de réalisation est en cours de traitement, les instructions lorsqu'elles sont exécutées peuvent amener le système 20 à recommencer le traitement de la demande de réalisation en amenant le système à récupérer, à partir de la troisième base de données, le jeton de paiement et l'ID d'offre stockés dans la troisième base de données. Par la suite, le système peut récupérer le résultat sélectionné dans la première base de données sur la base de l'ID d'offre récupéré dans la troisième base de données et peut récupérer la première forme de paiement dans la seconde base de données sur la base du 25 jeton de paiement récupéré dans la troisième base de données. [0011] Le système peut aussi inclure un ou plusieurs dispositifs de mémoire incluant une base de données qui inclut une pluralité d'entrées, chacune des entrées incluant un identifiant de vendeur, un premier attribut, un attribut alternatif, et un identifiant de bureau de règlement. Les instructions, lors de l'exécution, peuvent amener le système à déterminer le bureau de règlement 30 associé au système de vendeur de produits pour le produit inclus dans le résultat sélectionné en amenant le système à rechercher dans la base de données une première entrée pour laquelle l'identifiant de vendeur et le premier attribut correspondent à la demande de réalisation. En 5 3062942 réponse à absence de détection de la première entrée, le système peut chercher une seconde entrée dans la base de données pour laquelle l'identifiant de vendeur et l'attribut alternatif correspondent à la demande de réalisation, et en réponse à la détection de la seconde entrée, sélectionner le bureau de règlement sur la base de l'identifiant de bureau de règlement inclus dans la seconde entrée. [0012] De plus, les instructions lors de l'exécution peuvent amener le système à se déconnecter du bureau de règlement et à se connecter à un bureau méta associé au métamoteur de recherche. Pendant la connexion au bureau méta, le système peut récupérer l'enregistrement électronique, ajouter un élément financier relatif à des frais de service facturés par le métamoteur 10 de recherche à l'enregistrement électronique et marquer l'élément financier comme étant confidentiel. Par la suite, le système peut se déconnecter du métabureau. [0013] En outre, le système peut inclure un ou plusieurs dispositifs de mémoire comprenant une base de données qui inclut des frais de transaction pour chacun de plusieurs types de forme de paiement. Dans ce cas, les instructions lorsqu'elles sont exécutées peuvent amener le système, 15 en réponse à la détermination que le méta est le commerçant, à générer une carte de crédit virtuelle, comme seconde donnée de paiement et à récupérer, à partir de la base de données, des premiers frais de transaction pour le traitement de la première forme de paiement, et des seconds frais de transaction pour le traitement de la carte de crédit virtuelle. Le système peut ensuite déterminer si les premiers frais de transaction sont plus élevés que les seconds frais de 20 transaction. En réponse la détermination que les premiers frais de transaction sont plus élevés que les seconds frais de transaction, le système peut générer un coupon électronique pour une différence entre les premiers frais de transaction et les seconds frais de transaction, et peut notifier le coupon électronique à l'utilisateur. [0014] Dans un autre mode de réalisation exemplaire, un procédé pour améliorer un métamoteur de recherche exploité par un méta et configuré pour générer des résultats en réponse à une interrogation de recherche, dans lequel chacun des résultats inclut un produit offert à la vente par un système de vendeur de produits exploité par un vendeur et ayant un nom de domaine qui diffère du nom de domaine du métamoteur de recherche, inclut : En réponse à la sélection par l'acheteur de l'un des résultats générés par le métamoteur de recherche pour achat via le métamoteur de recherche et à la réception par un ou plusieurs processeurs à partir du métamoteur de recherche d'une demande de réalisation pour le résultat sélectionné, la demande de réalisation incluant une première donnée de paiement associée à la première forme de 6 3062942 paiement de l'utilisateur et des données de résultat associées au résultat sélectionné, le procédé inclut la sélection comme commerçant, par l'un ou plusieurs des processeurs, du méta ou du vendeur qui exploite le système de vendeur de produits pour le produit inclus dans le résultat sélectionné, pour la demande de réalisation sur la base de la demande de réalisation, et la 5 détermination par l'un ou plusieurs processeurs d'un bureau de règlement associé au système de vendeur de produits pour le produit inclus dans le résultat sélectionné sur la base de la demande de réalisation. Le bureau de règlement est distant du métamoteur de recherche. Par la suite, le procédé inclut la connexion d'un ou de plusieurs processeurs au bureau de règlement. Pendant la connexion au bureau de règlement, le procédé inclut par ailleurs la génération, par un ou 10 plusieurs processeurs, d'un enregistrement électronique au bureau de règlement basé sur les données de résultat et sur la détermination du commerçant. L'enregistrement électronique inclut une seconde donnée de paiement associée à la demande de réalisation et un ou plusieurs éléments financiers qui modélisent une vente du produit inclus dans le résultat sélectionné. Le procédé inclut également le traitement, par un ou plusieurs processeurs, de la première forme de 15 paiement de l'utilisateur sur la base de la détermination du commerçant et, après le traitement de la première forme de paiement, la génération par un ou plusieurs processeurs d'un flux de données incluant ledit ou plusieurs éléments financiers, et transmettant le flux de données au méta via un ou plusieurs processeurs. [0015] Le procédé peut, par ailleurs, inclure la mise en couvre de l'une quelconque ou 20 plusieurs des opérations et/ou l'implémentation de l'une quelconque ou plusieurs des caractéristiques discutées ci-dessus en référence au système exemplaire. [00161 Dans un autre mode de réalisation exemplaire, un produit-programme d'ordinateur pour améliorer un métamoteur de recherche exploité par un méta et configuré pour générer des résultats en réponse à une interrogation de recherche, dans lequel chacun des résultats inclut un 25 produit offert à la vente par un système de vendeur de produits exploité par un vendeur et ayant un nom de domaine qui diffère du nom de domaine du métamoteur de recherche, inclut un support de stockage non transitoire lisible par ordinateur. Les instructions sont stockées sur le support de stockage non transitoire lisible par ordinateur qui, lors de l'exécution par un ou plusieurs processeurs géographiquement distants du métamoteur de recherche, amènent ledit ou 30 plusieurs processeurs à effectuer les opérations suivantes. En réponse à la sélection par l'acheteur de l'un des résultats générés par le métamoteur de recherche pour achat, et à la réception d'une demande de réalisation par le métamoteur de recherche pour le résultat sélectionné, la demande 7 3062942 de réalisation incluant une première donnée de paiement associée à la première forme de paiement de l'utilisateur et des données de résultat associées au résultat sélectionné, ledit ou plusieurs processeurs sélectionnent le méta ou le vendeur qui exploite le système de vendeur de produits pour le produit inclus dans le résultat sélectionné comme commerçant pour la demande 5 de réalisation sur la base de la demande de réalisation. Ledit ou plusieurs processeurs déterminent par ailleurs un bureau de règlement associé au système de vendeur de produits pour le produit inclus dans le résultat sélectionné sur la base de la demande de réalisation, dans lequel le bureau de règlement est distant du métamoteur de recherche. Par la suite, ledit ou plusieurs processeurs se connectent au bureau de règlement et génèrent, pendant la connexion au bureau 10 de règlement, un enregistrement électronique au bureau de règlement basé sur les données de résultat et sur la détermination du commerçant. L'enregistrement électronique inclut une seconde donnée de paiement associée à la demande de réalisation et un ou plusieurs éléments financiers qui modélisent une vente du produit inclus dans le résultat sélectionné. Ledit ou plusieurs processeurs traitent par ailleurs la première forme de paiement de l'utilisateur sur la base de la 15 détermination du commerçant, et, après que la première forme de paiement a été traitée, génèrent un flux de données incluant ledit plusieurs éléments financiers et transmettent le flux de données au méta. [0017] Les instructions, lorsqu'elles sont exécutées, peuvent par ailleurs amener ledit ou plusieurs processeurs à effectuer l'une quelconque ou plusieurs des opérations et/ou à 20 implémenter l'une quelconque ou plusieurs des caractéristiques discutées ci-dessus en référence au système exemplaire. [0018] Le résumé ci-dessus apporte peut-être une vue d'ensemble simplifiée de certains des modes de réalisation de l'invention afin de fournir une compréhension basique de certains aspects de l'invention discutés dans les présentes. Le résumé ne prétend pas apporter une vue d'ensemble 25 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 présenter simplement quelques concepts sous une forme simplifiée comme préambule à la description détaillée présentée ci-dessous. BRÈVE DESCRIPTION DES DESSINS 30 [0019] Les modes de réalisation de la présente invention seront mieux compris et seront appréciés plus pleinement grâce à la lecture de la description détaillée ci-après qui complète les dessins. 8 3062942 [0020] FIG. 1 est une vue schématique d'un environnement d'exploitation exemplaire qui inclut une pluralité de systèmes pour améliorer un métamoteur de recherche. [0021] FIG. 2 est une vue schématique du système informatique exemplaire de la FIG. 1. [0022] FIG. 3 est une vue schématique d'une architecture de traitement exemplaire pouvant 5 être mise en oeuvre par un ou plusieurs des systèmes informatiques de la FIG. 1. [0023] FIG. 4 est un diagramme séquentiel d'un processus exemplaire pour améliorer le métamoteur de recherche qui peut être mis en oeuvre par l'architecture de traitement de la FIG. 3. [0024] FIG. 5 est un diagramme séquentiel d'un autre processus exemplaire pour améliorer un métamoteur de recherche qui peut être mis en oeuvre par l'architecture de traitement de la 10 FIG. 3. [0025] FIG. 6 est un autre diagramme séquentiel d'un autre processus exemplaire pour améliorer un métamoteur de recherche qui peut être mis en oeuvre par l'architecture de traitement de la FIG. 3. DESCRIPTION DÉTAILLÉE [0026] La FIG.1 illustre un environnement d'exploitation exemplaire 10 qui peut inclure un ou plusieurs systèmes d'utilisateur 12, un rnétasystème de recherche 14, un ou plusieurs systèmes de vendeur de produits 16 et un système de gestion de transaction 18. Chacun de ces systèmes peut communiquer avec les autres via un ou plusieurs réseaux privés et/ou publics 24, tels qu'Intemet. Un ou plusieurs de ses systèmes peuvent être logiquement ou physiquement 20 distants des autres (p. ex., implémentés géographiquement par des plateformes informatiques séparées). Par exemple, les systèmes d'utilisateur 12, te système de gestion de transaction 18 et/ou les systèmes de vendeur de produits 16 peuvent être logiquement ou physiquement distants du métamoteur de recherche 14. En outre, un ou plusieurs de ces systèmes, tels que le système de gestion de transaction 18 et/ou un ou plusieurs des systèmes de vendeur de produits 16, peuvent 25 chacun être implémentés par une même ou par plusieurs plateformes informatiques. Par exemple, deux ou plusieurs des systèmes de vendeur de produits 16 peuvent partager au moins une plateforme informatique. [0027] Les systèmes d'utilisateur 12 peuvent nclure des dispositifs informatiques qui permettent aux utilisateurs d'accéder à des systèmes distants tels que le métamoteur de 30 recherche 14 ou les systèmes de vendeur de produits 16 sur ledit ou plusieurs réseaux 24. Par exemple, un système d'utilisateur 12 peut être un ordinateur portable, un ordinateur de bureau, 9 3062942 un terminal client léger ou une tablette. Chaque système d'utilisateur 12 peut inclure un indicateur web ou une ou plusieurs applications pour se connecter aux systèmes distants. [0028] Les systèmes de vendeur de produits 16 peuvent faciliter la vente de produits sur Internet pour divers vendeurs en ligne. Spécifiquement, chaque vendeur en ligne (ci-après 5 désigné dans les présentes comme « vendeur ») peut être un commerçant en ligne (ci-après désigné dans les présentes comme « commerçant »), et peut exploiter un ou plusieurs des systèmes de vendeur de produits 16. En général, un commerçant peut être considéré comme une entité ou une société qui reçoit un paiement d'un utilisateur en contrepartie de produits vendus à l'utilisateur sur Internet. En d'autres termes, un commerçant peut vendre des produits aux 10 utilisateurs via Internet en recevant et en traitant des informations de paiement de l'utilisateur, soit directement soit par l'intermédiaire de tierces parties sous contrat, sur ledit ou plusieurs réseaux 24, en échange des produits. [0029] Les systèmes de vendeur de produits 16 peuvent permettre à un utilisateur de chercher et de sélectionner des produits pour achat chez un ou plusieurs fournisseurs de produits 15 (p. ex., des compagnies aériennes, des hôtels, des loueurs de voitures, des exploitants ferroviaires, etc.) et peuvent collecter et traiter des données de paiement de l'utilisateur pour les produits sélectionnés. En outre, les systèmes de vendeur de produits 16 peuvent suivre et gérer un inventaire de produits offerts par un ou plusieurs fournisseurs de produits et peuvent faciliter l'approvisionnement des produits vendus en générant et en maintenant des enregistrements 20 électroniques. De tels enregistrements électroniques peuvent inclure des enregistrements d'achat, des enregistrements de réservation, des reçus, des documents contractuels et/ou des billets pour les produits vendus. [0030] Un système donné de vendeur de produits 16 peut être exploité par un fournisseur particulier de produits (c.-à-d., le vendeur qui exploite le système de vendeur de produits 16 est 25 un fournisseur particulier de produits) et de même, il peut être dédié à la gestion et à la vente des produits du fournisseur particulier de produits. Par exemple, le fournisseur de produits peut être une compagnie aérienne et les produits offerts et gérés par le système de vendeur de produits donné 1G peuvent être des produits de voyage vendus par la compagnie aérienne. Autrement, un système de vendeur de produits 16 peut gérer et vendre des produits d'un type particulier tel que 30 des produits de transport aérien qui sont fournis par de multiples fournisseurs de produits. Comme autre exemple, un système de vendeur de produits 16 peut gérer et vendre des produits de types multiples et de multiples fournisseurs de produits. Par exemple, un seul système de 10 3062942 vendeur de produits 16 peut gérer et vendre des produits de transport aérien, des produits hôteliers, et des produits de location de voiture via un seul point d'accès tel qu'un site web. [0031] En général, un utilisateur peut se connecter à un système de vendeur de produits 16 en instruisant un système d'utilisateur d'accéder au système de vendeur de produits 16, par exemple via un navigateur ou une application installée sur le système de l'utilisateur 12. Spécifiquement, chaque système de vendeur de produits 16 peut inclure un site web ayant un nom de domaine et une adresse de réseau uniques pour accéder au système de vendeur de produits 16. Un utilisateur peut donc accéder à un système de vendeur de produits 16 en se déplaçant à l'aide d'un navigateur sur le système de l'utilisateur 12 vers le nom de domaine unique du site web hébergé par le système de vendeur de produits 16 ou en lançant une application installée sur le système d'utilisateur 12 programmée pour échanger des informations avec le système de vendeur de produits 16 via le nom de domaine ou l'adresse de réseau du système de vendeur de produits 16, Une Cois connecté au système de vendeur de produits 16, l'utilisateur peut interagir avec le site web ou l'application pour chercher et acheter de produits sur le système de vendeur de 15 produits 16, par exemple via un moteur de recherche de produit hébergé par le système de vendeur de produits 16. Par la suite, le système de vendeur de produits 16 peut collecter et traiter une donnée de paiement de l'utilisateur en contrepartie des produits sélectionnés via le site web ou l'application. [0032] Le métasystème de recherche 14 peut offrir des moyens alternatifs à travers lesquels 20 un utilisateur peut chercher ou acheter des produits offerts par les systèmes de vendeur de produits 16. En particulier, le métasystème de recherche 14 peut être exploité par une méta-entité (ci-après désigné dans les présentes comme « méta et peut inclure un métamoteur de recherche qui, en réponse à la réception d'une interrogation de recherche d'un utilisateur incluant un ou plusieurs critères de recherche, interroge les systèmes de vendeur de produits 16 concernant la 25 disponibilité des produits sur la base des critères de recherche. Le métasystème de recherche 14 peut ensuite retourner une liste de résultats qui répond à l'interrogation de recherche de l'utilisateur, les résultats incluant des produits offerts à la vente par les systèmes de vendeur de produits 16 et qui correspondent aux critères de recherche de l'utilisateur. De cette façon, le métasystème de recherche 14 peut fournir une liste complète des produits offerts à la vente par 30 de multiples systèmes de vendeur de produits distincts. [0033] Un utilisateur peut accéder au métasystème de recherche 14 pratiquement de la même façon qu'un utilisateur peut accéder au système de vendeur de produits 16, Spécifiquement, le 11 3062942 'métasystème de recherche 14 peut inclure un site web ayant un nom de domaine et une adresse de réseau uniques qui diffèrent du nom de domaine et des adresses de réseau des systèmes de vendeur de produits 16. Un utilisateur peut donc accéder au métasystème de recherche 14 en amenant un navigateur web sur un système d'utilisateur 12 à naviguer vers le nom de domaine du site web du métasystème de recherche 14, ou en ouvrant une application installée sur le système de l'utilisateur 12 qui est configurée pour échanger des informations avec le métasystème de recherche 14 via son adresse de réseau ou son nom de domaine. Par la suite, l'utilisateur peut interagir avec le navigateur web ou l'application du système de l'utilisateur 12 pour soumettre une interrogation de recherche au métamoteur de recherche du métasystème de 10 recherche 14. L'interrogation de recherche peut inclure un ou plusieurs critères de recherche décrivant les caractéristiques du produit qui intéresse l'utilisateur. [0034] En réponse à la réception de l'interrogation de recherche, le métamoteur de recherche du métasystème de recherche 14 peut interroger chacun des systèmes de vendeur de produits 16 pour obtenir des données de produit basées sur les critères de recherche fournis, par exemple en 15 soumettant une interrogation de recherche correspondante à un moteur de recherche hébergé par chacun des systèmes de vendeur de produits 16 via leurs adresses de réseau ou leurs noms de domaine. Les données de produits reçues de la part de chaque système de vendeur de produits 16 peuvent inclure des informations sur les produits disponibles à la vente provenant du système de vendeur de produits 16 qui correspondent aux critères de recherche, telles qu'une description de 20 chaque produit, le coût de chaque produit, le fournisseur de produits de chaque produit et la quantité disponible restante pour chaque produit. Autrement, ces données peuvent avoir été mises en antémémoire par le métasystème de recherche 14 avant la réception de la demande de recherche de l'utilisateur. Le métamoteur de recherche du métasystème de recherche 14 peut ensuite générer une liste des résultats sur la base des données de produit qui peut alors être 25 affichée à l'utilisateur par le navigateur ou l'application du système de l'utilisateur 12. Chacun des résultats peut inclure un ou plusieurs produits disponibles à la vente en provenance des systèmes de vendeur de produits 16 et qui correspondent aux critères de recherche de l'utilisateur. Par exemple, un résultat peut inclure un itinéraire de voyage composé d'un ou de plusieurs vols et/ou d'un séjour dans un hôte! disponible à la vente via un système de vendeur de 30 produits 16. De cette façon, l'utilisateur est capable de rechercher et de comparer les produits offerts par de multiples systèmes de vendeur de produits 16 à partir d'un seul point d'accès, notamment le métasystème de recherche 14. 12 3062942 [0035] Les métasystèmes conventionnels de recherche sont limités à la recherche et à l'affichage de produits disponibles et ils n'ont pas de mécanisme permettant à un utilisateur d'initier un achat directement à partir des métasystèmes de recherche. En d'autres termes, traditionnellement les mélos ne peuvent pas agir en qualité de commerçants pour les produits. Au 5 lieu de cela, lorsqu'un utilisateur indique un souhait d'acheter un produit affiché par un métasystème conventionnel de recherche, le métasystème de recherche redirige l'utilisateur vers le système de vendeur de produits responsable du suivi et de la vente du produit. Cette redirection permet aux métasystèmes conventionnels de recherche d'éviter l'impact technique qui résulterait de l'implémentation de mécanismes pour collecter et traiter les données de 10 paiement des utilisateurs afin de collecter le paiement des produits, ainsi que le maintien d'enregistrements électroniques relatifs à la vente et à la distribution des produits, ce qui peut être extrêmement complexe pour certains types de produit. Par exemple, l'approvisionnement de produits de voyage implique typiquement une combinaison complexe d'enregistrements de réservation, de billets électroniques. et de divers coupons pour des services auxiliaires, et 15 implique des formats et des interfaces spécifiques à l'industrie. [0036] Cependant cette fonctionnalité limitée a aussi un coût. Par exemple, les métas peuvent recevoir des recettes basées sur des taux de conversion (c.-à-d. le nombre d'utilisateurs qui finalisent l'achat d'un produit). Parce que les métasystèmes conventionnels de recherche redirigent les utilisateurs vers des systèmes de vendeur de produits distants pour finaliser l'achat 20 de produits et parce qu'ils ne sont pas exploités pour le compte du métasystème de recherche, les métas sont souvent incapables de suivre les taux de conversion de leurs clients de façon fiable. En outre, en fonction de la chaîne, la redirection vers un autre système dans lequel est effectué l'achat d'un produit est souvent peu fiable (p. ex., les chaînes mobiles impliquant des applications), ce qui peut par ailleurs affecter négativement le taux de conversion des métas. De 25 plus, lorsqu'un utilisateur est redirigé d'un métasystème conventionnel de recherche vers un autre système, les options de paiement de l'utilisateur pour le produit sont limitées aux formes de paiement acceptées par le système vers lequel l'utilisateur est redirigé. Il en résulte que le taux de conversion du méta peut par ailleurs être encore affecté négativement parce que les utilisateurs ne peuvent pas utiliser leur forme de paiement préférée. 30 [0037] Le système de gestion de transaction 18 optimise le métasystème de recherche 14 en permettant au méta d'agir en qualité de commerçant tout en minimisant l'impact technique sur le métasystème de recherche 14 et les systèmes de vendeur de produits 16, et en améliorant 13 3062942 l'expérience de l'utilisateur avec le métasystème de recherche. Spécifiquement, un utilisateur peut initier l'achat du résultat affiché par le métasystème de recherche directement avec celui-ci. En réponse à la sélection de l'un des résultats affichés par le métasystème de recherche 14 pour achat, une demande de réalisation relative au résultat sélectionné peut être transmise du métasystème de recherche vers le système de gestion de transaction 18. La demande de réalisation peut inclure la forme de paiement de l'utilisateur qui peut avoir été obtenue de ['utilisateur par le métasystème de recherche 14 et peut inclure les données de résultat indiquant le résultat sélectionné par l'utilisateur. Par la suite, le système de gestion de transaction 18 peut déterminer si le méta ou le vendeur associé au système de vendeur de produits 16 pour le résultat 10 sélectionné doit être sélectionné comme commerçant pour la transaction sur la base d'une ou de plusieurs règles. Si le vendeur est sélectionné comme commerçant, le système de gestion de transaction 18 peut alors fournir la forme de paiement de l'utilisateur au système de vendeur de produits 16 correspondant pour traitement et règlement en contrepartie des produits du résultat sélectionné. Autrement, si le méta est sélectionné comme commerçant, le système de gestion de 15 transaction 18 peut alors continuer à traiter la forme de paiement de l'utilisateur et peut la régler pour le compte du méta, fournir la forme de paiement de l'utilisateur au métasystème de recherche 14 pour traitement et règlement, ou fournir la forme de paiement de l'utilisateur à une plateforme tierce sous contrat pour le traitement et le règlement de transactions pour le compte du méta. 20 [00381 Quelle que soit la détermination du commerçant, le système de gestion de transaction 18 peut amener le système de vendeur de produits 16 correspondant au résultat sélectionné à générer et à gérer tous les enregistrements électroniques qui sont nécessaires pour l'achat. En outre, le système de gestion de transaction 18 peut générer et transmettre un flux de données au méta en temps réel qui inclut les informations relatives à l'achat, telles que le coût, 25 les informations de paiement, les produits achetés et ainsi de suite, afin de permettre au méta de suivre le taux de conversion de façon fiable. [0039] Ainsi, le système de gestion de transaction 18 permet au méta d'agir en qualité de commerçant tout en minimisant les impacts techniques à la fois sur le métasystème de recherche 14 et sur les systèmes de vendeur de produits 16. Spécifiquement, le métasystème de 30 recherche 14 ne requiert pas de modification pour l'ajout d'une nouvelle fonctionnalité permettant de générer et de gérer les enregistrements électroniques nécessaires pour un achat. En outre, lorsque le méta est sélectionné comme commerçant, le système de gestion de 14 3062942 transaction 18 peut être configure pour générer une carte de crédit virtuelle compatible avec les interfaces et les enregistrements électroniques du système de vendeur de produits 16 qui correspondent au résultat sélectionné. De cette façon, le vendeur peut utiliser la VCC plus tard pour régler les produits vendus avec le méta et n'a pas besoin de faire des aménagements 5 techniques particuliers pour permettre au méta d'agir en qualité de commerçant. En outre, du point de vue de l'utilisateur, tous les processus mentionnés auparavant peuvent être masqués de sorte que l'utilisateur n'est pas redirigé vers un quelconque système de vendeur de produits 16, donnant l'impression que la transaction est entièrement traitée par le métasystème de recherche 14. 10 [0040] Faisant maintenant référence à la FIG.2, le système d'utilisateur 12, le métasystème de recherche 14, les systèmes de vendeur de produits 16 et le système de gestion de transaction 18 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, tels que le système informatique exemplaire 26. Le système informatique 26 peut inclure un processeur 28, une mémoire 30, un dispositif de stockage de mémoire de masse 32, 15 une interface entrée/sortie (I/O) 34, et une interface homme-machine (HM1) 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 VO 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 réseau en nuage (cloud), ou toute autre 20 ressource informatique appropriée qui peut être utilisée avec le système informatique 26. [0041] 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 (gate arrays), des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits 25 analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base des instructions de fonctionnement enregistré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 30 vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache memory), ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 32 peut inclure des dispositifs de stockage de données tels qu'un 15 3062942 ' disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non-volatil; ou tout autre dispositif capable de stocker des informations. [0042] Le processeur 28 peut fonctionner sous le contrôle d'un système d'exploitation 40 qui réside dans la mémoire 30. Le système d'exploitation 40 peut gérer les ressources de l'ordinateur 5 de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application tels que l'application 42 qui réside dans la mémoire 30, puissent 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 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 10 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. [0043] L'interface 34 peut fournir une interface machine qui couple de façon fonctionnelle le 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 15 ressources externes 38 en communiquant par l'intermédiaire de l'interface 1/0 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 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 20 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 (matériel et logiciel) qui sont fournies comme services sur le réseau 24, par exemple un service 25 d'informatique en nuage (cloud computing). [0044] 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 écran tactile, un haut-parleur et tout autre indicateur visuel et 30 audio capable de communiquer des données à l'utilisateur. Le HMI 36 peut aussi inclure des dispositifs de saisie et des contrôles tels qu'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., 16 3062942 'capables d'accepter des commandes ou des saisies de l'utilisateur, et de les transmettre au processeur 28. [0045] 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 5 systèmes et modifies 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 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- 10 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 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 15 modules. [0046] La FIG. 3 illustre une architecture exemplaire de traitement 50 qui peut être implémentée par un ou plusieurs des systèmes de l'environnement d'exploitation 10. L'architecture de traitement 50 peut inclure un métamoteur de recherche 51, un orchestrateur de transaction 52, plusieurs bureaux de règlement 53 et plusieurs bases de données. En particulier, 20 l'architecture de traitement 50 peut inclure une ou plusieurs bases de données d'enregistrement électronique 54, une base de données de vendeur 56, une base de métadonnées 58, une base de données hébergeant des jetons 60, une ou plusieurs bases de données de réalisation 62, une base de données de frais de transaction 64 et une ou plusieurs bases de données de produit 66. Dans certains modes de réalisation, le métasystème de recherche 14 peut inclure le métamoteur de 25 recherche 51 ; les systèmes de vendeur de produits 16 peuvent inclure les bureaux de règlement 53 et les bases de données d'enregistrement électronique 54 et le système de gestion de transaction 18 peut inclure l'orchestrateur de transaction 52 et une ou plusieurs des bases de données restantes. En général, l'architecture de traitement 50 peut améliorer le fonctionnement du métamoteur de recherche 51 en facilitant le traitement d'une demande de réalisation générée 30 lorsqu'un utilisateur finalise l'achat d'un produit directement via le métamoteur de recherche 51 x., sans que le système d'utilisateur 12 soit redirigé vers les systèmes de vendeur de produits 16). Dans certains modes de réalisation, une ou plusieurs des bases de données peuvent 17 3062942 être combinées. Par exemple, la base de données de jeton 50 et une ou plusieurs des hases de données de réalisation 62 peuvent faire partie d'une même base de données. Le contenu des bases de données et le fonctionnement de l'architecture de traitement 50 sont décrits de façon plus détaillée ci-dessous. 5 [0047] La FIG. 4 illustre un processus exemplaire 100 pour améliorer le métamoteur de recherche 51, par exemple via l'orchestrateur de transaction 52, de façon à permettre aux transactions d'achat en ligne d'être initiées directement à partir du métamoteur de recherche 51. Le processus 100 peut être effectué par l'architecture de traitement 50. [0048] Dans le bloc 102, une interrogation de recherche peut être reçue par le métamoteur de 10 recherche 51. En particulier, un utilisateur peut activer une application sur un système d'utilisateur 12 qui est programmée pour échanger du contenu avec le métamoteur de recherche 51 ou peut naviguer à l'aide d'un navigateur sur un système d'utilisateur 12 vers un site web connecté au métamoteur de recherche 51. Par la suite, l'utilisateur peut interagir avec le site web ou avec l'application pour soumettre une interrogation de recherche au métamoteur de 15 recherche 51. L'interrogation de recherche peut inclure une pluralité de critères de recherche qui décrivent les caractéristiques du produit qui intéresse l'utilisateur. [0049] Dans le bloc 104, en réponse à la réception de la demande de recherche, le rnétamoteur de recherche 51 peut générer une pluralité de résultats qui répondent aux critères de recherche. Chacun des résultats peut inclure un ou plusieurs des produits offerts à la vente par un 20 ou plusieurs des systèmes de vendeur de produits 16 de sorte que les résultats forment une liste complète des produits disponibles à la vente par plusieurs vendeurs. Comme décrit précédemment, chacun des systèmes de vendeur de produits 16 peut avoir un nom de domaine et une adresse de réseau uniques qui diffèrent de ceux du métamoteur de recherche 51 [0050] En particulier, chaque base de données de produit 66 de l'architecture de 25 traitement 50 peut être hébergée par un des systèmes de vendeur de produits 16 et peut inclure des données indicatives des produits disponibles offerts à la vente par le système de vendeur de produits 16. Par conséquent, en recevant la requête de recherche, le métamoteur de recherche 51 peut interroger les bases de données de produit 66 en fonction des critères de recherche, par exemple en transmettant une interrogation au moteur de recherche des systèmes de vendeur de 30 produits 16 via le nom de domaine ou l'adresse Internet uniques des systèmes de vendeur de produits 16. En réponse aux interrogations, le métamoteur de recherche 51 peut recevoir des données de produit de chacun des systèmes de vendeur de produits 16. Les données de produit de 18 3062942 chaque système de vendeur de produits 16 peuvent inclure des informations sur les produits disponibles offerts à la vente par le système de vendeur de produits 16 qui satisfont les critères de recherche de l'utilisateur. Par exemple, les données de produit peuvent inclure une description des produits disponibles, le coût des produits, une identification du système particulier de 5 vendeur de produits d'où proviennent les données de produit récupérées et une identification des fournisseurs de produits pour les produits. Le métamoteur de recherche 51 peut ensuite générer les résultats sur la base des données de produit reçues et afficher les résultats pour évaluation par l'utilisateur. Dans certaines applications, chaque résultat peut inclure un itinéraire de voyage comprenant de multiples produits de voyage. 10 [0051} Dans certains modes de réalisation, les données de produit utilisées pour générer les résultats peuvent être préalablement masquées par le métamoteur de recherche 51 avant la réception de l'interrogation de recherche de l'utilisateur. Par exemple, le métamoteur de recherche 51 peut masquer les données de produit relatives à des interrogations de recherche fréquentes. En outre, l'orchestrateur de transaction 52 peut maintenir un accès aux bases de données de produit 66, par exemple via les moteurs de recherche des systèmes de vendeur de produits 16 et/ou préserver le masquage des données de produit relatives aux interrogations de recherche fréquentes. Dans ce cas, â la réception par le métamoteur de recherche 51, le métamoteur de recherche 51 peut soumettre une interrogation correspondante à l'orchestrateur de transaction 52 qui peut ensuite récupérer et transmettre les données de produit correspondant aux 20 critères de recherche au métamoteur de recherche 5 L [0052] Dans le bloc 106, en réponse à la sélection par l'utilisateur de l'un des résultats générés par le métamoteur de recherche 51 pour achat, une demande de réalisation peut être reçue en provenance du métamoteur de recherche 51 par l'orchestrateur de transaction 52. La demande de réalisation peut inclure des données de l'utilisateur telles que le nom de l'utilisateur 25 et des données de paiement associées à la forme de paiement de l'utilisateur. La demande de réalisation peut aussi inclure des données de résultat associées au résultat sélectionné telles qu'une identification d'un ou de plusieurs produits inclus dans le résultat sélectionné, un prix associé à l'un ou à plusieurs des produits du résultat sélectionné, une identification du vendeur et/ou du système de vendeur de produits 16 à partir duquel ledit ou plusieurs produits du résultat 30 sélectionné ont été récupérés et une identification des fournisseurs de produits associée au ou à plusieurs produits du résultat sélectionné. 19 3062942 [0053] Dans certains modes de réalisation, en réponse à la sélection par l'utilisateur de l'un des résultats pour achat, le métamoteur de recherche 51 peut interroger l'utilisateur sur une forme de paiement (p. ex., une carte de crédit). En particulier, le métasystème de recherche 14 peut amener le navigateur ou l'application du système d'utilisateur 12 à afficher une interface 5 d'utilisateur avec des champs pour saisir une forme de paiement. Dans ce cas, les données de paiement incluses dans la demande de réalisation peuvent inclure la forme de paiement saisie par l'utilisateur. [0054] Dans d'autres modes de réalisation, en réponse à la sélection du résultat par l'utilisateur pour achat, le système d'utilisateur peut être redirigé vers une page de collecte de 10 paiement fournie par l'orchestrateur de transaction 52. L'utilisateur peut ensuite continuer à interagir avec la page de collecte pour fournir sa forme de paiement. En réponse à la réception de la forme de paiement de l'utilisateur via la page de collecte de paiement, l'orchestrateur de transaction 52 peut générer un jeton de paiement unique pour la forme de paiement et stocker la forme de paiement et le jeton de paiement dans une base de données de paiement. La base de 15 données de paiement peut être accessible par l'orchestrateur de transaction 52, mais ne pas être accessible par le métamoteur de recherche 51. La forme de paiement et le jeton de paiement de l'utilisateur peuvent être liés l'un à l'autre dans la base de données de paiement qui peut être l'une des bases de données de réalisation 62 de l'architecture de traitement 50. La base de données de paiement peut aussi inclure d'autres formes de paiement liées aux jetons de paiement 20 uniques qui ont été générés précédemment pour le même ou pour d'autres utilisateurs. Par la suite, l'orchestrateur de transaction 52 peut transmettre le jeton de paiement lié à la forme de paiement de l'utilisateur au métamoteur de recherche 51 et/ou au métasystème de recherche 14. Les données de paiement de la demande de réalisation envoyées du métamoteur de recherche 51 à l'orchestrateur de transaction 52 peuvent ensuite inclure le jeton de paiement. Dans ce cas, à la 25 réception de la demande de réalisation, l'orchestrateur de transaction 52 peut récupérer la forme de paiement de l'utilisateur dans la base de données de paiement sur la base du jeton de paiement. [0055] Dans certains modes de réalisation, si un jeton de paiement a été généré précédemment pour l'utilisateur par l'orchestrateur de transaction 52 par rapport à une 30 transaction antérieure, l'utilisateur peut alors entrer son jeton de paiement en sélectionnant un résultat pour achat et contourner la saisie d'une nouvelle forme de paiement. 20 3062942 [0056] La tokenisation de la forme de paiement de l'utilisateur mentionnée ci-dessus peut améliorer la sécurité, la fiabilité et la performance du métamoteur de recherche 51 et/ou du métasystème de recherche 14. Spécifiquement, cette caractéristique assure que la forme de paiement actuelle de l'utilisateur va être exposée à un nombre réduit de systèmes et que la forme 5 de paiement actuelle de l'utilisateur est conservée séparément et de façon confidentielle par rapport au métamoteur de recherche 51 et au métasystème de recherche 14. De la même façon, cette caractéristique réduit l'impact technique sur le métasystème de recherche 14, par exemple en évitant que le méta ait besoin de mettre en oeuvre des pages de collecte de paiement et de développer des systèmes conformes aux normes de sécurité associées au partage des formes de 10 paiement des utilisateurs. De plus, un jeton de paiement peut être exprimé en utilisant moins de données qu'une forme de paiement entière, ce qui améliore la performance du métasystème de recherche 14 et du métamoteur de recherche 51 en simplifiant les interfaces, en allégeant les messages d'interface et en améliorant la fiabilité par rapport aux messages de réseau qui sont propagés. La caractéristique de tokenisation est décrite de façon plus détaillée en référence à la 15 FIG. 5. [0057] Dans le bloc 108, un des bureaux de règlement 53 qui est associé au vendeur et/ou au système de vendeur de produits 16 identifié dans la demande de réalisation peut être sélectionné. En particulier, chaque système de vendeur de produits 16 peut inclure un ou plusieurs bureaux de règlement électronique 53 dans lesquels les transactions d'achat peuvent être traitées. Chaque 20 bureau de règlement 53 peut permettre de générer des enregistrements électroniques et de traiter des formes de paiement pour collecter le paiement d'une transaction d'achat pour le compte du vendeur associé. Dans certains modes de réalisation un ou plusieurs des bureaux de règlement 53 des systèmes de vendeur de produits 16 peuvent être hébergés par une même ou par plusieurs plateformes informatiques et peuvent utiliser des modules de logiciel partagés pour générer des 25 enregistrements électroniques et traiter des formes de paiement. La détermination du bureau de règlement spécifique 53 dans lequel la transaction doit être traitée pour un vendeur donné peut dépendre de plusieurs règles et de la demande de réalisation reçue par le métamoteur de recherche 51. Les bureaux de règlement 53 peuvent être logiquement et/ou physiquement distants du métamoteur de recherche 51 et du métasystème de recherche 14. 30 [0058] Dans un mode de réalisation, la détermination du bureau de règlement spécifique 53 peut dépendre d'une identification du vendeur, du pays et de la devise associés à la forme de paiement de l'utilisateur afin d'éviter toute conversion de devise, et le langage associé à 21 3062942 'l'utilisateur, chacun de ces éléments pouvant être inclus ou déduit (p. ex., la caractéristique de tokenisation) de la demande de réalisation reçue du métamoteur de recherche 51. Dans ce but, la base de données de vendeur 56 peut inclure une ou plusieurs bases de données comprenant plusieurs entrées. Chaque entrée peut représenter une règle qui inclut plusieurs éléments de règle 5 générale, tels qu'un identifiant de vendeur et une devise, un ou plusieurs éléments de règle primaire, un ou plusieurs éléments de règle alternative etiou un identifiant pour un bureau de règlement 53. Ledit ou plusieurs éléments de règle primaire peuvent inclure un ou plusieurs attributs tels qu'un pays principal et une langue principale, et ledit ou plusieurs éléments de règle alternative peuvent inclure un ou plusieurs attributs alternatifs tels qu'un pays secondaire et une 10 langue secondaire. Le tableau A ci-dessous montre deux entrées qui peuvent être stockées dans la base de données de vendeur 56. TABLEAU A Vendeur Devise Pays Alt. Pays Langue Alt. Bureau de règlement CDGAF0980 Langue AF EUR FR BE EN FR LH EUR DE DE FRALH0980 [0059] Pour déterminer un bureau de règlement 53, l'orchestrateur de transaction 52 peut 15 rechercher une entrée dans la base de données de vendeur 56 ayant des éléments de règle générale et des éléments de règle primaire qui correspondent aux données incluses dans la demande de réalisation ou sont déduites de celle-ci. Par exemple, l'orchestrateur de transaction 50 peut rechercher une entrée pour laquelle l'identifiant de vendeur, la devise, et/ou plusieurs attributs primaires correspondent à la demande de réalisation. Si cette entrée est 20 trouvée, l'orchestrateur de transaction 52 peut alors sélectionner le bureau de règlement 53 identifié dans l'entrée. Si une cette entrée n'est pas trouvée ; l'orchestrateur de transaction 52 peut alors effectuer une autre recherche dans la base de données de vendeur 56 pour rechercher une ou plusieurs entrées qui correspondent aux données incluses dans la demande de réalisation, ou qui sont déduites de celle-ci, lorsqu'un ou plusieurs éléments de règle alternative sont aussi 25 pris en compte. Par exemple, l'orchestrateur de transaction 52 peut rechercher une ou plusieurs entrées pour lesquelles l'identifiant de vendeur, la devise, un ou plusieurs des attributs primaires et/ou un ou plusieurs des attributs alternatifs correspondent aux données incluses dans la demande de réalisation ou sont déduites de celle-ci. 22 3062942 ' [0060] Dans un mode de réalisation, l'orchestrateur de transaction 52 peut sélectionner le bureau de règlement 53 identifié clans l'entrée ayant le plus d'éléments de règle correspondant. Ainsi lorsque de multiples entrées correspondantes sont à égalité pour le plus grand nombre d'entrées correspondantes, l'orchestrateur de transaction 52 peut alors utiliser des poids attribués 5 aux divers éléments de règle pour chaque entrée à égalité et sélectionner le bureau de règlement 53 identifié dans l'entrée dont la somme pondérale est la plus élevée. Par exemple, le poids associé à un élément de règle primaire peut-être plus élevé que le poids associé à un élément de règle alternative. Dans ce cas, si une entrée correspond via deux éléments de règle alternative, et une entrée supplémentaire correspond également via un élément de règle alternative et un élément de règle primaire, l'entrée supplémentaire dont la somme pondérale est la plus élevée peut alors être sélectionnée. Comme autre exemple, le pays peut être associé à un poids plus élevé que le poids associé à la devise. Par conséquent. si une entrée correspond via la devise mais ne correspond pas via le pays, et une entrée supplémentaire correspond également via le pays mais ne correspond pas via la devise, alors l'entrée supplémentaire peut être sélectionnée pour avoir une somme pondérale plus élevée. Les poids attribués à chaque élément de règle peuvent être basés sur des règles commerciales ou des attributions administratives. Dans certains modes de réalisation, seuls certains éléments de règle peuvent être soumis à une pondération, tels que la devise, les attributs primaires et/ou les attributs secondaires. En outre, l'appariement avec un ou de plusieurs des éléments de règle, tels que le vendeur, peut-être une condition préalable nécessaire avant qu'une entrée puisse faire l'objet d'une sélection. Si aucune entrée correspondante est trouvée après une recherche en sous-séquences, l'orchestrateur de transaction 52 peut alors rejeter la demande de réalisation et envoyer un message notifiant ce fait au métamoteur de recherche 51. [0061] Dans certain modes de réalisation, le méta peut être en mesure d'influencer la 25 détermination du bureau de règlement 53. En particulier, le métamoteur de recherche 51 peut fournir un identifiant d'un bureau de règlement spécifique 53 à l'orchestrateur de transaction 52, par exemple dans la demande de réalisation transmise à l'orchestrateur de transaction 52. Dans ce cas, l'orchestrateur de transaction 52 peut contourner la recherche dans la base de données de vendeur 56 et sélectionner le bureau de règlement 53 identifié dans la demande de réalisation. 30 Autrement, le méta ou le métamoteur de recherche 51 peuvent fournir une liste identifiant plusieurs bureaux de règlement 53 qui peuvent être sélectionnés par l'orchestrateur de transaction 52. Dans ce cas, l'orchestrateur de transaction 52 peut procéder à une recherche dans 23 3062942 'la base de données de vendeur 56 comme décrit ci-dessus. Cependant, pour une vérification supplémentaire, l'orchestrateur de transaction 52 peut comparer le bureau de règlement 53 sur la base de la recherche avec les bureaux identifiés dans la liste. Si le bureau de règlement 53 sélectionné par l'orchestrateur de transaction 52 sur la base de la recherche n'est pas inclus dans 5 la liste fournie par le méta, l'orchestrateur de transaction 52 peut alors rejeter la demande de réalisation comme cela a été décrit précédemment. [0062] Dans le bloc 110, il est possible de se connecter automatiquement au bureau de règlement 53 déterminé, par exemple avec l'orchestrateur de transaction 52. Par exemple, la base de métadonnées 58 peut inclure une ou plusieurs bases de données qui incluent les justificatifs de 10 connexion pour le méta relatifs aux bureaux de règlement 53, incluant le bureau de règlement déterminé 53. Par conséquent, après que le bureau de règlement 53 a été déterminé, l'orchestrateur de transaction 52 peut récupérer les justificatifs de connexion du méta pour le bureau de règlement déterminé 53 à partir de la base de métadonnées 58 et peut par la suite se connecter au bureau de règlement déterminé 53 en utilisant les mêmes justificatifs. [0063] Dans le bloc 112, un enregistrement électronique peut être généré, par exemple dans une des bases de données d'enregistrement électronique 54. En particulier, pendant la connexion au bureau de règlement déterminé 53, l'orchestrateur de transaction 52 peut provoquer la génération et le stockage d'un enregistrement de réservation ou d'achat au bureau de règlement déterminé 53. En d'autres termes, un enregistrement de réservation peut être généré et stocké 20 dans une base de données de réservation incluse dans les bases de données d'enregistrement électronique 54 et peut être accessible via le bureau de règlement 53, par un utilisateur ou par un système connecté au bureau de règlement 53. Lorsque l'orchestrateur de transaction provoque l'occurrence d'un évènement dans un bureau de règlement déterminé 53, l'évènement peut être mis en oeuvre par le système de vendeur de produits 16 incluant le bureau de règlement 25 déterminé 53 en conjonction avec les orchestrateurs de transaction 52 qui émettent une requête pour cet évènement au système de vendeur de produits 16. Le contenu de l'enregistrement de réservation peut être basé sur les données incluses dans la demande de réalisation ou déduites de celle-ci. Par exemple, l'enregistrement de réservation peut inclure une identification d'un utilisateur ex,, un passager ou un acheteur) et une identification dudit ou de plusieurs produits 30 du résultat sélectionné. L'orchestrateur de transaction 52 peut alors provoquer la tarification dudit ou de plusieurs produits en utilisant les données de tarification associées aux produits du résultat sélectionné (p. ex., données tarifaires), et un ou plusieurs éléments financiers qui 24 3062942 modélisent la vente dudit ou de plusieurs produits peuvent être ajoutés à l'enregistrement de réservation. En particulier, ledit ou plusieurs éléments financiers peuvent inclure des détails relatifs à la façon dont le produit a été vendu et tarifé. Par exemple, chaque élément financier peut inclure un prix d'achat, une information relative à un rabais ou une surcharge, l'état du 5 paiement ex., réglé ou non réglé) et/ou l'état de la vente (p. ex., réservée, finalisée ou annulée). [0064] Dans le bloc 114. il est possible de déterminer si le méta ou le vendeur dudit ou de plusieurs produits inclus dans le résultat sélectionné doit être le commerçant pour la transaction en ligne. Cette détermination peut être basée sur ies données incluses dans la demande de réalisation ou déduites de celle-ci. La détermination du commerçant peut être ajoutée à l'enregistrement de réservation générée pour l'achat au bureau de règlement déterminé 53, par exemple dans un élément financier. [0065] En réponse à la détermination que le méta est le commerçant (branche « OUI » du bloc 114) une carte de crédit virtuelle (VCC) peut alors être générée automatiquement au 15 bloc 116. En particulier, pour que le vendeur vende ledit ou plusieurs produits du résultat sélectionné par l'utilisateur, il peut être nécessaire de fournir au système de vendeur de produits correspondant 16 une forme de paiement compatible avec le système de vendeur de produits 1 Cependant, lorsque le méta agit en qualité de commerçant, il n'est peut-être pas souhaitable de fournir la forme de paiement actuelle de l'utilisateur au vendeur pour des raisons confidentielles. 20 Par conséquent, l'orchestrateur de transaction 52 peut faire appel à un fournisseur de VCC, tel qu'un fournisseur de carte de crédit ou une banque, pour générer une VCC compatible avec le système de vendeur de produits 16 des produits du résultat sélectionné, celle-ci étant associée de façon confidentielle au méta et à la forme de paiement de l'utilisateur par l'orchestrateur de transaction 52. 25 [0066] Dans le bloc 118, l'orchestrateur de transaction 52 peut amener les données de paiement incluant la VCC à être insérées dans l'enregistrement de réservation généré au bureau de règlement déterminé 53, par exemple comme élément de forme de paiement (FP), Plus tard lorsque le vendeur poursuit avec le règlement de l'achat, le vendeur peut utiliser la VCC pour saisir le paiement pour les produits achetés à partir du méta. La VCC facilite de cette façon le 30 flux de règlement entre le méta et le vendeur lorsque le méta est le commerçant, tout en réduisant l'impact technique sur le système de vendeur de produits 16. 25 3062942 .[0067] Dans certain modes de réalisation, lorsqu'il est déterminé que le méta doit agir en qualité de commerçant, l'orchestrateur de transaction 52 peut insérer des éléments additionnels dans l'enregistrement de réservation qui sont accessibles au méta et demeurent confidentiels par rapport au vendeur. En particulier, au cours de la connexion au bureau de règlement S déterminé 53, l'orchestrateur de transaction 52 peut causer l'ajout d'un élément de sécurité à l'enregistrement de réservation permettant de consulter et de manipuler l'enregistrement de réservation pendant la connexion à un métabureau associé au méta. Le bureau méta peut être hébergé par l'orchestrateur de transaction 52, peut être implémenté par une même ou plusieurs plateformes informatiques sous la forme d'un ou de plusieurs bureaux de règlement 53 et peut 10 partager des modules logiciels avec un ou plusieurs des bureaux de règlement 53. [0068] Après que l'élément de sécurité a été ajouté à l'enregistrement de réservation, l'orchestrateur de transaction 52 peut se déconnecter du bureau de règlement déterminé 53 et se connecter au métabureau. Au cours de la connexion au métabureau, l'orchestrateur de transaction 52 peut récupérer l'enregistrement de réservation et ajouter un élément de forme de 15 paiement qui modélise la forme de paiement actuelle pour le méta. Par ailleurs, l'orchestrateur de transaction 52 peut ajouter un autre élément financier à l'enregistrement de réservation qui modélise des frais de service appliqués par le méta pour le traitement de la transaction L'orchestrateur de transaction 52 peut marquer chacun de ces éléments comme éléments confidentiels dans l'enregistrement de réservation afin d'empêcher le vendeur de les récupérer ou 20 de les consulter via le bureau de règlement déterminé 53. Par la suite, l'orchestrateur de transaction 52 peut se déconnecter du métabureau et retourner dans le bureau de règlement déterminé 53 pour effectuer les étapes restantes du processus 100. [0069] Dans le bloc 120, la forme de paiement de l'utilisateur peut être traitée pour le méta, par exemple par l'orchestrateur de transaction 52. Dans certains modes de réalisation, le bloc 120 25 peut inclure la retarification du résultat sélectionné, en tenant compte des frais de transaction associés au traitement de la forme de paiement de l'utilisateur lorsque le méta est le commerçant. Le prix indiqué à l'utilisateur pour chaque résultat affiché par le métamoteur de recherche 51 peut en particulier être basé sur le fait que le vendeur agit en qualité de commerçant. Cependant, les frais de transaction pour la forme de paiement de l'utilisateur peuvent fluctuer selon que le 30 méta ou le vendeur est sélectionné comme commerçant, causant ainsi un changement du prix pour le résultat sélectionné par l'utilisateur lorsque le méta est sélectionné comme commerçant. Ainsi, si le prix recalculé relatif au résultat sélectionné est plus élevé que celui qui a été annoncé 26 3062942 'à l'utilisateur à l'origine, l'orchestrateur de transaction 52 peut rejeter la demande de réalisation ou peut transmettre un avertissement au métamoteur de recherche 51. [0070] En supposant que le traitement de la demande de réalisation se poursuive, soit parce que le prix du résultat sélectionné n'est pas affecté négativement par le méta en qualité de 5 commerçant, soit parce que le métamoteur de recherche 51, peut-être à l'initiative de l'utilisateur, instruit l'orchestrateur de transaction 52 de continuer en dépit de l'avertissement d'un prix plus élevé, l'orchestrateur de transaction 52 peut amener une plateforme de paiement associée au méta à effectuer une vérification antifraude concernant la forme de paiement de l'utilisateur et demander une autorisation à la banque associée à la forme de paiement de 10 l'utilisateur pour le nouveau prix calculé. La plateforme de paiement peut être une plateforme tierce sous contrat avec le méta et peut être implémentée par le système de gestion de transaction 18 ou par le métasystème de recherche 14. [0071] Autrement, en réponse à la détermination que le vendeur d'un ou de plusieurs produits inclus dans le résultat sélectionné est le commerçant (branche «NON » du bloc 114) l'orchestrateur de transaction 52 peut alors, dans le bloc 122, amener les données de paiement incluses dans la forme de paiement de l'utilisateur à être ajoutées à l'enregistrement de réservation au bureau de règlement déterminé 53. Dans le bloc 124, la forme de paiement de l'utilisateur peut être traitée par le vendeur. Spécifiquement, l'orchestrateur de transaction 52 peut amener une plateforme de paiement associée au bureau de règlement déterminé 53 ainsi que le système de vendeur de produits correspondant 16 à effectuer une vérification antifraude pour la forme de paiement de l'utilisateur etiou à autoriser la forme de paiement fournie par l'utilisateur pour le montant de l'achat. [0072] Ainsi, conformément au processus 100, la forme de paiement de l'utilisateur peut être traitée sur la base de la détermination du commerçant. Spécifiquement. si le méta est sélectionné 25 comme commerçant au bloc 114, la forme de paiement de l'utilisateur peut alors être traitée sur la base de la détermination du commerçant par l'orchestrateur de transaction 52 en amenant une plateforme de paiement associée au méta à traiter la forme de paiement de l'utilisateur (bloc 120). Autrement, si le vendeur est sélectionné comme commerçant au bloc 114, la forme de paiement de l'utilisateur peut alors être traitée sur la base de la détermination de commerçant par 30 l'orchestrateur de transaction 52 en amenant une plateforme de paiement associée au système de vendeur de produits 16 à traiter les informations de paiement de l'utilisateur (contrairement à la génération d'une VCC par l'orchestrateur de transaction 52) (bloc 124). 27 3062942 [0073] Dans le bloc 126, les enregistrements électroniques peuvent être mis à jour et/ou générés au bureau de règlement déterminé 53. Spécifiquement, l'orchestrateur de transaction 52 peut demander l'émission d'un contrat pour confirmer la vente, par exemple au système de vendeur de produits correspondant 16. Dans le cas de produits de transport aérien, l'émission de contrat peut inclure l'émission d'un billet. En réponse à la requête, un contrat électronique peut être émis au bureau de règlement déterminé 53 qui peut être stocké dans une base de données de contrat incluse dans les bases de données d'enregistrement électronique 54. De plus, l'enregistrement de réservation généré précédemment pour la vente peut être mis à jour au bureau de règlement déterminé 53 pour inclure un numéro unique associé au contrat électronique 10 généré. Dans certains modes de réalisation, le bloc 124 du processus 100 peut faire partie du bloc 126. En d'autres termes, la demande d'émission de contrat peut aussi impliquer la demande de traitement des informations de paiement de l'utilisateur qui peut alors être effectuée au bureau de règlement 53 par le système de vendeur de produits 16. [0074] Au bloc 128, après la forme de paiement de l'utilisateur a été traitée, et que les 15 enregistrements électroniques ont été générés et/ou mis à jour, un flux de données peut être généré et transmis en temps réel au méta, par exemple par l'orchestrateur de transaction 52. En particulier, lorsque le méta est le commerçant, le flux peut inclure les éléments financiers et les détails de paiement de l'utilisateur inclus dans l'enregistrement de réservation. De cette façon, le méta peut suivre un taux de conversion actualisé en même temps que la vente est finalisée. De 20 manière connexe, le flux de données permet au méta de réclamer au vendeur une commission justifiée à titre d'apporteur et d'effectuer un rapprochement entre la commission reçue et l'achat. En outre, la commission peut faire partie du processus de règlement entre le vendeur et le méta, permettant ainsi au méta de provisionner la commission d'une façon sûre. [0075] Dans certains modes de réalisation, le métasystème de recherche 14 peut inclure 25 plusieurs bureaux de déclaration maintenus par le méta. Dans ce cas, l'orchestrateur de transaction 52 peut déterminer un des bureaux de déclaration comme destinataire du flux de données en temps réel sur la base de plusieurs règles et d'éléments de règle. Chaque méta peut de cette façon consolider les rapports de transactions diverses provenant de bureaux spécifiques selon les détails de chaque transaction. Plus particulièrement, de façon similaire à la base de 30 données de vendeur 56, la base de données de méta 58 peut inclure une ou plusieurs bases de données incluant plusieurs entrées. Chacune des entrées peut représenter une règle qui inclut des éléments de règle et l'identification d'un bureau de déclaration. Les éléments de règle peuvent 28 3062942 'inclure une identification du méta, une identification d'un métamoteur de recherche 51 particulier et/ou un métasystème de recherche 14 du méta d'où la demande de réalisation a été envoyée (un méta pouvant héberger de multiples métamoteurs de recherche 51 et/ou de multiples métasystèmes de recherche 14) ainsi qu'une devise, un pays et une région associés à l'achat. Le tableau B ci-dessous montre plusieurs entrées qui peuvent être incluses dans la base de métadonnées 58. TABLEAU B Méta moteur de Méta Devise Pays Région Bureau de recherche/système déclaration SuperSearch.us MÉTA .1 USD US NORAM NYCME2000 MeoaSearch.uk META1 GBP UK Europe LONME2000 MegaSearch.fr MÉTA I EUR FR Europe LONME2000 AlwaysSearch.de TOPMÉTA EUR DE NECSE FRAT02000 [0076] L'orchestrateur de transaction 52 peut ainsi rechercher dans la base de métadonnées 10 une ou plusieurs entrées incluant des éléments de règle qui correspondent aux données incluses dans la demande de réalisation ou qui sont déduites de celle-ci. Par la suite, l'orchestrateur de transaction 52 peut sélectionner le bureau de déclaration identifié dans l'entrée avec le plus d'éléments de règle appariés pour y transmettre le flux de données en temps réel. Si des entrées multiples incluant un nombre égal d'éléments appariés sont trouvées, l'orchestrateur de 15 transaction 52 peut alors utiliser des poids affectés aux éléments de règle de chaque entrée et sélectionner le bureau de déclaration identifié dans l'entrée ayant la somme pondérale la plus élevée, Par exemple, une région peut être associée à un poids plus élevé que celui qui est associé à la devise. Dans ce cas, si une entrée correspond via la devise mais ne correspond pas via la région et une entrée additionnelle correspond également via la région mais ne correspond pas via 20 la devise, l'entrée additionnelle peut alors être sélectionnée pour avoir la somme pondérale la plus élevée. Les poids attribués à chaque élément de règle peuvent être basés sur des règles commerciales ou des attributions administratives. Dans certains modes de réalisation, seuls certains des éléments de règle peuvent faire l'objet d'une affectation de poids, tels que la devise, le pays et la région. En outre, l'appariement d'un ou de plusieurs des éléments de règle, tels que 25 le méta, peuvent être une condition préalable nécessaire avant qu'une entrée ne puisse faire l'objet d'une sélection. Si aucune entrée n'est trouvée, l'orchestrateur de transaction 52 peut, par 29 3062942 'défaut, envoyer le fiux de données au métamoteur de recherche 51 et/ou au métasystème de recherche 14 en provenance duquel la demande de réalisation a été reçue. [0077) La FIG.5 illustre un processus 200 qui peut également être mis en oeuvre par l'architecture de traitement 50 pour améliorer le métamoteur de recherche 51. En particulier, le processus 200 améliore la performance et l'intégrité de l'architecture de traitement 50 en utilisant des données incluses dans les bases de données 62 et dans la base de données de jeton 60. Les bases de données de réalisation 62 peuvent inclure une base de données de résultat, une base de données de paiement, une base de données de coupon et une base de données de profil. Le contenu de chacune de ces bases de données est décrit de façon plus détaillée ci-dessous. [0078] Dans le bloc 202, une demande de recherche peut être reçue de l'utilisateur au niveau du métamoteur de recherche 51. Dans le bloc 204, une pluralité de résultats qui satisfont la demande de recherche peut être générée, par exemple par le métamoteur de recherche 51 ou par l'orchestrateur de transaction 52 sur la base de données de produit incluses dans les bases de 15 données de produit 66. Ces blocs peuvent fonctionner de façon similaire aux blocs 102 et 104 du processus 100 (FIG.4). [0079] Dans le bloc 206, chacun des résultats peut être associé à un identifiant unique d'offre. L'orchestrateur de transaction 52 I ou le métamoteur de recherche 51 peuvent en particulier générer un ID unique pour chaque résultat, Par la suite, au bloc 208, les résultats et les 20 ID d'offre peuvent être stockés dans la base de données de résultat, de sorte que chaque résultat est lié à un ID d'offre correspondant dans la base de données de résultat. Par exemple, si le métamoteur de recherche 51 génère les résultats et/ou les ID d'offre, le métamoteur de recherche 51 peut transmettre les résultats et/ou les ID d'offre à l'orchestrateur de transaction 52 qui peut alors stocker les résultats et les ID d'offre dans la base de données de résultat. La base 25 de données de résultat peut être accessible par l'orchestrateur de transaction 52, mais ne pas être accessible par le métamoteur de recherche 51 et/ou par le métasystème de recherche 14. Dans certains modes de réalisation, la base de données de jeton 60 peut inclure ou être combinée avec la base de données de résultat en une seule base de données plus large. Dans le bloc 210, si les résultats et/ou les ID d'offre ont été générés par l'orchestrateur de transaction 52, les résultats 30 et/ou les ID d'offre peuvent être transmis au métamoteur de recherche 51. Quel que soit le cas, le métamoteur de recherche 51 a les résultats, le métamoteur de recherche 51 peut à son tour afficher les résultats à l'utilisateur pour évaluation. 30 3062942 [0080] Dans le bloc 212, en réponse à la sélection par l'utilisateur de l'un des résultats pour achat, une demande de réalisation peut être reçue, par exemple par l'orchestrateur de transaction 52. Cependant, plutôt que d'inclure les données de l'utilisateur et les données de résultat comme décrit ci-dessus dans la demande de réalisation, la demande de réalisation peut 5 inclure un ou plusieurs jetons (égaiement désignés dans les présentes comme « ID »). Spécifiquement, la demande de réalisation peut inclure l'ID d'offre correspondant au résultat sélectionné, par exemple dans les données de résultat de la demande de réalisation. De plus, ou autrement, la demande de réalisation peut inclure un ID de profit correspondant à un profil stocké dans la base de données de profil, un ID de coupon correspondant à un coupon 10 électronique stocké dans la base de données de coupon que l'utilisateur souhaite appliquer au prix du résultat sélectionné, et/ou un jeton de paiement correspondant à la forme de paiement de l'utilisateur stocké dans la base de données de paiement. L'ID de profil, l'ID de coupon et/ou le jeton de paiement peuvent être inclus dans les données relatives à l'utilisateur dans la demande de réalisation. L'utilisateur peut avoir saisi sa forme de paiement correspondant au jeton de paiement lors d'une transaction antérieure ou en réponse à la sélection du résultat pour achat comme cela a été décrit ci-dessus. De façon similaire. l'utilisateur peut avoir créé et stocké un profil correspondant à l'ID de profil au cours d'une interaction avec l'orchestrateur de transaction 52 dans le cadre d'une transaction antérieure ou en réponse à la sélection du résultat pour achat. Le coupon électronique correspondant à l'ID de coupon peut avoir été créé et stocké 20 dans la base de données de coupon dans le cadre d'une transaction antérieure qui est décrite de façon plus détaillée en référence à la FIG 6. [0081] En incluant les jetons mentionnés ci-dessus plutôt que les données correspondant à ces jetons dans la demande de réalisation, les interfaces entre le métamoteur de recherche 51 et rchestrateur de transaction 52 sont allégées et plus fiables. Spécifiquement, c'est parce qu'il 25 faut moins de données pour représenter les jetons qu'il n'en faut pour représenter les données correspondantes que les besoins en données devant être échangées entre le métamoteur de recherche 51 et l'orchestrateur de transaction 52 sont moindres lorsqu'un utilisateur sélectionne un résultat pour achat. Par ailleurs, parce que moins de données sont utilisées pour exprimer la demande de réalisation, la propagation devient plus fiable, car la probabilité d'une altération de 30 la demande de réalisation par une interférence pendant la transmission diminue. De plus, parce que le méta ne collecte pas et ne transmet pas de forme de paiement, certaines normes de conformité relatives aux échanges de formes de paiement sont évitées, ce qui réduit l'impact 31 3062942 'technique sur le métasystème de recherche 14. De façon similaire, la caractéristique de tokenisation concentre le trafic et le traitement sur le système hébergeant l'orchestrateur de transaction 52 plutôt que sur le métamoteur de recherche 51, ce qui améliore globalement la performance du métamoteur de recherche 51 et de l'architecture de traitement 50. Par exemple, s le système hébergeant le système de l'orchestrateur de transaction 52 peut être configuré de façon à avoir accès à des ressources de traitement additionnelles et peut être mieux adapté pour gérer un trafic et un traitement augmentés, réduisant ainsi encore plus l'impact technique sur le métasystème de recherche 14. [0082] Dans le bloc 214, en réponse à la réception de la demande de réalisation, des données 10 de réalisation peuvent être déterminées sur la base des jetons inclus dans la demande de réalisation. L'orchestrateur de transaction 52 peut en particulier récupérer le résultat sélectionné de l'utilisateur dans la base de données de résultat en fonction de l'ID d'offre inclut dans la demande de réalisation, récupérer la forme de paiement de l'utilisateur dans la base de données de paiement en fonction du jeton de paiement inclus dans la demande de réalisation, récupérer le coupon électronique applicable au coût du résultat sélectionné dans la base de données de coupon en fonction de l'ID de coupon inclus dans la demande de réalisation et/ou des informations de l'utilisateur telles que le nom de l'utilisateur, dans la base de données de profil en fonction de l'ID de profil inclus dans la demande de réalisation. [0083] Les jetons de la demande de réalisation peuvent être stockés, dans le bloc 216. 20 L'orchestrateur de transaction 52 peut en particulier stocker le jeton de paiement, l'ID d'offre, l'ID de coupon et/ou l'ID de profil inclus dans la demande de réalisation, dans la base de données de jeton 60. La base de données de jeton 60 peut être accessible par l'orchestrateur de transaction 50, mais ne pas être accessible par le métamoteur de recherche 51 ou par le métasystème de recherche 14. Par ailleurs, la base de données de jeton 60 peut être stockée sur 25 un dispositif de mémoire non volatile, de sorte que si le système hébergeant la base de données subit une perturbation ou doit être réinitialisé, les données qui y sont stockées seront sauvegardées. [0084] Bien que la conservation des jetons de la demande de réalisation (bloc 216) donnée en exemple survienne après la détermination des données de réalisation sur la base des jetons de la 30 demande de réalisation (bloc 214), dans d'autres modes de réalisation, les jetons de la demande de réalisation peuvent être stockés préalablement à la détermination des données de réalisation. La conservation des jetons avant la détermination des données de réalisation peut améliorer la 32 3062942 fiabilité du système globalement, car les jetons sont déjà stockés dans l'éventualité d'une erreur ou d'une perturbation du système pendant la récupération des données de réalisation. Des détails supplémentaires sur la gestion des perturbations sont donnés ci-dessous. [0085] Dans le bloc 218, la transaction initiée par l'utilisateur à partir du tnétamoteur de recherche 51 peut continuer a être traitée. Spécifiquement, l'orchestrateur de transaction 52 peut procéder au traitement de la demande de réalisation, par exemple en effectuant les opérations détaillées dans le processus sur la base des données de réalisation récupérées (FIG.4). Par.la suite, dans le bloc 220, il est possible de déterminer si le traitement de la demande de réalisation a été perturbé. Par exemple, une interruption peut survenir en raison d'un crash du système ou 10 d'une interruption de l'alimentation électrique affectant l'un quelconque des systèmes de l'environnement d'exploitation 10. Une fois que le système perturbé fonctionne à nouveau normalement, l'orchestrateur de transaction 52 peut déterminer qu'une perturbation est survenue. En réponse à la détermination que le système a subi une perturbation au cours du traitement de la demande de réalisation (branche « OUI » du bloc 220), les jetons inclus dans la demande de 15 réalisation transmise précédemment par le in étamoteur de recherche 51 peuvent être récupérés, au bloc 222, à partir de la base de données de jeton 60. Par la suite, au bloc 224 les données de réalisation associées aux jetons peuvent être récupérées, par exemple par l'orchestrateur de transaction 52, dans les bases de données de réalisation 62, de la façon décrite ci-dessus en référence au bloc 214. Le traitement de la transaction peut ensuite continuer dans le bloc 226 sur 20 la base des données de réalisation. De cette façon, l'orchestrateur de transaction 52 peut reprendre le traitement de la demande de réalisation en fonction des données de réalisation récupérées après le retour à un mode de fonctionnement normal du système qui a subi la perturbation. [0086] Le processus 200, et particulièrement la base de données de jeton 60, peut fournir une 25 amélioration de la sécurité et de l'intégrité des systèmes qui implémentent l'architecture de traitement 50. Notamment, les jetons stockés dans la base de données de jeton sont très petits par rapport aux données ils sont respectivement associés. Par conséquent, le processus 200 permet de stocker le panier d'achats de l'utilisateur dans son intégralité avec très peu de données. En outre, le stockage et la récupération de ces données peuvent se faire très rapidement améliorant ainsi le 30 temps de réponse du système. De plus, dans le cas d'une quelconque perturbation de système, aucune donnée n'est perdue et le processus peut facilement reprendre ou recommencer. 33 3062942 [0087] La FIG.6 illustre un processus exemplaire 300 pouvant être mis en oeuvre par l'architecture de traitement 50 pour optimiser le métamoteur de recherche 51 encore plus et améliorer l'expérience de l'utilisateur. Spécifiquement, comme le montre le processus 100 (FIG.4). lorsque le méta est sélectionné comme commerçant, une VCC peut être générée et 5 fournie au vendeur. Cependant, dans certaines situations, les frais de transaction associés au traitement de la VCC générée pour une demande de réalisation donnée peuvent s'avérer moins élevés que les frais de transaction pour le traitement de la forme de paiement de l'utilisateur pour une demande de réalisation donnée. Par conséquent, dans cette circonstance, l'orchestrateur de transaction 52 peut être configuré pour générer un coupon à l'utilisateur. 10 [0088] Plus particulièrement, en réponse à la sélection du méta comme commerçant pour une demande de réalisation donnée (branche « OUI » du bloc 302), des frais de transaction pour le traitement de la forme de paiement de l'utilisateur pour une demande de réalisation donnée par le méta peuvent être récupérés dans le bloc 304, par exemple par l'orchestrateur de transaction 52, et des frais de transaction pour le traitement de la VCC générés pour la demande de réalisation 15 par le vendeur (ou le système de vendeur de produits correspondant) peuvent être récupérés, par exemple par l'orchestrateur de transaction 52. Par la suite, les frais de transaction récupérés peuvent être comparés au bloc 306 afin de déterminer lesquels sont plus élevés. L'orchestrateur de transaction 52 peut, en particulier, déterminer si les frais récupérés pour la forme de paiement de l'utilisateur sont plus ou moins élevés que les frais de transaction récupérés pour la VCC. 20 [0089] En réponse à la détermination que les frais de transaction récupérés pour la forme de paiement de l'utilisateur sont plus élevés que les frais de transaction récupérés pour la VCC (branche « UPF PLUS ÉLEVÉ » du bloc 306). un coupon électronique pour la différence entre les frais de transaction peut être généré et stocké au bloc 308. L'orchestrateur de transaction 52 peut, en particulier, générer et stocker le coupon électronique dans une des bases de données de 25 réalisation 62, notamment dans une base de données de coupon. Le coupon électronique peut inclure un ID de coupon, et l'orchestrateur de transaction 52 peut notifier le coupon électronique à l'utilisateur et lui fournir un ID de coupon après que la transaction est traitée, par exemple via l'envoi d'un message au système d'utilisateur 12. L'utilisateur peut ensuite saisir l'ID de coupon ultérieurement lorsqu'il utilise le métamoteur de recherche 51 pour effectuer l'achat d'un 30 produit. [0090] Autrement, en réponse à la détermination que les frais de transaction pour la VCC sont plus élevés que les frais de transaction récupérés pour la forme de paiement de l'utilisateur 34 3062942 '(branche « VCC PLUS ELEVEE » du bloc 306), un rejet de la demande de réalisation peut alors être émis au bloc 310, ou une alerte peut être générée et fournie au métamoteur de recherche 51, par exemple par l'orchestrateur de transaction 52. Dans l'éventualité d'une alerte, le processus 100 (FIG.4) peut être interrompu (p. ex., plus de traitement après les blocs116 ou 118) 5 jusqu'à ce que le métamoteur de recherche 51, potentiellement sous les ordres de l'utilisateur, instruise l'orchestrateur de transaction 52 de passer outre l'alerte et de continuer. [0091] Autrement, si le méta n'est pas sélectionné comme commerçant pour une demande de réalisation donnée (branche « NON » du bloc 302), il est alors possible de déterminer que cette décision doit être écartée au profit de l'utilisateur. Spécifiquement, les frais de transaction, pour 10 le traitement de la forme de paiement de l'utilisateur, relatifs à la demande de réalisation par le méta peuvent être récupérés au bloc 312. De plus, un ou plusieurs frais de transaction pour le traitement d'une ou de plusieurs VCC potentielles relatives à la demande de réalisation par le vendeur (ou le système de vendeur de produits correspondant 16) peuvent être récupérés. Dans le bloc 314, il est possible de déterminer si au moins certains des frais de transaction pour les VCC potentielles sont moindres que les frais de transaction pour la forme de paiement de l'utilisateur. En d'autres termes, l'orchestrateur de transaction 52 peut comparer chacun des frais de transaction récupérés une VCC avec les frais de transaction pour la forme de paiement de l'utilisateur jusqu'à aboutir aux frais de transaction les moins élevés. [0092] En réponse à la détermination que les frais de transaction pour une VCC sont moins 20 élevés que les frais de transaction pour la forme de paiement de l'utilisateur (« branche "OUI" du bloc 314), il est alors possible de passer outre la décision du commerçant au bloc 316 afin de sélectionner le méta comme commerçant pour la demande de réalisation. Le processus 300 peut ensuite poursuivre aux blocs 304 et 306 qui, comme cela a été décrit ci-dessus, peuvent permettre à l'utilisateur de bénéficier de frais de transaction moins élevés via un coupon. Autrement, si des frais de transaction moins élevés pour le traitement d'une VCC potentielle ne peuvent pas être récupérés (branche «NON » du bloc 314) la demande de réalisation peut alors continuer à être traitée au bloc 318 avec le vendeur en qualité de commerçant. [0093] Dans certains modes de réalisation, l'orchestrateur de transaction 52 peut obtenir les frais de transaction mentionnés ci-dessus en émettant une demande de cotation aux plateformes 30 de paiement associées au métamoteur de recherche 51 et au système de vendeur de produits pertinent 16 pour chaque forme de paiement ou VCC potentielle visée. Cependant, le traitement de chacune de ces requêtes prend du temps et par conséquent pourrait nuire à la performance du 3062942 ' système, particulièrement au vu du grand nombre potentiel de VCC qui peut être généré pour une demande de réalisation. De ce fait, afin d'améliorer la performance du système, l'orchestrateur de transaction 52 peut plutôt récupérer les frais de transaction pertinents dans la base de données de frais de transaction 64. 5 [0094] Dans ce but. la base de données de frais de transaction 64 peut être préremplie avec plusieurs frais de transaction pour divers vendeurs et/ou divers types de forme de paiement. Spécifiquement, comme décrit précédemment, des frais de transaction pour une forme de paiement ou VCC donnée peuvent fluctuer selon que c'est le méta ou le vendeur qui traite la forme de paiement ou VCC et également sur la base d'autres données incluses dans la demande 10 de réalisation ou déduites de celle-ci. Par exemple, des frais de transaction pour une forme de paiement ou VCC donnée peuvent dépendre du type (p. ex., carte de crédit ou carte de débit), de l'enseigne, du pays d'émission, de la devise, des produits achetés (p. ex., produits de voyage, origine/destination et dates), du point de vente, de la date d'achat et du type d'utilisateur (p. ex., statut de passager). Les frais de transaction stockés dans la base de données de frais de 15 transaction 64 peuvent être indexés en fonction d'un ou de plusieurs des éléments de données cités ci-dessus. De cette façon, plutôt que d'attendre le traitement de plusieurs demandes de cotation par une ou plusieurs plateformes de paiement, l'orchestrateur de transaction 52 peut simplement interroger la base de données de frais de transaction 64 pour obtenir les frais de transaction visés sur la base des données incluses dans la demande de réalisation ou déduites de 20 celle-ci. [0095] La base de données de frais de transaction 64 peut être remplie en mettant à jour la base de données de frais de transaction 64 avec les frais de transaction à chaque fois qu'une demande de cotation est traitée par une des plateformes de paiement l'un des systèmes de vendeur de produits 16 et/ou en actualisant la base de données de frais de transaction 64, en 25 fonction de ces requêtes, par lots. Dans certains modes de réalisation, les données incluses dans la base de données de frais de transaction 64 peuvent être limitées aux frais de transaction relatifs au contenu de demandes de réalisation fréquentes, tel que les vendeurs populaires, les produits les routes les dates, etc. [0096] En général, les routines exécutées pour mettre en oeuvre les modes de réalisation de 30 l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-là, peuvent être désignées dans les 36 3062942 '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 divers dispositifs de mémoire et de stockage dans un ordinateur, et qui lorsqu'il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, provoque 5 l'exécution par l'ordinateur d'opérations et/ou d'é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 effectuer 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 programmation. 10 [0097] 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 qui suit est utilisée uniquement par commodité ; ainsi l'invention ne peut être limitée à tin seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par 15 ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels qui sont résidents dans un ordinateur typique [p. ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de programme 20 (API), les applications, les petites applications (applets)), etc. ; on remarquera que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique des fonctionnalités de programme telles qu'elles sont décrites dans les présentes. [0098] Le code de programme mis en oeuvre dans toute application/module décrit(e) dans les présentes peut être distribué individuellement ou collectivement comme un produit-programme 25 d'ordinateur, sous une variété de formes. En particulier, le code de programme peut-être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur en amenant un processeur à exécuter des aspects des modes de réalisation de l'invention. [00991 Les supports de stockage de données lisibles par ordinateur et qui sont 30 intrinsèquement durables, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, 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 37 3062942 'données, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires RAM, ROM, EPROM (mémoire à lecture exclusive, programmable et effaçable), EEPROM (mémoire à lecture exclusive, programmable et effaçable électriquement), une mémoire flash, ou toute technologie de support solide de mémoire, un CD-ROM (disque compact portable doté d'une mémoire à lecture seule), ou tout autre stockage optique, des bandes d'enregistrement magnétique, une mémoire à disque magnétique, ou tout autre médium pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (par exemple, des ondes radio ou toutes autres ondes 10 é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 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. 15 [0100] 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 stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions 20 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 à usaee spécial, ou tout autre appareil programmable de traitement de données pour produire une machine telle que les instructions qui s'exécutent par l'intermédiaire d'un ou de plusieurs processeurs provoquent une 25 série de calculs devant être effectués pour implémenter les fonctions, actions et/opérations spécif-ïées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs. [0101] 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 moins de blocs que ceux qui sont illustrés tout en restant conformes avec 30 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. REVENDICATIONS1. Un système de gestion de transaction pour améliorer un métamoteur de recherche exploité par un méta et configuré pour générer une pluralité de résultats en réponse à une interrogation de recherche, chacun des résultats incluant un produit offert à la vente par un système de vendeur de produits exploité par le vendeur et ayant un nom de domaine qui diffère du nom de domaine du métamoteur de recherche, dans lequel le système de gestion de transaction et le métamoteur de recherche sont logiquement ou physiquement distants les uns des autres, c.-à-d., géographiquement distants les uns des autres ou implémentés par des plateformes informatiques séparées, dans lequel le système de gestion de transaction et le métamoteur de recherche sont disposés de façon à communiquer entre eux via un ou plusieurs réseaux privés et/ou publics, le système de gestion de transaction comprenant : un ou plusieurs processeurs qui sont distants du métamoteur de recherche ; et une mémoire incluant des instructions qui lors de l'exécution par le ou plusieurs des processeurs d'ordinateur, amènent le système de gestion de transaction à : en réponse à la sélection par l'acheteur de l'un des résultats générés par le métamoteur de recherche pour achat, et à la réception d'une demande de réalisation reçue par le métamoteur de recherche pour le résultat sélectionné, la demande de réalisation incluant une première donnée de paiement associée à une première forme de paiement de l'utilisateur et des données de résultat 20 associées au résultat sélectionné. sélectionner le méta ou le vendeur exploitant le système de vendeur de produits inclus dans le résultat sélectionné comme étant le commerçant chargé de la demande de réalisation sur la base de la demande de réalisation ; déterminer un bureau de règlement associé au système de vendeur de produits 25 inclus dans le résultat sélectionné sur la base de la demande de réalisation, le bureau de règlement étant distant du métamoteur de recherche ; établir une connexion avec le bureau de règlement ; pendant la connexion au bureau de règlement, générer un enregistrement électronique avec le bureau de règlement sur la base des données de résultat et de la 30 détermination du commerçant, l'enregistrement électronique inclut une seconde donnée 38 3062942 revendications modifiées copie au propre traiter la première forme de paiement de l'utilisateur sur la base de la détermination du commerçant ; et après que la première forme de paiement a été traitée : générer un flux de données incluant le ou plusieurs éléments financiers ; et transmettre le flux de données au méta. 2. Le système de gestion de transaction selon la revendication I dans lequel le système est en outre configuré pour associer chacun des résultats générés par le métamoteur de recherche à un ID d'offre unique, pour stocker chacun des résultats dans une base de données de sorte que 10 chaque résultat est lié à l'ID d'offre associé au résultat dans la base de données, les données de résultat incluent l'ID d'offre associé au résultat sélectionné, et, en réponse à la réception de la demande de réalisation, pour déterminer le résultat sélectionné sur la base de l'ID d'offre inclus dans les données de résultat à partir de la base de données. 3. Le système de gestion de transaction selon la revendication 1 ou 2 dans lequel le système est en outre configuré, en réponse à la sélection du résultat par l'utilisateur pour achat, pour rediriger l'utilisateur vers une page de collecte de paiement fournie par le système permettant à l'utilisateur de saisir la première forme de paiement, et, en réponse à la réception de la première forme de paiement de l'utilisateur via la page de collecte de paiement, pour : 20 générer un jeton de paiement pour la première forme de paiement; stocker la première forme de paiement et le jeton de paiement dans une base de données qui est accessible par le système, mais qui n'est pas accessible par le rnétamoteur de recherche, de sorte que la première forme de paiement est liée au jeton de paiement dans la base de données ; et 25 transmettre le jeton de paiement au métamoteur de recherche dans lequel la première donnée de paiement inclut le jeton de paiement. 4. Le système de gestion de transaction selon la revendication 3 dans lequel le système est en outre configuré, en réponse à la réception de la demande de réalisation, pour déterminer à 30 partir de la base de données, la première forme de paiement sur la base du jeton de paiement inclus dans la première donnée de paiement. 39 3062942 revendications modifiées copie au propre 5. Le système de gestion de transaction selon l'une quelconque des revendications 1 à 4 dans lequel le système est en outre configuré pour en réponse à la sélection du méta comme commerçant, générer une carte de crédit virtuelle comme seconde donnée de paiement ; et en réponse à la détermination que le vendeur qui exploite le système de vendeur de produits pour le résultat sélectionné est le commerçant, insérer la première forme de paiement dans l'enregistrement électronique comme seconde forme de paiement, afin de générer l'enregistrement électronique au bureau de règlement sur la base des données de résultat et de la détermination du commerçant. 10 6. Le système de gestion de transaction selon l'une quelconque des revendications 1 à 5, comprenant par ailleurs un ou plusieurs dispositifs de mémoire stockant une pluralité de bases de données accessibles par le système et non accessibles par le métamoteur de recherche, les bases de données incluant : une première base de données incluant les résultats générés par le métamoteur de recherche, chacun des résultats étant lié à un ID d'offre unique dans la première base de données, dans laquelle les données de résultat incluses dans la demande de réalisation incluent l'ID d'offre liée au résultat sélectionné dans la première base de données ; et une seconde base de données incluant une pluralité de secondes formes de paiement d'une pluralité d'utilisateurs, les secondes formes de paiement incluant la première forme de paiement de l'utilisateur qui a sélectionné le résultat, dans laquelle chacune des secondes formes de paiement est liée à un jeton de paiement unique dans la seconde base de données et la première donnée de paiement inclut le jeton de paiement Hé à la première forme de paiement dans la seconde base de données. dans lequel le système de gestion de transaction est en outre configure , en réponse à la. réception de la demande de réalisation, pour : stocker le jeton de paiement de la première donnée de paiement et l'ID d'offre des données de résultat dans une troisième base de données qui est accessible par le système et n'est pas accessible par le métamoteur de recherche ; récupérer le résultat sélectionné dans la première base de données sur la base de l'ID d'offre des données de résultat ; et 40 3062942 revendications modifiées copie au propre récupérer la première forme de paiement dans la seconde base de données sur la base du jeton de paiement de la première donnée de paiement. 7. Le système de gestion de transaction selon la revendication 6 dans lequel le système est 5 en outre configuré pour : récupérer, dans la troisième base de données, le jeton de paiement et l'ID d'offre stockés dans la troisième base de données ; récupérer le résultat sélectionné dans la première base de données sur la base de l'ID d'offre récupéré dans la troisième base de données ; et 10 récupérer la première forme de paiement dans la seconde base de données sur la base du jeton de paiement récupéré dans la troisième base de données, afin de, en réponse à une perturbation du système lorsque la demande de réalisation est en cours de traitement, recommencer le traitement de la demande de réalisation. 15 8. Le système de gestion de transaction selon l'une quelconque des revendications l à 7, comprenant par ailleurs : un ou plusieurs dispositifs de mémoire incluant une base de données qui comprend une pluralité d'entrées, chacune des entrées incluant un identifiant de vendeur, un premier attribut, un attribut alternatif, et un identifiant de bureau de règlement, 20 dans lequel le système est en outre configuré pour : effectuer une recherche dans la base de données pour une première entrée pour laquelle l'identifiant de vendeur et le premier attribut correspondent à demande de réalisation ; et en réponse à l'absence de détection de la première entrée : 25 rechercher une seconde donnée dans la base de données pour laquelle l'identifiant de vendeur et l'attribut alternatif correspondent à la demande de réalisation et en réponse à la détection de la seconde entrée, sélectionner le bureau de règlement sur la base de l'identifiant de bureau de règlement inclus dans la 30 seconde entrée. afin de déterminer le bureau de règlement associé au système de vendeur de produits pour le produit inclus dans le résultat sélectionné. 41 3062942 revendications modifiées copie au propre 9. Le système de gestion de transaction selon l'une quelconque des revendications I à dans lequel le système est en outre configuré pour : se déconnecter du bureau de règlement et se connecter à un bureau méta associé au 5 métamoteur de recherche ; pendant la connexion au bureau méta : récupérer l'enregistrement électronique ; ajouter à l'enregistrement électronique un élément nancier relatif à des frais de service facturés par le métamoteur de recherche ; 10 marquer l'élément financier comme étant confidentiel ; et se déconnecter du méta bureau. 10. Le système de gestion de transaction selon l'une quelconque des revendications 1 à comprenant par ailleurs : 15 un ou plusieurs dispositifs de mémoire comprenant une base de données qui nclut des frais de transaction pour chacun d'une pluralité de types de forme de paiement, dans lequel le système est en outre configuré pour : en réponse à la détermination du méta comme commerçant générer, comme seconde donnée de paiement, une carte de crédit 20 virtuelle ; récupérer dans la base de données des premiers frais de transaction pour le traitement de la première forme de paiement, et des seconds frais de transaction pour le traitement de la carte de crédit virtuelle ; déterminer si les premiers frais de transaction sont plus élevés que les 25 seconds frais de transaction ; et en réponse à la détermination que les premiers frais de transaction sont plus élevés que les seconds frais de transaction : générer un coupon électronique pour une différence entre les premiers frais de transaction et les seconds frais de transaction ; et 30 notifier le coupon électronique à l'utilisateur. 42