FR 3049367 A1 20170929 FR 1652514 A 20160324 SYSTÈME DE TRAITEMENT DE TRANSACTIONS EN LIGNE POUR DES TRANSACTIONS IMPLIQUANT DE MULTIPLES PRODUITS CONTEXTE [0001] L'invention concerne de façon générale des ordinateurs et des systèmes informatiques et en particulier, des méthodes, et des produits-programme informatique pour le traitement de transactions en ligne impliquant l'achat de produits multiples. [0002] Le commerce électronique moderne implique typiquement le partage et le traitement des données entre de multiples systèmes informatiques interconnectés par un réseau. Dans cet environnement, les transactions qui impliquent de multiples fournisseurs de produits peuvent produire des interactions complexes entre des systèmes de fournisseurs pour s'assurer que chaque produit est disponible et tarifé simultanément. Du côté de l'acheteur, des systèmes peuvent aussi contribuer à la complexité en apportant de multiples formes de paiement, chacune pouvant nécessiter un traitement de données par une ou plusieurs banques, un paiement ou des systèmes informatiques de transactions sécurisées. Pour prendre en charge des ensembles de données d'entrée toujours plus importants ainsi que les tâches associées de manipulation des données qui peuvent être distribués par de multiples systèmes informatiques, les systèmes de traitement de données en ligne (Online transaction Processing, ou OLTP) exigent des processus de gestion de transaction sophistiqués. Ces processus peuvent gérer la communication entre l'acheteur, le vendeur, le fournisseur et les systèmes de paiement, et peuvent employer des techniques d'optimisation de bases de données pour permettre le traitement d'un grand nombre de données tout en conférant une haute disponibilité, une concomitance, la récupération des transactions en ligne et de la vitesse. [0003] Il est donc nécessaire que des systèmes améliorés, des méthodes, et des produits- programmes informatiques pour le traitement de transaction en ligne améliorent la rapidité d'exécution et l'exactitude des transactions en ligne impliquant l'achat de multiples produits. RÉSUMÉ [0004] Dans un mode de réalisation de l'invention, un système de traitement de transactions en ligne est fourni. Le système inclut un ou plusieurs processeurs et une mémoire couplée aux processeurs. La mémoire stocke des données comprenant un programme codé qui, lorsqu'il est exécuté par au moins un des processeurs, amène le système à recevoir des données qui 3049367 2 définissent une transaction pour l'achat d'un itinéraire incluant un ou plusieurs produits, un vendeur des produits et un ou plusieurs fournisseurs des produits. Le système peut récupérer un premier ensemble de règles pour l'affectation de commerçants à des produits au niveau de la transaction et l'affectation d'un commerçant à chaque produit sur la base du premier ensemble de règles et d'une ou de plusieurs caractéristiques de la transaction. Le système peut par ailleurs récupérer un second ensemble de règles pour l'affectation de commerçants aux produits, au niveau du produit, et peut mettre à jour chaque affectation sur la base du second ensemble de règles, d'une ou de plusieurs caractéristiques du produit et d'une ou de plusieurs caractéristiques de l'affectation. [0005] Dans un autre mode de réalisation de l'invention, une méthode de traitement des transactions est fournie. La méthode inclut la réception de données qui définissent la transaction, le vendeur des produits et le fournisseur des produits. La méthode récupère le premier ensemble de règles pour l'affectation de commerçants aux produits au niveau de la transaction, et affecte le commerçant à chaque produit sur la base du premier ensemble de règles et des caractéristiques de la transaction. La méthode récupère par ailleurs le second ensemble de règles pour l'affectation de commerçants aux produits, au niveau du produit, et actualise chaque affectation sur la base du second ensemble de règles, des caractéristiques du produit et des caractéristiques de l'affectation. [00061 Dans un autre mode de réalisation de l'invention, un produit-programme informatique pour le traitement d'une transaction en ligne est fourni. Le produit-programme informatique inclut un support de stockage non transitoire lisible par ordinateur, un programme codé stocké sur le support qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène les processeurs à recevoir les données définissant la transaction pour l'achat de l'itinéraire, le vendeur des produits et les fournisseurs des produits. Le programme codé amène les processeurs à récupérer le premier ensemble de règles pour l'affectation des commerçants aux produits, au niveau de la transaction, et l'affectation du commerçant pour chaque produit sur la base du premier ensemble de règles et des caractéristiques de la transaction. Le programme codé amène par ailleurs les processeurs à récupérer le second ensemble de règles pour l'affectation des commerçants aux produits, au niveau du produit, et actualise chaque affectation en fonction du second ensemble de règles, des caractéristiques du produit et des caractéristiques de l'affectation. 3049367 3 BRÈVE DESCRIPTION DES DESSINS [0007] Les dessins qui accompagnent et sont incorporés dans les présentes constituent une partie des spécifications ; ils illustrent des modes variés de réalisation de l'invention et, avec la description générale de l'invention ci-dessus et la description détaillée des modes de réalisation donnée ci-après, servent à expliquer les modes de réalisation de l'invention. [0008] La FIG. 1 est une vue schématique d'un exemple d'environnement d'exploitation incluant un système de traitement de transaction en ligne (OLTP) en communication avec un système vendeur et un système fournisseur. [0009] La FIG. 2 est une vue schématique d'un exemple d'ordinateur pouvant être utilisé pour fournir l'environnement d'exploitation de la FIG. 1. [0010] La FIG. 3 est une vue schématique du système OLTP illustrant un module de détermination du commerçant, un module de formes de paiement, un module de produits décisifs, un module de produits récupérables, un module de récupération de transactions, un module de confirmation de réservation, un module d'émission de contrat et un module de mise en file d'attente d'un enregistrement. [0011] La FIG. 4 est une vue schématique du module de détermination du commerçant de la FIG. 3. [0012] La FIG. 5 est un organigramme du processus de détermination du commerçant, au niveau de la transaction, qui peut être mis en oeuvre par le module de détermination du commerçant de la FIG. 4. [0013] La FIG. 6 est un organigramme du processus de détermination d'un commerçant, au niveau du produit, qui peut être mis en oeuvre par le module de détermination du commerçant de la FIG. 4. [0014] La FIG. 7 est un organigramme du processus de contournement d'un commerçant qui peut être mis en oeuvre par le module de détermination du commerçant de la FIG. 4. [0015] La FIG. 8 est une vue schématique du module de formes de paiement de la FIG. 3. [0016] La FIG. 9 est un organigramme du processus de détermination des formes de paiement qui peut être mis en oeuvre par le module de formes de paiement de la FIG. 8. [0017] La FIG. 10 est un organigramme d'un sous-processus qui peut être mis en oeuvre par le processus de détermination des formes de paiement de la FIG. 9. 3049367 4 [0018] La FIG. 11 est un organigramme d'un autre sous-processus qui peut être mis en oeuvre par le processus de détermination des formes de paiement de la FIG. 9. [0019] La FIG. 12 est une vue schématique du module de produits décisifs de la FIG. 3. [0020] La FIG. 13 est un organigramme du processus de détermination des produits décisifs qui peut être mis en oeuvre par le module de produits décisifs de la FIG. 12. [0021] La FIG. 14 est un organigramme d'un processus de confirmation de réservation qui peut être mis en oeuvre par le module de confirmation de la FIG. 3. [0022] La FIG. 15 est un organigramme du processus de confirmation de l'émission d'un contrat qui peut être mis en oeuvre par le module d'émission de contrat de la FIG. 3. [0023] La FIG. 16 est une vue schématique du module de produits récupérables de la FIG. 3. [0024] La FIG. 17 est un organigramme d'un processus de détermination des produits récupérables qui peut être mis en oeuvre par le module de produits récupérables de la FIG. 16. [0025] La FIG. 18 est une vue schématique des messages qui peuvent être transmis entre le processus de détermination de la FIG. 17 et le système de détection anti-fraude, la base de données des enregistrements de voyage, la base de données des règles de récupération et une base de données de l'inventaire. [0026] La FIG. 19 est une vue schématique des messages qui peuvent être transmis entre le processus de détermination de la FIG. 17 et la base de données des enregistrements de voyage, le système de paiement, le module de réservation de la FIG. 3, et le module de mise en file d'attente de la FIG. 3. [0027] La FIG. 20 est un organigramme d'une partie du processus de récupération de transaction qui peut être mis en oeuvre par le module de récupération des transactions de la FIG. 3. [0028] La FIG. 21 est un organigramme d'une autre partie du processus de récupération des transactions de la FIG. 20. DESCRIPTION DÉTAILLÉE [0029] Les modes de réalisation de l'invention visent des systèmes, des méthodes, et des produits-programme d'ordinateur pour gérer des transactions en ligne impliquant l'achat de produits multiples, tels qu'un ensemble de produits liés au voyage comprenant un itinéraire pour un voyage. Les modes de réalisation de l'invention peuvent être mis en oeuvre sur un système de 3049367 traitement de transaction en ligne (OLTP) comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Le système OLTP peut être configuré pour traiter un itinéraire complexe qui inclut des produits de voyage hétérogènes tels que des vols, des hôtels, des locations de voiture, des croisières, des attractions et des produits d'assurance fournis par des fournisseurs multiples. L'itinéraire peut être défini dans un enregistrement de base de données qui fournit un lieu de stockage central pour les données relatives au traitement de la transaction en ligne. L'enregistrement de base de données, avec les données définissant une ou plusieurs formes de paiement pour régler la transaction, peut être traité de manière séquentielle par une pluralité de modules pour finaliser la transaction. Ces modules peuvent déterminer un commerçant et une ou plusieurs formes de paiement pour chaque produit de l'itinéraire et peuvent aussi identifier les produits décisifs et récupérables dans l'itinéraire. Ces données peuvent être associées aux produits dans l'enregistrement de la base de données et peuvent être utilisées par le système OLTP pour confirmer des réservations et émettre des contrats pour les produits. [0030] Lorsque le système OLTP rencontre une erreur ou lorsque le traitement de la transaction est interrompu pour quelque raison que ce soit, l'enregistrement de la base de données peut être mis en file d'attente jusqu'à la reprise du processus. En réponse à la réception d'une demande de reprise, le système OLTP peut déterminer l'état de chaque produit en fonction de l'enregistrement de la base de données. En fonction du statut de chaque produit, le système OLTP peut par ailleurs déterminer une séquence de traitement pour les produits qui permet de finaliser la transaction et de traiter les produits en fonction de la séquence déterminée. [0031] Faisant maintenant référence à la FIG. 1, un système d'exploitation 10 conforme à un mode de réalisation de l'invention peut inclure un système OLTP 12, un système vendeur 14, un système fournisseur 16, un système pourvoyeur 18, une base de données d'inventaire 20, une base de données d'enregistrements de voyage 22, un système de paiement 24 et un système de détection anti-fraude 26. Chacun d'entre eux : le système OLTP 12, le système vendeur 14, le système fournisseur 16, le système fournisseur 18, la base de données d'inventaire 20, la base de données d'enregistrements de voyage 22, le système de paiement 24 et le système de détection anti-fraude 26 peuvent communiquer par l'intermédiaire du réseau 28. Le réseau 28 peut inclure un ou plusieurs réseaux privés ou publics (par ex., Internet) qui permettent l'échange de données entre des systèmes connectés au réseau 28. 3049367 6 [0032] Le système OLTP 12 peut être configuré pour traiter des transactions en ligne pour l'achat d'un ensemble de produits. L'ensemble de produits peut inclure des produits d'un ou de plusieurs fournisseurs et/ou pourvoyeurs de produits, tels qu'une compagnie aérienne, une compagnie ferroviaire, un hôtel, un service de location de voitures, un croisiériste ou autre fournisseur ou vendeur de produits de voyage. Un fournisseur peut être une entreprise qui facture et reçoit des paiements de la part d'un acheteur du produit, et un pourvoyeur peut être une entreprise qui livre le produit. Dans certains cas, le fournisseur et le pourvoyeur peuvent être la - même entreprise, auquel cas les termes « fournisseur » et « pourvoyeur » peuvent être utilisés de façon interchangeable. Ce serait le cas, par exemple, lorsqu'un transporteur fournit une place assise sur un vol et facture l'acheteur lors de la confirmation de la réservation de la place assise. L'acheteur peut payer le produit au vendeur lorsque le vendeur est le commerçant, ou payer le produit au fournisseur lorsque le fournisseur est le commerçant. [0033] Chaque ensemble de produits peut comprendre, par exemple, un itinéraire pour un voyage vendu par un vendeur indirect des produits, tel qu'une agence de voyages. Dans un mode de réalisation de l'invention, le système OLTP 12 peut inclure ou faire partie d'un système de distribution globale (Global Distribution System, ou GDS) configurés pour faciliter la communication entre le système vendeur 14 et un ou plusieurs systèmes fournisseurs 16 et/ou systèmes pourvoyeurs 18. Le GDS peut permettre aux agents de voyage, aux transporteurs émetteurs, ou à tout autre vendeur indirect de confirmer des réservations sur le système fournisseur 16 par l'intermédiaire du GDS. Le GDS peut conserver des liens, vers une pluralité de systèmes fournisseurs 16, par l'intermédiaire du réseau 28, qui permettent au GDS d'acheminer les demandes de réservation du vendeur indirect à un fournisseur correspondant du produit en cours de réservation. Le système vendeur 14 peut ainsi réserver des produits de voyage auprès de multiples fournisseurs grâce à une seule connexion au GDS. [0034] Le système fournisseur 16 et/ou le système pourvoyeur 18 peuvent inclure un système de réservation central (CRS) qui permet au système OLTP 12 de réserver et de confirmer des produits de voyage. Le système fournisseur 16 et le système pourvoyeur 18 peuvent aussi interagir avec d'autres systèmes fournisseurs et pourvoyeurs, soit directement soit par l'intermédiaire du GDS, pour permettre au fournisseur tel un transporteur émetteur de vendre des produits fournis par le pourvoyeur tel que le transporteur de fait. Lorsque le fournisseur et le 3049367 7 pourvoyeur sont deux entreprises différentes, le pourvoyeur peut facturer le fournisseur pour les produits fournis. [0035] Le système fournisseur 16 et le système pourvoyeur 18 peuvent inclure un système de documents électroniques tel que le système de billetterie électronique (ETS), configuré pour conserver des enregistrements de l'achat, pour utiliser et échanger des documents tels que des contrats émis par le fournisseur ou le pourvoyeur correspondant. Le système de documents électronique peut accéder à la base de données d'enregistrements de voyage 22 et/ou à une autre base de données d'enregistrement, selon les besoins, pour suivre l'état des contrats émis par le fournisseur ou le pourvoyeur. Les données, définissant un contrat et assurant un suivi de l'utilisation du contrat, peuvent être stockées dans un enregistrement correspondant dans la base de données d'enregistrements de voyage 22 et sous la forme d'un ou de plusieurs documents dans le système de documents électroniques. [0036] Le système fournisseur 16 peut inclure des systèmes d'arrière-guichets (bock-office) et des systèmes intermédiaires (middle-office) configurés pour permettre aux acheteurs de régler les comptes avec le fournisseur. Ces systèmes bureautiques de comptabilisation peuvent abriter un logiciel sécurisé de commerce électronique qui gère les bases de données des fournisseurs et conservent les enregistrements des ventes des fournisseurs et des transactions d'achat, mettent à jour la base de données d'inventaire 20 et assurent aussi le suivi des factures, des reçus et des rapports. [0037] En réponse à une réservation de produit par un voyageur, le système OLTP 12 peut stocker les données, dans la base de données d'enregistrements de voyage 22, qui identifient le produit réservé Ces données peuvent être conservées dans un enregistrement de base de données désigné comme enregistrement de voyage. L'enregistrement de voyage peut inclure un ou plusieurs champs de données qui contiennent le produit, le voyageur, et d'autres informations associées à un ou plusieurs produits réservés dans l'itinéraire. Chaque enregistrement de voyage peut inclure des données définissant l'itinéraire pour un voyage particulier, un voyageur ou un groupe de voyageurs. L'itinéraire défini peut inclure des produits de voyage de fournisseurs et/ou de pourvoyeurs multiples de produits de voyage. Pour faciliter la localisation de l'enregistrement de voyage dans la base de données d'enregistrements de voyage 22, un numéro d'enregistrement ou autre identifiant approprié peut être associé à l'enregistrement de voyage. 3049367 8 [0038] Le système de paiement 24 peut être configuré pour traiter des formes de paiement liées à l'achat de produits par le client. Le système de paiement 24 peut être configuré pour échanger des données avec un ou plusieurs systèmes bancaires tels que le système de la banque émettrice et/ou le système de la banque acquéreur afin d'autoriser le paiement et les transferts de fonds entre comptes. Dans le cas d'un achat payé, au moins en partie par carte de crédit ou de débit, au moment de la transaction, le système de paiement 24 peut transmettre une demande d'autorisation au système de la banque émettrice qui peut être déterminée à partir du numéro d'identification d'émetteur de la carte. En réponse à la demande d'autorisation, le système de la banque émettrice peut vérifier que le compte est valide et qu'il dispose de fonds suffisants pour couvrir le montant de la transaction. Le système de la banque émettrice peut ensuite transmettre une réponse relative à l'autorisation au système de paiement 24 en indiquant que la transaction a été approuvée, refusée ou que plus d'informations sont nécessaires. [0039] Le processus de confirmation de réservation d'un itinéraire réservé peut inclure la vérification de la base de données d'inventaire 20 pour confirmer la disponibilité des produits identifiés dans l'itinéraire réservé (par ex., la disponibilité des places sur un vol, les chambres libres dans un hôtel, etc.). Cette vérification peut inclure l'envoi d'une demande de réservation du système OLTP 12 à un ou plusieurs systèmes fournisseurs 16. Si les produits demandés sont disponibles, les produits peuvent être réservés, une confirmation de réservation peut être transmise au système OLTP 12, et l'inventaire peut être ajusté dans la base de données d'inventaire 20 pour refléter la réservation. En réponse à la validation de la transaction par le voyageur, le paiement du voyageur au commerçant peut être effectué par la facturation du compte du voyageur pour le prix des services. À réception du paiement, la réservation peut être confirmée par le système fournisseur 16. [0040] Le système de détection anti-fraude 26 peut recevoir des demandes pour analyser les formes de paiement utilisées par le client pour finaliser une transaction et il peut déterminer un niveau de risque associé à la forme de paiement du client (Form of Payment, ou FOP). Le niveau de risque peut être déterminé sur la base d'une ou de plusieurs caractéristiques de la forme de paiement, du client, et/ou de la transaction. Par exemple, le système de détection anti-fraude 26 peut effectuer une vérification de l'intégrité des données, comparer les caractéristiques de la transaction en attente avec les caractéristiques de transactions frauduleuses connues, effectuer une recherche dans une base de données historique des transactions pour identifier des modes de 3049367 9 vélocité anormaux, des changements de nom et d'adresse et des fraudeurs connus. Le système de détection anti-fraude 26 peut générer une évaluation du risque (par ex., fraude détectée, examen manuel recommandé, ou aucune fraude détectée) et renvoyer l'évaluation de risque au système OLTP 12. [0041] Faisant maintenant référence à la FIG. 2, le système OLTP 12, le système vendeur 14, le système fournisseur 16, le système pourvoyeur 18, la base de données d'inventaire 20, la base de données d'enregistrements de voyage 22, le système de paiement 24, le système de détection anti-fraude 26, et le réseau 28 de l'environnement d'exploitation 10 peuvent être mis en oeuvre sur un ou plusieurs systèmes ou dispositifs informatiques, tels que l'exemple d'ordinateur 30. L'ordinateur 30 peut inclure un processeur 32, une mémoire 34, un dispositif de mémoire de masse 36, une interface entrée/sortie (I/O) 38, et une interface homme-machine (HMI) 40. L'ordinateur 30 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources extérieures 42 par l'intermédiaire du réseau 28 ou de l'interface I/O 38. Les ressources externes peuvent inclure, sans s'y limiter, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage (cloud), ou toute autre ressource informatique appropriée qui peut être utilisée avec l'ordinateur 30. [0042] Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : des microprocesseurs, microcontrôleurs, des processeurs de signaux numériques, des micro-ordinateurs, des unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base d'instructions de fonctionnement enregistrées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais sans s'y limiter, la mémoire à lecture seule (read-only memory (ROM), la mémoire à accès aléatoire (random access memory(RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 36 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile ou tout autre dispositif capable de stocker des informations. 3049367 [0043] Le processeur 32 peut fonctionner sous le contrôle d'un système d'exploitation 44 qui réside dans la mémoire 34. Le système d'exploitation 44 peut gérer les ressources informatiques afin que le programme codé de l'ordinateur, intégré sous la forme d'une ou plusieurs applications logicielles telles que l'application 46 qui réside dans la mémoire 34, puisse recevoir les instructions exécutées par le processeur 32. Le processeur 32 peut aussi exécuter l'application 46 directement, et dans ce cas le système d'exploitation 44 peut être omis. La ou les applications logicielles peuvent inclure un cas de fonctionnement comportant un serveur qui peut accepter des requêtes des applications clientes et leur fournir des réponses. Une ou plusieurs structures de données 48 peuvent aussi résider dans la mémoire 34 et peuvent être utilisées par le processeur 32, le système d'exploitation 44, ou l'application 46 pour stocker ou manipuler des données. [0044] L'interface I/O 38 peut fournir une interface machine qui couple le processeur 32 de façon fonctionnelle aux autres dispositifs et systèmes tels que le réseau 28 ou la ressource externe 42. Le serveur d'application 46 peut ainsi collaborer avec le réseau 28 ou avec la ressource externe 42 en communiquant par l'intermédiaire de l'interface I/O 38 pour fournir les divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l'invention. L'application 46 peut aussi comporter un programme codé qui est exécuté par une ou plusieurs ressources externes 42, ou autrement reposer sur les fonctions ou signaux fournis par d'autres composants de système ou de réseau externes à l'ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications situées à l'extérieur de l'ordinateur 30, distribuées à des ordinateurs multiples ou à d'autres ressources externes 42 ou fournies par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel qu'un service informatique cloud, par l'intermédiaire du réseau 28. [0045] Le HMI 40 peut être couplé de façon fonctionnelle au processeur 32 de l'ordinateur 30 pour permettre à un utilisateur d'interagir directement avec l'ordinateur 30. Le HMI 40 peut inclure un affichage vidéo ou alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. Le HMI 40 peut aussi inclure des dispositifs et des contrôles d'entrée tels qu'un clavier alphanumérique, un dispositif de pointage, des claviers, des boutons poussoir, des boutons de 3049367 11 commande, des microphones, etc., capables d'accepter des commandes ou des entrées de l'utilisateur et de les transmettre au processeur 32. [0046] Une base de données 50 peut résider sur le dispositif de mémoire de masse 36 et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. La base de données 50 peut inclure des données et accommoder les structures de données associées qui stockent et organisent les données. En particulier, la base de données 50 peut être aménagée avec toute organisation ou structure de base de données, notamment, mais sans s'y limiter, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, une base de données orientée-objet ou des combinaisons de celles-là. [0047] Un système de gestion de bases de données sous forme 'une application logicielle qui s'exécute sous la forme d'instructions sur le processeur 32 peut être utilisé pour accéder aux informations ou aux données stockées dans des enregistrements de la base de données 50 en réponse à une requête, lorsqu'une requête peut être déterminée de façon dynamique et exécutée par le système d'exploitation 44, les autres applications 46 ou un ou plusieurs modules. Bien que les modes de réalisation de l'invention puissent être décrits dans les présentes en utilisant une terminologie de base de données relationnelle, hiérarchique, de réseau, orienté-objet, ou autre terminologie de base de données dans des cas spécifiques, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent utiliser tout modèle de gestion approprié de base de données, et ne sont pas limités à tout type particulier de base de données. [0048] Faisant maintenant référence à la FIG. 3, le système OLTP 12 peut inclure un module de détermination de commerçant 60, un module de formes de paiement 62, un module de produits décisifs 64, un module de produits récupérables 66, un module de récupération de transaction 68, un module de confirmation de réservation 70, un module d'émission de contrat 72 et un module de mise en file d'attente 74. Le système OLTP 12 peut orchestrer le fonctionnement des modules pour traiter des transactions en faisant appel aux modules pour traiter un ou plusieurs produits définis par l'enregistrement de voyage dans une séquence déterminée par le système OLTP 12. Afin de traiter la transaction, les modules du système OLTP 12 peuvent récupérer des données d'un ou de plusieurs des systèmes vendeur 14, système fournisseur 16, de base de données d'inventaire 20, de la base de données d'enregistrements de voyage 22, du 3049367 12 système de paiement 24, du système de détection anti-fraude 26 ou de tout autre système approprié, ou leur transmettre des données. DÉTERMINATION DU COMMERÇANT [0049] Dans un système conventionnel OLTP, le vendeur assume typiquement le rôle de commerçant pour l'intégralité de la transaction. Le résultat est que le vendeur peut être tenu pour responsable du montant total de la vente, y compris pour les parties du paiement transférées aux fournisseurs des produits. Forcer le vendeur à assumer le rôle de commerçant peut aussi limiter les produits qui peuvent être inclus dans un itinéraire vendu par le vendeur parce que certains fournisseurs peuvent refuser que leurs produits soient distribués par des vendeurs tiers assumant le rôle de commerçant. Par exemple, un transporteur peut exiger d'être le commerçant pour la vente des vols afin de maintenir un contrôle sur les politiques tarifaires. Le système OLTP peut aussi être obligé de traiter de multiples formes de paiement telles que les cartes de crédit, les bons cadeaux ou les programmes de fidélité qui peuvent affecter encore plus la capacité du système OLTP à sélectionner le commerçant pour chaque produit. [0050] La détermination du commerçant pour chaque produit peut exiger la comptabilisation de multiples variables telles que des accords commerciaux spécifiques entre le vendeur et le fournisseur. Certains accords commerciaux peuvent exiger que le vendeur assume simplement le rôle d'intermédiaire entre l'acheteur et le fournisseur. D'autres accords commerciaux peuvent exiger que le vendeur soit responsable de la vente. Les accords qui exigent que le vendeur soit le commerçant peuvent s'appliquer dans des cas où le vendeur achète des produits, tels que des blocs de places dans l'inventaire d'un transporteur, à un fournisseur pour les revendre à un acheteur. Vu que les vendeurs peuvent conclure un grand nombre d'accords commerciaux et que chaque accord commercial peut dépendre d'un nombre de conditions, la tâche de détermination du commerçant pour chaque produit d'une transaction peut être trop complexe à déterminer sans un système informatique spécialisé. [0051] Faisant maintenant référence à la FIG. 4, le module de détermination du commerçant 60 est illustré plus en détail. Le module de détermination du commerçant 60 peut être configuré pour gérer de multiples commerçants pour chaque transaction d'achat d'un itinéraire. Dans ce but, le module de détermination du commerçant 60 peut sélectionner le commerçant pour chaque produit de voyage dans l'itinéraire en fonction de l'effet produit par la 3049367 13 sélection du commerçant sur un paramètre financier tel que le montant total de la vente qui est crédité au vendeur. La sélection du commerçant pour un produit spécifique dans un itinéraire spécifique peut être basée sur les règles commerciales du fournisseur, les règles commerciales du vendeur, une ou plusieurs caractéristiques du produit et/ou le contexte de la transaction. En particulier, les règles commerciales du vendeur peuvent déterminer le commerçant sur la base de paramètres spécifiques au vendeur qui gère la transaction. Par exemple, des règles commerciales spécifiques peuvent être définies par le vendeur pour maintenir une compatibilité avec un ou plusieurs accords commerciaux avec un fournisseur et/ou la politique commerciale du vendeur. Le module de détermination du commerçant 60 peut s'assurer que le vendeur est uniquement responsable du montant de la transaction pour laquelle le vendeur procure réellement un service. Cela peut permettre au vendeur d'éviter une imposition inappropriée et de permettre aux fournisseurs d'avoir plus de visibilité sur les politiques tarifaires. [0052] Le module de détermination du commerçant 60 peut inclure une base de données de règles globales 82, une base de données des règles applicables aux produits 84, une base de données des règles de contournement 86, et une base de données du registre d'erreurs 88. Afin de déterminer le commerçant pour un produit sur la base des règles stockées dans ces bases de données, le module de détermination de commerçant 60 peut inclure un processus 90 au niveau de la transaction, un processus 92 au niveau du produit, et un processus de contournement d'un marchand 94 qui collaborent pour déterminer le commerçant pour chaque produit, conformément aux règles de sélection des commerçants dans les bases de données de règles et en fonction du contexte de la transaction. Une fois que les commerçants ont été déterminés, un processus d'actualisation de l'enregistrement de voyage 96 peut mettre à jour l'enregistrement de voyage correspondant dans la base de données d'enregistrements de voyage 22 pour indiquer le commerçant pour chaque produit dans l'itinéraire. [0053] Un processus de rapport d'erreurs 98 peut fonctionner de manière asynchrone pour générer des rapports d'erreurs sur la base des enregistrements d'erreurs stockés dans la base de données du registre d'erreurs 88. Le processus 92 au niveau du produit, peut stocker une erreur dans la base de données du registre d'erreurs 88 par exemple, lorsque le processus 92 au niveau du produit est incapable de déterminer un commerçant pour un produit dans l'itinéraire en fonction d'une règle universelle ou d'une règle de produit. 3049367 14 [0054] Le module de détermination du commerçant 60 peut récupérer des données à partir des systèmes externes tels que la base de données d'enregistrements de voyage 22 et/ou le système de paiement 24, et les stocker sur ceux-là. Par exemple, le processus au niveau de la transaction 90 peut recevoir des données identifiant une plusieurs formes de paiement utilisées pour la transaction à partir du système de paiement 24 et des données définissant des produits et l'itinéraire à partir de la base de données d'enregistrements de voyage 22. Le processus 96 d'actualisation de l'enregistrement de voyage peut à son tour transmettre les données à la base de données d'enregistrements de voyage 22, définissant le commerçant pour chaque produit dans l'itinéraire. Le processus 98 de rapport d'erreurs peut aussi transmettre des rapports d'erreurs à un module de formatage et de livraison 100, qui peut formater et délivrer des rapports d'erreurs à une adresse prédéfinie de réseau, tel qu'une adresse électronique, dans un format lisible par l'utilisateur. [0055] La base de données des règles globales 82 peut contenir des paramètres utilisés pour identifier des règles pour la sélection d'un commerçant applicables à tous les produits dans l'itinéraire, ou des règles qui s'appliquent seulement à un sous-ensemble de produits dans l'itinéraire. C'est-à-dire, que les règles stockées dans la base de données de règles universelles 82 peuvent inclure des règles qui définissent des paramètres de décision concernant le commerçant qui ne sont pas spécifiques à un produit unique, mais qui s'appliquent plutôt à l'ensemble de l'itinéraire ou au sous-ensemble de l'itinéraire. Par exemple, les règles globales peuvent sélectionner le commerçant sur la base de la période entre le moment où l'itinéraire est confirmé et la date d'utilisation la plus proche d'un produit dans l'itinéraire (par ex., la date de départ pour un vol « aller ». Ce type de règle peut sélectionner le vendeur comme commerçant si la période de temps en question est inférieure au temps minimum permis n'IN. Les règles qui sélectionnent le commerçant comme vendeur, lorsque la période de temps avant l'utilisation est inférieure à TmIN peuvent être configurées pour permettre au vendeur de garantir une confirmation en assumant la responsabilité de la vente, par ex., lorsque la confirmation est demandée peu de temps avant le départ du vol. Les règles globales peuvent aussi définir à quel type de produit la règle s'applique. Par exemple, la règle ci-dessus qui sélectionne le vendeur comme commerçant ne peut s'appliquer qu'à des produits prépayés. [0056] Des exemples supplémentaires de règles universelles peuvent inclure une règle qui sélectionne le vendeur comme commerçant pour tous les produits d'un itinéraire dans une 3049367 catégorie prédéfinie lorsque le nombre de commerçants pour l'itinéraire dépasse un seuil MMAX. Un autre exemple de règle globale peut sélectionner le vendeur comme commerçant pour tous les produits de l'itinéraire soumis à une pénalité en cas d'annulation, si le nombre de pénalités en cas d'annulation dépasse un seuil P MAX. Un autre exemple de règle globale peut sélectionner le vendeur comme commerçant pour tous les produits prépayés, si la forme de paiement se fait sous forme de points ou par un système de paiement en ligne tel que PAYPAL®. [0057] D'autres règles peuvent déterminer que les formes conventionnelles de paiement sont faites directement au fournisseur, ce qui peut nécessiter que le fournisseur soit le commerçant. Par contraste, d'autres formes de paiement telles que les bons cadeaux ou les programmes de fidélité peuvent être effectuées directement au vendeur, ce qui peut nécessiter que le vendeur soit le commerçant. Le Tableau 1 illustre comment les règles ci-dessus peuvent être organisées dans la base de données des règles globales 82. [0058] La base de données des règles applicables aux produits 84 peut stocker des règles qui identifient un commerçant par défaut pour des produits spécifiques selon les caractéristiques du produit. Ces règles peuvent être spécifiques à chaque type de produit et aux caractéristiques du produit ; elles peuvent identifier le commerçant pour chaque produit en fonction des caractéristiques du produit. Les paramètres utilisés par la base de données de règles de produit 84 pour identifier le commerçant peuvent être définis sur la base des accords commerciaux du vendeur. Des exemples de paramètres qui pourraient être utilisés pour sélectionner un commerçant en utilisant des règles de produit incluent le type de produit (par ex., un vol, un hôtel, une attraction, etc.), un modèle de paiement (par ex., prépayé ou payé à réception), la forme de paiement (carte de crédit, carte de fidélité de vendeur, paiement en ligne, etc.), l'identité de la banque émettrice (pour des formes de paiement impliquant une carte de crédit.), une majoration ou une réduction du prix par le vendeur, l'identité du pourvoyeur, l'identité du fournisseur, les contraintes de temps (par ex., une date limite avant l'utilisation du produit pour l'émission du billet) ou un point de vente. 3049367 16 [0059] Chaque règle de produit peut être basée sur des combinaisons différentes de paramètres et ne requiert pas nécessairement que chaque paramètre ait une valeur particulière. Cela permet à la base de données des règles 84 d'avoir des règles applicables à de larges catégories de produits et d'autres règles qui définissent le commerçant pour un ensemble plus restreint de produits, tels qu'un ou des produits spécifiques d'un fournisseur ou d'un pourvoyeur spécifique. Le Tableau 2 donne deux exemples de règles qui peuvent être définies sur la base des paramètres illustrés précédemment. La rangée supérieure du Tableau 3 illustre une règle relativement restreinte qui sélectionne le fournisseur comme commerçant pour des vols prépayés avec VISA® (forme de paiement codée CCVI) qui sont fournis et pourvus par Transportes Aéreos Meridionais (IATA code JJ) avec un point de vente au Brésil (BR). La règle définie par le rang inférieur du Tableau 2 peut définir une règle plus large, et sélectionne le fournisseur comme commerçant pour tout hôtel fourni par Ibis avec un point de vente au Brésil. [0060] Les règles dans la base de données de règles globales 82 et les règles de la base de données des règles de produit 84 peuvent être basées sur des groupements de paramètres applicables à tous les produits pouvant être inclus dans un itinéraire. Le commerçant identifié par l'application séquentielle du processus au niveau de la transaction 90 et du processus au niveau du produit 92 peut procurer une affectation d'un commerçant de référence qui peut être contournée par le processus de contournement du commerçant 94. La base de données de règles de contournement 86 peut contenir des règles qui identifient des cas d'utilisation spécifiques au niveau du produit, pour lesquels la sélection du commerçant de référence doit être contournée. Par exemple, le vendeur peut vouloir définir un commerçant différent pour chacun de deux produits de même type en fonction de paramètres qui sont strictement liés à la nature du produit. TABLEAU 1 - RÈGLES GLOBALES TMJN MmAx PmAx FOP Seuil/Type 4 3 1 Points, En ligne Produits à Prépayé Hôtel, voiture de Produits avec Prépayé contourner location, pénalité d'annulation attraction, croisière 3049367 17 TABLEAU 2 - RÈGLES DE PRODUIT Type Modèle Code Banque Statut Pourv. Four Min. PO Commerça de de FOP émettrice majoré/ n. jours S nt produit paiement réduit à l'av. Vol Prépayé CCVI JJ JJ BR Fournisseu r Hôtel IBIS BR Fournisseu r [0061] À titre d'exemple spécifique, le vendeur peut définir des règles dans la base de données de règles de contournement 86 qui amène le processus de contournement du commerçant 94 à déterminer le commerçant pour des produits de voyage aérien différemment, selon qu'il s'agit de vols domestiqués ou de vols internationaux. Comme autre exemple, le vendeur peut être tenu de sélectionner différents commerçants sur la base des accords commerciaux de distribution que le vendeur a conclus avec des fournisseurs ou des pourvoyeurs spécifiques. Ainsi, les règles de contournement peuvent fournir une troisième couche de règles pouvant identifier des cas spécifiques pour chaque catégorie de produits dans laquelle le commerçant doit être contourné avec une valeur différente que celle identifiée par les règles au niveau de la transaction et au niveau du produit. [0062] Le Tableau 3 et le Tableau 4 illustrent des exemples des règles ci-dessus pour des produits de voyage aérien et des produits hôteliers. En appliquant les règles, illustrées dans le Tableau 3, un vol domestique avec la compagnie aérienne Transportes Aéreos Meridionais (code pourvoyeur = JJ) dont l'origine et la destination sont au Brésil, peut être affecté au vendeur en tant que commerçant. En revanche, un vol international avec la compagnie aérienne Transportes Aéreos Meridionais, dont l'origine est au Brésil et la destination en Europe, peut être affecté au fournisseur en tant que commerçant. 3049367 18 TABLEAU 3 - RÈGLES DE CONTOURNEMENT DE PRODUIT DE VOYAGE AÉRIEN Compagnie Classe de Origine Destination Commerçant aérienne réservation JJ BR BR Vendeur JJ BR EU Fournisseur TABLEAU 4 - RÈGLES DE CONTOURNEMENT DE PRODUIT HÔTELIER Hôtel Chaîne Lieu Commerçant HILTON Fournisseur HILTON Brésil Vendeur [0063] L'application des règles illustrées dans le Tableau 4, une chambre dans un hôtel HILTON® dans un lieu non spécifique peut entraîner l'affectation du fournisseur en tant que commerçant alors qu'une chambre dans un hôtel HILTON® situé au Brésil peut entraîner l'affectation du vendeur en tant que commerçant. Ces déterminations de commerçant peuvent être faites sans tenir compte du commerçant déterminé par le processus au niveau de la transaction 90 ou par le processus au niveau du produit 92. C'est-à-dire que les décisions d'affectation de commerçant faites par le processus au niveau de la transaction 90 ou par le processus au niveau du produit 92 peuvent être contournées par le processus de contournement du commerçant 94. [0064] La FIG. 5 illustre un organigramme d'un mode de réalisation du processus au niveau de la transaction 90 qui peut être mis en oeuvre par le module de détermination du commerçant 60. Le processus au niveau de la transaction 90 peut affecter un commerçant à chaque produit dans l'itinéraire défini par l'enregistrement de voyage en cours de traitement. Dans le bloc 112, le processus au niveau de la transaction 90 peut recevoir des données définissant l'itinéraire et une ou plusieurs formes de paiement. Ces données peuvent être reçues, par exemple, à partir de la base de données d'enregistrements de voyage 22 et/ou du système de paiement 24. Les données reçues à partir de la base de données d'enregistrements de voyage 22 peuvent inclure des informations relatives à la réservation et à la tarification pour chaque produit dans l'itinéraire qui peuvent être extraites de l'enregistrement de voyage. Les données de 3049367 19 paiement peuvent définir une ou plusieurs formes de paiement proposées par l'acheteur pour régler la transaction, par ex., un compte de carte de crédit, un compte de paiement en ligne, des points échangeables, un bon d'achat ou toute autre forme de paiement appropriée. En réponse à la réception des données, le processus au niveau de la transaction 90 peut sélectionner un produit à partir de l'itinéraire et poursuivre avec le bloc 114. [0065] Dans le bloc 114, le processus au niveau de la transaction 90 peut identifier un ensemble contenant une ou plusieurs règles globales dans la base de données de règles globales 82 applicables à l'itinéraire et peut appliquer ces règles au produit sélectionné. Les règles qui sont applicables peuvent dépendre d'une ou de plusieurs caractéristiques de l'itinéraire ou du contexte de la transaction, telle que l'identité du vendeur, un point d'origine de la transaction ou tout autre paramètre de sélection de règles pertinentes. Le processus au niveau de la transaction 90 peut appliquer les règles globales applicables aux produits sélectionnés au vu du contexte de transaction. L'application de règles globales peut comprendre la détermination d'une règle ou de règles dont les paramètres d'entrée sont satisfaits par les données du produit, les données de contexte de la transaction et/ou les données de formes de paiement pour le produit en cours d'analyse. [0066] Si le processus au niveau de la transaction 90 identifie une règle dont les paramètres d'entrée sont satisfaits pour le produit sélectionné (branche « OUI » du bloc de décision 116), le processus au niveau de la transaction 90 peut poursuivre avec le bloc 118 et affecter le commerçant défini par la règle satisfaite (par ex., le vendeur ou le fournisseur) au produit correspondant de l'itinéraire et peut poursuivre avec le bloc 120. Si le processus au niveau de la transaction 90 n'identifie pas de règle dont les paramètres d'entrée sont satisfaits par le produit sélectionné (branche« NON » du bloc de décision 118), le processus au niveau de la transaction 90 peut poursuivre avec le bloc 122 et peut affecter un commerçant par défaut (par ex., le vendeur). L'échec d'identification du commerçant pour le produit sur la base d'une règle globale peut aussi être enregistré dans la base de données du registre d'erreurs 88. L'enregistrement de l'échec dans la base de données du registre d'erreurs 88 peut faciliter la création de règles générales actualisées applicables à des produits et à des contextes qui ne sont pas identifiés dans les règles globales actuelles. Le processus au niveau de la transaction 90peut alors poursuivre avec le bloc 120. 3049367 [0067] Dans le bloc 120, le processus au niveau de la transaction 90 peut déterminer si tous les produits dans l'itinéraire ont été analysés. Si tous les produits n'ont pas été analysés (branche «NON» du bloc de décision 120), le processus au niveau de la transaction 90 peut poursuivre avec le bloc 124, sélectionner le produit suivant devant être analysé et revenir au bloc 114. Si tous les produits ont été analysés (branche "OUI » du bloc de décision 120), le processus au niveau global peut poursuivre avec le bloc 126. [0068] Dans certains cas, il peut y avoir des règles universelles qui peuvent être appliquées seulement après le processus au niveau du produit 92. Par exemple, une règle dont un paramètre d'entrée inclut le nombre de commerçants pour l'itinéraire peut avoir besoin d'être appliquée après la détermination des commerçants en utilisant les règles globales et les règles de produit. Ces règles universelles peuvent être signalées par le processus au niveau de la transaction 90, dans le bloc 126, pour application après détermination des paramètres d'entrée de la règle globale manquante. [0069] La FIG. 6 est un organigramme qui illustre un mode de déroulement du processus au niveau du produit 92 qui peut être mis en oeuvre par le module de détermination du commerçant 60. Dans le bloc 130, le processus au niveau du produit 92 peut sélectionner un produit à partir de l'itinéraire et poursuivre avec le bloc 132. Dans le bloc 132, le processus 92 au niveau du produit peut déterminer quelles règles de produit dans la base de données de règles de produit 84, sont applicables, le cas échéant, au produit sélectionné. Les règles qui sont applicables peuvent dépendre d'une ou de plusieurs caractéristiques du produit, de l'identité du vendeur, de l'identité du pourvoyeur, du type de produit ou de toute autre règle de paramètre de produit. Les règles de produit peuvent être configurées par exemple, pour s'assurer que la transaction respecte tout accord commercial applicable entre le vendeur et le fournisseur. [0070] Une fois que les règles de produit ont été identifiées, le processus au niveau du produit 92 peut appliquer les règles de produit applicables au produit sélectionné. L'application de règles de produit peut comprendre la détermination des règles applicables dont les paramètres d'entrée sont satisfaits par les données du produit, les données du contexte de la transaction, et/ou les données de formes de paiement pour le produit en cours d'analyse. Si le processus au niveau du produit 92 identifie une règle applicable dont les paramètres d'entrée sont satisfaits (branche « OUI » du bloc de décision 134), le processus au niveau du produit 92 peut poursuivre avec le bloc 136 et peut affecter le commerçant défini par la règle satisfaite (par ex., le vendeur ou le 3049367 21 fournisseur) au produit correspondant de l'itinéraire et peut poursuivre avec le bloc 138. Si le commerçant affecté par la règle de produit est différent du commerçant affecté par le processus au niveau de la transaction 90, le commerçant affecté par la règle de produit peut remplacer le commerçant affecté par le processus au niveau de la transaction 90. [0071] Si le processus au niveau du produit 92 ne peut pas identifier une règle dont les paramètres d'entrée sont satisfaits (branche « NON » du bloc de décision 134), le processus au niveau du produit 92 peut laisser le commerçant affecté en place, et peut poursuivre avec le bloc 138. Dans le bloc 138, le processus au niveau du produit 92 peut déterminer si tous les produits dans l'itinéraire ont été analysés. Si tous les produits n'ont pas été analysés (branche « NON » du bloc de décision 138), le processus au niveau de la transaction 90 peut poursuivre avec le bloc 140, sélectionner le produit suivant à analyser, et revenir au bloc 132. Si tous les produits ont été analysés (branche « OUI » du bloc de décision 138), le processus au niveau du produit 92 peut poursuivre avec le bloc 142. [0072] Dans le bloc 142, le processus au niveau du produit 92 peut déterminer si le commerçant affecté à tout produit n'a pas été sélectionné sur la base d'une règle globale ou d'une règle de produit. C'est-à-dire, que le processus au niveau du produit 92 peut déterminer si un commerçant par défaut est affecté à tout produit parce qu'il n'existait aucune règle globale et aucune règle de produit applicable au produit, dans les bases de données de règles. Si un ou plusieurs produits ont été affectés à des commerçants par défaut (branche « OUI » du bloc de décision 142), le processus au niveau du produit 92 peut poursuivre avec le bloc 144 et enregistrer les conditions qui ont entraîné l'affectation par défaut dans la base de données du registre d'erreurs 88. Si tous les produits ont été affectés à un commerçant par application d'au moins une règle au produit (branche «NON » du bloc de décision 142), le processus au niveau du produit 92 peut prendre fin. [0073] La FIG. 7 représente un organigramme qui illustre un mode de réalisation du processus de contournement du commerçant 94 qui peut être mis en oeuvre par le module de détermination de commerçant 60. Dans le bloc 150, le processus de contournement du commerçant 94 peut sélectionner un produit à partir de l'itinéraire et poursuivre avec le bloc 156. Dans le bloc 156, le processus 94 de contournement du commerçant peut vérifier dans la base de données des règles de contournement 86, l'existence de règles correspondant au produit. Si une règle correspondante n'est pas trouvée dans la base de données de règles de contournement 86 3049367 22 (branche « NON » du bloc de décision 154), le processus de contournement du commerçant 94 peut poursuivre avec le bloc 156 sans modifier le commerçant affecté au produit. Si le processus de contournement du commerçant identifie une règle correspondante aux produits dans la base de données de règles de contournement 86 (branche « OUI » du bloc de décision 154), le processus de contournement du commerçant 94 peut poursuivre avec le bloc 158 et mettre à jour le commerçant affecté au produit, conformément à la règle de contournement. [0074] Dans le bloc 156, le processus de contournement du commerçant 94 peut déterminer si les règles de contournement ont été vérifiées pour tous les produits dans l'itinéraire. Si tous les produits n'ont pas été vérifiés (branche « NON » du bloc de décision 156), le processus de contournement du commerçant 94 peut poursuivre avec le bloc 160, sélectionner le produit suivant, et revenir au bloc 152. Si tous les produits dans l'itinéraire ont été vérifiés (branche « OUI » du bloc de décision 156), le processus peut poursuivre avec le bloc 162. [0075] Dans le bloc 162, le processus de contournement du commerçant 94 peut déterminer si des règles globales qui ont été signalées pour une application ultérieure par le processus au niveau de la transaction 90 existent. Si aucune règle globale n'a été signalée pour une application ultérieure (branche « NON » du bloc de décision 162), le processus de contournement du commerçant 94 peut procéder au bloc 164. Si des règles globales ont été signalées pour une application ultérieure (branche « OUI » du bloc de décision 162), le processus de contournement du commerçant peut avancer au bloc 166 ; il peut appliquer les règles globales signalées aux produits pertinents et il peut poursuivre avec le bloc 164. Les produits pertinents peuvent inclure des produits dont le commerçant a été affecté par une règle au niveau global. C'est-à-dire, que dans un mode de réalisation de l'invention, le processus de contournement du commerçant 94 peut appliquer les règles globales signalées uniquement aux produits pour lesquels aucun commerçant n'a été affecté sur la base d'une règle de produit ou d'une règle de contournement du commerçant. [0076] Par exemple, si un ou plusieurs produits ont été signalés comme étant assujettis à l'exemple de la règle globale concernant le nombre maximum de commerçants illustré dans le Tableau 1, le processus de contournement du commerçant 94 peut appliquer la règle en déterminant le nombre de commerçants différents pour l'itinéraire. Selon la règle, le nombre de commerçants différents peut être déterminé uniquement sur la base des commerçants pour des produits prépayés. Le processus de contournement du commerçant 94 peut compter un seul 3049367 23 commerçant une fois, si ce commerçant est le même pour plusieurs produits. Si le nombre de commerçants résultant est supérieur au seuil établi par la règle (par ex., trois), le commerçant affecté peut être contourné en affectant le vendeur comme commerçant au produit en question. Les produits auxquels la règle s'applique peuvent aussi être définis par la règle. Par exemple, pour la règle illustrée dans le Tableau 1, seuls les produits : hôtel, location de voiture, attraction et croisière sont assujettis à la restriction de nombre maximum de commerçants ildmAx. [0077] Dans le bloc 164, le processus de contournement du commerçant 94 peut déterminer si l'acheteur a sélectionné une forme de paiement qui inclut un plan de financement. Les plans de financement peuvent être fournis par le vendeur ou par un ou plusieurs fournisseurs. Si la forme de paiement n'inclut pas un plan de financement (branche « NON » du bloc de décision 164), le processus de contournement du commerçant 94 peut prendre fin. Si la forme de paiement inclut un plan de financement (branche « OUI » du bloc de décision 164), le processus de contournement du commerçant 94 peut poursuivre avec le bloc 168. [0078] Pour s'assurer qu'un plan de financement sélectionné est pris en charge par le commerçant affecté au produit, le processus de contournement du commerçant 94 peut, dans le bloc 168, interroger le système de paiement 24 pour obtenir tous les plans de financement pris en charge pour l'enregistrement de voyage en cours de traitement. Le processus de contournement du commerçant 94 peut ensuite déterminer, pour chaque produit, si le plan de financement sélectionné est pris en charge par le commerçant affecté. Si le commerçant affecté prend en charge le plan de financement sélectionné, le commerçant peut être laissé en place sans modification. Si le commerçant affecté ne prend pas en charge le plan de financement sélectionné, le processus de contournement du commerçant 94 peut réaffecter le produit à un autre commerçant (par ex., le fournisseur lorsque le commerçant affecté est le vendeur, ou le vendeur lorsque le commerçant affecté est le fournisseur), si le commerçant alternatif prend en charge le plan de financement. [0079] Une fois que l'enregistrement a été traité par le processus au niveau de la transaction 90, le processus au niveau du produit 92et le processus de contournement du commerçant 94, un commerçant peut être affecté à chaque produit dans l'itinéraire. Le processus d'actualisation de l'enregistrement de voyage 96 peut ensuite actualiser l'enregistrement de voyage dans la base de données d'enregistrements de voyage 22 pour refléter les affectations de commerçants. 3049367 24 [0080] Si les règles globales ou les règles de produit échouent dans l'identification positive d'un commerçant pour un produit, le produit peut être affecté à un commerçant par défaut (par ex., le vendeur) pour permettre au traitement de la transaction de continuer. Cependant, l'utilisation de commerçants par défaut peut indiquer une interaction inattendue ou non voulue entre les règles de produit et/ou le contexte de la transaction. Pour notifier les vendeurs de ces occurrences, le processus de rapport d'erreurs 98 peut accéder à la base de données du registre d'erreurs 88 de façon asynchrone et peut avertir le vendeur du produit de l'utilisation de scénarios qui ne sont pas couverts par les règles globales dans la base de données de règles globales 82 ou par des règles de produit dans la base de données de règles de produit 84. [0081] Le processus de rapport d'erreurs 98 peut être exécuté de façon régulière selon un horaire défini par l'utilisateur. Le processus de rapport d'erreurs 98 peut récupérer des enregistrements d'erreurs générés pendant le traitement de transactions à partir de la base de données du registre d'erreurs 88. Comme décrit ci-dessus, les enregistrements d'erreurs peuvent identifier les produits et les conditions pour lesquels un commerçant n'a pas été identifié positivement par les règles. C'est-à-dire, que les enregistrements d'erreurs peuvent identifier les produits pour lesquels le commerçant (par ex., le vendeur) a été affecté uniquement par défaut. Le processus de rapport d'erreurs 98 peut agréger les enregistrements d'erreurs et fournir des enregistrements d'erreurs agrégés au module de formatage et de livraison 100. [0082] Le module de formatage et de livraison 100 peut formater les enregistrements d'erreurs dans des rapports et envoyer les rapports à une adresse prédéfinie telle qu'une adresse électronique, une adresse de protocole de transfert de fichier (File Transfer Protocol, ou FTP) ou une adresse de protocole Internet (IP) fournie par le vendeur. Le formatage peut être effectué sur la base d'un modèle qui peut être configuré par le bénéficiaire du rapport pour définir comment les données du registre doivent être affichées. La base de données du registre d'erreurs 88 et le processus de rapport d'erreurs 98 peuvent ainsi permettre au vendeur d'ajuster une ou plusieurs des règles globales ou des règles de produit pour couvrir l'utilisation de produits dans des scénarios qui ont déclenché la création de l'enregistrement de l'erreur. [0083] À titre d'exemple, le fonctionnement du module de détermination du commerçant 60 va maintenant être décrit à l'aide d'un scénario hypothétique. Le scénario inclut la réservation d'un voyageur pour un voyage à Rio de Janeiro le 19 mai par l'intermédiaire d'un site Web brésilien géré par le vendeur. Le point de vente est le Brésil et l'itinéraire inclut un produit de 3049367 voyage aérien, un produit hôtelier et un produit attraction. Le produit de voyage aérien est un vol de San Paulo (GRU) à Rio de Janeiro (GIG) avec la compagnie aérienne Transportes Aéreos Meridionais (code fournisseur = JJ) qui part le 19 juin. Le produit hôtelier est une chambre réservée du 19 juin au 21 juin à l'hôtel Ibis Botafogo. Le produit attraction est un billet pour visiter le Corcovado, le 20 juin. Dans cet exemple hypothétique, la forme de paiement sélectionnée par le voyageur inclut une carte de crédit (par ex., VISA®, code FOP CCVI), avec une facilité de financement en trois fois au taux d'intérêt de 1 %. [0084] L'information relative à l'itinéraire ci-dessus peut être fournie par le module de détermination du commerçant 60 à partir de la base de données d'enregistrements de voyage 22 et/ou du système de paiement 24. Un exemple de fichier de données contenant les données de l'itinéraire qui peut être reçu à partir de la base de données d'enregistrements de voyage 22 peut être configuré comme suit : RÉSERVATION ABC123 VOL .1.1 GRU GIG 19 JUIN HÔTEL IBIS BOTAFOGO 19-21 JUIN TREM DO CORCOVADO BILLET 20 JUIN. Les informations de paiement décrites ci-dessus peuvent être fournies au module de détermination du commerçant 60 par le système de paiement 24. Un exemple de fichier de données de paiement peut être configuré comme suit : CCVI 1234XXXX PLAN DE FINANCEMENT 3 x 1 19 MAI, BRÉSIL Le processus au niveau de la transaction 90 peut récupérer les règles universelles pour le vendeur, à partir de la base de données de règles globales 82, qui peut être représentée par les exemples de règles définies par le Tableau 5. 3049367 26 [0085] Il y a trente jours à partir de la date de la transaction (19 mai) jusqu'à la première date d'utilisation de tout produit dans l'itinéraire (le vol part le 19 juin), donc la condition de seuil définie dans la colonne TMIN n'est pas satisfaite. La condition de seuil dans la colonne MMAX ne peut pas être déterminée avant que le nombre de commerçants soit connu. Aucun des produits dans l'itinéraire n'est soumis à une pénalité, donc la condition de seuil définie dans la colonne PMAX n'est pas satisfaite. La forme de paiement est une carte de crédit, donc le type de condition dans la colonne FOP n'est pas satisfait. Puisqu'aucune des conditions de la règle n'est satisfaite à ce stade, les règles globales du Tableau 5 ne peuvent identifier de façon positive un commerçant pour tout produit. Cependant, puisque le nombre de commerçants n'est pas encore connu, la règle globale qui dépend d'un nombre maximum de commerçants ne dépassant pas MmAx peut être signalée pour une application ultérieure. Ainsi, au moment où le traitement de l'enregistrement de voyage passe du processus au niveau de la transaction 90 au processus au niveau du produit 92, le commerçant n'a pas encore été déterminé pour aucun des produits dans cet exemple. [0086] Le processus 92 au niveau du produit peut analyser l'itinéraire au niveau du produit et peut affecter un commerçant pour chaque produit qui servira de référence au processus de contournement du commerçant 94 pour une décision finale concernant le commerçant. Afin de déterminer les règles de produit applicables, le processus au niveau du produit 92 peut interroger la base de données des règles de produit 84 pour connaître les règles qui correspondent aux informations relatives au produit, reçues à partir de la base de données d'enregistrements de voyage 22. La base de données des règles de produit 84 peut être configurée pour que chaque produit ait une règle correspondante qui identifie un commerçant pour le produit. Le Tableau 6 TABLEAU 5 - RÈGLES GLOBALES TMIN MivAx PMAX FOP Seuil/Type 4 3 1 Points, En ligne Produits à Prépayé Hôtel, voiture de Produits avec Prépayé contourner location, pénalité en cas attraction, croisière d'annulation 3049367 27 fournit un exemple d'un ensemble de règles de produit qui peuvent être renvoyées par la base de données des règles de produit 84. [0087] Dans l'exemple présent, la comparaison des données de produits avec les règles du Tableau 6 montre que le produit voyage aérien correspond à la règle définie dans le rang supérieur du Tableau 2, dans la mesure où le vol est fourni par Transportes Aéreos Meridionais (code pourvoyeur = JJ). Le produit hôtelier correspond à la règle définie dans le rang inférieur du Tableau 1, dans la mesure où la forme de paiement est VISA® (FOP code CCIV), le pourvoyeur est Ibis, et le point de vente est au Brésil. Ainsi, le fournisseur (Transportes Aéreos Meridionais) est affecté comme commerçant pour le produit de voyage aérien, et le fournisseur (Ibis) est affecté comme le commerçant pour l'hôtel. Cependant, comme aucune règle de produit ne correspond à l'attraction, le commerçant de référence pour l'attraction est affecté comme commerçant par défaut, par ex., le vendeur. [0088] Puisque le commerçant pour un des produits n'a pas été déterminé ni par une règle globale ni par une règle de commerçant, le processus au niveau du produit 92 peut générer un enregistrement d'erreur dans la base de données du registre d'erreurs 88. L'enregistrement d'erreur peut informer le vendeur qu'aucune règle n'est définie, ni dans la base de données de règles globales 82, ni dans la base de données des règles de produit 84 pour le produit attraction. L'enregistrement d'erreur peut stocker toutes les données pertinentes pour la transaction, telles qu'une identité de l'enregistrement de voyage (par ex., un identifiant d'enregistrement) ainsi que l'information relative aux produits attraction. Lorsque le processus au niveau du produit 92 a complété son traitement de l'enregistrement de voyage, le module de détermination de commerçant 60 peut transmettre le traitement de l'enregistrement de voyage du processus au niveau du produit 92, au processus de contournement du commerçant 94. TABLEAU 6 - RÈGLES DE PRODUITS Type de Code FOP Pourvoyeur Fournisseur Pays POS Commerçant produit Vol JJ JJ Pourvoyeur Hôtel CCVI IBIS BR Pourvoyeur 3049367 28 [0089] Au moment où l'enregistrement de voyage est transmis au processus de contournement du commerçant 94, le commerçant de référence affecté au produit voyage aérien peut être Transportes Aéreos Meridionais, le commerçant de référence affecté à l'hôtel peut être Ibis et le commerçant par défaut affecté à l'attraction peut être le vendeur. Le processus de contournement du commerçant 94 peut commencer par récupérer les règles de contournement du commerçant pour les produits voyages aériens et les règles de contournement du commerçant pour les produits hôtels à partir de la base de données de règles de contournement 86. Des règles exemplaires utilisées avec cet exemple sont illustrées dans les Tableaux 7 et 8. TABLEAU 7 - RÈGLES DE CONTOURNEMENT DE PRODUIT VOYAGE AÉRIEN Compagnie aérienne Origine Destination Commerçant JJ BR NYC Vendeur JJ BR EU Vendeur TABLEAU 8 - RÈGLES DE CONTOURNEMENT DE PRODUIT HÔTELIER Hôtel Chaîne Lieu Commerçant HILTON AR Vendeur IBIS BR Vendeur [0090] Le transporteur (par ex., Transportes Aéreos Meridionais, code pourvoyeur = JJ) et l'origine (par ex., San Paolo) du produit voyage aérien correspondent au transporteur afférent et aux conditions relatives à l'origine des deux règles du Tableau 7. Cependant, la destination du produit voyage aérien (Rio de Janeiro) ne correspond pas à la condition de destination de la règle (New York City). Puisqu'aucune des règles de contournement ne correspondent au produit voyage aérien, le commerçant affecté précédemment, Transportes Aéreos Meridionais, est maintenu. La chaîne et le lieu du produit hôtel correspondent à la règle définie par le rang inférieur du Tableau 8. Cette règle peut être due, par exemple, à un accord commercial avec Ibis qui requiert que le vendeur soit aussi le commerçant pour les hôtels Ibis au Brésil. Puisque le produit correspond à la règle de contournement de commerçant, le commerçant pour le produit hôtel est changé, d'Ibis au vendeur. 3049367 29 [0091] Lorsque l'analyse pour les affectations de commerçant, pour chaque produit dans l'itinéraire sur la base des règles de contournement du commerçant dans la base de données de règles de contournement 86, est achevée, le processus de contournement du commerçant 94 peut vérifier la conformité avec les règles globales signalées. Dans le présent exemple, il existe une règle signalée, qui dépend du nombre maximum de commerçants, qui pourrait donner lieu à un éventuel contournement. Ainsi, le processus de contournement du commerçant 94 peut déterminer le nombre de commerçants et peut appliquer la règle signalée. Puisque seulement deux commerçants sont actuellement affectés comme commerçants aux produits dans l'itinéraire, notamment Transportes Aéreos Meridionais et le vendeur, et que MmAX pour la règle globale signalée est trois, alors la règle globale signalée ne prime pas sur les affectations actuelles. [0092] Parce que l'acheteur a demandé une forme de paiement qui inclut un plan de financement, le processus de contournement du commerçant 94 peut par ailleurs déterminer si cette forme de paiement nécessite des contournements additionnels de commerçants affectés. À cette fin, le processus de contournement du commerçant 94 peut interroger le système de paiement 24 pour obtenir une liste des plans de financement disponibles pour l'enregistrement de voyage. En réponse à l'interrogation, le système de paiement 24 peut renvoyer un fichier de données contenant les plans de financement disponibles. Un exemple de réponse reçue du système de paiement 24 peut être configuré comme suit : .1.1--> 1x %,2 x 0 %,3 x 1%, 10 x 4 % OLTA---->lx 0%, 2 x 0%, 3 x 1%, 4 x 2 %, 10 x 5%, 12x 5 % [0093] Parce que les seuls commerçants restants sont les fournisseurs du produit voyage aérien (code pourvoyeur JJ) et le vendeur (par ex., une agence de voyages en ligne ou (Online Travel Agency, ou OLTA) et parce que le plan de financement demandé (par ex., 3 x 1 %) est pris en charge par chaque commerçant, il n'y a pas lieu de changer les affectations de commerçant pour tout produit. Ayant appliqué toutes les règles applicables, le processus de contournement du commerçant 94 peut prendre fin et le module de détermination du commerçant 60 peut procéder à l'exécution du processus d'actualisation de l'enregistrement de voyage 96. Le processus d'actualisation de l'enregistrement de voyage 96 peut formater les données du commerçant affecté et transmettre une demande d'actualisation à la base de données d'enregistrements de voyage 22. La demande d'actualisation peut donner l'ordre à la base de 3049367 données d'enregistrements de voyage 22 de mettre à jour l'enregistrement de voyage pour indiquer le commerçant affecté à chaque produit. [0094] À un moment désigné dans le temps après la détermination de commerçant, le processus de rapport d'erreurs 98 peut fournir un rapport d'erreurs au système du vendeur détaillant les scénarios pour lesquels le module de détermination de commerçant 60 n'a pas pu identifier un commerçant de référence. Dans ce but, le processus de rapport d'erreurs 98 peut accéder à la base de données de registre d'erreurs et récupérer les enregistrements d'erreurs qui n'ont pas encore été rapportés (par exemple, l'enregistrement d'erreur lié au produit attraction). Ces données peuvent être formatées conformément au modèle défini précédemment par le module de formatage et de livraison 26 et peuvent être envoyées dans un courriel au destinataire demandé. La base de données du registre d'erreurs 88 peut être purgée après le traitement de chaque itinéraire afin que seules les erreurs de l'enregistrement de voyage actuel soient envoyées une fois que le module de détermination du commerçant 60 a finalisé son traitement. FORME DE DÉTERMINATION DE PAIEMENT [0095] En fonction de la décision relative au commerçant, les paiements effectués pour confirmer une réservation peuvent requérir des formes de paiement différentes pour régler les comptes avec le fournisseur et le vendeur. Pour chaque produit dans l'itinéraire, deux flux de paiements sont possibles. L'acheteur peut payer le vendeur qui à son tour paie le fournisseur du produit, ou l'acheteur peut payer le fournisseur du produit directement. Dans les cas où le paiement est acheminé par l'intermédiaire du vendeur, le montant payé au vendeur peut être différent du montant que le vendeur paie au fournisseur. Cela peut être le cas par exemple, si le vendeur a majoré ou réduit le prix du produit. Une forme de paiement utilisée pour régler un compte avec le fournisseur peut être désignée comme forme de paiement du fournisseur. Une forme de paiement utilisée pour régler un compte avec le vendeur peut être désignée comme forme de paiement du vendeur. Comme décrit ci-dessous, le module de forme de paiement 62 peut être configuré pour identifier les formes de paiement appropriées devant être utilisées pour régler les comptes entre l'acheteur et le vendeur, entre le vendeur et le fournisseur et entre l'acheteur et le fournisseur. Les données identifiant la forme de paiement devant être utilisée avec chaque produit dans l'itinéraire défini par l'enregistrement de voyage peuvent être stockées dans 3049367 31 un champ de données et peuvent être associées au produit correspondant dans l'enregistrement de voyage. [0096] Un enregistrement conventionnel de nom de passager (PNR) peut être limité par rapport aux types et au nombre de formes de paiement pouvant être suivis. Par exemple, un PNR peut être limité à seulement la forme de paiement utilisée par l'acheteur, ou la forme de paiement utilisée par le vendeur. Dans le cas du vendeur, la forme de paiement peut devoir être saisie sous forme d'un substitut (par ex., ESPÈCES) et les paiements actuels peuvent nécessiter un suivi en ligne. Le module de formes de paiement 62 peut résoudre ce problème en suivant toutes les formes de paiement relatives à la confirmation d'un itinéraire dans l'enregistrement de voyage permettant ainsi un traitement automatisé en ligne, du début à la fin, entre l'acheteur, le vendeur et le fournisseur. [0097] Le module de formes de paiement 62 peut inclure des processus qui permettent les paiements automatiques, les transactions sécurisées et la récupération d'erreur. Ces processus peuvent ajouter des formes de paiement utilisées par le vendeur à l'enregistrement de voyage correspondant, avec les paiements effectués par l'acheteur directement au fournisseur gérés par le système du fournisseur. Les paiements effectués par l'acheteur au vendeur par carte de crédit peuvent être plus susceptibles de fraude et/ou d'erreurs, par rapport aux autres formes de paiement, en raison du vol du numéro de la carte ou d'erreur d'entrées causées par les agents ou le vendeur. [0098] Le module de formes de paiement 62 peut permettre aux formes de paiement d'être définies dans l'enregistrement de voyage pour les paiements effectués par l'acheteur au vendeur et les paiements effectués par le vendeur au fournisseur. Le module de formes de paiement 62 peut ainsi permettre de déterminer les formes de paiement effectuées par le vendeur au fournisseur en interrogeant l'enregistrement de voyage. Pour automatiser les paiements effectués par le vendeur au fournisseur dans les cas impliquant des formes de paiements multiples utilisées par le vendeur, la forme de paiement peut être déterminée sur la base de règles de paiement conservées dans une base de données de règles de paiement. Ces règles de paiement peuvent être définies par le vendeur et peuvent dépendre de paramètres tels que le marché sur lequel le produit est proposé, le type de produit ou tout autre paramètre pertinent. [0099] Faisant maintenant référence à la FIG. 8, le module de formes de paiement 62 peut inclure un processus de détermination des formes de paiement 180, un processus 3049367 32 d'enregistrement 182 qui enregistre le traitement de la transaction par le processus de détermination des formes de paiement 181 dans une base de données du registre 184, et une base de données des règles de paiement 186. Le processus de détermination 180 peut récupérer le produit, le point de vente et les données du commerçant à partir de l'enregistrement de voyage en interrogeant la base de données d'enregistrements de voyage 22. Le processus de détermination 180 peut aussi recevoir des données en provenance du module de détermination du commerçant 60 et peut communiquer avec le système de paiement 24 et le système de détection anti-fraude 26. Le processus de détermination 180 peut aussi récupérer ou autrement accéder aux données contextuelles de la transaction, telles que la date et l'heure. Le processus de détermination 180 peut traiter ces données pour déterminer la forme de paiement utilisée pour payer chaque fournisseur sur la base des règles qui gouvernent les formes de paiement, récupérées à partir de la base de données de règles de paiement 186. La base de données de règles de paiement 186 peut être configurée de façon à ce que le vendeur puisse définir les règles de paiement dans la base de données des règles de paiement 186. [00100] Une fois que les formes de paiement ont été déterminées, le processus de détermination 180 peut ajouter des données à l'enregistrement de voyage qui identifient la forme de paiement du fournisseur pour chaque produit dans l'enregistrement de voyage. Le processus de détermination 180 peut aussi ajouter des données à l'enregistrement de voyage qui identifient la forme de paiement du vendeur. Pendant le processus de définition des formes de paiement, le processus de détermination 180 peut pousser des données vers le processus d'enregistrement 182 ce qui peut générer des enregistrements de registre dans la base de données du registre 184. Le processus de détermination 180 peut aussi interagir avec d'autres modules pour mettre à jour l'enregistrement de voyage et/ou demander une analyse de fraude. [00101] Les données reçues à partir du processus de détermination 180 peuvent être liées à des événements ou au progrès réalisé dans la détermination de la forme de paiement pour un produit dans l'itinéraire. En réponse à la réception d'une demande de génération d'un enregistrement dans la base de données du registre 184, le processus d'enregistrement 182 peut générer l'enregistrement et stocker l'information définissant un événement dans la base de données du registre 184. Le processus d'enregistrement 182 peut transmettre une réponse au processus de détermination 180, soit pour accuser réception de la génération réussie d'un enregistrement, soit pour informer le processus de détermination 180 de l'échec de la génération 3049367 33 de l'enregistrement. Dans le cas d'un échec de la génération de l'enregistrement par le processus d'enregistrement 182, le processus de détermination 180 peut, par exemple, retransmettre la demande. Si la demande faite au processus d'enregistrement 182 consiste à générer un enregistrement d'erreur, le processus d'enregistrement 182 peut transmettre une réponse au processus de détermination 180 sous la forme d'une réponse EDIFACT or XML qui indique le type d'erreur qui a été enregistré dans la base de données du registre 184. [00102] La FIG. 9 représente un organigramme d'un mode de réalisation du processus de détermination 180 qui peut être mis en oeuvre par le module des formes de paiement 62. Dans le bloc 202, le processus de détermination 180 peut récupérer les données définissant l'itinéraire qui est en cours d'achat. Le processus de détermination 180 peut récupérer ces données, par exemple, à partir de la base de données d'enregistrements de voyage 22 en réponse à une demande EDIFACT ou XML afin de déterminer la forme de paiement pour un produit particulier de l'itinéraire ou pour l'intégralité de l'itinéraire. L'information relative au produit récupérée à partir de l'enregistrement de voyage peut inclure des données identifiant le commerçant affecté au produit par le module de détermination de commerçant 60. Les données récupérées à partir de l'enregistrement de voyage peuvent aussi inclure des informations contextuelles pour la transaction telles que le point de vente, la date et l'heure de la vente. [00103] Dans le bloc 204, le processus de détermination 180 peut déterminer toutes données manquantes, nécessaires pour la détermination des formes de paiement utilisées pour l'achat des produits dans l'itinéraire. Si des données sont manquantes (branche » OUI » du bloc de décision 204), le processus de détermination 180 peut poursuivre avec le bloc 206 et peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur dans la base de données du registre 184. Le module de formes de paiement 62 peut ensuite terminer le processus de détermination 180 pour l'itinéraire question. La demande de génération d'un enregistrement d'erreur peut identifier le type de données manquantes, de sorte que le processus d'enregistrement 182 peut inclure cette information dans l'enregistrement d'erreur. [00104] Si aucune des données nécessaires pour déterminer la forme de paiement ne manque (branche «NON » du bloc de décision 204), le processus de détermination 180 peut poursuivre avec le bloc 208. Dans le bloc 208, le processus de détermination 180 peut demander au processus d'enregistrement 182 de générer un enregistrement dans la base de données du registre 184 en indiquant les données nécessaires pour la détermination des formes de paiement 3049367 34 pour les produits récupérés dans l'itinéraire. Le processus de détermination 180 peut ensuite sélectionner un produit à analyser à partir de l'itinéraire et poursuivre avec le bloc 210. [00105] Faisant maintenant référence à la FIG. 10, un sous-processus 212 qui est représenté peut être exécuté par le processus de détermination 180 dans le bloc 210 pour créer la forme de paiement du client. Dans le bloc 214 du sous-processus 212, le sous-processus 212 peut demander la création d'une forme de paiement client dans l'enregistrement de voyage. La création de la forme de paiement client peut aussi inclure l'obtention d'une autorisation pour la forme de paiement client. La forme de paiement client peut être déterminée en interrogeant le système de paiement 24 pour obtenir des informations relatives à la forme de paiement, si le fournisseur est le commerçant, ou elle peut être déterminée à partir de données dans la demande initiale pour la confirmation de l'itinéraire, si le vendeur est le commerçant. Quel que soit le cas, en réponse à la détermination de la forme de paiement du client, les données définissant la forme de paiement du client pour le produit sélectionné peuvent être stockées dans l'enregistrement de voyage. L'obtention d'une autorisation pour la forme de paiement du client peut inclure la transmission d'une demande d'autorisation à la banque émettrice, et la réception de l'autorisation de la banque émettrice. [00106] Lorsque le sous-processus 212 est incapable de créer la forme de paiement du client dans l'enregistrement de voyage (branche «NON» du bloc de décision 216), le sous- processus 212 peut procéder au bloc 218. Dans le bloc 218, sous-processus 212 peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur dans la base de données du registre indiquant un échec de création de la forme de paiement du client pour le produit sélectionné. Le sous-processus 212 peut alors poursuivre avec le bloc 220 et terminer le processus de détermination 180. Si le sous-processus 212 réussit à créer la forme de paiement du client dans l'enregistrement de voyage (branche « OUI » du bloc de décision 216), le sous-processus 212 peut avancer au bloc 222. [00107] Dans le bloc 222, le sous-processus 212 peut demander au processus 182 de générer un enregistrement dans la base de données du registre 184 indiquant que la création de la forme de paiement pour le produit sélectionné a été ajoutée avec succès à l'enregistrement de voyage. Le sous-processus 212 peut ensuite poursuivre avec le bloc 224 et demander une analyse de fraude sur la forme de paiement du client. Le sous-processus 212 peut demander l'analyse de fraude par exemple, en interrogeant le système de détection anti-fraude 26. 3049367 [00108] Si la réponse à la demande d'analyse de fraude indique que la forme de paiement du client est frauduleuse (branche « OUI » du bloc de décision 226), le sous-processus 212 peut poursuivre avec le bloc 228. Dans le bloc 228, le sous-processus 212 peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur dans la base de données du registre indiquant qu'une fraude a été détectée pour la forme de paiement du client. Le sous-processus 212 peut ensuite avancer au bloc 220 et terminer le processus de détermination 180. [00109] Si la réponse à la demande d'analyse de fraude indique que la forme de paiement du client est soumise à un test de sécurité plus rigoureux, par exemple un examen manuel (branche « TEST » du bloc de décision 226), le sous-processus 212 peut poursuivre avec le bloc 230. Dans le bloc 230, le sous-processus 212 peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur indiquant que le test de sécurité est en cours sur la forme de paiement du client. Le sous-processus 212 peut ensuite revenir au processus de détermination 180. [00110] Si la réponse à une demande d'analyse de fraude indique que la forme de paiement du client n'apparaît pas comme étant frauduleuse (branche « NON » du bloc de décision 226), le sous-processus 212 peut poursuivre avec le bloc 234. Dans le bloc 234, le sous-processus 212 peut demander au processus 182 de générer un enregistrement de registre indiquant que la forme de paiement du client n'apparaît pas comme étant frauduleuse. Le sous-processus 212 peut ensuite revenir au processus de détermination 180. [00111] Faisant maintenant référence à la FIG. 9, au bloc 232 du processus de détermination 180, le processus de détermination 180 peut déterminer si le vendeur est le commerçant du produit sélectionné. Si le vendeur n'est pas le commerçant (branche « NON » du bloc de décision 232), le processus de détermination 180 peut poursuivre avec le bloc 236. Dans le bloc 236, le processus de détermination 180 peut créer une forme de paiement pour le fournisseur dans l'enregistrement de voyage en utilisant la forme de paiement du client. Le processus de détermination 180 peut créer une forme de paiement pour le fournisseur dans l'enregistrement en transmettant, par exemple, une demande à la base de données d'enregistrements de voyage 22 et en demandant que la base de données d'enregistrements de voyage 22 ajoute un champ de données définissant la forme de paiement du fournisseur pour le produit à l'enregistrement de voyage. Une fois que la forme de paiement du fournisseur a été 3049367 36 créée dans l'enregistrement de voyage, le processus de détermination 180 peut poursuivre avec le bloc 238. [00112] Si le commerçant du produit sélectionné est le vendeur (branche « OUI » du bloc de décision 232), le processus de détermination peut poursuivre avec le bloc 240. Dans le bloc 240, le processus de détermination 180 peut créer une forme de paiement pour le vendeur dans l'enregistrement de voyage, en utilisant la forme de paiement du client. Comme décrit ci-dessus pour la forme de paiement fournisseur, le processus de détermination 180 peut créer la forme de paiement du vendeur en transmettant une demande à la base de données d'enregistrements de voyage 22 et en demandant que la base de données d'enregistrements de voyage 22 ajoute un champ de données définissant la forme de paiement du vendeur à l'enregistrement de voyage. Le processus de détermination 180 peut alors poursuivre avec le bloc 242. [00113] Faisant maintenant référence à la FIG. 11, un sous-processus 244 est représenté qui peut être exécuté par le processus de détermination 180 dans le bloc 242 pour créer une forme de paiement du fournisseur. La forme de paiement du fournisseur peut être créée dans l'enregistrement de voyage en utilisant les règles de paiement récupérées à partir de la base de données des règles de paiement 186. [00114] Dans le bloc 246 du sous-processus 244, le sous-processus 244 peut interroger la base de données des règles de paiement 186 pour connaître les règles qui gouvernent les formes de paiement utilisées par le vendeur pour payer le fournisseur. Si la base de données des règles de paiement 186 ne renvoie aucune règle gouvernant les formes de paiement utilisées par le vendeur pour payer le fournisseur (branche « NON » du bloc de décision 248), le sous-processus 244 peut poursuivre avec le bloc 250. Dans le bloc 250, le sous-processus 244 peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur dans la base de données du registre 184. L'enregistrement d'erreur peut indiquer que les règles gouvernant les formes de paiement utilisées par le vendeur pour payer le fournisseur pour le produit en cours d'analyse sont absentes de la base de données de règles de paiement 186. Le sous-processus 244 peut alors poursuivre avec le bloc 252 et peut terminer le processus de détermination 180. [00115] Si la base de données des règles de paiement 186 renvoie au moins une règle gouvernant les formes de paiement utilisées par le vendeur pour payer le fournisseur (branche « OUI » du bloc de décision 248), le processus de détermination 180 peut poursuivre avec le bloc 254. Dans le bloc 254, le sous-processus 244 peut tenter de faire correspondre les règles 3049367 37 renvoyées au produit sélectionné sur la base des informations récupérées à partir de l'enregistrement de voyage et des autres données reçues dans le bloc 202 du processus de détermination 180Si aucune règle ne correspond au produit ou s'il y a trop de règles (par ex., plus d'une règle) qui correspondent aux produits (branche « NON » du bloc de décision 254), le sous-processus 244 peut poursuivre avec le bloc 256. [00116] Dans le bloc 256, le sous-processus 244 peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur dans la base de données du registre 184 indiquant, soit qu'aucune règle ne correspond au produit soit que trop de règles correspondent au produit. Le sous-processus 244 peut alors poursuivre avec le bloc 252 et peut terminer le processus de détermination 180. [00117] Si un nombre approprié de règles (une règle) correspond au produit (branche « OUI » du bloc de décision 254), le sous-processus 244 peut poursuivre avec le bloc 258 et peut déterminer la forme de paiement du fournisseur en utilisant les règles de paiement correspondantes. Les règles de correspondance peuvent définir la forme de paiement du fournisseur directement (par ex., les règles incluent un champ de données qui identifie la forme de paiement du fournisseur ou qui associe les règles à la forme de paiement du fournisseur) ou en fournissant un identifiant qui peut être utilisé pour déterminer la forme de paiement du fournisseur. [00118] Après avoir récupéré la forme de paiement du fournisseur ou l'identifiant, le sous- processus 244 peut transmettre une requête au système de paiement 24 demandant que le système de paiement 24 crée un champ de données dans l'enregistrement de voyage définissant la forme de paiement du vendeur au fournisseur pour le produit sélectionné. Le champ de données peut définir un paiement du vendeur au fournisseur et peut être utilisé par le système de paiement 24 pour finaliser la transaction. [00119] Dans le bloc 260, si le système de paiement 24 ne reconnaît pas la génération de la forme de paiement du fournisseur (branche « NON » du bloc de décision 260), le sous-processus 244 peut poursuivre avec le bloc 262 et peut demander au processus d'enregistrement 182 de générer un enregistrement d'erreur dans la base de données du registre 184. L'enregistrement d'erreur peut indiquer que la génération de la forme de paiement du fournisseur a échoué. Le sous-processus 244 peut alors poursuivre avec le bloc 252 et peut terminer le processus de détermination 180. 3049367 38 [00120] Si le système de paiement 24 reconnaît la création d'une forme de paiement fournisseur (branche « OUI » du bloc de décision 260), le sous-processus 244 peut poursuivre avec le bloc 264 et demander au processus d'enregistrement 182 de générer un enregistrement dans la base de données du registre 184 indiquant que la forme de paiement fournisseur a été créée avec succès pour le produit sélectionné. Le sous-processus 244 peut ensuite transmettre une réponse à la demande EDIFACT ou XML reçue à l'origine, en indiquant que la forme de paiement fournisseur a été créée avec succès. Le sous-processus 244 peut ensuite revenir au bloc 238 du processus de détermination 180. [00121] Faisant référence à nouveau à la FIG. 9, dans le bloc 238 du processus de détermination 180, le processus de détermination 180 peut déterminer si tous les produits définis dans l'enregistrement de voyage ont été analysés. Si tous les produits n'ont pas été analysés (branche « NON » du bloc de décision 238), le processus de détermination 180 peut poursuivre avec le bloc 266 pour sélectionner le produit suivant et revenir au bloc 210. Si tous les produits ont été analysés (branche « OUI » du bloc de décision 238), le module de formes de paiement 62 peut quitter le processus de détermination 180. [00122] Le processus de détermination de la forme de paiement 180 peut définir des formes de paiement dans l'enregistrement de voyage pour chaque produit dans l'itinéraire sur la base, au moins en partie, du commerçant défini par le module de détermination de commerçant 60 pour le produit. Si le vendeur est le commerçant du produit, le module de formes de paiement 62 peut ajouter, un champ de données pour la forme de paiement du vendeur à l'enregistrement de voyage définissant la forme de paiement utilisée par l'acheteur pour payer le vendeur et ajouter un champ de données pour la forme de paiement du fournisseur définissant la forme de paiement utilisée par le vendeur pour payer le fournisseur. Si le fournisseur du produit est le commerçant, le module de formes de paiement 62 peut ajouter un champ de données à l'enregistrement de voyage définissant la forme de paiement utilisée par l'acheteur pour payer le fournisseur du produit. [00123] La base de données des règles de paiement 186 peut être remplie par un tiers autorisé tel que le vendeur. La base de données de règles de paiement 186 peut ainsi être adaptée pour répondre à des exigences spécifiques pour chacun dans un groupe de vendeurs. À titre d'exemple, le système vendeur 14 peut transmettre des messages, tels que des messages EDIFACT ou XML, 3049367 39 contenant des données de règles au système OLTP 12 qui peut à son tour remplir la base de données de règles de paiement 186 sur la base du contenu des messages reçus. [00124] Dans un mode de réalisation de l'invention, la base de données des règles de paiement 186 peut contenir une liste extensible de paramètres qui fournit un ensemble de paramètres d'entrée. Chaque ensemble de paramètres d'entrée peut être associé à une forme de paiement donnée ou un identifiant de forme de paiement (par ex., un numéro d'identification) identifiant la forme de paiement. En réponse à la réception d'une demande dont les paramètres d'entrée correspondent à une ou plusieurs règles, la base de données des règles de paiement 186 peut renvoyer la forme de paiement ou l'identifiant dans une réponse. Dans certains cas, la forme de paiement peut être stockée comme un identifiant pour éviter de fournir des informations sensibles telles qu'un numéro de carte de crédit ou un numéro de compte, sous un format facile à lire. [00125] Le Tableau 9 est un exemple de règles qui peuvent être stockées dans la base de données des règles de paiement 186. Les règles indiquées le sont uniquement à titre d'exemple, et le nombre et le type de paramètres d'entrée, les types de sorties et le nombre de règles peuvent être élargis à tous types appropriés de paramètres d'entrée, de paramètres de sortie, de nombre de règles ou de types de produits. TYPE TABLEAU 9 - RÈGLES DE ENTRÉE FORMES FOUR DU FOURNISSEUR SORTIE DE MODÈLE CLIENT TYP E CC DE PAIEMENT N. POUR FOP PRODU DE FOP MAJORATION RÉDUCTION V. IT PAIEMEN T VOL * CC VIS * MI( FACTU A RE HÔTEL PMT À * * MAJ CC # 1 RÉCEPTIO N VOL * POINTS * * AF ESPÈCE DE S FIDÉLIT É 3049367 [00126] À titre d'exemple, une opération du module de formes de paiement 62 sera décrite en utilisant un scénario hypothétique. Le scénario inclut un enregistrement de voyage définissant un itinéraire qui inclut un vol fourni par Air Mauritius (IATA code MK) pour lequel une agence de voyages (c'est-à-dire, le vendeur) est le commerçant. L'acheteur utilise une carte de crédit émise par VISA® pour payer la réservation. Après avoir reçu une demande de détermination de forme de paiement pour le vol, le module de formes de paiement 62 peut déchiffrer un champ de données de l'enregistrement de voyage pour déterminer que l'agence de voyages est le commerçant pour le vol. [00127] Après avoir déterminé que l'agence de voyages est le commerçant, le module de formes de paiement 62 peut demander la création d'un champ de données de forme de paiement du vendeur dans l'enregistrement de voyage qui définit la forme de paiement du vendeur. Le champ de données de la forme de paiement du vendeur peut être associé au vol d'Air Mauritius et peut contenir le numéro de carte de crédit de l'acheteur (qui peut être masqué pour des raisons de sécurité) ou un autre identifiant de la forme de paiement du client. En réponse à la création d'un champ de données pour la forme de paiement du vendeur dans l'enregistrement de voyage, le module de formes de paiement 62 peut demander au système de détection anti-fraude 24 d'effectuer une analyse de fraude pour la carte de crédit de l'acheteur. [00128] Si le système de détection anti-fraude 26 indique qu'aucune fraude n'a été détectée sur la carte de crédit de l'acheteur, le module de formes de paiement 62 peut déterminer une forme de paiement de fournisseur basée sur les règles de paiement dans la base de données des règles de paiement 186. Le module de formes de paiement 62 peut créer un champ de données de forme de paiement du fournisseur dans l'enregistrement de voyage qui définit la forme de paiement du fournisseur et associe le champ de données de la forme de paiement du fournisseur au vol dans l'enregistrement de voyage. En appliquant les paramètres d'entrée de l'exemple de scénario aux règles définies dans le Tableau 9, la forme de paiement du fournisseur renvoyée est « FACTURE ». [00129] Après avoir déterminé la forme de paiement du vendeur, le module de forme de paiement 62 peut transmettre une requête à la base de données d'enregistrements de voyage 22 demandant que le champ de données de forme de paiement du fournisseur définisse la forme de paiement du fournisseur comme FACTURE. Une fois que la création et le remplissage de la 3049367 41 forme de paiement du fournisseur dans l'enregistrement de voyage ont été effectués avec succès, le module de formes de paiement 62 peut transmettre une réponse au système OLTP 12 indiquant que la forme de paiement a été créée avec succès dans l'enregistrement de voyage. DÉTERMINATION DES PRODUITS DÉCISIFS [00130] Dans certains cas, l'itinéraire défini par l'enregistrement de voyage peut inclure des produits de voyage procurés par différents fournisseurs. En réponse à la réception d'une demande de confirmation de réservation d'un itinéraire avec des fournisseurs multiples, le système OLTP 12 peut transmettre une demande de confirmation de réservation à chacun des systèmes fournisseurs correspondants 16. Cela peut conduire à un scénario dans lequel certaines des demandes de confirmation de réservation sont rejetées et d'autres sont confirmées par les systèmes fournisseurs respectifs 16. Dans d'autres cas, un seul fournisseur peut être capable de confirmer la réservation d'un produit, mais aucun autre si, par exemple, un des produits n'est pas disponible. [00131] Lorsqu'une demande de confirmation est rejetée, la décision de confirmer ou non d'autres produits de voyage confirmés peut dépendre de l'importance que revêt le produit rejeté pour le voyageur. Si un produit est décisif pour le voyage (c.-à-d. que le voyageur ne souhaite pas effectuer le voyage si le produit spécifique n'est pas disponible ou qu'il ne souhaite pas remplacer le produit spécifique par un produit alternatif), le système OLTP 12 peut être configuré pour annuler le voyage. L'annulation du voyage peut inclure l'annulation de réservations précédemment confirmées, et l'annulation de paiements déjà effectués. Si le produit n'est pas décisif pour le voyage (c.-à-d. que le voyageur souhaite effectuer le voyage sans le produit ou que le produit peut être remplacé par un produit alternatif), le système OLTP 12 peut être configuré pour confirmer les réservations des produits restant dans l'itinéraire. [00132] Faisant maintenant référence à la FIG. 12, le module de produits décisifs 64 peut inclure un processus de détermination des produits décisifs 270, une base de données de règles applicables aux produits décisifs 272 et une base de données de règles de séquence 274. La base de données de règles applicables aux produits décisifs 272 et la base de données de règles de séquence 274 peuvent inclure des règles qui permettent au processus de détermination 270 de déterminer les produits décisifs dans un itinéraire et l'ordre selon lequel les produits réservés doivent être confirmés. Le module de produits décisifs 64 peut aussi inclure un processus d'enregistrement 276 qui enregistre les événements (par ex., une confirmation de réservation et 3049367 42 des décisions d'annulation) dans une base de données du registres 278. Le processus de détermination 270 peut communiquer avec le module de confirmation de réservation 70, le module d'émission de contrat 72 et le module de mise en file d'attente 74. Le module d'émission de contrat 72 peut gérer l'émission des contrats entre l'acheteur ou le vendeur et le fournisseur. Le module de mise en file d'attente 74 peut mettre des enregistrements de voyage en file d'attente lorsqu'ils nécessitent une intervention manuelle ou lorsqu'ils doivent être mis de côté pendant que le traitement de la transaction est interrompu pour une autre raison, telle que l'attente des résultats d'une détection de fraude. [00133] En permettant au système OLTP 12 de déterminer quels produits sont décisifs pour le voyageur, le module de produits décisifs 64 peut permettre au système OLTP 12 d'éviter l'annulation automatique des réservations qui incluent un produit ne pouvant pas être confirmé. Le système OLTP 12 peut ainsi empêcher des pertes de revenus inutiles au vendeur et il peut prévenir le désagrément pour les voyageurs de devoir reconfirmer les itinéraires, sil'itinéraire peut être récupéré. En permettant au système OLTP 12 d'identifier et d'annuler les réservations de produits dans des itinéraires qui ne sont pas récupérables, le module de produits décisifs 64 peut aussi permettre aux fournisseurs de produits de réduire l'inventaire inutilisé de réservations qui ne sont pas confirmées parce que le produit décisif dans l'itinéraire est indisponible. [00134] Les règles applicables aux produits décisifs et les règles de séquence de confirmation de réservation peuvent être configurées pour déterminer l'importance du produit en fonction des caractéristiques du produit lui-même ainsi que des autres produits dans l'itinéraire. À titre d'exemple, conserver une réservation d'hôtel quand un vol ne peut pas être confirmé n'a pas de sens. En revanche, l'impossibilité de confirmer une attraction (par ex., une représentation théâtrale) n'est pas une raison pour annuler une réservation d'hôtel qui fait partie d'un itinéraire pour un voyage d'affaires. Cependant l'impossibilité de confirmer la réservation d'une attraction qui représente le but principal du voyage (par ex., un voyage pour assister à un événement sportif) peut fournir une raison d'annuler des réservations d'hôtel et de vol. Ainsi, des règles complexes peuvent être requises pour déterminer si la réservation doit être maintenue ou annulée sur la base, à la fois du but du voyage et du type de produit. C'est-à-dire, qu'un produit peut être jugé décisif pour un itinéraire s'il est insensé de confirmer tout produit restant dans l'itinéraire, lorsque le produit en question ne peut pas être confirmé. 3049367 43 [00135] La base de données de règles applicables aux produits décisifs 272 peut maintenir un ensemble de règles qui sont configurables par le vendeur et qui identifient si un produit est décisif ou non, sur la base des paramètres d'entrée. Ces paramètres d'entrée peuvent inclure des caractéristiques de produit et des caractéristiques de vendeur. Des exemples de caractéristiques de produit qui peuvent être utilisées comme des paramètres d'entrée incluent le fait que le produit fasse partie d'un itinéraire vendu comme un forfait (par ex., un forfait voyage tout compris dans une station de vacances), le type de produit (par ex., vol, hôtel, voiture de location, etc.), l'identité du fournisseur du produit ou du pourvoyeur du produit (par ex., le transporteur, la chaîne d'hôtel ou l'entreprise de location de voitures) ou toute autre caractéristique pertinente du produit. [00136] Des exemples de caractéristiques de vendeur qui peuvent être utilisées comme paramètres d'entrée incluent un code de société qui identifie le vendeur, le marché (par ex., le Brésil, l'Argentine, etc.) sur lequel la vente a été effectuée, le point de vente du produit (par ex., le lieu du bureau spécifique où la vente a été effectuée). Les règles correspondant aux paramètres d'entrée peuvent définir un résultat qui identifie si le produit est décisif ou non décisif pour l'itinéraire. Le processus de détermination 270 peut ainsi déterminer, si un produit est décisif sur la base du résultat produit par la règle qui correspond aux paramètres d'entrée. Le Tableau 10 est un exemple des règles applicables aux produits décisifs qui peuvent être stockées dans la base de données 272 des règles applicables aux produits décisifs. [00137] Le rang supérieur du Tableau 10 peut illustrer une règle relativement large qui définit une chambre d'hôtel (TYPE = HTL) vendue par un vendeur spécifique (CODE ENTR= B2W) au Brésil (MARCHÉ = BR) comme produit non décisif. Cela peut être dû à la politique d'un vendeur, selon laquelle les chambres d'hôtel vendues au Brésil sont normalement jugées fongibles parce que des hôtels alternatifs qui satisfont le voyageur peuvent typiquement être trouvés. 3049367 44 FORFAIT TABLEAU - RÈGLES APPLICABLES ENTRÉE CODE AUX DÉCISIFS SORTIE CARACTÉRISTIQUES DU PRODUIT ENTR. CARACTÉRISTIQUES DU POS 10 POURVOYEUR PRODUITS TYPE VENDEUR MARCHÉ * HTL * B2W BR * NON- DÉC. DIS-1 HTL DISNEY B2W BR * DÉCISIF * VOL B2W BR * DÉCISIF * TRAIN * B2W BR * NON DÉC. [00138] Le second rang à partir du haut peut illustrer une règle relativement plus restreinte qui présente un cas spécifique où l'hôtel peut ne pas être fongible. Cette règle inclut des paramètres d'entrée qui exigent que le produit fasse partie d'un forfait voyage spécifique (FORFAIT = DIS I, par ex., un week-end à DISNEY^14) et une chambre d'hôtel (TYPE = HTL) qui est fournie par un pourvoyeur spécifique (POURVOYEUR = DISNEY®) et qui est vendue par un vendeur spécifique (CODE ENTR. = B2W) au Brésil (MARCHÉ = BR). Un produit dans un inventaire qui correspond à ces paramètres d'entrée peut être jugé comme étant un produit décisif par le vendeur parce que, dans ce cas spécifique, être logé dans une chambre au coeur du parc d'attractions est vraisemblablement jugé comme un élément important pour le voyageur. Des rangs additionnels du Tableau 10 montrent que le vendeur a mis en oeuvre une règle relativement large qui définit un vol comme un élément décisif de l'itinéraire et une autre règle relativement large qui définit que le voyage en train n'est pas décisif. [00139] La FIG. 13 représente un organigramme d'un mode de réalisation d'un processus de détermination 270 qui peut être mis en oeuvre par le module de produits décisifs 64. Dans le bloc 282, le processus de détermination 270 peut extraire des données de produits à partir de l'enregistrement de voyage définissant l'itinéraire en cours de confirmation. Les données de ce produit peuvent inclure des caractéristiques du produit et du vendeur et peuvent être utilisées pour définir les paramètres d'entrée pour les règles applicables aux produits décisifs. 3049367 [00140] Dans le bloc 284, le processus de détermination 270 peut interroger la base de données des règles applicables aux produits décisifs 272 pour trouver une ou plusieurs règles correspondant aux paramètres d'entrée extraits de l'enregistrement de voyage. Dans un mode de réalisation de l'invention, un moteur de règles peut déterminer la règle la plus applicable sur la base d'une pondération attribuée à chaque paramètre d'entrée. Cette sélection de règles et cette attribution de pondération pour déterminer la meilleure règle peuvent se faire dans le processus de détermination 270 ou à l'extérieur du processus de détermination 270. Quel que soit le mode de sélection des règles, la base de données des produits décisifs 272 peut déterminer la règle ou plusieurs règles qui correspondent aux paramètres d'entrée et transmettre une réponse au processus de détermination 270 qui contient soit les règles correspondantes, soit les données indicatives du résultat produit par la règle, par ex., que le produit soit décisif ou non. [00141] À la réception de la réponse, le processus de détermination 270 peut demander au processus d'enregistrement 276 de signaler le produit comme décisif ou non décisif dans la base de données du registre 278, le cas échéant. Le processus de détermination 270 peut signaler le produit, par exemple, en stockant les données dans l'enregistrement de voyage et en indiquant si le produit est décisif ou non décisif. Si la base de données des règles applicables aux produits décisifs 272 ne peut identifier une règle correspondante, le processus de détermination 270 peut fixer le degré d'importance du produit à une valeur par défaut. Dans un mode de réalisation de l'invention, cette valeur par défaut peut être « décisive ». Si l'importance du produit est fixée par défaut, le processus d'enregistrement 276 peut signaler le produit pour indiquer que la valeur a été déterminée par défaut. [00142] Dans le bloc 286, le processus de détermination 270 peut interroger la base de données des règles de séquence 274. Les règles de séquence peuvent déterminer l'ordre à respecter pour confirmer les produits dans l'itinéraire en fonction, au moins en partie, du fait que le produit a été signalé comme décisif. Les règles de séquence peuvent être configurées pour optimiser l'ordre de confirmation des produits afin de maintenir un enregistrement de voyage viable pendant le processus de confirmation, ce qui peut faciliter l'annulation du processus de confirmation, si un problème était rencontré. Dans ce but, les règles de séquence peuvent être configurées pour classer tous les produits signalés comme décisifs dans l'itinéraire devant tous les produits classés non décisifs de l'itinéraire. Ce classement peut amener le système OLTP 12 à 3049367 46 confirmer la réservation de tous les produits décisifs dans un itinéraire avant d'essayer de confirmer les produits non décisifs. [00143] Si le système OLTP 12 est incapable de confirmer la réservation d'un produit décisif, il n'y a peut-être aucune raison de continuer le processus de confirmation de réservation. Ainsi, le système OLTP 12 peut être configuré pour attendre que la réservation de tous les produits décisifs soit confirmée avant de confirmer la réservation des produits non décisifs. Une logique similaire peut être appliquée à l'émission des contrats. C'est-à-dire, que le système OLTP 12 peut attendre que les contrats de tous les produits décisifs d'un itinéraire soient établis avant d'essayer d'établir les contrats pour tout produit non décisif. [00144] La FIG. 14 représente un organigramme du processus de confirmation de réservation 290 qui peut être mis en oeuvre par le module des produits décisifs 64 et/ou le module de confirmation de réservation 70. Dans le bloc 292, le processus de confirmation 290 peut sélectionner un produit à partir de l'itinéraire en cours de confirmation. Le produit peut être sélectionné sur la base de l'ordre de séquençage déterminé par le module des produits décisifs 64, de sorte que le produit dont le classement est le plus élevé dans l'itinéraire soit sélectionné en premier. Le processus de confirmation 290 peut alors poursuivre avec le bloc 294 et transmettre une demande de confirmation du produit au système fournisseur 16, au système pourvoyeur 18, ou à tout autre système pertinent tel qu'un système informatique de réservation . [00145] Si la réservation n'est pas confirmée (branche « NON » du bloc de décision 296), le processus de confirmation 290 peut poursuivre avec le bloc 298. Dans le bloc 298, le processus de confirmation 290 peut déterminer si le produit sélectionné est un produit décisif. Cette détermination peut être faite par exemple, en demandant au processus d'enregistrement 276 d'interroger la base de données du registre 278 ou sur la base des données indiquant si le produit est décisif ou non décisif dans l'enregistrement de voyage. Si le produit sélectionné est non décisif (branche « NON » du bloc de décision 298), le processus de confirmation 290 peut poursuivre avec le bloc 300 et il peut demander au processus d'enregistrement 276 d'enregistrer une alerte dans la base de données du registre 278. L'alerte peut indiquer que le produit non décisif sélectionné n'a pas été réservé et que le voyageur ou le vendeur souhaite peut-être choisir un produit de remplacement. Le processus de confirmation peut alors poursuivre avec le bloc 302. 3049367 47 [00146] Si le produit sélectionné est un produit décisif (branche « OUI » du bloc de décision 298), le processus de confirmation 290 peut poursuivre avec le bloc 304. Dans le bloc 304, le processus de confirmation peut annuler toute confirmation antérieure ; il peut annuler tout paiement correspondant et annuler la réservation. À cette fin, le processus de confirmation 290 peut demander au processus d'enregistrement 276 de fournir une liste des confirmations enregistrées dans la base de données de registres 278. Le processus de confirmation 290 peut ensuite annuler chaque réservation confirmée antérieurement dans l'ordre inverse de leur confirmation. Une fois que toutes les réservations confirmées ont été annulées, le processus de confirmation 290 peut annuler les paiements et la réservation. L'annulation de la réservation peut inclure par exemple, la suppression de l'enregistrement de voyage de la base de données d'enregistrements de voyage 22. [00147] Si la réservation et confirmée (branche « OUI » du bloc de décision 296), le processus de confirmation 290 peut avancer au bloc 306 et il peut demander au processus d'enregistrement 276 d'enregistrer une confirmation dans la base de données du registre 278. La confirmation peut aussi être enregistrée en stockant, dans l'enregistrement de voyage, un numéro de confirmation reçu du système de réservation. Dans les deux cas, le processus 290 peut poursuivre avec le bloc 302. [00148] Dans le bloc 302, le processus de confirmation 290 peut déterminer si le produit sélectionné est le dernier produit de l'itinéraire, c.-à-d., s'il reste un produit qui n'a pas encore été traité, dans l'itinéraire. Si le produit sélectionné n'est pas le dernier produit dans l'itinéraire (branche « NON » du bloc de décision 302), le processus de confirmation 290 peut poursuivre avec le bloc 308, sélectionner le produit suivant dans la séquence et revenir au bloc 294. Si le produit sélectionné est le dernier produit dans l'itinéraire (branche « OUI » du bloc de décision 302), le processus de confirmation 290 peut poursuivre avec le bloc 310. [00149] Dans le bloc 310, le processus de confirmation 290 peut déterminer si des alertes ont été enregistrées dans la base de données du registre 278. Si des alertes ont été enregistrées (branche « OUI » du bloc de décision 310), le processus de confirmation 290 peut poursuivre avec le bloc 312 et il peut demander au module de file d'attente 74 de placer l'enregistrement de voyage en file d'attente pour traitement ultérieur. Ce traitement peut inclure, par exemple, la fourniture d'une indication au voyageur ou au vendeur qu'un produit non décisif n'a pas été confirmé. Cette indication peut amener le voyageur ou le vendeur à sélectionner un produit 3049367 48 alternatif. Si aucune alerte n'a été enregistrée (branche « NON » du bloc de décision 310), le processus de confirmation 290 peut prendre fin. [00150] La FIG. 15 représente un organigramme du processus de confirmation de l'émission d'un contrat 320 (par ex., l'émission d'un billet), qui peut être mis en oeuvre par le module de produits décisifs 64 et/ou le module d'émission de contrat 72. Dans le bloc 322, le processus de confirmation 320 peut sélectionner un produit à partir de l'itinéraire. Le produit peut être sélectionné selon l'ordre de séquençage, de sorte que le produit classé au plus haut niveau dans l'itinéraire, pour lequel l'émission d'un contrat n'a pas été demandée, est sélectionné. Le processus de confirmation 320 peut poursuivre avec le bloc 324 et transmettre une demande d'émission de contrat pour le produit sélectionné. La demande d'émission peut être transmise, par exemple, à un système de documents électroniques du fournisseur, du pourvoyeur ou à un système informatique de réservation. [00151] Si l'émission du contrat pour le produit n'a pas été confirmée (branche « NON» du bloc de décision 326), le processus de confirmation 320 peut poursuivre avec le bloc 328. Dans le bloc 328, le processus de confirmation 320 peut déterminer si le produit sélectionné est un produit décisif. Si le produit sélectionné n'est pas décisif (branche « NON » du bloc de décision 328), le processus de confirmation 320 peut poursuivre avec le bloc 330 et peut demander au processus d'enregistrement 276 d'enregistrer une alerte dans la base de données du registre 278. L'alerte peut indiquer qu'un contrat n'a pas été émis pour le produit sélectionné et que le voyageur ou le vendeur peut souhaiter choisir un produit de remplacement. Le processus de confirmation 320 peut alors poursuivre avec le bloc 332. [00152] Si le produit sélectionné et un produit décisif (branche « OUI »du bloc de décision 328), le processus de confirmation 320 peut poursuivre avec le bloc 334. Dans le bloc 334, le processus de confirmation 320 peut annuler tout contrat émis précédemment pour des produits dans l'itinéraire, et peut poursuivre avec le bloc 335. Dans le bloc 335, le processus de confirmation 320 peut annuler tout paiement effectué et/ou autorisation de paiement pour des produits de voyage dans l'itinéraire. Le processus de confirmation 320 peut alors poursuivre avec le bloc 336, annuler toute confirmation de réservation antérieure et annuler la réservation. Le processus de confirmation 320 peut annuler les contrats émis et les réservations confirmées, dans l'ordre inverse de celui dans lequel ils ont été émis ou confirmés. Une fois que toutes les réservations confirmées, les paiements et/ou les autorisations de paiement ont été annulés, le 3049367 49 processus de confirmation peut annuler la réservation, par exemple, en supprimant l'enregistrement de voyage dans la base de données d'enregistrements de voyage 22. [00153] Si l'émission du contrat est confirmée (branche « OUI » du bloc de décision 326), le processus de confirmation 320 peut poursuivre avec le bloc 338, demander au processus d'enregistrement 276 d'enregistrer la confirmation dans la base de données du registre 278 et poursuivre avec le bloc 332. Dans le bloc 332, le processus de confirmation 320 peut déterminer si le produit sélectionné est le dernier produit dans l'itinéraire. Si le produit sélectionné n'est pas le dernier produit dans l'itinéraire (branche « NON » du bloc de décision 332), le processus de confirmation 320 peut avancer au bloc 340, il peut sélectionner le produit suivant dans la séquence et revenir au bloc 324. Si le produit sélectionné est le dernier produit dans l'itinéraire (branche « OUI » du bloc de décision 332), le processus de confirmation 320 peut poursuivre avec le bloc 342. [00154] Dans le bloc 342, le processus de confirmation 320 peut déterminer si des alertes ont été enregistrées dans la base de données du registre 278. Si des alertes ont été enregistrées (branche « OUI » du bloc de décision 342), le processus de confirmation 320 peut poursuivre avec le bloc 344 et mettre l'enregistrement de voyage en file d'attente pour un traitement ultérieur. Ce traitement peut inclure, par exemple, d'annuler la confirmation de réservation du produit responsable de l'alerte et de notifier le voyageur ou le vendeur qu'un contrat n'a pu être émis pour le produit non décisif, de sorte que le voyageur ou le vendeur puisse sélectionner un produit alternatif. Si aucune alerte n'a été enregistrée (branche «NON » du bloc de décision 342), le processus de confirmation 320 peut prendre fin. [00155] Le Tableau 11 est un exemple d'un ensemble de règles applicables aux produits décisif utilisées dans les exemples suivants dans le but d'illustrer le fonctionnement du module de produits décisifs 64. 3049367 FORFAIT TABLEAU - RÈGLES APPLICABLES ENTRÉE CODE AUX DÉCISIFS SORTIE CARACTÉRISTIQUES DU PRODUIT ENTR. CARACTÉRISTIQUES DU POS 11 POURVOYEUR PRODUITS TYPE VENDEUR MARCHÉ * VOL * B2W * * DÉCISIF * HTL * B2W * * DÉCISIF * AUTO * B2W * NON DÉC. [00156] À titre d'exemple, le mode d'opération du module de produits décisifs 64 est décrit en utilisant un scénario hypothétique dans lequel un voyageur réserve un voyage à Miami. L'exemple d'itinéraire inclut un vol, un hôtel et une location de voiture. Les données de produits pour l'itinéraire peuvent être obtenues en interrogeant la base de données d'enregistrements de voyage 22 pour trouver l'enregistrement de voyage correspondant aux voyages réservé. Le processus de détermination 270 peut analyser le vol en interrogeant la base de données de règles de produit décisif 272 en utilisant les paramètres d'entrée suivants qui ont peut-être été extraits de l'enregistrement de voyage. Forfait : (aucun), type de produit : VOL, code pourvoyeur : AF, Code entreprise : B2W, Marché : FR et point de vente : PARB221DU. [00157] La base de données de règles de produit décisif 272 peut identifier la règle applicable (par exemple, la règle définie par le rang supérieur du Tableau 11) et il peut renvoyer le résultat au processus de détermination 270. Dans le présent exemple, l'assortiment des paramètres d'entrée mentionnés ci-dessus avec les règles définies par les règles exemplaires de produit décisif du Tableau 11 indique que le vol est défini comme un produit décisif par le vendeur B2W. [00158] Le processus de détermination 270 peut analyser la réservation d'hôtel en interrogeant la base de données de produits décisifs 272 avec les paramètres suivants qui peuvent avoir été extraits de l'enregistrement de voyage : Forfait : (aucun), Type de produit : HTL, Code pourvoyeur : IHG, Code entreprise : B2W, marché : FR et Point de vente : PARB22I DU. La base de données de règles de produit décisif 272 peut identifier la règle applicable (par ex., la règle définie par le rang du milieu dans le Tableau 11) et renvoyer le résultat au processus de 3049367 51 détermination 270. Dans le présent exemple, la correspondance des paramètres d'entrée mentionnés ci-dessus avec les règles définies par les règles de produit décisif exemplaires du Tableau 11 indique que l'hôtel est défini comme produit décisif par le vendeur B2W. [00159] Le processus de détermination 270 peut analyser la réservation de location de voiture en interrogeant la base de données de règles de produit décisif 272 avec les paramètres suivants qui ont peut-être été extraits de l'enregistrement de voyage : Forfait : (aucun), Type de produit : VOITURE, Code pourvoyeur : AVIS®, Code entreprise : B2W, Marché : FR et Point de vente : PARB221DU. La base de données de règles de produit décisif 272 peut identifier la règle applicable (par ex., la règle définie par le rang inférieur du tableau 11) et renvoyer le résultat au processus de détermination 270. Dans le présent exemple, la correspondance des paramètres d'entrée susmentionnés avec les règles définies par l'exemple des règles de produit décisif du Tableau 11 indique que la location de voiture est définie comme produit non décisif par le vendeur B2W. [00160] Sur la base des résultats de la détermination des produits décisifs, le processus de détermination 270 peut essayer de confirmer les produits décisifs, par ex. la réservation de vol et la réservation d'hôtel, avant d'essayer de confirmer la location de voiture. Après avoir reçu confirmation du vol et de l'hôtel en provenance des systèmes de réservation respectifs, le processus de détermination 270 peut stocker les numéros de confirmation dans l'enregistrement de voyage. [00161] Le processus de détermination 270 peut ensuite essayer de confirmer la location de voiture. Si le système de réservation de location de voiture ne confirme pas la location de la voiture, le processus de détermination 270 peut déterminer s'il est nécessaire d'annuler des réservations pour tout autre produit dans l'itinéraire. Parce que la location de voitures est définie comme un produit non décisif par le vendeur, le processus de confirmation de réservation peut continuer et les confirmations du vol et de l'hôtel restent intactes. [00162] Le processus de détermination 270 peut ensuite établir un contrat pour le vol réservé (par ex., en amenant le système billettique à émettre un billet électronique) et pour l'hôtel. L'enregistrement de voyage peut être mis en file d'attente en raison de l'échec de confirmation d'un des produits dans l'itinéraire. La mise en file d'attente de l'enregistrement de voyage peut causer la transmission d'une alerte au système du vendeur pour que le vendeur puisse prendre une mesure proactive et corrective concernant le remplacement du produit location de voiture. 3049367 52 [00163] Pour donner un autre exemple décrivant le mode de fonctionnement du module de produits décisifs 64, un scénario hypothétique inclut un voyageur qui réserve un voyage vers Miami dont l'itinéraire inclut un vol, un hôtel et une location de voiture. Comme pour l'exemple précédent, l'application des règles du Tableau 11 indique que le vol et l'hôtel sont des produits décisifs et que la voiture n'est pas un produit décisif. Sur la base des résultats de la détermination de produits décisifs, le processus de détermination 270 peut essayer de confirmer les produits décisifs, par ex., la réservation du vol et la réservation de l'hôtel, avant d'essayer de confirmer la location de voiture. Comme précédemment, la réservation du vol est confirmée. Cependant, dans cet exemple, le système de réservation de l'hôtel ne peut confirmer la réservation d'hôtel. Parce que l'hôtel est défini comme produit décisif, le processus de détermination 270 détermine que l'itinéraire défini par l'enregistrement de voyage n'est plus viable. C'est-à-dire, que sans l'hôtel, le reste de l'itinéraire n'a plus de valeur pour le voyageur. Ainsi, en réponse à l'échec de confirmation de l'hôtel, le processus de détermination 270 peut annuler la réservation du vol et transmettre une alerte au système du vendeur indiquant que l'itinéraire a été annulé. [00164] En identifiant les produits décisifs d'un itinéraire à l'aide des règles stockées dans la base de données de règles produit décisif 272, le module de produits décisifs 64 peut permettre aux vendeurs (par ex., les agences de voyages en ligne) de définir des règles flexibles de façon dynamique. La base de données des règles de produit décisif 272 peut permettre aux vendeurs de définir quels produits sont des produits décisifs dans un itinéraire sur la base des caractéristiques de l'itinéraire sélectionné, tels que le forfait, le marché, le fournisseur ou le pourvoyeur. La base de données de règles de produit décisif 272 peut permettre que les règles soient configurées pour différents types de produits tels que des vols, des hôtels, des locations de voitures, des attractions, des croisières et des assurances de voyage. Les produits peuvent être signalés comme décisifs ou non décisifs dans la base de données du registre 278 de façon à faciliter les processus suivants, tels que l'annulation ou la modification d'un enregistrement de voyage. [00165] La séquence des produits dans un itinéraire en utilisant les règles stockées dans la base de données de règles de séquence 274 par le vendeur, le module de produits décisifs 64 peut permettre au vendeur d'avoir un contrôle sur la séquence des actions afin de préserver une réservation viable. Si un produit décisif ne peut pas être confirmé, des mécanismes d'inversion peuvent être déclenchés afin de nettoyer la réservation et d'annuler des paiements entre l'acheteur et l'agence de voyages en ligne. 3049367 53 PRODUITS RÉCUPÉRABLES [00166] Dans certains cas, une analyse de fraude peut être effectuée sur la forme de paiement du client. Si le résultat de l'analyse de fraude recommande que la forme de paiement du client soit soumise à un autre type d'analyse de fraude (par ex., un examen manuel par un spécialiste de la gestion de fraude), le résultat final de l'analyse de fraude pour la forme de paiement du client peut ne pas être disponible pendant un laps de temps (par ex., quelques heures ou quelques jours). Afin de préserver la disponibilité et les prix des produits de voyage dans l'itinéraire pendant cette période de temps, le système OLTP 12 peut confirmer la réservation tous les produits ou de certains d'entre eux et peut confirmer la réservation avant que le statut final de l'analyse de fraude ne soit connu. Afin de gérer l'exposition du vendeur aux pénalités en cas d'annulation des produits après expiration d'une période d'annulation permise, le système OLTP 12 peut identifier quels produits peuvent être confirmés et émis par rapport aux fournisseurs dont la responsabilité financière est limitée en cas d'annulation, si le statut final de fraude indique la présence d'une fraude. [00167] Faisant maintenant référence à la FIG. 16, le module 66 de produits récupérables peut inclure un processus de détermination de produits récupérables qui accèdent à une base de données de règles de récupération ou à la base de données de règles de récupération 352 et à un processus d'enregistrement 354 qui conserve une base de données du registre de récupération 356. Le processus de détermination 350 peut recevoir des données de la base de données d'inventaire 20 qui définissent la disponibilité des produits. Il peut extraire les données de la base de données d'enregistrements de voyage 22 qui définissent les caractéristiques des produits et récupérer les données du système de détection anti-fraude 26 qui définissent le statut d'une détection de fraude pour la forme de paiement du client. Le processus de détermination 350 peut aussi communiquer avec le système de paiement 24 pour déterminer les pénalités, avec le module de confirmation de réservation 70 pour confirmer des produits de voyage et avec le module de mise en file d'attente 74 pour mettre en file d'attente des enregistrements de voyage liés à des transactions en attente du résultat de la détection de fraude. [00168] Si le système de détection anti-fraude 26 indique qu'une forme de paiement utilisée par l'acheteur est potentiellement frauduleuse, une analyse supplémentaire de fraude telle qu'une revue manuelle peut-être commandée afin de déterminer de façon conclusive si la transaction est frauduleuse. En raison de la durée attendue de l'examen il peut y avoir un besoin de préserver la 3049367 54 disponibilité et le prix d'un ou de plusieurs produits de l'itinéraire jusqu'à ce que les résultats de l'examen manuel soient connus, en confirmant la réservation des produits avant l'achèvement de l'examen manuel. Cependant, dans certains cas, la confirmation d'un produit peut entraîner la responsabilité du vendeur envers le fournisseur, si le produit est annulé ultérieurement parce que l'examen manuel indique que la transaction est frauduleuse. [00169] Afin de limiter cette responsabilité, le processus de détermination 350 peut, si un examen manuel est commandé, déterminer la responsabilité financière potentielle du vendeur pour un ou plusieurs des produits, si les produits sont confirmés avant que le statut final de fraude ne soit déterminé. Des produits qui peuvent être confirmés et annulés ultérieurement sont jugés être des « produits récupérables », si la transaction s'avère être frauduleuse sans que la responsabilité financière incombe au vendeur, ou si la responsabilité financière encourue par le vendeur est en dessous d'un seuil prédéterminé. Un produit récupérable est un produit qui peut être confirmé si la réponse du module de fraude indique que la transaction doit être testée, sans que le vendeur encoure une responsabilité financière inacceptable. Par exemple, un produit peut être jugé récupérable si les termes et conditions d'achat du produit allouent suffisamment de temps pour demander un remboursement sans encourir une pénalité après réception des résultats du l'examen manuel. [00170] Faisant maintenant référence aux FIGS 17 à 19, la FIG. 17 représente un organigramme d'un mode de réalisation d'un processus de détermination de produits récupérables 350 qui peut être mis en oeuvre par le module 66 de produits récupérables et les FIGS 18 et 19 sont un exemple d'échange de message qui peut se dérouler entre le processus de détermination 350, la base de données d'inventaire 20, la base de données d'enregistrements de voyage 22, le système de détection anti-fraude 26 et la base de données de règles de récupération 352. [00171] Dans le bloc 362, le processus de détermination 350 peut transmettre une interrogation 364 au système de détection anti-fraude 26. Le système de détection anti-fraude 26 peut déterminer la probabilité que la transaction soit frauduleuse et peut transmettre une réponse 366 au processus de détermination 350. Si la réponse 366 indique que le système de détection anti-fraude 26 a détecté une fraude (branche « refusé » du bloc de décision 368), le processus de détermination 350 peut poursuivre avec le bloc 370 et refuser la transaction. Si la transaction est refusée, une autorisation pour facturer le coût de la transaction à la forme de 3049367 paiement peut être annulée. Si la réponse 366 indique qu'aucune fraude n'a été détectée (branche « approuvé » du bloc de décision 368), le processus de détermination 350 peut poursuivre avec le bloc 372 et demander au module de confirmation de réservation 70 de confirmer les produits de l'itinéraire en cours d'achat. Si la réponse 366 indique que l'analyse de fraude n'était pas conclusive (branche « test » du bloc de décision 368), le processus de détermination 350 peut poursuivre avec le bloc 374 et demander une intervention manuelle sur la transaction. [00172] Si un examen manuel est initié, le processus de détermination 350 peut commencer à identifier quels produits de l'itinéraire sont récupérables en procédant au bloc 376. Dans le bloc 376, le processus de détermination 350 peut transmettre des interrogations 378, 380 et 382 à la base de données d'enregistrements de voyage 22, à la base de données de règles de récupération 352 et à la base de données d'inventaire 20, respectivement. La décision de transmettre l'interrogation 382 à la base de données d'inventaire 20 peut dépendre des règles récupérées à partir de la base de données de règles de récupération 352. C'est-à-dire, que si les règles de récupération identifiées dans la base de données de règles de récupération 352 ne dépendent pas de la disponibilité du produit dans l'itinéraire, le processus de détermination 350 peut ne pas avoir besoin d'interroger la base de données de l'inventaire. [00173] En réponse à la réception de la requête 378, la base de données d'enregistrements de voyage 22 peut transmettre une réponse 384 au processus de détermination 350 qui inclut l'enregistrement de voyage associé à la transaction en cours de traitement. En réponse à la réception de l'interrogation 380, la base de données des règles de récupération 352 peut transmettre une réponse 386 définissant les règles qui gouvernent l'annulation de confirmation pour chacun des produits dans l'itinéraire. En réponse à la réception de l'interrogation 382, la base de données d'inventaire 20 peut transmettre une réponse 388 définissant la disponibilité pour chacun des produits de l'itinéraire. [00174] Une fois que les interrogations des bases de données ont été complétées, le processus de détermination 350 peut poursuivre avec le bloc 390 et identifier quels produits de l'itinéraire sont récupérables. Le processus de détermination 350 peut déterminer les paramètres qui sont pertinents pour les règles de récupération sur la base de l'enregistrement de voyage renvoyé par la réponse 384. Les paramètres définis par l'enregistrement de voyage peuvent inclure le point de vente du produit, le type, le prix, le fournisseur et le pourvoyeur du produit, le niveau de fidélité du voyageur et le prix total de l'itinéraire. Des paramètres additionnels relatifs aux règles de 3049367 56 récupération peuvent inclure une disponibilité pour chaque produit déterminé à partir de la réponse 388. [00175] Les règles de récupération peuvent définir, pour chaque produit dans l'itinéraire, un temps minimum restant avant qu'un contrat doive être émis pour les produits définis dans un PNR (par ex., des vols stockés dans une base de données PNR d'un GDS), un nombre minimum de jours avant la date d'utilisation du produit (par ex., la date de départ pour un vol), un temps minimum avant la fin de la journée, le montant maximum de pénalités acceptable si la confirmation de la réservation est annulée et un temps restant minimum avant d'encourir une pénalité pour des produits non définis par le PNR (par ex., des chambres d'hôtel ou des voitures de location). [00176] Les règles de récupération appliquées par le processus de détermination 350 peuvent varier en fonction des caractéristiques de la transaction. Par exemple, une transaction pour confirmer un itinéraire dont la valeur est relativement élevée pour le vendeur peut être soumise à des règles différentes que celles qui seraient appliquées à une transaction pour confirmer un itinéraire dont la valeur est relativement faible pour le vendeur. Les règles peuvent aussi varier selon le pays, la région ou la ville du point de vente. La quantité de temps restant entre la confirmation et l'utilisation du produit peut aussi déterminer si le produit ou l'itinéraire sont récupérables. Par exemple, un produit peut être jugé irrécupérable, s'il est peu probable que l'analyse de fraude finale soit terminée avant d'atteindre le moment limite pour éviter une pénalité. [00177] Les règles peuvent aussi varier sur la base de combinaisons de paramètres, par exemple, le statut du passager, la disponibilité du produit ou une catégorie de service associée au produit. Par exemple, si la disponibilité d'un produit est limitée pour un voyageur titulaire d'une carte Or (Gold card), un produit qui serait autrement jugé irrécupérable peut-être défini comme récupérable. Cette approche flexible pour définir les produits récupérables peut permettre au produit d'être confirmé même s'il y a une pénalité pour l'annulation ou un temps insuffisant pour effectuer l'examen manuel avant que la pénalité d'annulation ne soit encourue. Les règles peuvent ainsi garantir que la disponibilité des produits qui auraient autrement été jugés irrécupérables, soit maintenue pour un voyageur dont le statut est supérieur à la normale (par ex., un voyageur titulaire d'une carte Or (Gold card). Un vendeur peut définir des règles qui offrent un traitement préférentiel à certains voyageurs, par exemple, sur la base d'une politique selon 3049367 57 laquelle le vendeur préférerait encourir une pénalité plutôt que de nuire à une relation commerciale avec un client important. [00178] Dans des cas spécifiques, si aucune règle spécifique concernant un produit n'est définie dans la base de données des règles de récupération, les règles de récupération peuvent inclure des règles par défaut. Comme exemple de règle par défaut, une chambre dans un hôtel qui n'affiche aucune condition d'évaluation de la pénalité peut être traitée comme irrécupérable, si la réservation de la chambre intervient après 18 heures le jour avant le jour d'arrivée. Dans d'autres cas, la règle par défaut peut être que tout produit qui n'a pas de règle définie dans la base de données de règles de récupération soit traité comme irrécupérable. [00179] Une fois que les règles applicables de récupération ont été déterminées, le processus de détermination 350 peut déterminer si chaque produit dans l'enregistrement de voyage est récupérable. Cette détermination peut inclure, pour chaque durée limite applicable, de déterminer si la durée restante est plus importante que la durée limite minimum définie par les règles de récupération. Par exemple, le processus de détermination 350 peut déterminer si la durée restante dans le jour ouvré est plus importante que la durée minimum requise par les règles de récupération. Le processus de détermination 350 peut aussi déterminer si la durée avant la date d'utilisation du produit est plus importante que la durée avant la date d'utilisation du produit, requise par les règles de récupération. Le processus de détermination 350 peut aussi déterminer si le produit est jugé récupérable, même si la confirmation du produit exposait le vendeur à certaines pénalités. Si toutes les conditions définies par les règles de récupération sont réunies, le produit peut être jugé récupérable. [00180] Pendant l'analyse, le processus d'enregistrement 354 peut signaler chaque résultat d'analyse de produit et stocker les paramètres utilisés pour identifier le potentiel de récupération du produit (par ex., le délai, la disponibilité, la durée minimum, la date minimum, la durée avant expiration) dans la base de données de registre de récupération 356. Lorsque le processus de détermination 350 rencontre un problème qui l'empêche, de compléter l'analyse (par exemple, une règle manquante), le processus d'enregistrement 354 peut stocker des données dans la base de données de registre de récupération 356, indiquant quelles informations de produit n'ont pas été récupérées. Si le potentiel de récupération d'un produit ne peut pas être déterminé, le processus de détermination 350 peut renvoyer une erreur. En cas d'erreur, le processus 3049367 58 d'enregistrement 354 peut signaler le produit qui a causé l'échec et stocker une erreur de registre dans la base de données du registre de récupération 356. [00181] Une fois que le processus de détermination 350 a déterminé quels produits de l'itinéraire sont récupérables, le processus de détermination 350 peut poursuivre avec le bloc 392 et déterminer si les produits décisifs de l'itinéraire sont tous récupérables. Si un ou plusieurs des produits décisifs ne sont pas récupérables (branche « NON » du bloc de décision 392), il peut être impossible de garantir la viabilité de la réservation et le processus de détermination 350 peut poursuivre avec le bloc 394 pour annuler le paiement. L'annulation du paiement peut inclure l'annulation de l'autorisation de paiement et la suppression du champ de forme de paiement dans l'enregistrement de voyage. [00182] Faisant maintenant référence à la FIG. 19, le processus de détermination 350 peut commencer le processus d'annulation de paiement en transmettant une demande 396 à la base de données d'enregistrements 22 en demandant à la base de données d'enregistrements de supprimer le champ de forme de paiement de l'enregistrement de voyage. En réponse à la suppression du champ de forme de paiement de l'enregistrement de voyage, la base de données d'enregistrements de voyage 22 peut transmettre une réponse 398 au processus de détermination 350 confirmant que le champ de données de formes de paiement a été supprimé. Le processus de détermination 350 peut aussi transmettre une demande 400 au système de paiement 24 demandant au système de paiement 24 d'annuler l'autorisation de facturer la transaction à la forme de paiement du client. Cette annulation peut inclure, par exemple, le déclenchement de la levée des retenues placées sur la forme de paiement du client par la banque émettrice pour le montant de la transaction. Une fois que l'annulation de l'autorisation a été complétée avec succès, le système de paiement 24 peut transmettre une confirmation 402 au processus de détermination 350. [00183] Si le processus de détermination 350 détermine que tous les produits décisifs sont récupérables (branche « OUI » du bloc de décision 392), le processus de détermination 350 peut poursuivre avec le bloc 404. Dans le bloc 404, le processus de détermination 350 peut confirmer tous les produits récupérables et mettre l'enregistrement de voyage en file d'attente jusqu'à réception des résultats de l'examen manuel. À cette fin, le processus de détermination 350 peut transmettre une demande 406 au module de confirmation de réservation 70 en demandant au module de confirmation de réservation 70 de réserver tous les produits récupérables. Une fois 3049367 59 que les produits définis par la demande de confirmation 406 ont été réservés, le module de confirmation 70 peut transmettre une réponse 408 confirmant que les produits ont été confirmés. Après avoir reçu la confirmation, le processus de détermination 350 peut transmettre une demande 410 au module de file d'attente 74 en demandant que l'enregistrement de voyage soit mis en file d'attente pour traitement ultérieur soit à la réception des résultats de l'examen manuel, soit à l'expiration de la durée limite. [00184] Le Tableau 12 est un exemple de tableau de règles de récupération qui peuvent résider dans la base de données des règles de récupération 352. Les colonnes définies comme « entrée » peuvent définir les paramètres d'entrée correspondant au contexte des données récupérées à partir de l'enregistrement de voyage. Dans l'exemple de mode de réalisation indiqué, les données d'entrée incluent le pays du point de vente, la valeur totale de l'itinéraire, le type de passager et le type de produit. Les données d'entrée illustrées incluent aussi une disponibilité du produit qui peut être déterminée en interrogeant la base de données d'inventaire 20. Une règle par défaut peut être définie par exemple, en incluant un rang avec seulement le type de produit comme entrée (par ex., HTL) qui définit une sortie par défaut (par ex., notification un jour minimum à l'avance). TABLEAU 12 - RÈGLES DE ENTRÉE RÉCUPÉRATION SORTIE POS VALEUR PROD TYPE TYPE MIN MIN TIVpN min TEOD PEN PAYS TOTALE AVL PASS PROD TpivR R ACCPT BR 1500 BRL * * 10 12 5 HRS N JOURS JOURS * * REVENDICATIONS1. Un système de traitement de transaction en ligne comprenant : un ou plusieurs processeurs ; et une mémoire couplée aux processeurs, la mémoire stockant des données comprenant un programme codé qui, lorsqu'il est exécuté par au moins un des processeurs, amène le système à : recevoir le résultat d'une analyse de fraude qui indique qu'une forme de paiement définie par une demande de confirmation d'un itinéraire incluant un ou plusieurs produits doit être testée ; déterminer, en réponse à la réception du résultat de l'analyse de fraude, un contexte de transaction de l'itinéraire ; identifier les règles de récupération dont les paramètres d'entrée sont satisfaits par le contexte de transaction ; identifier tout produit décisif de l'itinéraire ; appliquer les règles de récupération identifiées aux produits décisifs pour déterminer si les produits décisifs sont récupérables ; à la réponse que tous les produits décisifs dans l'itinéraire sont récupérables, confirmer la réservation des produits décisifs ; et à la réponse qu'au moins un produit décisif dans l'itinéraire est irrécupérable, annuler la forme de paiement. 2. Le système selon la revendication 1 dans lequel l'identification de règles de récupération dont les paramètres d'entrée sont satisfaits par le contexte de transaction, et dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs: à la transmission d'une interrogation à la base de données de règles de récupération, l'interrogation incluant des données qui définissent au moins une partie du contexte de transaction ; 3049367 76 à la recherche, dans la base de données, de règles de récupération dont les paramètres d'entrée sont satisfaits par la partie du contexte de transaction ; et à la transmission d'une réponse contenant les résultats de la recherche au système. 3. Le système selon la revendication 1 ou la revendication 2 dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs: en réponse à tous les produits décisifs dans l'itinéraire étant récupérables, au déclenchement d'un test de la forme de paiement. 4. Le système selon l'une quelconque des revendications 1-3 dans lequel l'annulation de la forme de paiement comprend : l'actualisation d'un enregistrement de voyage définissant l'itinéraire pour indiquer que la forme de paiement n'est pas utilisée pour confirmer la réservation de l'itinéraire ; et la transmission d'une demande à un système de paiement pour annuler la forme de paiement. 5. Le système selon l'une quelconque des revendications 1-4 dans lequel l'application de règles de récupération identifiées aux produits décisifs pour déterminer si les produits décisifs sont récupérables, et dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs: à la récupération de données d'un enregistrement de voyage caractérisant chaque produit décisif, dans la base de données des enregistrements de voyage ; et pour chaque produit décisif: à l'application des règles de récupération identifiées aux données caractérisant le produit décisif afin de déterminer si au moins une des règles de récupération identifiée est satisfaite par les données ; et si au moins une des règles de récupération identifiées est satisfaite par les données, à l'identification du produit décisif en tant que produit récupérable. 3049367 77 6. Le système selon la revendication 5 dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs, pour chaque produit décisif : en réponse aux règles de récupération dépendant d'une disponibilité du produit décisif, à la détermination de la disponibilité du produit décisif, dans lequel la détermination avisant qu'un produit décisif est récupérable, est basée au moins en partie sur la disponibilité du produit décisif. 7. Le système selon l'une quelconque des revendications 1-6 dans lequel le contexte de transaction définit un point de vente de l'itinéraire, une valeur totale de l'itinéraire, un type de produit dans l'itinéraire, un fournisseur du produit, un pourvoyeur du produit, une disponibilité du produit, le mode de réservation du produit, ou un type de passager. 8. Le système selon l'une quelconque des revendications l-7 dans lequel l'itinéraire inclut un produit non décisif et dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs : en réponse à tous les produits décisifs dans l'itinéraires étant récupérables, à l'application de règles de récupération identifiées au produit non décisif pour déterminer si le produit non décisif est récupérable; en réponse au produit non décisif étant récupérable, à la confirmation de la réservation du produit non décisif ; et en réponse au produit non décisif étant irrécupérable, à la non-confirmation du produit non décisif. 9. Le système selon l'une quelconque des revendications l-8 dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs: en réponse à tous les produits décisifs étant en cours de confirmation, à l'ajout d'un enregistrement de voyage qui définit l'itinéraire dans une file d'attente. 3049367 78 10. Le système selon la revendication 9 dans lequel le traitement de la transaction en ligne comprend : en réponse à la réception d'une réponse au test de la forme de paiement indiquant que la forme de paiement est frauduleuse, ou que le moment pour annuler une réservation sans déclencher de pénalité est sur le point d'expirer, à la suppression de l'enregistrement de voyage dans la file d'attente, à l'annulation de la réservation de l'itinéraire, et à la transmission d'une demande d'annulation d'une autorisation de la forme de paiement au système de paiement ; et en réponse à la réception d'une réponse au test de la forme de paiement indiquant que la forme de paiement n'est pas frauduleuse, à la confirmation de la réservation, à l'émission des contrats et à la capture de paiement pour tout produit restant dans l'itinéraire qui n'a pas encore été confirmé. 11. Le système selon l'une quelconque des revendications 1-10 dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs: en réponse au contexte de transaction ne satisfaisant pas les paramètres d'entrée d'au moins une règle de récupération, à la détermination que les produits décisifs dans l'itinéraire sont irrécupérables.