FR3049366A1

FR3049366A1 - Systeme de traitement de transactions en ligne pour des transactions impliquant de multiples produits

Info

Publication number: FR3049366A1
Application number: FR1652510A
Authority: FR
Inventors: Matteo Aragone; Jean-Chafic Hays; Michael Lamy; Emmanuelle Geoffroy; Mustapha Rachid
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2016-03-24
Filing date: 2016-03-24
Publication date: 2017-09-29

Abstract

Des systèmes, des méthodes et des produits-programmes informatiques pour le traitement d'une transaction en ligne pour acheter un ensemble de produits comprenant un itinéraire. En réponse à la réception du rejet d'une demande de confirmation de réservation de l'un des produits, un système de traitement de transactions en ligne (OLTP) détermine si la réservation rejetée concerne un produit qui est décisif pour l'itinéraire. Le système OTLP peut le déterminer sur la base des règles applicables aux produits décisifs récupérées à partir d'une base de données de règles de produits décisifs. Après avoir déterminé si la réservation rejetée concerne un produit qui n'est pas décisif pour l'itinéraire, le système OLTP peut-être confirme les réservations pour les produits restants sur l'itinéraire. Après avoir déterminé si la réservation rejetée concerne un produit qui est décisif pour l'itinéraire, le système OLTP peut annuler toute réservation précédemment confirmée et annuler toute réservation faite précédemment pour les autres produits de l'itinéraire.

Description

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 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.

[0006] 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.

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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre par le processus de détermination des formes de paiement de la FIG. 9.

[0018] La FIG. 11 est un organigramme d'un autre sous-processus qui peut être mis en œuvre 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 œuvre 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 peiit être mis en œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre sur un système de 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 eri 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.

[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 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 (back-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.

[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 ritiné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 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 œuvre 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 microordinateurs, 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.

[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 HMI40 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 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 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.

DETERMINATION 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 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.

[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 Titiné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 Tmin. 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 catégorie prédéfinie lorsque le nombre de commerçants pour l'itinéraire dépasse un seuil Mmx. 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 Pmax. 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.

[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.

[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 domestiques 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.

[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 œuvre 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 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 1'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.

[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 œuvre 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 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 ritiné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 (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 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 Mmx [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.

[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 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 ABC 123

VOL JJ 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 3x1

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.

[0085] Il y a trente jours à partir delà 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 T min n'est pas satisfaite. La condition de seuil dans la colonne Mwxne 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 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.

[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.

[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.

[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 :

[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., 3x1%) 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 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 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 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 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 œuvre 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 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.

[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é 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 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.

[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, 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.

[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 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’itÎné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 27Ô 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 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, si l'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é.

[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.

[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 1, par ex., un week-end à DISNEY®) 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 cœur 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 œuvre 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 œuvre 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.

[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 à 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 œuvre 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.

[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’Îtiné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 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 œuvré 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 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 s’utilisées dans les exemples suivants dans le but d'illustrer le fonctionnement du module de produits décisifs 64.

[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écisif272 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écisif272 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 : 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 du milieu dans le 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 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écisif272 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.

[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écisif272 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.

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 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 œuvre 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 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éraÎre. 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 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 ritiné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 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 4 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 ritiné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 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'Îtmé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).

[00185] Le résultat de la règle peut inclure une durée restante minimum Tpm entre l'heure actuelle et le moment auquel les règles du pourvoyeur exigeront l'émission d'un billet pour un produit défini dans un PNR, une durée minimum Tnpnr entre l'heure actuelle et le moment où une pénalité sera encourue, si un contrat n'a pas été émis pour un produit qui n'est pas défini dans un PNR, et un temps minimum Teod entre l'heure actuelle et la fin du jour ouvré. Le temps minimum Teod peut être déterminé, par exemple, en fonction du temps nécessaire pour que le processus de détermination 350 effectue une vérification relative aux produits décisifs.

[00186] À titre d'exemple, le mode de fonctionnement du module de produits récupérables 66 sera maintenant décrit en utilisant plusieurs scénarios hypothétiques. Le contexte du premier scénario peut inclure un itinéraire comprenant un produit décisif qui est un vol réservé par l'intermédiaire d'un GDS (type produit = Vol, GDS). La valeur totale de l'itinéraire défini par l'enregistrement de voyage peut-être de 1000 Réal brésilien (BRL) et l'itinéraire peut ne pas inclure de produits non décisifs, par ex., le vol peut -être le seul produit de l'itinéraire. Le délai limite pour pouvoir émettre un billet pour le vol est peut-être de six jours après la confirmation ; il peut n’y avoir aucune pénalité pour l’annulation du vol et il peut y avoir quatre heures restantes entre l'heure actuelle et la fin de la journée.

[00187] Le contexte ci-dessus peut satisfaire aux exigences d'entrée de la règle définie au premier rang du Tableau 12 en ayant une valeur totale de moins de 1500 BRL. Le contexte peut ne pas satisfaire les exigences d'entrée de la règle définie au deuxième rang du Tableau 12 parce que la valeur totale n'est pas supérieure à 1500 BRL et elle peut ne pas satisfaire aux exigences d'entrée de la règle définie dans le troisième rang du tableau 12, parce que le voyageur n'est pas un membre « carte Or » (Gold card member) et parce que la disponibilité du produit n'est pas inférieure à dix unités. Ainsi, la base de données de règles de récupération 352 peut renvoyer la règle définie au premier rang du Tableau 12.

[00188] Avec l'application de la règle renvoyée dans le contexte actuel, les exigences de la règle peuvent être satisfaites parce qu'il y a plus de trois heures restantes avant la fin du jour ouvré (par ex., il reste assez de temps pour que les produits décisifs soient vérifiés), le produit a une heure limite pour l'émission du billet (par ex., six jours) supérieure à Tpm (par ex., trois jours), et ne contient pas de pénalités. Le produit peut donc être jugé récupérable et l'itinéraire peut être confirmé et mis en file d'attente puisque le vol est le seul produit décisif.

[00189] Le contexte d'un second scénario peut inclure un itinéraire comprenant un produit décisif qui est un vol qui n'a pas été réservé par l'intermédiaire d'un GDS (type produit = Vol, non-GDS). La valeur totale de l'itinéraire défini par l'enregistrement de voyage peut être de 1800 BRL. Le délai limite pour pouvoir émettre un billet pour le vol est peut-être de 11 jours après la confirmation du vol ; il peut n'y avoir aucune pénalité pour l'annulation du vol et il peut rester quatre heures entre l'heure actuelle et la fin du jour ouvré.

[00190] Le contexte ci-dessus peut satisfaire les exigences d'entrée pour la règle définie au deuxième rang du Tableau 12 en ayant une valeur totale supérieure à 1500 BRL ; il peut ne pas satisfaire les exigences d’entrée pour la règle définie au premier rang du Tableau 12 parce que la valeur totale n'est pas inférieure à 1500 BRL et il peut ne pas satisfaire les exigences d'entrée de la règle définie au troisième rang du Tableau 12 parce que le passager n'est pas un membre « carte Or » (Gold Card) et que la disponibilité est inférieure à 10. Ainsi, la base de données de règles de récupération 352 peut renvoyer la règle définie par le deuxième rang du tableau 12.

[00191] L'application de la règle renvoyée au contexte présent peut indiquer que le produit n'est pas récupérable parce que la règle exige une durée minimum Teod de 5 heures qui est supérieure au nombre d'heures restantes dans le jour ouvré. Ainsi, le produit peut être jugé irrécupérable et le processus de détermination 350 peut annuler le paiement.

[00192] Le contexte du troisième scénario peut inclure un itinéraire comprenant un produit décisif qui est un vol qui n’a pas été réservé par le GDS (type produit = Vol, non-GDS). La valeur totale définie de l'itinéraire par l'enregistrement de voyage peut être de 1800 BRL et l'itinéraire peut ne contenir aucun produit décisif. La délai limite pour pouvoir émettre un billet pour le vol est peut-être de deux jours après la réservation du vol ; il peut n'y avoir aucune pénalité pour l'annulation du vol et il peut rester deux heures entre l'heure actuelle et la fin du jour ouvré. Le voyageur peut être un membre « voyageur fréquent niveau Or » (Gold level frequent flyer), il peut ne rester que deux places assises actuellement disponibles sur le vol.

[00193] La valeur totale de l'itinéraire étant supérieure à 1500 BRL, le contexte ci-dessus peut ne pas satisfaire aux exigences d'entrée de la règle définie dans le premier rang du Tableau 12, mais il peut satisfaire aux exigences d'entrée de la règle définie dans le deuxième rang du Tableau 12. Parce que la disponibilité des unités est inférieure à 10, le voyageur est membre

Or du programme de fidélité, le produit est de type VOL, le contexte peut aussi satisfaire aux exigences d'entrée de la règle définie dans le troisième rang du Tableau 12. Ainsi, la base de données de règles de récupération 352 peut renvoyer les règles définies par le deuxième et le troisième rang du tableau 12.

[00194] En appliquant les règles renvoyées au contexte ci-dessus, la règle définie dans le deuxième rang du Tableau 12 peut ne pas être satisfaite parce que le produit doit être émis moins de 10 jours après la confirmation et qu'il reste moins de cinq heures dans le jour ouvré. Cependant, la règle définie par le troisième rang du tableau 12 n’a peut-être pas de limite de durée minimum applicable (c’est-à-dire, Tnpr et Teod = 0). Le produit peut donc être jugé récupérable sur la base de cette règle et l'itinéraire peut être confirmé et mis en file d'attente, dans la mesure où le vol est le seul produit décisif. Au cas où plus d'une règle correspond au scénario, la règle ayant le nombre le plus élevé de paramètres d'entrée correspondants peut être utilisée pour définir les données de sortie.

[00195] Le contexte d'un quatrième scénario peut inclure un itinéraire comprenant un produit décisif qui est un vol réservé par un GDS (type produit = Vol, GDS). La valeur totale définie de l'itinéraire par l'enregistrement de voyage peut-être 500 BRL et l'itinéraire peut ne contenir aucun produit décisif. Le délai limite pour pouvoir émettre un billet pour le produit peut être de neuf jours après la confirmation du produit ; il peut n'y avoir aucune pénalité pour l'annulation du produit et il peut rester quatre heures entre l'heure actuelle et la fin du jour ouvré.

[00196] Le contexte ci-dessus peut satisfaire à toutes les exigences d'entrée de la règle définie dans le premier rang du Tableau 12 en ayant une valeur totale inférieure à 1500 BRL. le contexte peut ne pas satisfaire à la contrainte de valeur totale de la règle définie dans le deuxième rang du Tableau 12 et peut ne pas satisfaire à l’exigence de montant ou de type de passager de la règle définie par le troisième rang du Tableau 12. Ainsi, la base de données de règles de récupération 352 peut renvoyer la règle définie par le premier rang du Tableau 12.

[00197] En appliquant la règle renvoyée au contexte présent, le nombre d'heures restantes avant la fin de la journée (par ex., quatre) est supérieur à Teob requis par la règle (par ex., trois), le nombre de jours avant que le billet ne doive être émis (par ex., neuf) est supérieur au nombre de jours Tpm requis par la règle (par ex., trois) et aucune pénalité ne doit être acceptée. Le produit peut donc être jugé récupérable et l'itinéraire peut être confirmé et mis en file d'attente, car le vol est le seul produit décisif.

[00198] Le contexte d'un cinquième scénario peut inclure un itinéraire comprenant un produit décisif qui est une chambre d'hôtel réservée par l'intermédiaire d'un GDS (type produit= HTL, GDS). La valeur totale de l'itinéraire définie par l'enregistrement de voyage peut être de 1000 BRL. Une pénalité peut être appliquée si la confirmation de la réservation est annulée et il peut ne rester que quatre heures entre l'heure actuelle et la fin du jour ouvré.

[00199] Le contexte ci-dessus peut satisfaire aux exigences d'entrée de la règle définie dans le premier rang du Tableau 12 en ayant une valeur totale inférieure à 1500 BRL. le contexte peut ne pas satisfaire la contrainte de valeur totale de la règle définie par le second rang du Tableau 12 et peut ne pas satisfaire aux exigences de montant ou de type de passager de la règle définie par le troisième rang du Tableau 12. Ainsi, dans cet exemple, l'interrogation de la base de données de règles de récupération 352 peut renvoyer la règle définie par le premier rang du tableau 12.

[00200] En appliquant la règle renvoyée au contexte dans les présentes, le produit peut ne pas satisfaire à la règle en raison de la pénalité. Parce que la règle renvoyée n’est pas satisfaite, le processus de détermination 350 peut appliquer la règle par défaut pour les hôtels, qui peut être définie par le quatrième rang du Tableau 12. Ainsi, le produit peut être jugé irrécupérable s'il y a moins d'un jour entre l’heure actuelle et l'heure à laquelle la chambre d'hôtel sera utilisée, auquel cas le processus de détermination 350 peut annuler le paiement. D'autre part la chambre d'hôtel peut être jugée récupérable s'il y a un jour ou plusieurs jours entre l'heure actuelle et l'heure à laquelle la chambre d'hôtel sera utilisée.

[00201] Le contexte d'un sixième scénario peut inclure un itinéraire comprenant des produits décisifs qui incluent une chambre d'hôtel qui n'a pas été réservée par un GDS (type produit = HTL, non-GDS), et un vol qui a été réservé par un GDS (type produit = Vol, GDS). La valeur totale de l'itinéraire définie par l'enregistrement de voyage peut être de 1800 BRL et l'itinéraire peut ne pas contenir de produits décisifs. Le délai limite pour pouvoir émettre un billet pour le vol est peut-être de 11 jours après la confirmation du vol ; aucune pénalité n'est applicable pour l'hôtel et il reste six heures entre l'heure actuelle et la fin du jour ouvré.

[00202] Puisque la valeur totale de l'itinéraire est supérieure à 1500 BRL, le contexte ci-dessus peut ne pas satisfaire aux exigences d'entrée de la règle définie par le premier rang du Tableau 12 mais il peut satisfaire aux exigences d'entrée de la règle définie par le deuxième rang du Tableau 12. Le contexte peut ne pas satisfaire à l'exigence de montant ou de type de passager de la règle définie par le troisième rang du Tableau 12. Ainsi, la base de données de règles de récupération 352 peut renvoyer la règle définie par le second rang du Tableau 12.

[00203] En appliquant la règle renvoyée au contexte dans les présentes, le nombre d'heures restantes avant la fin de la journée (par ex., six) est supérieur à Teob requis par la règle (par ex., cinq), le nombre de jours avant que le billet ne doive être émis (par ex., 11) est supérieur au nombre de jours Tpnr requis par la règle (par ex., 10), et aucune pénalité ne doit être acceptée.

Les produits peuvent donc être jugés récupérables et l’itinéraire peut être confirmé et mis en file d'attente, car le vol et l'hôtel sont les seuls produits décisifs.

[00204] Le contexte d'un septième scénario peut inclure un itinéraire comprenant des produits décisifs qui incluent un vol réservé par un GDS (type produit = Vol, GDS), une chambre d’hôtel prépayée (type produit = HTL), une location de voiture payée lors de la restitution (par ex., payée à la remise des clés), une attraction et une assurance. La valeur totale définie de l'itinéraire par l'enregistrement de voyage peut être de 8000 BRL, la voiture de location, l’attraction et l'assurance peuvent être des produits non décisifs et l'attraction peut être sujette à une pénalité en cas d'annulation. Le délai limite pour pouvoir émettre un billet pour le vol est peut-être de 12 jours après la confirmation du vol et il peut rester six heures entre l'heure actuelle et la fin du jour ouvré.

[00205] Parce que la valeur totale de l'itinéraire est supérieure à 1500 BRL, le contexte peut ne pas satisfaire aux exigences d'entrée de la règle définie par le premier rang du Tableau 12, mais elle peut satisfaire aux exigences d'entrée de la règle définie par le second rang du Tableau 1. Le contexte peut ne pas satisfaire à l'exigence de montant et de type de passager de la règle définie par le troisième rang du Tableau 12. Ainsi, la base de données de règles de récupération 352 peut renvoyer la règle définie par le deuxième rang du Tableau 12.

[00206] En appliquant la règle renvoyée au contexte présent, le nombre d'heures restantes avant la fin de la journée (par ex., six) est supérieur à Teob requis par la règle (par ex., cinq). Concernant le vol, le nombre de jours avant que le billet ne doive être émis (par ex., 12) est supérieur au nombre de jours Tpnr requis par la règle (par ex., 10), et aucune pénalité ne doit être acceptée pour confirmer la réservation du vol donc le vol peut être jugé récupérable. Il n'y a pas de pénalité associée à la chambre d’hôtel donc la chambre d'hôtel peut aussi être jugée récupérable. Parce que tous les produits décisifs dans l'itinéraire sont récupérables, le processus de détermination 350 peut appliquer la règle aux produits non décisifs. La voiture de location et l'assurance n'impliquent pas de pénalité en cas d'annulation et peuvent donc être jugées récupérables. L'attraction comporte une pénalité en cas d'annulation et peut donc être jugée irrécupérable. Les produits récupérables de l'itinéraire (vol, hôtel, voiture de location et assurance) peuvent être confirmés. L'attraction peut ne pas être confirmée ce qui peut amener l'enregistrement de voyage à être mis en file d'attente et une alerte peut être émise.

[00207] Le contexte d'un huitième scénario peut inclure un itinéraire comprenant des produits qui incluent un vol réservé par un GDS (type produit = Vol, GDS), une chambre d'hôtel prépayée (type produit = HTL), une voiture de location payée lors de la restitution (par ex., payé à la remise des clés) une attraction et une assurance. La valeur totale de l'itinéraire défini par l'enregistrement de voyage peut être de 8000 BRL. Le vol et l'hôtel peuvent être des produits décisifs et la voiture de location, l'attraction et l’assurance peuvent être des produits non décisifs. L'attraction peut impliquer une pénalité en cas d'annulation. Le délai limite pour pouvoir émettre le billet pour le vol peut être de deux jours après confirmation et il peut rester six heures entre l'heure actuelle et la fin du jour ouvré.

[00208] Parce que la valeur totale de l'itinéraire est supérieure à 1500 BRL, le contexte peut ne pas satisfaire aux exigences d'entrée de la règle définie par le premier rang du Tableau 12, mais il peut satisfaire aux exigences d'entrée de la règle définie dans le deuxième rang du Tableau 12. Le contexte peut ne pas satisfaire l'exigence de montant ou de type de passager de la règle définie dans le troisième rang du Tableau 12. Ainsi, la base de données des règles de récupération 352 peut renvoyer la règle définie dans le deuxième rang du Tableau 12.

[00209] En appliquant la règle renvoyée au présent contexte, le nombre d'heures restantes avant la fin de la journée (par ex., six) est supérieur à Teob requis par la règle (par ex., cinq) donc le processus de détermination 350 peut vérifier les produits décisifs. Il n'y a aucune pénalité associée à la chambre d'hôtel donc la chambre d'hôtel peut aussi être jugée récupérable. Concernant le vol, le nombre de jours avant que le billet ne doive être émis (par ex., deux) est inférieur au nombre de jours Tpm requis par la règle (par ex. 10) donc le vol peut aussi être jugé irrécupérable. Parce qu’un des produits décisifs est jugé irrécupérable, le processus de détermination 350 peut annuler le paiement.

MODULE DE RÉCUPÉRATION DE TRANSACTION

[00210] Comme décrit ci-dessus, dans certains cas, le traitement d'une transaction peut être interrompu avant que le traitement ne soit finalisé. Par exemple, le système OLTP 12 peut interrompre le traitement d'une transaction en réponse à la détection d'une erreur telle que l'échec de la confirmation d'une réservation ou l'échec de confirmation d'émission d'un contrat. Le système OLTP 12 peut aussi interrompre le traitement d'une transaction jusqu'à ce que les résultats d'une analyse de fraude de la forme de paiement du client soient reçus. En réponse à une erreur de confirmation ou d'émission de contrat, l'enregistrement de voyage peut être mis en file d'attente et une alerte peut être émise indiquant qu'une intervention manuelle est requise. Par exemple, lorsqu'un produit dans l'itinéraire n'est pas disponible, le système du fournisseur peut être incapable d'émettre un contrat pour le produit, générant une erreur. Dans le cas d'un échec de confirmation d'une réservation ou de l'émission d’un contrat pour un produit, un agent de voyages peut intervenir pour modifier l'itinéraire en remplaçant le produit non disponible avec un nouveau produit ou en retirant le produit de l'itinéraire. Quel que soit le cas, le traitement de la transaction peut nécessiter une reprise après la modification de l'enregistrement de voyage.

[00211] Une fois que l'erreur a été résolue, une demande peut être envoyée au système OLTP 12 demandant au système OLTP 12 de reprendre le traitement. Lorsque le traitement est interrompu pour attendre les résultats d'une analyse de fraude, le système OLTP 12 peut confirmer les produits récupérables et mettre l'enregistrement de voyage en file d'attente de sorte que le traitement puisse être repris à réception des résultats de l'analyse de fraude. Une reprise peut exiger que le système OLTP 12 détermine quelles actions doivent être effectuées pour finaliser la transaction ainsi que la séquence à suivre pour ces actions. Cela peut nécessiter la détermination d'un état de la transaction, de sorte que le traitement de la transaction puisse reprendre au point exact pour chaque produit dans l'itinéraire.

[00212] Lors de la réception d'une demande de reprise de traitement de la transaction, le module 68 de récupération de transaction peut déterminer l'état de la transaction sur la base de l'enregistrement de voyage ; il peut déterminer les actions restantes nécessaires à la finalisation de la transaction et peut déterminer dans quel ordre les actions doivent être exécutées. Le module de récupération de transaction 68 peut commencer la reprise en sortant l'enregistrement de voyage de la file d'attente et en déterminant le statut de la transaction. Une fois que le statut de la transaction a été déterminé, le module de récupération de transaction 68 peut envoyer des demandes de traitement à un ou à plusieurs modules du système OLTP 12 pour finaliser le traitement de la transaction. Ces demandes peuvent être pour des produits sélectionnés et peuvent être séquencées dans l'ordre déterminé par le module de récupération de transaction 68.

[00213] Le module de récupération de transaction 68 peut commencer à déterminer les actions qui ont été finalisées avec succès et les actions qui doivent encore être finalisées. Les actions qui doivent être finalisées peuvent varier pour chaque produit dans l'itinéraire et peuvent inclure l'affectation d'un commerçant au produit, la détermination d'une forme de paiement pour le produit, une demande d'analyse de fraude pour la forme de paiement, la détermination de l'importance du produit, la détermination du potentiel de récupération du produit, un paiement à effectuer au commerçant, une confirmation de la réservation du produit, l'émission d'un contrat pour le produit et la capture du paiement pour le produit. Les actions devant être finalisées peuvent aussi inclure une détection de fraude au niveau du produit ou au niveau de la transaction.

[00214] Le processus de reprise peut être particulièrement complexe selon le nombre de produits, le nombre de fournisseurs, le nombre total d'actions requises pour réserver l'itinéraire et le nombre de scénarios sous lesquels une reprise peut être nécessaire. Par ailleurs, la reprise du traitement d'une transaction peut être compliquée du fait de la possibilité que l'enregistrement de voyage soit en cours d'actualisation par un système tiers, par ex., un moteur de réservation sur Internet ou une actualisation manuelle par un agent de voyage pendant le traitement de la transaction qui a été interrompu. Pour cette raison le module de récupération de transactions 68 peut être incapable de s'appuyer sur le registre historique d'une transaction.

[00215] Les FIGS. 20 et 21 représentent un organigramme illustrant un processus de reprise 420 qui peut être mis en œuvre dans un mode de réalisation du module de récupération de transaction 68 en réponse à la réception d'une demande de reprise du traitement d'une transaction. Dans le bloc 422, le processus de reprise 420 peut identifier un ensemble de produits pour lesquels le traitement d’une transaction est inachevé. L'ensemble des produits inachevés peut inclure, par exemple, des produits définis dans l'itinéraire par l'enregistrement de voyage pour lesquels un paiement n'a pas été effectué, une réservation qui n'a pas été confirmée ou un contrat qui n'a pas été émis.

[00216] Dans le bloc 424, le processus de reprise 420 peut déterminer si une nouvelle forme de paiement a été définie dans l'enregistrement de voyage depuis que le traitement de la transaction a été interrompu. Si une nouvelle forme de paiement a été définie dans l'enregistrement de voyage (branche « OUI » du bloc de décision 424), le processus de reprise 420 peut poursuivre avec le bloc 426 et déterminer si un paiement a été effectué pour le produit sélectionné. Si le paiement a été effectué (branche « OUI » du bloc de décision 426), le processus de reprise 420 peut poursuivre avec le bloc 428.

[00217] Si un paiement n'a pas encore été effectué pour le produit sélectionné (branche « NON » du bloc de décision 426), le processus de reprise 420 processus peut poursuivre avec le bloc 430. Dans le bloc 430, le processus de reprise 420 peut demander au module de détermination du commerçant 60 de déterminer le commerçant pour le produit sélectionné. Si un commerçant a été précédemment affecté au produit sélectionné en question, le module de détermination du commerçant 60 peut contourner la décision précédente relative au commerçant. Dans un mode de réalisation de l'invention, on ne peut faire appel au module de détermination du commerçant 60 uniquement si le produit est nouveau, c'est-à-dire, si un commerçant n'a pas été déterminé précédemment pour le produit. Quel que soit le cas, une fois qu'un commerçant a été déterminé pour le produit sélectionné, le processus de reprise 420 peut poursuivre avec le bloc 428.

[00218] En revenant au bloc 424, si une nouvelle forme de paiement n'a pas été définie dans l'enregistrement de voyage (branche « NON » du bloc de décision 424), le processus de reprise 420 peut poursuivre avec le bloc 432. Dans le bloc 432, le processus de reprise 420 peut déterminer si le produit sélectionné est un nouveau produit, c’est-à-dire, que le produit a été ajouté à l'enregistrement de voyagé pendant l'interruption du traitement de la transaction. Si le produit sélectionné est un nouveau produit (branche « OUI » du bloc de décision 432), le processus de reprise 420 peut poursuivre avec le bloc 430 et peut faire appel au module de détermination du commerçant 60. Si le produit sélectionné n'est pas un nouveau produit (branche « NON » du bloc de décision 432), le processus de reprise 420 peut poursuivre avec le bloc 428.

[00219] Dans le bloc 428, le processus de reprise 420 peut déterminer si tous les produits dans l'ensemble de produits inachevés ont été traités. Si le produit sélectionné n'est pas le dernier produit dans l'ensemble (branche “« NON » du bloc de décision 428), le processus de reprise 420 peut poursuivre avec le bloc 434, sélectionner le produit suivant et revenir au bloc 424. Si le produit sélectionné est le dernier produit dans l'ensemble (branche « OUI » du bloc de décision 428), le processus de reprise 420 peut poursuivre avec le bloc 436.

[00220] Dans le bloc 436, le processus de reprise 420 peut déterminer si l’enregistrement inclut de nouvelles informations de paiement. Si l'enregistrement de voyage inclut de nouvelles informations de paiement (branche « OUI » du bloc de décision 436), le processus de reprise 420 peut poursuivre avec le bloc 438 et demander au système de paiement 24 d’obtenir une autorisation de paiement auprès d'une banque émettrice. Le processus de reprise 420 peut aussi demander au module de formes de paiement 62 de déterminer les formes de paiement utilisées pour payer le fournisseur et le vendeur pour l'itinéraire.

[00221] Si l’enregistrement de voyage n'inclut pas de nouvelles informations de paiement (branche « NON » du bloc de décision 436), le processus de reprise 420 peut poursuivre avec le bloc 440 et vérifier le statut de paiement de tous les produits dans l’itinéraire. Cette vérification peut comprendre l'addition de tous les paiements enregistrés dans l'enregistrement de voyage et le fait de déterminer si la somme des paiements correspond au montant total de la transaction. Si la somme des paiements individuels enregistrés dans l'enregistrement de voyage ne correspond pas au montant total de la transaction, le processus de reprise 420 peut interrompre le traitement de la transaction et mettre l'enregistrement de voyage en file d'attente pour une intervention manuelle.

[00222] Une fois que les formes de paiement ont été créées dans le bloc 438 ou que les paiements ont été vérifiés avec succès dans le bloc 440 le processus de reprise 420 peut poursuivre avec le bloc 442. Dans le bloc 442, le processus de reprise 420 peut vérifier le statut de fraude de la forme de paiement du client. Si le statut de fraude de la forme de paiement du client n'est pas défini dans l’enregistrement de voyage (branche « NON » du bloc de décision 442), le processus de reprise 420 peut poursuivre avec le bloc 444 et demander au système de détection anti-fraude 26 d'effectuer une analyse de fraude pour la forme de paiement du client. Si le statut de fraude ou le résultat de la détection de fraude demandé indique que le paiement du client est frauduleux, ou recommande de soumettre la forme de paiement du client à un test de sécurité plus rigoureux, le processus de reprise 420 peut interrompre le traitement de la transaction et mettre l'enregistrement de voyage en file d'attente pour une intervention manuelle.

[00223] Si la détection de fraude a été effectué (branche « OUI » du bloc de décision 442) ou si le résultat de la détection de fraude reçu au bloc 444 indique que la forme de paiement du client n'est pas frauduleuse, le processus de reprise 420 peut poursuivre avec le bloc 446. Dans le bloc 446, le processus de reprise 420 peut demander au module de produits décisifs 64 de déterminer quels produits dans l'enregistrement de voyage sont décisifs. Une fois que le module de produits décisifs 64 a déterminé quels produits sont décisifs, le processus de reprise 420 peut poursuivre avec le bloc 448.

[00224] Dans le bloc 448, le processus de reprise 420 peut vérifier la confirmation des réservations pour les produits dans l'itinéraire. Si toutes les confirmations pour chaque produit dans l'itinéraire ont été confirmées (branche « OUI » du bloc de décision 448), le processus de reprise 420 peut poursuivre avec le bloc 450. Si tout produit réservé dans l'itinéraire n'est pas confirmé (branche « NON » du bloc de décision 448), le processus de reprise 420 peut avancer au bloc 452 et confirmer la réservation des produits non confirmés avant de procéder au bloc 450.

[00225] Dans le bloc 450, le processus de reprise 420 peut vérifier si les contrats ont été émis pour chacun des produits dans l’enregistrement de voyage. Le processus de reprise 420 peut, par exemple, déterminer si un contrat a été émis pour un produit sur la base d'un champ de données de statut d'émission associé au produit dans l'enregistrement de voyage. Si des contrats ont été émis pour chaque produit dans l'itinéraire (branche « OUI » du bloc de décision 450), le processus de reprise 420 peut poursuivre avec le bloc 454. Si un contrat n'a pas été émis pour chacun des produits (branche « NON » du bloc de décision 450), le processus de reprise 420 peut poursuivre avec le bloc 456, demander au module d'émission de contrats 72 d'établir des contrats pour les produits pour lesquels un contrat n'a pas été émis, puis poursuivre avec le bloc 454.

[00226] Dans le bloc 454, le processus de reprise 420 peut vérifier l'existence d’un produit d'assurance dans l'enregistrement de voyage. Si un produit d'assurance est défini dans l'enregistrement de voyage, mais qu'il n'a pas été souscrit, le processus de reprise 420 peut déclencher une souscription au produit d'assurance avant de poursuivre avec le bloc 458. Dans le bloc 458, le processus de reprise 420 peut vérifier si les paiements définis dans l'enregistrement de voyage ont été capturés. Si des paiements n'ont pas été capturés et que des contrats ont été émis pour chaque produit, le processus de reprise 420 peut déclencher une capture de tout paiement non capturé.

[00227] À titre d'exemple le fonctionnement du module de récupération de transaction 68 est décrit ci-dessous en utilisant un scénario hypothétique. Le scénario peut inclure un voyageur qui sélectionne trois produits (A, B et C) devant être inclus dans un itinéraire en utilisant un moteur de confirmation de réservation sur Internet. Pour acheter l'itinéraire, le voyageur peut identifier une carte de crédit comme forme de paiement du client. Le système OLTP 12 peut confirmer chacun des produits avec succès. Des demandes d'émission de contrat pour les produits A et B sont finalisées avec succès mais une demande d'émission de contrat pour le produit C n'est pas confirmée, ce qui peut entraîner le système OLTP 12 à enregistrer une erreur, à interrompre le traitement de la transaction et à mettre l'enregistrement de voyage en filé d'attente.

[00228] Un agent de voyage dans un-centre d’appel peut recevoir une alerte du système OLTP 12 signalant l'erreur. Pour corriger l'erreur, l'agent de voyage peut modifier l'enregistrement de voyage en remplaçant le produit C par le produit D et en fournissant une nouvelle forme de paiement pour le produit D. L'agent de voyage peut ensuite demander que le traitement de la transaction soit repris. En réponse à la réception d'une demande de reprise de traitement, le module de récupération de transaction 68 peut lire l’enregistrement de voyage et déterminer quel les actions exécuter pour finaliser la réservation.

[00229] Le module de récupération de transaction 68 peut déterminer que le produit D a besoin d’une nouvelle affectation de commerçant, d'une autorisation de paiement, d'une analyse de fraude, d'une réservation et de l'émission d’un contrat. Le module de récupération de transaction 68 peut envoyer une demande au module de détermination du commerçant 60 demandant au module de détermination du commerçant 60 d'affecter un commerçant au produit D et d'actualiser l'enregistrement de voyage. Le traitement du produit D peut ensuite être acheminé par le module de formes de paiement 62, par le module de produits décisifs 64, par le module de produits récupérables 66, par le module de confirmation de réservation 70 et par le module d'émission de contrat 72.

[00230] En réponse à l’émission d'un contrat pour le produit D, le module de récupération de transaction 68 peut causer la capture des paiements pour les produits A, B et D. Le module de récupération de transactions 68 peut ainsi orchestrer le traitement de l'enregistrement de voyage par d'autres modules du système OLTP 12, les actions de chaque module dépendant de l'état de l'enregistrement de voyage et de la configuration des bases de données de règles interrogées par les modules. Chaque module peut être indépendant et fournir son propre ensemble de fonctionnalités. L’activation de certains modules peut être obligatoire pour reprendre la transaction alors que d'autres peuvent être activés en fonction de la configuration des bases de données de règles.

[00231] En général, les sous programmes exécutés pour mettre en œuvre les modes de réalisation de l'invention, qu'ils soient implémentés dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d’un programme, d'un objet, d'un module ou d'une séquence d'instructions ou même un sous-ensemble de ceux-là, peuvent être désignés dans les présentes comme « programme codé informatique » ou simplement « programme codé. » Un programme codé comporte typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l'ordinateur à effectuer des opérations nécessaires à l'exécution d'opérations et/ou d'éléments propres à la mise en œuvre des aspects variés des modes de réalisation de l’invention. Les instructions d'un programme, lisibles par ordinateur, pour effectuer les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation.

[00232] Divers programmes codés décrits dans les présentes peuvent être identifiés selon l'application dans laquelle ils sont mis en œuvre dans des modes de réalisation spécifiques de l'invention. Cependant, on remarquera que toute nomenclature d'un programme particulier suivant est utilisée uniquement par commodité. Ainsi l'invention ne devrait pas se limiter à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous programmes, procédures, méthodes, modules, objets, et ainsi de suite, ainsi que les diverses manières d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels résidant dans un ordinateur typique (par ex., des systèmes d'exploitation, des bibliothèques, des APIs, des applications, des mini-applications (applets), des services Web, etc.), on remarquera que les modes de réalisation de l’invention ne sont pas limités à l'organisation spécifique et à la répartition des fonctionnalités de programme décrites dans les présentes.

[00233] Le programme codé mis en œuvre dans toute application/module décrit(e) dans les présentes peut être distribué individuellement ou collectivement comme un produit-programme sous diverses formes. En particulier, le programme codé peut être distribué en utilisant un support de stockage lisible par ordinateur disposant d'instructions de programme lisibles par ordinateur en lui-même permettant à un processeur d'effectuer des aspects des modes de réalisation de l'invention.

[00234] Les supports de stockage, qui sont intrinsèquement non transitoires, lisibles par machine, peuvent inclure des médias tangibles volatiles et non volatiles, amovibles et non amovibles, mis en œuvre dans toute méthode ou technologie de stockage des informations telle que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme ou d’autres données. Les supports de stockage lisibles par ordinateur peuvent par ailleurs inclure des mémoires RAM, ROM, EPROM (mémoire à lecture exclusivement, programmable et effaçable), une mémoire flash ou autre technologie de support solide de mémoire, un CD-ROM (disque compact portable doté d'une mémoire à lecture seule) ou un autre stockage optique, des bandes d'enregistrement magnétique, des dispositifs de stockage à disque magnétique ou autres dispositifs de stockage magnétique ou tout autre support pouvant être utilisé pour stocker les informations désirées et lisibles par ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme « des signaux transitoires » en soi (par ex., des ondes radio ou d’autres ondes électromagnétiques se propageant, ondes électromagnétiques se propageant à travers un support de transmission tel qu'un guide d'ondes ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif à partir d’un support de stockage lisible par ordinateur, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau.

[00235] Les instructions de programme lisibles par ordinateur, stockées sur un support lisible par ordinateur, d'autres types d'appareils programmables de traitement de données ou d'autres dispositifs pour fonctionner d'une façon particulière, tels que les instructions stockées sur un support lisible par ordinateur, produisent un article de fabrication comprenant les instructions qui mettent en œuvre les fonctions, les actions et/ou les opérations précisées dans les organigrammes, les diagrammes de séquence et/ou les diagrammes blocs. Les instructions de programme d'ordinateur peuvent être fournies à un ou plusieurs processeurs d’un ordinateur à usage général, d’un ordinateur dédié ou d’un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu’elles sont exécutées à l'aide d’un ou de plusieurs processeurs, accomplissent une série de calculs pour mettre en œuvre les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.

[00236] Dans certains modes de réalisation alternatifs, les fonctions, les actions et/ou les opérations précisées dans les organigrammes, les diagrammes de séquence, et/ou les diagrammes blocs peuvent être commandés à nouveau, traités en série, et/ou traités en même temps conformément aux modes de réalisation de l'invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux illustrés conformément aux modes de réalisation de l'invention.

[00237] La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n'est pas destinée à limiter les modes de réalisation de l'invention. Le singulier des articles définis et indéfinis « un », « une », « le » et « la » tels qu'ils sont utilisés dans les présentes sous-entend également les formes plurielles, sauf si le contexte indique clairement le contraire. Par ailleurs, les formes verbales « comprend », « comprennent » et/ou « comprenant », lorsqu'elles sont utilisées dans cette spécification, précisent la présence de caractéristiques, de nombres entiers, d'étapes, d'opérations, d'éléments et/ou de composants mais n'excluent pas la présence ou l'ajout d'une ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes en cela. De plus, dans la mesure où les formes verbales « inclut », « ayant », « a », « avec », « composé de » ou des variantes, sont utilisées soit dans la description détaillée soit dans les revendications, ces termes sont censés être inclusifs de façon similaire au verbe « comprendre ».

[00238] Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, le demandeur n’a pas l’intention de restreindre ou de limiter, de quelque manière que ce soit, l'étendue des revendications jointes à de tels détails. Des avantages et des modifications supplémentaires apparaîtront aisément aux hommes de métier. L'invention sous un angle plus large n’est donc pas limitée aux détails spécifiques, aux méthodes et aux appareils représentatifs et aux exemples montrés et décrits. Par conséquent, il est possible de s'éloigner de ces détails sans s'éloigner de l'esprit et de la portée du concept inventif général du Demandeur.

Claims

REVENDICATIONS

1. 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 composant le programme codé qui, lorsqu'il est exécuté par au moins un des processeurs, amène le système à: recevoir une première demande de confirmation de réservation pour l’itinéraire comprenant une pluralité de produits ; identifier, sur la base d’un premier ensemble de règles, un ou plusieurs produits décisifs parmi la pluralité de produits ; transmettre une deuxième demande de confirmation de réservation pour l’un des produits décisifs ; et en réponse au rejet de la deuxième demande de confirmation de réservation, à l’annulation de toute demande de confirmation de réservation pour l’itinéraire.
2. Le système selon la revendication 1 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 à la réception d’une confirmation de réservation pour chacun des produits décisifs, à la transmission d’une troisième demande de confirmation de réservation pour un produit non décisif de la pluralité de produits ; et en réponse au rejet de la troisième demande de confirmation de réservation, à l’enregistrement du rejet de la troisième demande de confirmation de réservation dans une base de données du registre et la transmission d’une alerte à un système vendeur.
3. Le système selon la revendication 1 ou la revendication 2 dans lequel l’itinéraire est défini par un enregistrement de voyage dans une base de données d’enregistrements de voyage.
4. Le système selon la revendication 3 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 rejet de la troisième demande de confirmation de réservation, au signalement de l’enregistrement de voyage pour indiquer que le produit non décisif n’a pas été réservé, ou à la mise en file d’attente de l’enregistrement de voyage pour sélectionner un produit de remplacement.
5. Le système de l’une quelconque des revendications 1-4 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 à la réception des confirmations de réservation pour chacun des produits décisifs, à la transmission d’une demande d’émission de contrat pour l’un des produits décisifs ; et en réponse au rejet de la demande d’émission de contrat, à l’annulation de toute demande précédente de confirmation de réservation et de toute demande d’émission de billet, confirmée précédemment, pour l’itinéraire.
6. Le système selon l’une quelconque des revendications 2-5 dans lequel le code de programme, quand il est exécuté par au moins un processeur, amène le système par ailleurs: à l’enregistrement de chaque réponse à chaque demande de confirmation de réservation dans la base de données du registre.
7. Le système selon l’une quelconque des revendications 1-6 dans lequel la deuxième demande de confirmation de réservation est une demande parmi une pluralité de deuxièmes demandes de confirmation de réservation, chacune correspondant à l’un des produits décisifs 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 détermination, sur la base d’un deuxième ensemble de règles, d’une séquence dans laquelle les produits décisifs doivent être confirmés ; et à la transmission des deuxièmes demandes de confirmation de réservation conformément à la séquence.
8. Le système selon la revendication 7 dans lequel le code de programme, quand il est ' exécuté par au moins un processeur, amène le système par ailleurs: à la sélection d’un premier produit décisif dans la séquence ; à la transmission d’une deuxième demande de confirmation de réservation pour le premier produit décisif ; et à la transmission de chaque deuxième demande de confirmation de réservation restante en réponse à la réception d’une confirmation de réservation pour une deuxième demande de confirmation de réservation précédemment transmise.
9. Le système selon l’une quelconque des revendications 1-8 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 le premier ensemble de règles à partir d’une base de données de règles.
10. Le système selon l’une quelconque des revendications 2-9 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 à la réception d’une confirmation de réservation, au stockage d’un numéro de confirmation dans l’enregistrement de voyage pour un produit correspondant ; et à la mise à jour d’un statut du produit correspondant dans l’enregistrement de voyage confirmé.
11. Le système selon l’une quelconque des revendications 2-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 rejet de la deuxième demande de confirmation de réservation, à l’annulation de l’enregistrement de voyage et l’annulation de tout paiement effectué.
12. Le système selon l’une quelconque des revendications 1-11 dans lequel le premier ensemble de règles identifie les produits décisifs sur la base du type de produit, du signalement de chaque produit comme faisant partie d’un forfait voyage, le cas échéant, de l’identité d’un voyageur, de l’identité du fournisseur de chaque produit, de l’identité du pourvoyeur de chaque produit, de l’identité du vendeur de chaque produit ou d’un marché sur lequel chaque produit est fourni.