Brevet FR3048299A1 — publié le 20170901

SYSTÈME DE TRAITEMENT DE TRANSACTIONS EN LIGNE POUR LES TRANSACTIONS IMPLIQUANT DES FOURNISSEURS MULTIPLES CONTEXTE [0001] L'invention concerne : des ordinateurs et des systèmes informatiques et, en particulier, des méthodes, des systèmes et des produits de programme informatique pour le traitement en ligne des transactions impliquant un ensemble de produits et plus d'un fournisseur de produits. [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, des transactions pour un ensemble de produits qui impliquent des fournisseurs multiples peuvent avoir comme conséquences des interactions complexes entre des systèmes de fournisseurs et des systèmes de vendeurs pour assurer que chaque produit est disponible et tarifé simultanément. Les systèmes du côté de l'acheteur peuvent aussi contribuer à la complexité en apportant de multiples formes de paiement, chacune pouvant nécessiter un traitement des données par une ou plusieurs banques, ou par des systèmes informatisés de transaction sécurisée. Afin d'accommoder des ensembles de données toujours plus larges et les tâches qui leur sont associées pour manipuler des données, lesquelles peuvent être distribuées sur de multiples systèmes informatiques, les systèmes de traitement de transaction en ligne (OLTP) exigent des processus sophistiqués pour gérer les transactions. Ces processus peuvent gérer la communication entre acheteur, vendeur, fournisseur et 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é, de la vitesse, une concomitance et une récupération des transactions en ligne. [0003] Les transactions impliquant un vendeur au détail ou autre vendeur indirect peuvent être structurées de différentes façons. Une façon de structurer la transaction est de permettre au fournisseur d'être payé en utilisant une forme de paiement fournie par l'acheteur, par exemple, une carte de crédit. Dans ce cas, pour la vente des produits, le fournisseur peut être considéré comme un commerçant et le vendeur peut recevoir une commission ou une rémunération de la part du fournisseur pour le service. Une autre façon possible est de structurer la transaction de façon à recevoir un paiement de la part de l'acheteur en utilisant la forme de paiement fournie par l'acheteur et en utilisant une autre forme de paiement pour payer le fournisseur. Dans ce cas, le 3048299 vendeur peut être considéré comme le commerçant des produits. Être commerçant peut permettre au vendeur de contrôler les hausses de prix et/ou les rabais sur le produit, mais cela peut aussi signifier que le vendeur assume la responsabilité des transactions de paiement, de sorte que le vendeur assume le risque qu'une transaction puisse s'avérer frauduleuse. Ainsi, le vendeur peut désirer agir en qualité de commerçant pour certains produits, mais pas pour d'autres. [0004] Les systèmes OLTP conventionnels peuvent avoir des difficultés pour traiter une transaction d'achat pour des produits multiples, structurés de sorte que le commerçant est le vendeur d'un des produits et le fournisseur pour un autre des produits. Par exemple, une tentative d'affectation de commerçants différents à des produits différents au moment de la vente peut causer des erreurs dans le traitement de la transaction initiale ainsi que des problèmes pour reverser les paiements si l'acheteur demande plus tard un remboursement. Ainsi, les systèmes OLTP existants peuvent limiter la structuration de transactions liées à l'achat de produits multiples. [0005] Ainsi, des systèmes, des méthodes, et des programmes informatiques pour les systèmes OLTP sont nécessaires pour apporter une flexibilité accrue à la structuration de transaction impliquant l'achat de produits multiples. RÉSUMÉ [0006] Dans un mode de réalisation de l'invention, un système de traitement de transactions en ligne est procuré ; il inclut un plusieurs processeurs et une mémoire couplée avec les processeurs. La mémoire stocke un programme codé qui, lorsqu'il est exécuté par un plusieurs processeurs, amène le système à recevoir une demande de remboursement identifiant un enregistrement de base de données qui définit un itinéraire, un premier produit dans l'itinéraire devant être remboursé et un second produit dans l'itinéraire devant être remboursé. Par ailleurs, le programme codé amène le système à récupérer des données à partir de l'enregistrement de base de données qui définissent que le marchand est le fournisseur du premier produit ainsi qu'un premier paiement effectué par l'acheteur au commerçant du premier produit, que le vendeur est le commerçant du second produit ainsi qu'un second paiement effectué par l'acheteur au commerçant du second produit. Sur la base des premières données, le programme codé peut ensuite amener le système à déterminer un premier montant devant être remboursé à l'acheteur par le vendeur, un second montant devant être remboursé à l'acheteur par le fournisseur du 3048299 premier produit, et un troisième montant devant être remboursé au vendeur par le fournisseur du second produit. [0007] Un autre mode de réalisation de l'invention procure une méthode de traitement d'une demande de remboursement. La méthode inclut la réception d'une demande de remboursement sur le système de traitement de transaction en ligne, la demande de remboursement identifiant un enregistrement de base de données qui définit l'itinéraire, le premier produit de l'itinéraire devant être remboursé, et le second produit de l'itinéraire devant être remboursé. À partir de l'enregistrement de base de données, la méthode récupère des données qui, pour le premier produit, définissent que le commerçant est le fournisseur du premier produit ainsi que le paiement effectué par l'acheteur au commerçant du premier produit, pour le second produit, que le vendeur est le commerçant du second produit ainsi que le second paiement effectué par l'acheteur au commerçant du second produit. Sur la base des données, la méthode peut ensuite déterminer le premier montant à rembourser à l'acheteur par le vendeur, le second montant à rembourser par le fournisseur du premier produit à l'acheteur, et le troisième montant à rembourser par le fournisseur du second produit au vendeur. [0008] Un autre mode de réalisation de l'invention procure un produit-programme d'ordinateur qui inclut un support de stockage non transitoire déchiffrable par ordinateur comprenant un programme codé. Le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, le ou plusieurs processeurs sont amenés à recevoir la demande de remboursement identifiant l'enregistrement de base de données qui définit l'itinéraire, le premier produit de l'itinéraire devant être remboursé, et le second produit de l'itinéraire devant être remboursé. Le programme codé amène par ailleurs les processeurs à récupérer, à partir de l'enregistrement de base de données, les données qui définissent que le commerçant est le fournisseur du premier produit ainsi que le premier paiement effectué par l'acheteur au commerçant pour le premier produit, que le vendeur est le commerçant du second produit ainsi que le second paiement effectué par l'acheteur au commerçant du second produit. Sur la base des premières données, le programme codé peut ensuite amener les processeurs à déterminer le premier montant à rembourser à l'acheteur par le vendeur, le second montant à rembourser à l'acheteur par le fournisseur du premier produit, et le troisième montant à rembourser au vendeur par le fournisseur du second produit. 3048299 BRÈVE DESCRIPTION DES DESSINS [0009] Les dessins qui accompagnent et qui 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. [0010] Fig. 1, représente une vue schématique d'un environnement d'exploitation exemplaire incluant un système de traitement de transaction en ligne en communication avec un système vendeur, un ou plusieurs systèmes fournisseurs, une base de données d'enregistrements de voyage, et un système de paiement. [0011] Fig. 2, représente une vue schématique d'un ordinateur exemplaire pouvant être utilisé pour fournir l'environnement d'exploitation de la fig. 1. [0012] Fig. 3, représente une vue schématique du système de traitement de la transaction en ligne montrant un serveur de transactions, une base de données contextuelle, une base de données de transactions, et une base de données de règles. [0013] Fig. 4, représente l'organigramme du processus de détermination pouvant être implémenté par le serveur de transactions de la fig. 3. [0014] Fig. 5, représente une vue schématique des paiements pouvant être effectués entre un acheteur, un vendeur, et une pluralité de fournisseurs et illustrant un exemple du processus de détermination du paiement de la fig. 4. [0015] Fig. 6, représente une vue schématique des paiements pouvant être effectués entre l'acheteur, le vendeur, et la pluralité de fournisseurs et illustrant un autre exemple du processus de détermination du paiement de la fig. 4. 4. [0016] Fig. 7, représente un organigramme du processus de remboursement pouvant être implémenté par le serveur de transactions de la fig.3. [0017] Fig. 8, représente un organigramme d'un sous-processus de remboursement pouvant être implémenté par le processus de remboursement de la fig. 7. [0018] Fig. 9, représente un organigramme d'un processus de reprise pouvant être implémenté par le serveur de transaction de la fig. 3. 3048299 DESCRIPTION DÉTAILLÉE [0019] Les modes de réalisation de l'invention visent des systèmes, des méthodes, et des produits de programme d'ordinateur pour gérer des transactions en ligne impliquant l'achat de produits multiples, par exemple, un ensemble de produits liés au voyage composant un itinéraire pour un voyage. Les modes de réalisation de l'invention peuvent être implémentés sur un système de traitement de transactions en ligne (OLTP) comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Le système OLTP peut être configuré pour générer un itinéraire complexe qui inclut des produits hétérogènes tels que des vols, des hôtels, des locations de véhicules, des croisières, des attractions, et des produits d'assurances de voyage offerts par des fournisseurs multiples de types différents. L'itinéraire peut être défini dans un enregistrement de base de données ou un enregistrement de voyage qui procure un point central de stockage pour des données relatives au traitement de la transaction en ligne. [0020] Afin de permettre l'utilisation de différentes structures de paiement pour chaque produit dans l'itinéraire, des modes de réalisation de l'invention peuvent inclure un serveur de transactions qui traite les transactions pour l'achat et le remboursement d'itinéraires comprenant des produits qui ont été payés en utilisant différentes structures de paiement. Le serveur de transactions peut maintenir une base de données de transactions qui stockent des enregistrements de base de données ou des enregistrements de transaction, lesquels pistent les structures de paiement pour des itinéraires qui comprennent des produits pour lesquels le vendeur est le commerçant et les produits pour lesquels le fournisseur est le commerçant. La base de données de transactions peut permettre au serveur de transactions de déclencher des remboursements à l'acheteur de la part du fournisseur ou du vendeur, selon l'identité du commerçant du produit en question. [0021] Le traitement des remboursements du côté du fournisseur peut inclure l'annulation d'un produit réservé et/ou d'un contrat émis, ainsi que le déclenchement de paiements du fournisseur à l'acheteur. Le traitement des remboursements du côté du vendeur peut aussi inclure le déclenchement de paiements du vendeur à l'acheteur. Dans les deux cas, des transactions de remboursement peuvent être initiées par le serveur de transactions en réponse à la réception d'une demande de remboursement pour un itinéraire. Lorsqu'un remboursement de transaction est initié par le vendeur, le serveur de transactions peut gérer les remboursements à la fois du côté du fournisseur et du côté du vendeur pour tous les produits sélectionnés, et rembourser des 3048299 6 paiements du côté du vendeur qui peuvent être agrégés en une seule transaction par le système de paiement. [0022] Si un message d'erreur survient pendant le processus de remboursement, le serveur de transactions peut stocker l'état de cette transaction (par exemple, un état de remboursement pour chaque produit) dans l'enregistrement de transaction, mettre l'enregistrement de voyage en file d'attente pour un traitement ultérieur, et notifier le vendeur de l'erreur. Une fois que l'erreur a été résolue, le serveur de transactions peut reprendre le traitement du remboursement en interrogeant l'enregistrement de transaction concernant l'état de la transaction. [0023] Faisant maintenant référence à la fig.1, un environnement 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 ou plusieurs systèmes fournisseurs 16a à 16 n, une base de données de voyage 18, et un système de paiement 20. Chacun d'eux, le système OLTP 12, le système vendeur 14, les systèmes fournisseurs 16a à 16 n, la base de données d'enregistrements de voyage 18, et le système de paiement 20 peuvent communiquer par l'intermédiaire d'un réseau 22. Le réseau 22 peut inclure un ou plusieurs réseaux privés ou publics (par exemple, Internet) qui permettent l'échange de données entre les systèmes connectés au réseau 22. [0024] 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 pourvoyeur 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 société qui facture et reçoit le paiement pour le produit, et le pourvoyeur peut être une société qui délivre le produit. Dans certains cas, le fournisseur et le pourvoyeur peuvent être la même société, en ce cas les termes fournisseurs et pourvoyeurs peuvent être interchangeables. Ce serait le cas, par exemple, lorsqu'un transporteur procure une place assise sur un vol et facture l'acheteur lors de la réservation de la place assise. L'acheteur peut payer le vendeur pour le produit lorsque le vendeur est le commerçant, ou payer le fournisseur pour le produit lorsque le fournisseur est le commerçant. [0025] 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 3048299 7 distribution global, ou (Global Distribution System) (GDS), configuré pour faciliter la communication entre le système vendeur 14 et les systèmes fournisseurs 16a à 16n. Le GDS peut permettre aux agents de voyages, aux transporteurs émetteurs, ou à tout autre vendeur indirect, de faire des réservations sur les systèmes fournisseurs 16a à 16n par l'intermédiaire du GDS. Le GDS peut maintenir des liens vers les systèmes fournisseurs 16a à 16n par l'intermédiaire du réseau 22 qui permet au GDS d'acheminer les demandes de réservation en provenance du vendeur indirect vers 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. Les systèmes 16a à 16n peuvent inclure un système de réservation informatisé (CRS) qui permet au système OLTP 12 de réserver et de confirmer l'achat de produits de voyages. Les systèmes 16a à 16n peuvent aussi interagir avec d'autres systèmes fournisseurs 16a à 16n. [0026] 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 18 qui identifie le produit réservé. Ces données peuvent être maintenues dans un enregistrement de voyage qui comprend un ou plusieurs champs de données contenant le produit, le voyageur et toute autre information associée avec un ou plusieurs produits réservés faisant partie de l'itinéraire. Chaque enregistrement de voyage dans la base de données d'enregistrements de voyage 18 peut inclure des données définissant, pour un itinéraire de voyage en particulier, le voyageur ou le 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 18, un numéro de localisation ou autre identifiant approprié peut être associé à l'enregistrement de voyage. La base de données d'enregistrements de voyage 18 peut être procurée sur un système autonome ou peut faire partie d'un autre système tel qu'un CRS ou un GDS. [0027] Le système de paiement 20 peut être configuré pour traiter des formes de paiement liées à l'achat de produits par l'acheteur. Le système de paiement 20 peut inclure, ou être configuré pour, l'échange des données avec un ou plusieurs systèmes de banque, tels que le système de la banque émettrice et/ou le système de la banque acquérante, pour autoriser le paiement et le transfert de fonds de compte à compte. 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 20 peut 3048299 8 transmettre une demande d'autorisation à la banque émettrice qui peut être déterminée à partir du numéro d'identification d'émetteur sur la carte. En réponse à la demande d'autorisation, le système de la banque émettrice peut vérifier la validité du compte et vérifier que le compte 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 20 en indiquant que la transaction a été approuvée, refusée ou que plus d'information est nécessaire. [0028] Le processus de réservation d'un itinéraire peut inclure la vérification, auprès du système fournisseur correspondant 16a à 16 n, de la disponibilité des produits identifiés par l'itinéraire réservé, par exemple, la disponibilité de places assises sur un vol, de chambres libres dans un hôtel, etc. Cette vérification peut inclure l'envoi d'une demande de réservation à partir du système OLTP 12 au système fournisseur. Si les produits demandés sont disponibles, les produits peuvent être réservés, une confirmation de réservation peut être transmise par le système OLTP 12 et l'inventaire peut être ajusté dans la base de données inventaire pour refléter la réservation. Une fois que le voyageur a approuvé la transaction, l'acheteur peut effectuer le paiement au commerçant en facturant le compte de l'acheteur pour le prix des services. Dès la réception du paiement, la réservation peut être confirmée par le système du fournisseur. [0029] Faisant maintenant référence à la fig. 2, le système OLTP 12, le système vendeur 14, les systèmes fournisseurs 16a à 16n, la base de données des enregistrements de voyage 18, le système de paiement 20, et le réseau 22 de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, tels que l'ordinateur exemplaire 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 avec une ou plusieurs ressources extérieures 42 par l'intermédiaire du réseau 22 ou de l'interface 1/0. 38. Les ressources extérieures peuvent inclure, de façon non exhaustive, des serveurs, des bases de données, des dispositifs de mémoire de masse, des dispositifs périphériques, des services de réseau cloud, ou toute autre ressource informatique appropriée pouvant être utilisée avec l'ordinateur 30. [0030] Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : microprocesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques 3048299 9 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) basé sur des 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 de façon non exhaustive, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l'antémémoire ou tout autre dispositif capable de stocker des données. Le dispositif de stockage 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 données. [0031] 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 de l'ordinateur afin que le programme codé de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application tels 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 supprimé. Le ou plusieurs logiciels d'application peuvent inclure un cas de fonctionnement comportant un serveur pouvant accepter des requêtes de la part des applications clientes, ou leur apporter 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. [0032] L'interface I/O. 38 peut fournir une interface machine qui couple le processeur 32 de façon fonctionnelle avec d'autres dispositifs et systèmes, tels que le réseau 22 ou la ressource externe 42. Le serveur d'application 46 peut ainsi collaborer avec le réseau 22 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 repose sur les fonctions ou signaux fournis par d'autres composants de système ou de réseau externe à l'ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles il faut 3048299 comprendre que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieurement à 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 22. [0033] L'interface HMI 40 peut être couplée de façon fonctionnelle avec le processeur 32 de l'ordinateur 30 d'une manière connue pour permettre à un utilisateur d'interagir directement avec informatique 30. L'interface HMI 40 peut inclure un affichage vidéo ou une unité d'affichage à caractères, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. L'interface HMI 40 peut aussi inclure des dispositifs et des contrôles tels qu'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou entrées de l'utilisateur et de les transmettre dans le processeur 32. [0034] 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 de façon non exhaustive, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, une base de données orientée-objet, ou des combinaisons de celles-là. [0035] Un système de gestion de base de données sous forme de logiciel d'application qui est exécuté sous forme d'instructions sur le processeur 32, peut être utilisé pour accéder à l'information ou aux données stockées dans des enregistrements de la base de données 50 en réponse à une requête quand 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 des 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 relative aux bases de données dans certains cas, il faut comprendre que les modes de réalisation de l'invention peuvent utiliser n'importe quel modèle de gestion de base de données appropriée, et ne sont pas limités à un type particulier de base de données. 3048299 [0036] Faisant maintenant référence à la fig. 3. Le système OLTP 12 peut inclure un serveur de transactions 60, une base de données contextuelle 62, une base de données de transactions 64, et une base de données de règles 66. Le serveur de transactions 60 peut communiquer avec d'autres systèmes, tels que le système vendeur 14, les systèmes fournisseurs 16a à 16 n, la base de données d'enregistrements de voyage 18, et/ou le système de paiement 20. La base de données contextuelle 62 peut stocker l'information relative à chaque transaction gérée par le serveur de transactions 60 dans un enregistrement contextuel de transaction correspondant. L'information contextuelle dans la base de données contextuelle 62 peut permettre de maintenir la continuité pour un acheteur utilisant de multiples chaînes d'approvisionnement telles qu'un site web et ta n centre d'appel pour demander un remboursement et/ou pour résoudre un problème avec la transaction. L'information au niveau de la transaction, stockée dans l'enregistrement de transaction peut inclure un identifiant d'enregistrement pour l'enregistrement de voyage correspondant dans la base de données d'enregistrements de voyage 18, des données relatives à horodatage et les données relatives aux frais de gestion. Les données au niveau du produit peuvent inclure, pour chaque produit dans l'itinéraire, le type de produit (chambre d'hôtel, location de voiture, vol, etc.), le fournisseur du produit (par exemple, l'identité de la société ou de la franchise fournissant le produit), l'identité du commerçant (par exemple, l'identité du vendeur ou du fournisseur du produit), l'état actuel du produit (suppression imminente, suppression accomplie, erreur survenue, etc.) Un type d'erreur (par exemple, conditionnelle), les détails de paiement, le montant de la réservation, les montants de pénalité, le montant du tarif utilisé, et/ou le montant remboursable. [0037] Fig. 4 représente un organigramme illustrant un processus de détermination de paiement 70 qui peut être implémenté par le serveur de transactions 60. Dans le bloc 72, le processus 70 peut recevoir une demande pour le remboursement d'une partie ou de l'intégralité d'une transaction. La demande de remboursement peut inclure une liste des produits pour lesquels un remboursement est désiré, et qui peut être reçue par le système vendeur 14. Le système vendeur 14 peut transmettre la demande de remboursement en retour à un système utilisateur (par exemple, un agent de voyages ou un centre d'appel) qui initie le remboursement pour le compte du client. Le système vendeur 14 peut aussi transmettre la demande de remboursement en réponse à la demande de remboursement de l'acheteur par l'intermédiaire d'une interface accessible par le web, telle que le site d'une agence de voyages en ligne. Dans les 3048299 12 deux cas, le système vendeur 14 peut transmettre la demande de remboursement au serveur de transactions sous la forme d'un ou de plusieurs échanges informatisés de données pour l'administration, le commerce et le transport (EDIFACT), XML, or service de messagerie web. Ces messages peuvent être générés lorsque le système utilisateur entre des commandes cryptiques sur une interface de commande en ligne, ou en interagissant avec le système vendeur 14 par l'intermédiaire d'une interface utilisateur graphique (GUI). [0038] En réponse à la réception d'une demande de remboursement, le processus 70 peut débuter au bloc 74 et récupérer les conditions de remboursement et les pénalités du fournisseur pour chaque produit énuméré dans la demande de remboursement. Les conditions de remboursement et les pénalités du fournisseur peuvent être récupérées conformément avec une ou plusieurs règles stockées dans la base de données de règles 66. Par exemple, les conditions de remboursement et les pénalités du fournisseur peuvent être déterminées en interrogeant le système fournisseur 16 (par exemple, en demandant une transaction de remboursement et/ou des conditions tarifaires), sur la base des règles stockées dans l'enregistrement de transactions au moment où les produits ont été réservés, ou sur la base des règles stockées dans la base de données de règles 66 pour un fournisseur donné. [0039] Chaque fournisseur peut publier un tarif de pénalitéFS pour chaque produit. Ces frais de pénalité peuvent être appliqués individuellement à chaque produit, pendant le remboursement d'une transaction et ils peuvent être déduits du montant qui aurait autrement été remboursé au vendeur lorsque le vendeur est le commerçant pour la transaction de vente (par exemple, le vendeur a reçu le paiement de l'acheteur pour le produit) ou à l'acheteur si le fournisseur était le commerçant (c'est-à-dire, que le fournisseur a reçu le paiement pour le produit de la part de l'acheteur). [0040] Dans le bloc 76, le processus 70 peut récupérer pour chaque produit les frais de gestion du vendeur applicables individuellement à chaque produit. Les frais de gestion pour chaque produit Fp peuvent être un montant facturé par le vendeur pour le remboursement d'un produit particulier dans l'itinéraire en cours de remboursement. Les frais de gestion pour chaque produit Fp peuvent être appliqués par exemple, par le vendeur pour couvrir les coûts de traitement associés à la demande de remboursement. Les frais de gestion de chaque produit Fp peuvent être facturés en supplément de tous frais de pénalité facturés par tout fournisseur pour le remboursement de produits. Les critères qui peuvent être utilisés pour déterminer les frais de 3048299 13 gestion pour chaque produit peuvent inclure le type de produit (par exemple, vol, hôtel, forfait tout compris), la date de vente, la date de remboursement, le fournisseur, et/ou le pourvoyeur. [0041] Dans le bloc 78, le processus 70 peut récupérer tous frais de remboursement d'un vendeur qui peuvent être des frais applicables au niveau de la transaction. Les frais de remboursement du vendeur FR peuvent être des frais facturés par le vendeur pour le traitement de la demande de remboursement qui ne sont pas liés à un produit spécifique. Les critères qui pouvant être utilisés pour déterminer les frais de remboursement d'un vendeur peuvent inclure la date de vente et la date de remboursement. Par exemple, des frais de remboursement peuvent être appliqués à un remboursement demandé au-delà d'un certain nombre de jours après la date de vente. Dans un mode de réalisation de l'invention, les frais de remboursement du vendeur FR peuvent inclure les frais de gestion pour chaque produit Fp applicables au niveau du produit ; dans ce cas les frais de remboursement du vendeur FR peuvent être la somme des frais de gestion au niveau de la transaction et de plusieurs frais de gestion au niveau du produit. [0042] Dans le bloc 80, le processus 70 peut récupérer tous frais fixes de pénalité dont l'acheteur a été notifié au moment de la vente. Des frais fixes de pénalité FF peuvent définir un montant de pénalité auquel le vendeur s'engage en cas de remboursement d'un produit, quels que soient les frais de pénalité réels du fournisseur Fs pour le produit au moment du remboursement. Lorsqu'un remboursement est demandé, les frais fixes de pénalité FF peuvent être appliqués à l'acheteur sans tenir compte des frais de pénalité du fournisseur Fs, qui, dans le cadre d'un accord de pénalité fixe, peuvent être à la charge du vendeur. Au moment où l'acheteur demande un remboursement, les frais réels de pénalité d'un fournisseur, appliqués par les fournisseurs, peuvent être différents du montant des frais fixes de pénalité. Si la somme des frais de pénalité du fournisseur, appliquée par les fournisseurs, diffère de la somme des frais fixes de pénalité, le vendeur peut percevoir ou payer la différence entre les montants. Les critères utilisés pour déterminer les frais fixes de pénalité FF peuvent inclure le type de produit (vol, hôtel, forfait tour compris), la date de vente, l'identité du fournisseur, et/ou l'identité du pourvoyeur. Les règles identifiées par les critères peuvent fournir les conditions du vendeur, et le montant fixe de pénalité, qui peut être un pourcentage fixe de la valeur totale de la vente. [0043] Dans le bloc 82, le processus peut 70 peut déterminer le montant devant être remboursé au vendeur en qualité de commerçant Rsm. Lorsque des frais fixes de pénalité FF n'ont pas été communiqués à l'acheteur, les frais de pénalité du fournisseur FS peuvent être appliqués 3048299 14 sans condition au remboursement. Le montant devant être remboursé à l'acheteur Rachere'r et le montant devant être remboursé au vendeur R vendeur dans ce cas, peuvent être déterminés par les équations 1 et 2 : Racheteur = Pi- Fsi) - FR (Eq.1) LEST Rvendeur = (Pi - F51) - FR (Eq.2) iESm [0044] Où ST représente l'ensemble de tous les produits devant être remboursés (par exemple, l'itinéraire), Sm est l'ensemble des produits devant être remboursés pour lesquels le vendeur est le commerçant, Pi est le prix payé pour le produit i par l'acheteur, et Fsi représente les frais de pénalités du fournisseur Fs pour le produit i. Lorsque le commerçant ne peut être que le vendeur ou le fournisseur pour chaque produit, l'ensemble des produits pour lesquels le fournisseur est le commerçant Ss peut être donné par Sr - Sm). [0045] Lorsque les frais fixes de pénalité FF sont donnés au moment de la vente, il peut y avoir une comparaison avec les frais réels du fournisseur Fs pour déterminer si le vendeur a réalisé un bénéfice ou perdu de l'argent avec les frais fixes de pénalité FF. Le montant du gain Gr sur chaque produit /peut être déterminé par l'équation 3: Gi = FFI - Fsi Eq.3 En gardant à l'esprit que le gain Gi peut être négatif (c'est-à-dire, une perte) si les frais de pénalité du fournisseur Fs, dépassent les frais fixes de pénalité FF pour le produit i, le gain total G sur le remboursement peut être déterminé par l'équation 4: G= (Fpi - Fsi) Eq. 4 tEsT [0046] Les montants de Racheteur et R vendeur dans le scénario de pénalité fixe peuvent être déterminés en utilisant les équations 5 et 6 ci-dessous : Racheteur Pi - (Fsi + Gi) - FR (Eq.5) i EST i EST Rvendeur = Pi - Fsi + Gi) - FR + LFsi (Eq.6) LESm LEST LESp 3048299 [0047] Dans certains cas, le processus 70 peut déterminer qu'un nouveau paiement est nécessaire de la part de l'acheteur au vendeur, c'est-à-dire, lorsque la valeur de Rvendeur est négative. Ce peut être le cas, par exemple, lorsque le montant total des pénalités de remboursement appliqué au vendeur est supérieur à la somme des prix des produits. [0048] Une fois que les montants de Rvendeur et G ont été déterminés, le processus 70 peut avancer au bloc 84. Dans le bloc 84, le processus 70 peut récupérer des formes de paiement et envoyer les paiements. Les formes de paiement peuvent être récupérées à partir du système de paiement 20 sur la base de l'information stockée dans l'enregistrement de voyage au moment où les contrats sont émis pour les produits. Une fois que les formes de paiement ont été déterminées, le processus 70 peut envoyer les montants à rembourser en utilisant les formes de paiement, il peut résilier tout contrat émis dans les systèmes billettiques et/ou les réservations confirmées dans les systèmes de réservation, et il peut procurer un rapport de vente confirmant le remboursement au système de paiement 20. [0049] Fig. 5, est un organigramme financier exemplaire 90 qui illustre un scénario possible entre un acheteur 92 et un vendeur 94 (par exemple, une agence de voyages), et plusieurs fournisseurs 96, 98 et 100. Le fournisseur 96 peut être un transporteur qui vend une place assise sur un vol ayant le vendeur 94 en qualité de commerçant, le fournisseur 98 peut-être un autre transporteur aérien en qualité de commerçant pour une autre place assise sur un autre vol, et le fournisseur 100 peut-être un hôtel agissant en qualité de commerçant pour une chambre. [0050] Pour acheter les produits, l'acheteur 92 doit effectuer un paiement d'achat 102 (par exemple, $170) au vendeur 94 pour payer le produit fourni par le fournisseur 96. Du paiement d'achat 102, le vendeur peut conserver une majoration 104 (par exemple, $25) et des frais de gestion 106 (par exemple, $50). Le vendeur peut aussi effectuer un paiement d'achat 108 au fournisseur 96 égal au montant restant ($100) du paiement d'achat 102. L'acheteur 92 peut effectuer un paiement d'achat 110 (par exemple, $100) au fournisseur 98 pour payer le produit du fournisseur 98 lorsque le fournisseur 98 agit en qualité commerçant. L'acheteur 92 peut aussi effectuer un paiement d'achat 112 (par exemple, $200) au fournisseur 100 pour le produit du fournisseur 100 lorsque le fournisseur 100 agit en qualité de commerçant. Le montant total payé pour l'itinéraire par l'acheteur 92 peut-être la somme des paiements d'achat 102, 110 et 112 au vendeur 94 et aux fournisseurs 98 et 100, ou dans ce cas exemplaire : 3 04 82 9 9 16 Pacheteur = L Pi = $170 + $100 + $200 = $470 (Eq.7) LEST [0051] Fig. 6, est un organigramme financier exemplaire 120 qui illustre un scénario possible entre l'acheteur 92, le vendeur 94, et les fournisseurs 96, 98 et 100 pour un remboursement que le vendeur est autorisé à majorer avec des frais de remboursement de vendeur FR. Le fournisseur 96 peut effectuer un paiement de remboursement 122 (par exemple, $70) au vendeur 94 égal au montant du paiement d'achat 108 (par exemple, $100), moins les frais de pénalité du fournisseur Fs (par exemple, $30) appliqués par le fournisseur 96. Le vendeur 94 peut appliquer les frais de remboursement de vendeur FR (par exemple, $20) et peut effectuer un paiement de remboursement pour le montant restant (par exemple, $50) à l'acheteur 92. Les fournisseurs qui étaient les commerçants 98 et 100, peuvent effectuer des paiements de remboursement 126 et 128 à l'acheteur 92. Le montant du paiement de remboursement 126 (par exemple, $80) peut-être égal au montant du paiement d'achat 110 (par exemple, $100), moins les frais de pénalité du fournisseur Fs (par exemple, $20). Par contraste, si en cas d'annulation, le fournisseur 100 ne facture pas de frais de pénalité, le montant du paiement de remboursement 128 (par exemple, $200) peut être égal au montant du paiement d'achat 112 (par exemple, $200). En supposant que les frais de gestion 106 (par exemple, $50) ne soient pas remboursables et en utilisant les valeurs exemplaires de l'exemple ci-dessus, l'acheteur 92 recevrait un remboursement total de : R acheteur = $50 + $80 + $200 = $330 [0052] Dans certains cas, les produits forfaitaires tout compris peuvent être vendus avec des conditions d'après-vente, définies par le vendeur 94 qui sont indépendantes des frais de pénalité du fournisseur Fs. Par exemple, lorsqu'une politique de remboursement pour les produits décrits dans la fig.6 inclut des frais fixes de pénalité FF égaux à 15 % du montant total payé par l'acheteur, hormis les frais de gestion 106, le montant fixe de pénalité FF, en utilisant les valeurs de l'exemple ci-dessus, serait de: FF= 0,15 x ($470 - $50) = $63 Dans ce scénario, le montant serait le montant des frais fixes FF facturés à l'acheteur 92 par le vendeur 94, quel que soit le montant des frais de pénalité du fournisseur Fs,. [0053] En utilisant les mêmes valeurs monétaires exemplaires ci-dessus, le fournisseur 96 effectue un paiement de remboursement 122 (par exemple, $70) au vendeur 94 et les 3048299 17 fournisseurs 98 et 100 effectuent des paiements de remboursement 126 et 128 (par exemple, $80, $200) à l'acheteur 92. Puisque le montant du remboursement total à l'acheteur Racheieur est égal à P acheteur - FR - FF, le montant de R acheteur dans cet exemple serait de : $470 - $50 - $63 = $357. Puisque l'acheteur 92 reçoit un total de $280 de la part des vendeurs 98 et 100, le montant du paiement de remboursement 124 dans cet exemple serait de $357 - $280, c'est-à-dire $77. [0054] Fig. 7, est un organigramme du processus de remboursement 130 pouvant être implémenté par le serveur de transactions 60 pour orchestrer un remboursement de l'itinéraire. Dans le bloc 132, le processus peut déterminer l'identité du marchand, le montant, et la source du paiement de remboursement pour chaque produit de l'itinéraire comme cela a été décrit ci-dessus. Une fois que les identités des commerçants, les montants, et les sources des paiements de remboursement ont été déterminés dans le bloc 132, le processus 130 peut avancer au bloc de l'itinéraire 134 et transmettre les demandes de remboursement aux fournisseurs des produits dans l'itinéraire. Dans un mode de réalisation de l'invention, le processus 130 peut uniquement transmettre des demandes de remboursement aux fournisseurs pour lesquels le vendeur est le commerçant. Pour ce mode de réalisation, les remboursements du côté du fournisseur peuvent être gérés par le serveur de transactions 60 (par exemple, pour des produits dont le vendeur est le commerçant) ou peuvent être délégués à un pourvoyeur externe (par exemple, pour des produits dont le fournisseur est le commerçant). [0055] En réponse à la réception des paiements de remboursement de la part de chaque fournisseur d'un produit dans l'itinéraire dont le vendeur est le commerçant, et à la réception d'une confirmation que les produits respectifs ont été annulés par les fournisseurs, le processus 130 peut avancer au bloc 136. Dans le bloc 136, le processus 130 peut déclencher des paiements de remboursement de la part du vendeur à l'acheteur pour les produits dont le vendeur est le commerçant. Le processus 130 peut déclencher des paiements de remboursement en transmettant les demandes de remboursement au système de paiement 20, ce qui peut amener des paiements à être effectués à partir d'un compte du vendeur sous une forme de paiement utilisée par l'acheteur pour acheter les produits en question. En réponse à la réception des paiements de remboursement de la part de chaque fournisseur, le processus 130 peut avancer au bloc 138. [0056] Dans le bloc 138, le processus 130 peut rapprocher le paiement du remboursement reçu de la part des fournisseurs avec les paiements effectués en faveur de l'acheteur en guise de remboursement. Dans ce but, le processus 130 peut créer un « élément de remboursement 3048299 18 financier » (RFI) dans la base de données de transactions 64 qui peut stocker les détails des remboursements calculés et/ou récupérés au moment où la demande de remboursement a été reçue. Chaque RFI peut être associé avec une forme de paiement d'un vendeur qui peut être la forme de paiement utilisée pour régler les comptes des vendeurs. La forme de paiement du vendeur peut être définie dans l'enregistrement de voyage et peut définir le montant du paiement et la méthode de paiement applicable au remboursement. [0057] Fig. 8, est un diagramme du sous-processus de remboursement 140 qui peut être implémenté sur le serveur de transactions 60 pour traiter les paiements de remboursement des fournisseurs au vendeur. Dans le bloc 142, le sous-processus 140 peut sélectionner un fournisseur auquel il va demander un remboursement. Le fournisseur peut être sélectionné à partir d'une liste de fournisseurs de produits dans l'inventaire pour lesquels le vendeur était le commerçant. Une fois que le fournisseur a été sélectionné, le sous-processus 140 peut avancer au bloc 144. [0058] Dans le bloc 144, le sous-processus 140 peut transmettre une demande de remboursement au fournisseur sélectionné. En réponse, le système fournisseur 16a à 16n, peut traiter la demande de remboursement en déclenchant un paiement pour rembourser le vendeur, et en annulant toute réservation ou tout contrat émis pour le produit en question. Si le processus reçoit la confirmation que la demande de remboursement a été traitée (branche « OUI » du bloc de décision 146), le sous-processus 140 peut avancer au bloc 148 et mettre à jour l'enregistrement de voyage pour refléter le fait que le produit a été remboursé. Cette mise à jour peut inclure par exemple, le changement du produit dans l'enregistrement de voyage qui passe de l'état « réservé » oû « billet émis » à l'état « annulé » ou « remboursé ». [0059] Lorsque le fournisseur est le dernier fournisseur dans l'itinéraire devant être traité (branche « OUI » du bloc de décision 150), le sous-processus 140 peut prendre fin. Si d'autres fournisseurs doivent effectuer un remboursement (branche «NON » du bloc de décision 152), le sous-processus 140 peut avancer au bloc 152, sélectionner le fournisseur suivant et revenir au bloc 144. [0060] Dans certains cas, le sous-processus 140 peut rencontrer une erreur ; dans ce cas, le processus de remboursement peut être interrompu. Par exemple, si le système fournisseur 16a à 16n ne peut confirmer le traitement réussi d'une demande de remboursement (branche «NON » du bloc 146), le sous-processus 140 peut procéder au bloc 154. Dans le bloc 154, le processus 3048299 19 140 peut mettre l'enregistrement de voyage, correspondant à l'itinéraire comprenant le produit devant être remboursé, en file d'attente. La mise en file d'attente dans l'enregistrement de voyage peut provoquer l'envoi d'une notification au système vendeur 14 indiquant que le processus 130 a rencontré une erreur et a besoin d'attention. L'erreur peut ensuite être corrigée par un agent du centre d'appel par exemple, qui peut mettre à jour l'enregistrement de voyage en conséquence. [0061] Dans le bloc 156, le sous-processus 140 peut mettre à jour ou créer un enregistrement dans la base de données de transactions 64. Cet enregistrement peut stocker les données de transaction qui définissent l'état de la transaction. Par exemple les données de transaction peuvent indiquer quels produits dans l'enregistrement de voyage correspondant ont été remboursés, quels produits ont encore besoin d'être remboursés et quel produit a déclenché l'erreur. Une fois que l'enregistrement de voyage a été mis en file d'attente et que la base de données de transactions a été mise à jour, le sous-processus 140 peut prendre fin. [0062] Afin de faciliter la correction d'une erreur, le système vendeur 14 peut rechercher un enregistrement de transaction correspondant en interrogeant la base de données de transactions 64 et peut afficher l'information pour informer l'agent de la raison de l'échec de la demande de remboursement. Dans un mode de réalisation de l'invention, le serveur de transactions 60 peut inclure un portail web qui procure une interface utilisateur permettant d'accéder à la base de données de transactions 64 [0063] L'agent peut récupérer l'enregistrement de transaction pour l'itinéraire, déterminer l'état de la demande de remboursement qui a causé l'erreur et mettre à jour l'enregistrement de voyage. En réponse à la réception d'une demande concernant l'état de la transaction, le portail web peut renvoyer une liste de produits qui font partie de la transaction, les produits déjà remboursés, le produit ou l'étape qui a fait échouer la dernière demande de remboursement (le cas échéant) et tout message d'erreur renvoyé par les systèmes impliqués dans la demande de remboursement. Cette information peut permettre à l'agent, soit de corriger les données manquantes et/ou corrompues qui ont causé l'échec de la transaction ou de déclencher un remboursement pour le produit manuellement. L'agent peut aussi signaler un produit dans l'enregistrement de transaction afin que le serveur de transactions saute la demande de remboursement pour le produit signalé. Le signalement d'un produit pour lequel un remboursement a échoué peut permettre au processus de remboursement de continuer pour tout produit restant dans l'itinéraire. Dans les cas où le remboursement est déclenché manuellement, 3048299 l'agent peut signaler le produit pour indiquer son remboursement dans l'enregistrement de transactions et/ou dans l'enregistrement de voyage. Une fois que l'agent a corrigé ou ignorer la cause de l'erreur, l'agent peut amener le système vendeur 14 à envoyer une demande de reprise au système de transactions 60 demandant au système de transactions 60 de continuer le processus de remboursement à partir du point où le processus s'était arrêté. [0064] Fig. 9, est un organigramme d'un processus de reprise 160 qui peut être implémenté par le serveur de transactions 60 pour reprendre le processus de remboursement ayant été interrompu en raison d'une erreur. En réponse à la réception d'une demande de reprise dans le bloc 162, le processus 160 peut avancer au bloc 164 et interroger la base de données de transactions 64 concernant l'état de la transaction. En réponse à la réception de la requête, la base de données de transactions 64 peut localiser l'enregistrement de transaction correspondant à la transaction en question, et renvoyer des données indiquant l'état de la transaction. [0065] Dans le bloc 166, le processus 160 peut déterminer si le dernier produit ayant causé l'erreur est signalé comme étant remboursé, ou s'il est signalé comme ayant été ignoré. Lorsque le produit est ainsi signalé (branche « OUI » du bloc de décision 166), le processus 160 peut avancer au bloc 168 et sélectionner le fournisseur suivant dans la liste des fournisseurs de produits pour lesquels le vendeur est le commerçant. Le processus 160 peut alors avancer au bloc 170 et reprendre le processus de remboursement tel qu'il est décrit ci-dessus dans la fig. 8. Lorsque le dernier produit n'est pas signalé (branche « NON» du bloc de décision 166), le processus 160 peut avancer au bloc 172, sélectionner le dernier produit et avancer au bloc 170. [0066] En général, les routines exécutées pour mettre en oeuvre les modes de réalisation de l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme « programme codé informatique » ou simplement «programme codé. » Un programme codé comporte typiquement des instructions déchiffrables par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur, et qui lorsqu'elles sont déchiffrées et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l'ordinateur à effectuer des d'opérations nécessaires à l'exécution d'opérations et/ou d'éléments propres à la mise en oeuvre des aspects variés des modes de réalisation. Les instructions déchiffrables par ordinateur d'un programme, servant à effectuer les opérations des 3048299 21 modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, ou, soit un code source soit un code objet écrit en combinaison avec un ou plusieurs langages de programmation. [0067] Divers programmes codés décrits dans les présentes peuvent être identifiés selon l'application dans laquelle ils sont implémentés dans les modes de réalisation spécifiques de l'invention. Cependant, on remarquera que toute nomenclature d'un programme particulier qui suit est utilisée uniquement par commodité ; ainsi l'invention ne peut être limitée à 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 routines, des procédures, des méthodes, des modules, des objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels qui résident dans un ordinateur typique (par exemple, les systèmes d'exploitation, les bibliothèques, les APIs, les applications, les applets, etc.), on remarquera que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique de fonctionnalités de programme décrites dans les présentes. [0068] Le programme codé mis en oeuvre dans toute application/module décrite dans les présentes peut-être distribué individuellement ou collectivement comme un produit programme sous une variété de formes. En particulier, le programme codé peut être distribué en utilisant un médium de stockage déchiffrable par ordinateur disposant d'instructions de programme, déchiffrables par ordinateur en lui-même permettant à un processeur d'effectuer des aspects des modes de réalisation de l'invention. [0069] Les supports de stockage déchiffrables par machine, qui sont intrinsèquement non transitoires, peuvent inclure des médias tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans toute méthode ou technologie de stockage de données, telles que des instructions de programme déchiffrables par machine, des structures de données, des modules de programme, ou autres données. Les supports de stockage déchiffrables par ordinateur peuvent aussi comprendre des mémoires RAM, ROM, EPROM (mémoire à lecture exclusivernent;programmable et effaçable), une mémoire flash, ou toute technologie de support solide de mémoire, CD-ROM (disque compact portable doté d'une mémoire à lecture seule), ou tout autre stockage optique, bandes d'enregistrement magnétique, mémoire à disque magnétique, 3048299 22 ou tout autre médium pouvant être utilisé pour stocker les données désirées, et qui est apte à être déchiffré par un ordinateur. Un support de stockage déchiffrable par ordinateur ne peut être interprété comme « des signaux transitoires » en soi (par exemple, des ondes radio ou toute autre onde électromagnétique se propageant à travers un support de transmission telle qu'un guide d'ondes, ou des signaux électriques transmis par câble). Les instructions de programme déchiffrables par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage déchiffrable par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau. [0070] Les instructions de programme déchiffrables par ordinateur, stockées dans un support déchiffrable par ordinateur, d'autres types d'appareil programmable de traitement de données, ou d'autres dispositifs pour fonctionner d'une façon particulière, telles que les instructions stockées sur un support déchiffrable par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme d'ordinateur peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général, à un ordinateur dédié, ou à un autre appareil programmable de traitement de données pour produire une machine tel que des instructions qui, lorsqu'elles sont exécutées à l'aide du ou des processeurs, accomplissent une série de calculs pour implémenter les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs. [0071] Dans certains autres modes de réalisation, les fonctions, les actions et/ou des opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou des diagrammes blocs peuvent être commandées à nouveau, traitées en série, et/ou traitées 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 tout en restant conformes avec les modes de réalisation de l'invention. [0072] 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 s'il en est 3048299 23 indiqué autrement et clairement par le contexte. Par ailleurs, les termes « comprend », « comprennent » et/ou « comprenant » lorsqu'ils sont utilisés 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'un ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes en cela. De plus, dans la mesure où les verbes « inclure », « comporter » « ayant », « a », « possède », « dispose de » et « composé de », ou des variantes, sont utilisés dans la description détaillée des revendications, ces termes sont censés être inclusifs de façon similaire au verbe « comprendre ». [0073] Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il n'est pas de l'intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, l'étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles 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 illustrateurs 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 de l'appliquant. REVENDICATIONS1. Un système de traitement de transaction en ligne comprenant : un ou plusieurs processeurs ; et une mémoire en communication avec un ou plusieurs processeurs, la mémoire stockant un programme codé configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à : recevoir une demande de remboursement identifiant un premier enregistrement de base de données qui définit un itinéraire, un premier produit dans l'itinéraire devant être remboursé, et un second produit dans l'itinéraire devant être remboursé ; récupérer, à partir du premier enregistrement de base de données, les premières données qui définissent un commerçant pour le premier produit qui est le fournisseur du premier produit, un vendeur qui est le commerçant pour le second produit, et un second paiement effectué par l'acheteur au commerçant pour le second produit ; et déterminer, sur la base des premières données, un premier montant devant être remboursé à l'acheteur par le vendeur, un second montant devant être remboursé à l'acheteur par le fournisseur du premier produit, et un troisième montant devant être remboursé au vendeur par le fournisseur du second produit. 2. Le système selon la revendication 1 dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à récupérer une ou plusieurs règles qui définissent une première condition devant être satisfaite par le fournisseur du premier produit afin de rembourser le premier produit ; récupérer une ou plusieurs secondes règles qui définissent une seconde condition devant être satisfaites par le fournisseur du second produit afin de rembourser le second produit ; et récupérer une ou plusieurs troisièmes règles qui définissent une troisième condition devant être satisfaite par le vendeur afin de traiter la demande de remboursement, dans lequel le premier montant, le second montant, et le troisième montant sont par ailleurs déterminés sur la base d'une ou de plusieurs premières règles, d'une ou de plusieurs secondes règles et d'une ou de plusieurs troisièmes règles. 3048299 25 3. Le système selon la revendication 2 dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à récupérer une ou plusieurs troisièmes règles comprend : pour chacun des premiers et seconds produits, la récupération d'une ou de plusieurs quatrièmes règles qui définissent les premiers frais facturés par le vendeur pour rembourser le premier produit ou le second produit pour lesquels une ou plusieurs quatrièmes règles sont en cours de récupération et la récupération d'une ou de plusieurs cinquièmes règles qui définissent des seconds frais facturés par le vendeur pour traiter la demande de remboursement, dans laquelle une ou plusieurs troisièmes règles comprennent une ou plusieurs quatrièmes règles et une ou plusieurs cinquièmes règles. 4. Le système selon la revendication 2 dans laquelle : la première condition comprend au moins des premiers frais qui sont facturés par le fournisseur du premier produit ou d'une de l'une ou plusieurs premières qui sont appliquées par le fournisseur du premier produit, et la seconde condition comprend au moins l'un des seconds frais qui sont facturés par le fournisseur d'un second produit ou l'une d'une ou plusieurs des secondes règles appliquées par le fournisseur du second produit. 5. Le système selon l'une quelconque des revendications 1 à 4 dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à orchestrer un remboursement en : provoquant le transfert du premier montant du vendeur à l'acheteur ; provoquant le transfert du second montant du fournisseur du premier produit, à l'acheteur ; et en provoquant le transfert du troisième montant du fournisseur du second produit, au vendeur. 6. Le système selon l'une quelconque des revendications 1 à 5 dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à: 3048299 26 récupérer les secondes données à partir d'un second enregistrement de base de données, les deuxièmes données définissant une ou plusieurs formes de paiement utilisées pour effectuer le premier paiement et une ou plusieurs secondes formes de paiement utilisées pour effectuer le second paiement, dans lequel un ou plusieurs comptes de l'acheteur vers lesquels un premier montant et un second montant sont transférés, sont déterminés sur la base d'au moins en partie une ou plusieurs premières formes de paiement et une ou plusieurs secondes formes de paiement. 7. Le système selon l'une quelconque des revendications 1 à 5 dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à: en réponse à la détermination qu'une erreur est survenue, stocker les secondes données dans un second enregistrement de base de données, les secondes données définissant l'état de la demande de remboursement ; mettre en file d'attente le premier enregistrement de base de données ; et suspendre le traitement de la demande de remboursement. 8. Le système selon la revendication 7 dans laquelle les secondes données définissent l'état du traitement de la demande de remboursement en identifiant au moins un premier produit, un second produit, l'état de remboursement pour chaque produit, le produit ou le processus qui a déclenché l'erreur, et le type d'erreur. Le système selon les revendications 7 ou 8 dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à: en réponse à une demande de reprise, récupérer les secondes données dans un second enregistrement de base de données ; exécuter une commande provoquée par la demande de reprise afin de corriger ou d'ignorer la cause de l'erreur ; et reprendre le traitement de la demande de remboursement sur la base des secondes données. 3048299 27 10. Le système selon la revendication 9 dans laquelle la cause de l'erreur est un manquement de la part du fournisseur du premier produit ou du second produit, de répondre à une demande de transfert pour transférer le second montant à l'acheteur ou le troisième montant au vendeur, et dans lequel le programme codé est configuré de sorte que lorsqu'il est exécuté par un ou plusieurs processeurs, il amène le système à exécuter la commande pour corriger ou ignorer la cause de l'erreur en : sautant le traitement d'une portion du remboursement associée au fournisseur qui n'a pas répondu à la demande de transfert. 11. Un programme d'ordinateur qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène un ou plusieurs processeurs à : recevoir une demande de remboursement identifiant un enregistrement de base de données qui définit un itinéraire, un premier produit dans l'itinéraire devant être remboursé, et un second produit dans l'itinéraire devant être remboursé ; récupérer, à partir de l'enregistrement de base de données, de données définissant un commerçant pour le premier produit qui est le fournisseur du premier produit, un premier paiement effectué par un acheteur au commerçant pour le premier produit, un vendeur qui est le commerçant pour le second produit, et un second paiement effectué par l'acheteur au commerçant pour le second produit ; et déterminer, sur la base des données, un premier montant devant être remboursé à l'acheteur par le vendeur, un second montant devant être remboursé à l'acheteur par le fournisseur du premier produit et un troisième montant devant être remboursé au vendeur par le fournisseur du second produit.